Rada při návrhu db tabulek

[Pavel Stěhule]

Databáze jsou úzké hrdlo, protože spousta lidí je neumí používat. Dejte mi příklad, kde je úzkým hrdlem databáze, můžeme si k tomu napsat.

temer libovolna webova aplikace s vetsim provozem a vypnutym cachovanim, treba i tohle forum, kdyby tu bylo vetsi mnozstvi diskuteru. Netvrdim, ze preneseni aplikacni logiky na server ma vzdy nejaky zasadni negativni vliv, ale urcite neplati opak (databaze je vzdy efektivnejis) jak tvrdite vy.

Cache je dobrá - zvlášť pro webky, které na jeden refresh stránky vygenerují 300 dotazů. Co jsem už také viděl. Dnešní servery dávají cca 3000 - 6000 dotazů za sec na 1  CPU vlákno. Takže, když máte server, který má 32 vláken, tak bez problémů zvládnete 20-40 000 dotazů za sec (většinou tyto web aplikace generují primitivní dotazy).  Nicméně aktivní cache pro web aplikace (pro stránky) je důležitá - ušetříte jednak dotazy, druhak hromadu operací se řetězcema (a navíc se většinou dobře cacheuje).

U databázových aplikací ale většinou negenerujete interface, a také dost často nemůžete použít cache - ale většinou vygenerujete na obrazovku 10 dotazů - a tam pokud neděláte nějaké šílenosti, tak běžné servery utáhnou bezproblémově aplikace pro střední evropu.

[Reklama]

[PanVP]

300 dotazů na jeden refresh stránky  
WTF (?)
Bavíme se o jedné jediné běžné webové stránce?
Tři sta dotazů
Jako vážně?
Ale to uvádíte jako příklad enormní ouchylnosti ne?

[Miroslav Šilhavý]

300 dotazů na jeden refresh stránky  
WTF (?)
Bavíme se o jedné jediné běžné webové stránce?
Tři sta dotazů
Jako vážně?
Ale to uvádíte jako příklad enormní ouchylnosti ne?

Rekord, v mojí praxi, co jsem pomáhal řešit, bylo něco přes 500 dotazů na jeden reload stránky. Postaralo se o to ORM.
Po optimalizaci to bylo 6 dotazů.

Daleko běžnější je potkat cca 50 dotazů, které se dají zredukovat na pět i méně, ale smysluplných. Čísla dávám odhadem, statistiku jsem nevedl.

[PanVP]

cca 50 dotazů

Ano, cca 50 bych čekal a často mají svůj důvod.
Také chápu, že se dají optimalizovat, ale vesměs to (podle mě) nemá smysl.
Čas propálený optimalizací bývá o řád dražší než pořídit o trochu silnější železo.

Mimo to, sám jsem se spálil, tak jsem optimalizoval, až byl z optimalizovaných dotazů prasečí chlívek.
Rychlý, ale chlívek. A honit chybu napříč systémem po jednotlivých dotazech byl fujtajbl.

[Pavel Stěhule]

300 dotazů na jeden refresh stránky  
WTF (?)
Bavíme se o jedné jediné běžné webové stránce?
Tři sta dotazů
Jako vážně?
Ale to uvádíte jako příklad enormní ouchylnosti ne?

Samozřejmě, že je to extrém - ale ve své době to byla relativně rozšířená aplikace (rok 2009). Firma, kde jsem tehdy pracoval ji používala pro správu tiketů (takový centrální mozek), a pro 300 zaměstnanců už to byl brutus. Nakonec se ukázalo, že největší průser byl vlastně samostatný dedikovaný server - a síťové latence. V tomhle počtu už to dělalo hodně. Paradoxně pomohlo dát na jeden server apache, i databázový server, a zbavit se režie sítě. Nicméně viděl jsem i nějaké portály - které na refresh stránky generovaly vyšší desítky dotazů a bez cache to pro vyšší návštěvnost (v rámci ČR) nedávalo. Na druhou stranu, zrovna oni pak jednoduchou cache vyřešili 95% přístupů.

[Reklama]

[Miroslav Šilhavý]

Ano, cca 50 bych čekal a často mají svůj důvod.
Také chápu, že se dají optimalizovat, ale vesměs to (podle mě) nemá smysl.
Čas propálený optimalizací bývá o řád dražší než pořídit o trochu silnější železo.

Málokdy potřebujete tolik živých entit na jednu stránku.
Železem to nedotáhnete, náročnost roste se zátěží a daty víc, než lineárně. To se dá železem dotáhnout z počátku, ale na limit to narazí dřív, nebo později.

Především ale není zas tak těžké umět řemeslo tak, že taková situace ani nevznikne. To pak nestojí prakticky žádný čas navíc, ani to železo.

Už jen na těch padesáti dotazech máte dost nepříjemnou 50x režii na dotaz; pokud je DB stroj síťový (což u větších projektů chcete, protože dřív nebo později to budete potřebovat oddělit), tak už je velmi citelná.

Mimo to, sám jsem se spálil, tak jsem optimalizoval, až byl z optimalizovaných dotazů prasečí chlívek.
Rychlý, ale chlívek. A honit chybu napříč systémem po jednotlivých dotazech byl fujtajbl.

Tady už nemůžu polemizovat, musel bych vidět konkrétní situaci. Pokud je tím myšleno to, co si domýšlím, tak to lze dobře řešit pohledy a procedurami, chlívek se pak nekoná.

[PanVP]

pohledy

