Příspěvky

76

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 01. 07. 2021, 21:30:29 »

Tomu co popisuješ dobře rozumím. Čemu nerozumím je, čím podkládáš svá tvrzení, že by to nemělo jít? To v tom textu schází.

Uvedu příklad: V MySQL je taková vlastnost, že v praxi moc nejde použít view, protože implementace v MySQL jej nedokáže optimalizovat a v mnoha případech to degraduje na fullscan. Teď neřešme nakolik je můj popis problému přesný.

Vysvětli mi prosím, máš-li chuť, proč by tuto informaci o tomto zrádném chování nemohlo vědět ORM (ve svém engine pro MySQL), a zohledňovat to při vytváření dotazů? Proč by to musel, principielně umět vývojář. Proč by tato znalost této vlastnosti bylo mnohem náročnější "naučit" ORM, než to učit vývojáře?

Tak předně, úplně bych zapomněl na MySQL. To je parodie na RDBMS, která má pár drobných výhod a spoustu velkých nevýhod.

To, co popisujete, není vlastnost, ale chyba nebo nedodělek. Není dobrý nápad chybu nebo nedodělek napravovat o vrstvu výš. Jako nějaká obezlička, budiž, ale řešení to není.

Co je překážkou? To už jsem psal. Že struktura dat, tabulí, indexů a dotazů neexistuje jen jediná možná. Existuje mnoho způsobů, jak se dobrat téhož, a liší se složitostí zápisu dotazu (v případě automaticky generováného dotazu nás to netrápí), liší se náročností pro získání dat a liší se náročností pro zápis dat. ORM nedokáže rozhodnout, kterou strategii preferujete. Neví, jestli potřebujete rychle zapisovat a pomalu číst, nebo pomalu zapisovat a rychle číst. Nebo jestli něco mezi. Netuší, jestli bude výhodnější parciální index, ale rychlejší ve většině případů, nebo plný index, rychlý, ale o něco pomalejší v průměrném případě. Neví, jestli Vám jde o celkovou rychlost, nebo o zminimalizování locků...

To vše je na člověku - ne protože by to technologie nechtěla umět, ale protože člověk musí zvolit strategii pro daný projekt. Každá má svá pro a proti.

Nevím, jestli jste někdy tyto věci řešil - pokud se soustředíte na MySQL, musí to být dost vzdálené si to představit, protože tam opravdu často existuje jen jedna jediná "správná" cesta a všechny ostatní jsou úplně tragické.

77

Hardware / Re:Rozumna usb-c nabijecka pro notebook Lenovo E14

« kdy: 01. 07. 2021, 20:55:00 »

Tak to hodně štěstí. Jen samotný USB-C kabel, má-li být pořádný a s tvrdými konektory, stojí tak nějak pětistovku.

78

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 01. 07. 2021, 20:29:42 »

Jak jsem psal výše, mě zajímají principy. To, že aktuální ORM nejsou ve stavu, kdy by to všechno fungovalo krásně out-of-the-box, to je mi jasné, uvědomuji si to, a uznávám. Ale považuji to za otázku vývoje, nikoliv za principielní problém. Ano, já si pamatuju dobu, kdy to lidem stálo za to a v Delphi psali pasáže v asm.

Takže děkuji za jakékoliv příspěvky, které popisují principielní potíže, se kterými se musí ono ORM vypořádat.

Ta principiální potíž je v tom, že RDBMS jsou výkonné právě a tehdy, kdy jsou správně nastavené tabule, constrainty, klíče, vzdálené klíče, indexy, ..., a především, když je možné maximum rozhodovacích mechanismů přenést do DB. Interné optimalizátor dotazu se pak těchto informací může chytit a snažit se je využít k vymyšlení nejlepšího postupu pro získání / zápis dat.

Tedy např. když vím, že chci přebarvit všechna auta na červenou, vyjma zelených aut vyrobených v roce 2009, pak potřebuju, aby databáze měla takovou strukturu, aby se k diskriminantům dostala rychle. Musí umět rychle vyhodnotit, jestli nejdřív vybere auta vyrobená <> 2009 a pak s barvou <> zelenou, nebo jestli bude rychlejší opačný postup. Nebo jestli bude nejrychlejší projít všechna auta po sobě, a těch pár, které jsou zelené a vyrobené v 2009 přeskočit (tj. indexy, statistiky, složené indexy, ...).

