Hlavní navigace

Vlákno názorů ke článku Problémy optimalizace SQL dotazů a jejich teoretická řešení od Jan - Možná jsem ze staré školy, ale stále dělám...

  • 25. 2. 2020 8:53

    Jan

    Možná jsem ze staré školy, ale stále dělám nad databází CRUD operace, kde funguje selská logika optimalizaze. Nezpracovávám nějaká našmírovaná data, ani big data (což je možná totéž), ale jen ty, která uživatel zadal.
    Proto je řešením to co píšete v úvodu, za prvé, mít v pořádku statistiky. Za druhé, po nějaké době provozu aplikace, dejme tomu po půl roce provozu, je potřeba všechny SQL commandy zrevidovat. Tabulky jsou reálně zaplněné s produkčními záznamy a teď je teprve potřeba se pořádně podívat, co drhne.
    Základem jsou samozřejmě správné indexy - pořád stará písnička - a nemít je naopak u sloupců s malou selektivitou. U CRUD pro nějakou běžnou evidenci jsou indexy zpravidla dostačující. Samozřejmě, přepokládám nízke kardinality, jeden zaměstnanec má jednu až dvě adresy, 0 - 3 děti (orientačně cca do čísla 10 je jedno kolik), atd...
    Pro mé účely jsou tedy adaptivní algoritmy cestou, kterou nechci jít, neboť si myslím, že je dobré datům rozumět a nechci se dostat do situace, že mi algoritmus již nepomůže a já jako programátor nebudu vědět co s tím.

  • 25. 2. 2020 10:26

    Standa

    Souhlasim s tebou, ale to vse lze poradne delat kdyz je dobre zanalyzovano, dobre udelana normalizace a celkove dobre navrzena databaze. Bohuzel v dnesni uspechane dobe casto DB delaji "programatori" (bohuzel casto z java prostredi), kteri o DB nemaji moc poneti a chteji ji vyuzivat jen jako uloziste ktere se ma samo i vsechno postarat. Tudiz nejake vztahy mezi entitama moc neresi a je z toho chaos. Tam musi nastoupit bud hloubkovy refaktoring (na ktery neni cas, penize a lidi) a nebo ta DB musi umet vestit z kristalove koule (viz techniky z clanku)
    Take je to neco jineho u aplikaci ktere vyuzivaji metamodely, tam casto nastupuje i to ze bussiness nedokaze specifikovat pozadavky a tak v prubehu zivota aplikace se rozlozeni a vzathy mohou docela dost lisit.

  • 25. 2. 2020 10:30

    Miroslav Šilhavý

    To se přeci vůbec nevylučuje. Data máte v databázi normalizovaná (např. tabulka rodičů <-reference tabulka dětí). U dětí máte evidovaný věk, pohlaví.

    Když potřebujete zjistit, kteří rodiče mají aspoň jedno dítě pod osmnáct let, je situace ještě triviální.
    Ve chvíli, kdy budete potřebovat složitější operace - např. najdi rodiče, kteří mají aspoň tři děti a aspoň jedno je mladší než osmnáct let, tak už se nabízí víc postupů, jak se k výsledku dostat. Např. nejdříve vyhodnotíte podmínku jednoho dítěte <18 a poté zjistíte počet dětí; nebo to vyhodnotíte v opačném pořadí. U složitějších dotazů se začne nabízet násobně více postupů (query plans) vedoucích ke stejnému výsledku.

    Pokud je v něčem síla moderních SQL databází, tak je to právě v tom, že Vám:
    1. umějí odhalit úzká hrdla (EXPLAIN [ANALYZE]),
    2. umějí odhalit rozdíl odhadů, které vycházejí ze statistik vs. realita (EXPLAIN vs. EXPLAIN ANALYZE),
    3. dají nástroje (INDEX, CLUSTER, PARTITION BY, ...) kterými nastavíte správnou cestu na vykonání dotazu

    Přesně jak Pavel psal, a do kamene tesat: SQL dotaz definuje výsledek – nikoliv způsob, jak se k žádanému výsledku dostat. Vůbec se to však nevylučuje s tím, že máte v ruce všechny nástroje, jak data v databázi správně nastavit. Úprava dotazů není tou cestou - správný server SQL by měl i odlišné dotazy, ale dávající stejný výsledek vnitřně vykonat totožně.

  • 25. 2. 2020 10:37

    Pavel Stěhule

    CRUD je v podstatě OLTP a tam jednak se většinou nepracuje s extrémně velkými daty (tabulky - nad desítky GB) a nedělají se ani moc velké analýzy. Tam stávající systémy fungují docela dobře. Popisované problémy jsou primárně na OLAPu případně na větších datech s ORM.

    Když máte stovky tisíc různých SQL dotazů, tak tam to ručně nejde dělat. Takových problémových (a takhle velkých) aplikací je ale minimum (a zvlášť, když bych to vztáhl na republiku).

  • 25. 2. 2020 23:07

    Jan

    Já vám neodporuji (a ani není čemu, neboť neuvádíte, jaký typ úloh řešíte, v článku se nezmiňujete).
    Z mého pohledu je i velký počet tabulek v rámci jednolitého systému nesmysl, hovoří se pak o mikroslužbách, kde každá dělá dobře svoji práci nad omezeným množstvím tabulek a tím pádem ani operací není tolik, viz např. https://www.root.cz/clanky/mikrosluzby-zalozene-na-rest-api/
    Tady se pohybuji já.