Ano, pohledy jsou z hlediska optimalizací dobré, výrazně lepší než samostatné selecty.
Tenkrát jsem si naběhl a při refaktorizaci se pěkně zapotil...a poučil.

Železem to nedotáhnete, náročnost roste se zátěží a daty víc, než lineárně.

To určitě nelze paušalizovat!

Pan Stěhule to myslím kvantifikoval celkem slušně -

Dnešní servery dávají cca 3000 - 6000 dotazů za sec na 1  CPU vlákno. Takže, když máte server, který má 32 vláken, tak bez problémů zvládnete 20-40 000 dotazů za sec

Jen slovo vlákno bych nahradil (samostatné) jádro.
Vlákna se dají na jádru pouštět souběžně tak dvě, případně tři pokud je zapnuté HT, výš už to - pokud je aplikace dobře napsaná - moc neškáluje. Pokud jsou součástí jádra blokovací operace, tak se zase nedostanete na ten počet dotazů.

Jinými slovy: 40 000 / 40 dotazy na stránku = ~10 000 souběžných uživatelů. Jenže cache chytne hrozně moc.
Z mého pohledu je důležité, aby se server nestaral o podávání triviálních věcí jako CSS, cachování, podávání obrázků a v neposlední řadě žrouta ve formě HTTPS spojení. Takže zatímco pomocí Cache zvednete počet návštěvníků i na osminásobek, ladění aplikace by určitě nepřineslo stejný efekt. Leda později, až i tak je často levnější přidat druhý server.

No ale já jsem jen prostý pobíječ much, třetiřadý programátor pracující v druhořadé firmě za prvořadé peníze 

[Google CTCCTCGGCGGGCACGTAG]

Za provadeni dotazu v cyklu nemuze ORM. Uplne stejne muzete v cyklu volat nejakou funkci, ktera dotazuje databazi i bez ORM.

[Miroslav Šilhavý]

...

Když máte 10000 dotazů, ale po 50 dotazech na požadavek, nakumulujete 50x latenci.
Když máte 10000 dotazů, ale po 5 dotazech na požadavek, nakumulujete latenci 5x.

V obou případech bude server zvládat stejně, ale v prvním případě bude aplikace 10x pomalejší. Pohled ze strany serveru nevypovídá tak přesně o výkonu aplikace.

Zmiňujete cachování, ale i to se liší. Cache blíž ke zpracování (cache RDBMS, cache OS, cache řadiče, cache CPU, ...) jsou efektivní v tom, že dávají přesná data mnohem rychleji. Někdy se ale pojem "cache" užívá v aplikační úrovni, a často je to za cenu mírně nepřesných výsledků (např. zpožděných).

Aplikační cache, která by měla přinejmenším revalidovat relevanci uložených informací, se nevyhne (opět, překvapivě) určité latenci. Ta latence bývá na tolik významná, a revalidace tím pádem na tolik náročná, že ve spoustě případů se vyplatí vzít rovnou data, než se s cache patlat. Pokud máte na mysli cache s potenciálně neaktuálními daty, pak se dostáváme na půdu unfair srovnání, a taky budeme řešit, co všechno z takového přístupu vyplývá za rizika.

[Miroslav Šilhavý]

Za provadeni dotazu v cyklu nemuze ORM. Uplne stejne muzete v cyklu volat nejakou funkci, ktera dotazuje databazi i bez ORM.

Volat v cyklu funkci, která dotazuje databázi, je návrhový antivzor. SQL je tak komplexní dotazovací jazyk, aby se tomu dalo vyhnout.

V případě užití ORM se tomu prakticky vyhnout nedá.

[Google CTCCTCGGCGGGCACGTAG]

V případě užití ORM se tomu prakticky vyhnout nedá.

mytus, to platilo mozna pred dvaceti lety u nejakych primitivnich javovskych ORM.

[Google CTCCTCGGCGGGCACGTAG]

naopak, pokud potrebujete v aplikaci vykreslovat nejake tabulky a v ruznych tabulkach se opakuji sloupce, treba jen s malou obmenou, s ORM muzete snadno sestavovat dotazy DRY zpusobem.

treba v Djangu staci k dotazu pridat

Kód: [Vybrat]

.annotate(sloupec_vysledku=funkce_generujici_sql(parametry))

ten kod muze pridat treba slozity join, CASE konstrukci a podobne

VZDY to vygeneruje validni SQL.

v cistem SQL je tohle oser s lepenim dotazu z retezcu, proto se casteji volaji dotazy v cyklu

ocenil bych, kdyby se do diskuze o ORM zapojovali lidi, kteri s ORM pracuji. Vy tu jen papouskujete myty, ktere znate z doslechu.

[Google CTCCTCGGCGGGCACGTAG]

Pokud chcete tabulky se strankovanim + razenim, tak je MUSITE vyselektovat jednim dotazem, ma to tak vetsina webu, ORM se k tomu pouziva bezne.

Selektovani dat v cyklu je antipattern, s ORM nema nic spolecneho.

[Miroslav Šilhavý]

Pokud chcete tabulky se strankovanim + razenim, tak je MUSITE vyselektovat jednim dotazem, ma to tak vetsina webu, ORM se k tomu pouziva bezne.

Selektovani dat v cyklu je antipattern, s ORM nema nic spolecneho.

Tak samozřejmě, takovou trivku jsem na mysli neměl.

[PanVP]

Já bych se v tomhle případě Mirka zastal.


Případně lepší (asi nepůjde vložit)


...prostě třeba od takových lidí není možné žádnou velkou hloubku ani důkladnost čekat, zaměstnavatel je nutí dělat úplně všechno...