Můžete mít také auta, u kterých nevíte rok výroby nebo nevíte barvu. ORM za Vás nerozhodne, jestli může (má) použít inner nebo outer join. V prostém případě to nebude mít na výkon velký vliv, ale pokud půjde o složený dotaz se subselecty, bude inner/outer hrát roli v tom, co dokáže optimalizátor ze subselectu vyčlenit nad něj, a co ne.

O tom, jak dotaz realizovat, musí přemýšlet i ten, kdo pracuje přímo v SQL, a nezřídka se stává, že váhá. Zejména, když sestavujete view, tak očekáváte, že bude použito v dalším složeném dotazu. Když view navrhnete špatně, tak může dávat při prostém selectu data rychle, ale může být pro optimalizátor už dále neoptimalizovatelné v dalších složených dotazech. Někdy se vyplatí, pokud víte, co se s tím bude dál dít, napsat view složitěji, ale optimalizovatelněji.

Toto všechno neumí vyřešit RDBMS, a programátor v SQL se s tím taky zapotí. Proto tvrdím, že není reálné očekávat, že ORM by i někdy v budoucnu toto uměly.

Dál mě k tomu přesvědčení vede i to, že optimalizace se musí provádět co nejblíž k datům. RDBMS jsou výkonné jen a právě díky tomu. Dovedu si představit ORM, které by nějakou svojí inteligencí přenášelo nadefinované objekty do dobře vytvořených SQL definic. Jenže to to ORM nebude schopné vymyslet samo, musí to vyčíst z definic poskytnutých programátorem. Tyto definice v rámci ORM by tedy musely být na tolik přesné, aby je šlo 1:1 přenést do DB. Pokud by ty definice měly být na tolik přesné - pak už ORM nebude šetřit práci, pouze bude jinou mluvou definovat totéž.

Mám takový pocit, že hledáte potvrzení, že nějaká ORM mechanika dokáže vymyslet to, co nikdo za desítky let nevymyslel ani v rámci RDBMS.

79

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 01. 07. 2021, 20:06:50 »

V tom případě, v tom já nevidím problém. Jdu pod kapotu ORM (nikoliv napřímo do db). Mnoho z nich obsahuje různé nástroje jak optimalizovat různé věci. Je to stále v režii ORM, neobcházím validaci (nebo to činím při plném vědomí), a nevidím v tom žádný problém. Nepovažuji to za mrzačení.

Samozřejmě v tomto případě ale nemohu pouštět write dotazy napřímo do databáze, protože pak dotyčené ORM obcházím; on je source of truth.

Rozumím. A i na to jsem reagoval. I když jdete "pod kapotu" v rámci ORM, výsledek nebude zázračný (důvody jsem psal, nebudu se opakovat). Nikdy to nebude mít šanci využít plný výkon.

Nebude zázračný ale bude více než dostatečný. Stejně, jako ručně optimalizovaný kód v asembleru bude vždy lepší jak to co vymyslí kompilátor. Je to stejná písnička (btw, to jsem už taky psal, také se opakuji).

Ok, to už je věc názoru. Potkal jsem už řádku projektů, kde po zvětšení datové nálože a zvýšení přístupů, vylétly požadavky na výkon tak moc, že už se to nijak škálovat nedalo. Pomohl jedině přepis a aspoň důležité části šly mimo ORM (čímž vznikl paskvil, ale aspoň se vyřešil problém).

Jasné, pro malý shopík na webu, kam přijde 50 objednávek za den, bude ORM stačit na věky věkův.

80

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 01. 07. 2021, 19:34:19 »

V tom případě, v tom já nevidím problém. Jdu pod kapotu ORM (nikoliv napřímo do db). Mnoho z nich obsahuje různé nástroje jak optimalizovat různé věci. Je to stále v režii ORM, neobcházím validaci (nebo to činím při plném vědomí), a nevidím v tom žádný problém. Nepovažuji to za mrzačení.

Samozřejmě v tomto případě ale nemohu pouštět write dotazy napřímo do databáze, protože pak dotyčené ORM obcházím; on je source of truth.

Rozumím. A i na to jsem reagoval. I když jdete "pod kapotu" v rámci ORM, výsledek nebude zázračný (důvody jsem psal, nebudu se opakovat). Nikdy to nebude mít šanci využít plný výkon.

81

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 01. 07. 2021, 19:22:27 »

Nerozumím. Odporuješ si. Já tvrdím, že bych dávkové příkazy honil přes ORM, a ty namítneš, že "Když ORM, tak kompletně, přijmout jeho výhody a nevýhody. Data pak jedině přes aplikaci, nikdy už ne přímo z DB."?

