Hlavní navigace

Vlákno názorů k článku Na co si dát pozor při návrhu databáze? od Palo - To su same vyborne rady. Nepouzivajte JOINY v...

  • Článek je starý, nové názory již nelze přidávat.
  • 16. 11. 2016 7:13

    Palo (neregistrovaný) ---.rainside.sk

    To su same vyborne rady. Nepouzivajte JOINY v relacnej databaze a nepouzivajte funkcie nad stlpcami. Skvele, zmenim koli tomu specifikaciu systemu a klientovi poviem ze by ten vypocet uzavierky bol pomaly tak ju radsej nebudeme robit.
    A samozrejme vsetko si drzte v 4NF cokolvek ine je uz denormalizovane. Uzivatelom dajte len jednoduche nahlady (nejoinovat) oni si to nejako pospajaju v hlave alebo ved na co im je ten excel.
    Nie je postup skor opacny ze mam problem a MUSIM ho nejako vyriesit nie sa mu vyhnut? A preto je niekedy dobrym riesenim 'predpocitany' (denormalizovany) stlpec. JOIN cez unikatny dostatocne maly kluc (integer ako unikatny surrogate key) je absolutne rychla zalezitost. A to sme sa nedostali este ani k duplikovaniu udajov z dovodu rozdelenia domenovej logiky. Alebo triky akymi sa vyhnut v multithreadingu dead lockom alebo ako minimalizovat write locky a ako prisposobit databazu takemuto druhu spracovania.
    Cely vyvoj databazy je riadeny logikou, nemozem uvazovat iba nad strukturami (domenou) ale aj na funkciami a sposobom akym sa tieto udaje spracovavaju (busines logika). Frekvenciou ich citania, modifikacie a pridavania. Tieto faktory ovplyvnuju akou optimalizacnou strategiou sa rozhodnem ist no a v kazdom pripade nezabudajme na predcasnu optimalizaciu, to je uplne to najhorsie co mozete urobit. Takze priklad so zamestnancami je uplne jedno ako urobite lebo ak ich bude okolo 5.000 a tu najvacsie organizacie v nasich koncinach tak to bude v relacnej DB rychle aj ked to urobite so vsetkymi antipaternami spomenutymi v tomto clanku.
    Clanok mozno pre zaciatocnika s SQL dobry ale trochu odtrhnuty od praxe. Ak som to prehnal prepacte snazil som sa byt konstruktivny.

  • 16. 11. 2016 7:27

    pb. (neregistrovaný) 2001:470:6f:----:----:----:----:----

    Předpokládám, že ten příklad se zaměstnanci byl uvedený opravdu jen jako jednoduchý, snadno pochopitelný příklad. Nečekal bych, že to někdo vezme tak doslova.

    Taky už jsem dělal databázi, u které jsem si říkal, že tam bude jen pár tisícovek záznamů, protože přece i ty největší organizace v našich končinách nemají více než 5000 zaměsnanců, ale pak se z toho vyvinula evidence obyvatel na evropské úrovni (neberte mě zase TAK doslovně - nebyla to evidence lidí).

    K funkcím "nad stĺpcami":

    select * from data where time > '2016-11-17' and time < '2016-11-18';
    50 msecs

    select * from data where date(time) = '2016-11-17';
    Běží dosud, prohledává sekvenčně miliardu záznamů. Musím to za chvíli zabít, za chvíli mi začnou volat, že něco není v pořádku.

  • 16. 11. 2016 7:57

    Palo (neregistrovaný) ---.rainside.sk

    Mozno som bol po ranu precitlively :-). Treba ale zdoraznit ze optimalizovat sa oplati skutocne iba nad skutocne VEEEELKYMI udajmi. Radovo GB dat dnesne stroje zjedia ako nic. Pamatam ze udaje v SAPe jedneho podniku mali 3GB po 2 rokoch pouzivania, v dnesnej dobe by to utiahlo PC za par tisic. Ja dam tiez nieco:
    accledgertrans - 150990 zaznamov
    Testovaci stroj nejaky normalny server s 30timi virtualmi:
    > select count(*) from accledgertrans where createddate between '2016-07-01' and '2016-07-30'
    Elapsed time (seconds) - Total: 0.045, SQL query: 0.044
    > select count(*) from accledgertrans where date(createddate) between '2016-07-01' and '2016-07-30'
    Elapsed time (seconds) - Total: 0.137, SQL query: 0.137

    No a prave minuly tyzden sme optimalizovali po 3 rokoch intenzivneho pouzivania databazu. Klient si zacat stazovat ze uz sa to prilis spomalilo. Az po 3 rokoch konecne maju dost udajov a mozeme sa pozriet na dotazy ktore naozaj pouzivaju aby sme ich mohli analyzovat. Nemalo zmysel robit to pred 3mi rokmi. Toto zvladlo zopar indexov, ale robili sme uz aj komplet prerobenie logiky koli optimalizacii. Ano aj to sa robi ale az potom ako mam skutocne udaje a skutocne dotazy. Klientovi sa aj tak neda verit, v case analyzy ani sam netusi kolko tych udajov bude.

  • 16. 11. 2016 8:20

    pb. (neregistrovaný) 2001:470:6f:----:----:----:----:----

    Souhlasím s tím, že je celkem zbytečné nějak výrazně optimalizovat databázi dříve, než se v ní objeví dostatečné množství dat. Databáze se někdy chovají na první pohled dost chaoticky a čas strávený dotazem může na objemu dat záviset velmi nelineárně.

    Předpokládám ale, že tento článek měl být varováním před něčím jiným, než před předčasnou optimalizací. Velkou část těch situací v článku uvedených jsem si prožil a dnes už tak nějak podvědomě tuším, kudy cesta nevede. Mé dnešní databázové návrhy jsou často poznamenané snahou vyhnout se situacím v článku.

    Dneska už na podobně věci myslím už při návrhu aplikace. Spoustu věcí dnes dělám v databázi Sqlite pro PC, Raspberry a podobné stroje - tam to může být kritické i při pár stovkách tisíc záznamů.

    Množství a šíře problémů, které se řeší pomocí databází, je mnohem větší, než si my dva dovedeme představit. Myslím si proto, že je dobře, když se s námi někdo podělí o svoje zkušenosti, byť se nám mohou jevit jako banality.

  • 16. 11. 2016 9:45

    Pavel Stěhule

    Úprava schématu je drahá - pokud se jednou schéma navrhne špatně, tak je to nadlouho. A přitom si stačí pamatovat a respektovat pár jednoduchých doporučení.
    Bohužel velká většina, téměř všechny problémy s databázemi jsou způsobené nějakou banalitou. Živím se jako databázový konzultant, a člověk si už kolikrát připadá jak v jednom nonstop dejavu. Opravdu originálních problémů je promile - ale pak to stojí za to (low level problémy v zámcích kernelu nebo Postgresu). Téměř všechno, s čím se obyčejně a často setkávám jsou banality - bohužel některé z nich nelze za rozumné náklady opravit.
    Někdy je to o to smutnější, že nepochopené banální problémy dokopali uživatele, i vývojáře do bizarních řešení a ještě do větších problémů. Proto jsem to tady napsal - je to absolutní minimum - co by si každý z IT mohl zapamatovat.

  • 16. 11. 2016 9:29

    Andrej Ramašeuski

    "dnesne stroje" to je nekdy raspberry pi, a nebo, dokonce (coz osobne pouzivam) mysql na nas s 128M pameti. a tam je hranice velkych dat je trochu jinde. a i na tech vykonnejsich strojich mensi efektivita databazi se projevi na uctu za elektinu nebo, v pripade cloudoveho hostingu, na uctu za virtualni procesorove jednotky.

  • 16. 11. 2016 9:34

    Pavel Stěhule

    Trochu mám pocit, že v článku občas čtete slova, která jsem nenapsal, a naopak to, co jsem napsal, nevidíte.
    V prvé řadě musím vědět, co píši za aplikaci a pro koho. Kolik budu mít dat - za rok, za tři, za pět let. Malé databáze Vám leccos odpustí. U velkých můžete mít problém.
    Pokud píšete aplikaci, která je postavená nad databází - a data a operace nad databází jsou důležité, pák úvahy o návrhu schématu rozhodně nejsou z kategorie premature optimization. V době, kdy přijdete na problémy s výkonem - někdy za týden, jindy za rok, už nemůžete udělat žádné větší změny ve schématu aniž byste radikálně přepisoval aplikaci.

  • 16. 11. 2016 11:02

    Daniel (neregistrovaný) 193.29.76.---

    Obecně bych souhlasil, ale je to podle mě trochu složitější. Předesílám, že jsme tedy spíš ze světa Oraclu, ale myšlenkové pochody jsou snad platformě nezávislé, aspoň v tomto případě :)

    IMHO na dotazu s mnoha JOINy není nic špatného; např. v normalizované OLTP databázi, kde to vede ideálně na NESTED LOOPy po indexech. Tím spíš, že může být hodně nacachováno a provádí se pak spíš logické IO. A díky statistikám indexů obvykle chyba v odahu není příliš zásadní.
    Samozřejmě, že v tom světě skladů má smysl se joinům ideálně vyhýbat, ale někdy to prostě nejde - např. když mi aplikace sype fakta a do reportu musím přidat atributy z dimenzí. Pak ale může mít smysl obětovat normalizaci a join mít ten join předpočítaný a materializovaný; abych ho nemusel počítat pokaždé, když si někdo otevře v BI nástroji první obrazovku. Samozřejmě záleží na zadání - jestli chce BI aktuální přesné hodnoty, nebo třeba v 5min intervalech.

    Tím chci jen říct, že opravdu moc záleží na ujasnění si, co vlastně mám dělat. "vyhýbejte se mnoha joinům v dotazu" a "normalizujte, co to jde" - omlouvám se za zkratky, ale snad nejsou úplně mimo - tedy nepovažuji za univerzálně platné rady pro začátečníky, čímž je tedy kategoricky nevyvracím.
    Nicméně chápu, že nemusí být rozumné jej hned na začátku vyděsit existencí různých světů s různými pravidly.

  • 16. 11. 2016 11:14

    Pavel Stěhule

    Nejsem proti JOINům - jsem proti zbytečným JOINům - když máte reálně 10 entit, tak budete mít 9 JOINů. Když entity rozkouskujete podle tříd, tak už máte třeba 20, 30 tabulek a 20-30 JOINů.
    Získat data z jednoho objektu - to nikdy nebude problém - je téměř jedno jestli udělám 10 nebo 100 nested loopu, které budou vracet jeden řádek - tam budou rozdíly max. v jednotkách ms. I když u 50 JOINů a více se už bude pálit čas i na plánování dotazu. Jakmile ale budete počítat report, a i v OLTP databázi chcete počítat reporty, tak nested loop bude to poslední, co budete chtít vidět v prováděcím plánu - a se špatnými odhady už je to o přetlačování databáze a typicky oser.
    Jestli něco začátečníci musí pochopit, pak je to fakt, že každý sw má nějaké limity a hranice, za které je už nepraktické jej dál používat, ohýbat. Běžně se setkávám s neskutečnými problémy plynoucí z toho, že Excel někdo používá jako databázi - nebo že MS Access se používá nikoliv pro 30 lidí, jak byla zamýšlená, ale pro 300 lidí. To, že vývojáři vůbec nerespektovali realitu, dneska vede k tomu, že pár firem má těžké provozní problémy a nefunkční systémy. Jsou tu různé světy, mají různá pravidla, různé limity a ty limity je nutné znát.

  • 16. 11. 2016 11:38

    Daniel (neregistrovaný) 193.29.76.---

    Jasně, to jsme pak na stejné lodi ;) Jinak tedy nevím jak v PG, ale v ORA není nutné vždy pálit CPU parsováním/op­timalizováním - plány se cachují a přepoužívají, je-li to možné - pokud tedy někdo neni prase a nedělá "WHERE id = '1'". To jsem bohužel v produkci už viděl a pak samozřejmě cursor_cache obsahuje tisíc podobných ošklivých dotazů, kde rozdíl v SQL jsou právě jen hodnoty ID; prostě to nahoře v JAVE slepili jako řetězec a nazdar, bojuj databáze!
    Jasně, ani používání proměnných není samospásné a může vést k jiným problémům; např. v těch DWH je určitě lepší obětovat čas CPU za lepší plán, než šetřit parsování a seknout se (řádově) v kardinalitě, třeba kvůli roztodivné distribuci hodnot. Ale to jsme už trochu jinde... pochopil jsem co chcete říct a souhlasím.

  • 16. 11. 2016 14:45

    Palo (neregistrovaný) ---.rainside.sk

    Tak ak mate niekoho kto zrovna v JAVE lepi retazce ako dotazy tak ten si Oracle do ruky nezasluzi. Specialne Java ma slusne ORM frameworky ktore presne toto riesia.

  • 16. 11. 2016 16:40

    Pavel Stěhule

    Postgres plány sám od sebe nekešuje - musí se použít explicitně prepared statements - Postgresový planner je o něco rychlejší, a od určité složitosti používá genetickou optimalizaci - takže náročnost optimalizace není exponenciální - navíc mnohem větší hrůzu než z opakovaného plánovaní mají vývojáři pg strach z neadekvátní kardinality.

  • 16. 11. 2016 12:56

    lupa.cz jsou už jako čučkaři

    Autor chtel zcela jiste misto eliminace JOINu spise uvest, ze problem je predcasna materializace databazovych vet v ramci provadeciho planu. To je to podstatne, proc nejake DB systemy dokazou zvladnout spousty JOINu, aniz by to melo fatalni dopady na vykon. A to je taky duvod proc kdyz uz to relacni technologie nestiha, musi se nejcasteji na sloupcove baze a kdyz ani ta to neda, tak se musi jit do log-merge struktur.