Reagoval jsem na druhou větu: >>Pod kapotu jdu v případě, kdy potřebuju optimalizovat na krev, ne v případě kdy potřebuju "něco spustit".<<

82

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 01. 07. 2021, 18:01:49 »

Já bych pro dávkové příkazy ORM neobcházel. To ORM tam jednou mám, a tak to píšu přes něj. Pod kapotu jdu v případě, kdy potřebuju optimalizovat na krev, ne v případě kdy potřebuju "něco spustit".

To moc dobře nefunguje. Databáze je zatížená spoustou neefektivních dotazů, a ve chvíli, kdy potřebujete jeden ladit "na krev", tak se nikam nehnete. Zjistíte, že i ten jeden, jinak třeba dobře napsaný dotaz prostě čeká kvůli ostatním neefektivním transakcím a lockům z ORM.

Celkově je hloupé mít dobrou technologii, zmrzačit ji, a pak se snažit zrmzačený pahýl znovu rozhýbat.

Psal jsem to už výše, ORM má svoje místo, ale problém nastává ve chvíli, kdy někoho napadne, že by si mohl pomoct obejitím. Získá tím málo, ale hodně zkomplikuje situaci. Když ORM, tak kompletně, přijmout jeho výhody a nevýhody. Data pak jedině přes aplikaci, nikdy už ne přímo z DB.

83

Sítě / Re:IOT a zabezpečení LAN (separátní virtuální sítě a komunikace mezi nimi)

« kdy: 01. 07. 2021, 08:17:32 »

Základní zabezpečení je přes firewall.
Já to nepovažuju za dostatečné, je to náchylné na konfigurační chyby a zranitelné poměrně lehce, pokud se objeví chyba v routeru.

Pro síť s více segmenty bych nejprve volil rozdělení na L2, tedy VLAN a na routeru VRF.
Teprve nad to firewall.

84

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 30. 06. 2021, 22:48:59 »

Tohle je z principu nemožné.
Pokud bude "zákaz zazelenit" vyhodnocený aplikační logikou, pak ORM nedokáže sestavit žádný efektivní update dotaz do databáze. V nejlepším případě bude posílat list IDček k updatování, nebo něco podobného.

Pokud ta "aplikační logika" bude vycházet přímo z vlastností objektů (když má auto výkon > 100kW a jen dvoje dveře, nemůže být obarvené na zeleno, ostatní můžou), které jsou mapovány do databáze, tak by to ORM zvládnout mohl. Ale už i ten zápis se bude asi přibližovat relačnímu SQL jazyku.

Přesně to mám na mysli. Definice takových mapovaných objektů, nebo zápis požadavku bude sice jinou mluvou, ale nevyhne se složitosti zápisu v SQL.

Ale můžeme to rozvést dál: pokud to bude vycházet z databáze, ale jaksi "na volno" - nebude to vyjádřené vazbami, pohledy, constraints, triggery, opatřené žádoucími indexy, ..., ale třeba jen definované zápisem nějaké konfigurace => pak to taky v obecném případě nedosáhne výkonu, který RDBMS může poskytnout, a ani to nebude mít potenciál optimalizovatelnosti to ke stejnému výkonu. Pokud by to bylo v DB definované přesně, a na pevno, pak ORM neusnadní práci při tvoření struktury a práci s daty, pouze poskytne vhodnější interface bližší k jazyku aplikace.

85

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 30. 06. 2021, 19:35:58 »

   

• Pokud v APP, tak máš problém s jakýmikoli hromadnými operacemi. Např. primitivní nastavení vlastnosti: když uděláš "UPDATE cars SET color = 'green'", ale v APP logice budeš mít u některých aut zákaz je nazelenit, tak to rozbiješ, protože tu APP logiku rozbiješ.

Situaci, kdy se používá mix přístupů výše jsem už komentoval.

proc bych psal SQL update rucne? Jeste jednou, kazde ORM umi vygenerovat validni batch update dotaz.

Tohle je z principu nemožné.
Pokud bude "zákaz zazelenit" vyhodnocený aplikační logikou, pak ORM nedokáže sestavit žádný efektivní update dotaz do databáze. V nejlepším případě bude posílat list IDček k updatování, nebo něco podobného.

86

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 28. 06. 2021, 06:37:20 »

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.

87

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 28. 06. 2021, 00:59:16 »

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á.

88

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 28. 06. 2021, 00:56:15 »

...

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.

89

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 28. 06. 2021, 00:29:27 »

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á.

90

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 28. 06. 2021, 00:14:33 »

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.