Rada při návrhu db tabulek

Re:Rada při návrhu db tabulek
« Odpověď #180 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.


BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Rada při návrhu db tabulek
« Odpověď #181 kdy: 01. 07. 2021, 20:02:10 »
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).

Re:Rada při návrhu db tabulek
« Odpověď #182 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.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Rada při návrhu db tabulek
« Odpověď #183 kdy: 01. 07. 2021, 20:11:45 »
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.

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.

Re:Rada při návrhu db tabulek
« Odpověď #184 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.


BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Rada při návrhu db tabulek
« Odpověď #185 kdy: 01. 07. 2021, 21:09:17 »
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.

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?

A naopak, PostgreSQL umí velice dobře view, a rules, a Sqlite a MySQL od verze (už si nepamatuju) umí window. Etc, etc.,
« Poslední změna: 01. 07. 2021, 21:10:51 od BoneFlute »

Re:Rada při návrhu db tabulek
« Odpověď #186 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é.

Re:Rada při návrhu db tabulek
« Odpověď #187 kdy: 01. 07. 2021, 21:44:51 »

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.

Principiální problém je samozřejmě s výkonem. Tím, že ORM neběží na databázovém serveru, ale na aplikačním, tak máte výrazně větší režii při přístupu k datům (režie sítě, režie protokolu, různých vrstev). Zvlášt u extrémně rychlých dotazů (dotazy, které vrací, modifikují pár řádků nad PK), je tato režie hodně vysoká. A v podstatě pak hrdlem je síť a pálíte výkon konverzí dat a realizací komunikace. Můžete si pomoct aplikační cache. Pokud ale máte víc dat, tak se nevejdete do RAM na aplikáči, a a musíte implementovat ACID nad ACIDem, což zase zvyšuje komplexitu nástroje. Implementace distribuované transakční cache je dost komplikovaná záležitost. Zvyšuje se výkon CPU, zvyšují se přenosové rychlosti, IOPS SSD jsou někde úplně jinde, ale na druhou stranu, roste objem dat, klesá trpělivost uživatelů (nikdo nechce čekat na výsledek minuty), a klesají znalosti programátorů (mění se znalosti programátorů - znají ORM, patterny, buildovací prostředí, a virtualizaci), ale neznají základy toho jak fungují databáze (což dřív také nebyla žádná sláva, ale teď to mají k databázím dál). Tudíž si myslím, že posledních 15 let, jsou u větších projektů stejné problémy (i přes brutální nárůst výkonu).

Další problém ORM je odtržení statistik. Sice mohou mít datový model (a mají), ale nemají statistiky, jak data ve skutečnosti vypadají. V ideálním případě by možná tuto znalost nepotřebovali, kdyby existoval ideální optimalizátor dotazů. Už jednoduchá úloha je docela komplikovaná - rozhodnout, jestli si inicializovat cache blokově (napřed si stáhnu potřebná data) nebo iteračně. Pokud budete mít statistiky na aplikáči, tak duplikujete funkcionalitu db, a navíc asi statistiky budete mít jen z cache (nikoliv ze všech dat). Co vím, tak většina ORM statistiky o datech nemá, proto dynamicky nedokáže měnit strategie zpracování dat (nedokáže se přizpůsobit datům). Relační SQL databáze se o to snaží - máte 3 typy JOINů, máte seq scan, index scan - a optimalizátor hledá způsob, jak co nejrychleji přenést data z disku a jak přitom spotřebovat co nejméně paměti.

SQL ale optimalizuje pouze jeden dotaz - už neoptimalizuje sekvenci příkazů. Tam se předpokládá invence programátora. Někdy se vám vyplatí načíst data do RAM aplikáče, a pak nad touto RAM dělat komplikovanější operace. Jindy iterujete po řádcích, jindy agregujete, a gró výpočtu udělá databáze a na aplikáč se posílá jen výsledek. Optimální strategii volí programátor se znalostí dat, a znalostí procesu - ví k čemu data bude používat, a kde je potřebuje.

Re:Rada při návrhu db tabulek
« Odpověď #188 kdy: 01. 07. 2021, 22:03:51 »
SQL ale optimalizuje pouze jeden dotaz - už neoptimalizuje sekvenci příkazů. Tam se předpokládá invence programátora. Někdy se vám vyplatí načíst data do RAM aplikáče, a pak nad touto RAM dělat komplikovanější operace. Jindy iterujete po řádcích, jindy agregujete, a gró výpočtu udělá databáze a na aplikáč se posílá jen výsledek. Optimální strategii volí programátor se znalostí dat, a znalostí procesu - ví k čemu data bude používat, a kde je potřebuje.

Optimalizace na úrovni SQL ale fungují cca na 70 procent, tak jak fungují statistiky a odhady. Statistiky ale nejsou přesné, a tudíž nejsou přesné odhady. Máte korelace v datech, fyzicky data nejsou rovnoměrně uložena v tabulkách. Někdy dochází ke změně charakteru statistik v čase (což statistický model vubec nedokáže zpracovat). Modelovat se dá velice přesně, ale to vám dost pálí výkon - a ten při optimalizaci dotazu nemáte. Takže chca nechca musíte přidávat dodatečnou informaci, tím jak píšete SQL (ať už jsou to hinty, nebo  použité konstrukce, nebo sekvence příkazů). Pokud je ale databáze navržená pro ORM, tak programátoři nemají znalosti, chybí jim odvaha do kódu sahat, chybí jim zkušenost, a fakt to hodně dře. U větších aplikací (u malých to není problém), pak musíte řešit jednak výkon SQL, a také výkon ORM (pokud jej používáte).

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Rada při návrhu db tabulek
« Odpověď #189 kdy: 01. 07. 2021, 22:19:22 »
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.
Tuto myšlenku jsme už tu o pár stránek dříve probírali, včetně mých námitek na ně. Tudíž jen zopakuji: nesouhlasím. Nevidím důvod, proč by to ORM nemělo umět, proč by to neměl zvládnout lépe jak člověk. Z tvého popisuj tento závěr nevyplývá.

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é.
Mám pár zkušeností s různými ORM. Mám nějaké zkušenosti s MySQL, Sqlite, PostgreSQL, MSSQL - stačí? A záleží na tom?
Já tě nevnímám jako autoritu, tudy cesta nevede. Tudíž dokavad neuvedeš důvod, proč by to jít nemělo, tak se nepohneme :-) (Jako důvod si představuji něco, na co ti řeknu: "jó, tak to nevím jak by se dalo řešit". Zatím jsem na všechny tvé nepřekonatelné problémy našel snadné řešení a napsal ti ho.)


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.

Principiální problém je samozřejmě s výkonem. Tím, že ORM neběží na databázovém serveru, ale na aplikačním, tak máte výrazně větší režii při přístupu k datům (režie sítě, režie protokolu, různých vrstev). Zvlášt u extrémně rychlých dotazů (dotazy, které vrací, modifikují pár řádků nad PK), je tato režie hodně vysoká. A v podstatě pak hrdlem je síť a pálíte výkon konverzí dat a realizací komunikace. Můžete si pomoct aplikační cache. Pokud ale máte víc dat, tak se nevejdete do RAM na aplikáči, a a musíte implementovat ACID nad ACIDem, což zase zvyšuje komplexitu nástroje. Implementace distribuované transakční cache je dost komplikovaná záležitost. Zvyšuje se výkon CPU, zvyšují se přenosové rychlosti, IOPS SSD jsou někde úplně jinde, ale na druhou stranu, roste objem dat, klesá trpělivost uživatelů (nikdo nechce čekat na výsledek minuty), a klesají znalosti programátorů (mění se znalosti programátorů - znají ORM, patterny, buildovací prostředí, a virtualizaci), ale neznají základy toho jak fungují databáze (což dřív také nebyla žádná sláva, ale teď to mají k databázím dál). Tudíž si myslím, že posledních 15 let, jsou u větších projektů stejné problémy (i přes brutální nárůst výkonu).

Další problém ORM je odtržení statistik. Sice mohou mít datový model (a mají), ale nemají statistiky, jak data ve skutečnosti vypadají. V ideálním případě by možná tuto znalost nepotřebovali, kdyby existoval ideální optimalizátor dotazů. Už jednoduchá úloha je docela komplikovaná - rozhodnout, jestli si inicializovat cache blokově (napřed si stáhnu potřebná data) nebo iteračně. Pokud budete mít statistiky na aplikáči, tak duplikujete funkcionalitu db, a navíc asi statistiky budete mít jen z cache (nikoliv ze všech dat). Co vím, tak většina ORM statistiky o datech nemá, proto dynamicky nedokáže měnit strategie zpracování dat (nedokáže se přizpůsobit datům). Relační SQL databáze se o to snaží - máte 3 typy JOINů, máte seq scan, index scan - a optimalizátor hledá způsob, jak co nejrychleji přenést data z disku a jak přitom spotřebovat co nejméně paměti.

SQL ale optimalizuje pouze jeden dotaz - už neoptimalizuje sekvenci příkazů. Tam se předpokládá invence programátora. Někdy se vám vyplatí načíst data do RAM aplikáče, a pak nad touto RAM dělat komplikovanější operace. Jindy iterujete po řádcích, jindy agregujete, a gró výpočtu udělá databáze a na aplikáč se posílá jen výsledek. Optimální strategii volí programátor se znalostí dat, a znalostí procesu - ví k čemu data bude používat, a kde je potřebuje.
To co popisuješ není principielní problém ORM. To jsou reálné problémy aktuálních implementací.

Pro příklad hned první věta:
Principiální problém je samozřejmě s výkonem. Tím, že ORM neběží na databázovém serveru, ale na aplikačním, tak máte výrazně větší režii při přístupu k datům (režie sítě, režie protokolu, různých vrstev).
Tohle prostě není pravda. ORM nemá principielní důvod aby měl problém s výkonem. Je to mapper. Ty to popisuješ, jako kdyby si načetl všechny data z databáze k sobě a pak přes foreach to filtroval. Bez ohledu na to, že to některé případi takhle dělají, není to principielní problém.

Já se opravdu nechci bavit o tom, že aktuální ORM implementace mají velké problémy. Já se zajímám o prinicipielní problémy.

Re:Rada při návrhu db tabulek
« Odpověď #190 kdy: 01. 07. 2021, 22:37:31 »
Já se opravdu nechci bavit o tom, že aktuální ORM implementace mají velké problémy. Já se zajímám o prinicipielní problémy.

Možná se nesrozumitelně vyjadřuju, beru. Pokusím se tedy shrnout:

Principiální problém je v tom, že ORM je vrstva nad databází. Očekává se od ní trochu něco jiného než od té databáze.

Pokud bychom přijali, že ideální ORM bude 100% efektivní abstrakce nad databází, v podstatě pak už by databáze nebyla potřeba. Do ORM by se doimplementovaly storage operace a bylo by hotovo.

ORM - jakožto pojem - má smysl jen právě proto, že nepřívětivé vlastnosti databáze mapuje do přívětivých objektových operací ve vyšším programovacím jazyce. Toto nelze vyřešit jinak, než kompromisem. Tedy ztráta pramenící z principu, nikoliv z implementace.

Pavel trefně zmínil absenci statistik (které samy o sobě nedávají 100% odraz skutečnosti). Taky to, že co má databáze při ruce s minimální režií, ORM může získat jen za cenu poměrně vysoké režie (síťová, a další mezivrstvy). Tedy další ztráta pramenící z principu a ne z implementace.

A pak je tu ten třetí důvod, o kterém můžeme diskutovat, jestli je principiální, nebo implementační. To je volba strategie programátorem. Já ji považuji za principiální. U složitých úloh by se jistě dalo uvažovat o tom, že budoucí optimalizátory budou rychlejší a efektivnější. Jenže pořád tu zůstává velká řada triviálních úloh, u kterých může programátor strategii přímo určit a lze ji považovat za optimální. Tedy, můžeme diskutovat o tom, že by v budoucnu mohlo ORM (kdyby mělo statistiky a mohlo vytvářet hinty), mohlo být efektivnější ve složitých úlohách, než ploché SQL, protože ORM má o struktuře dat trochu jiné, a v určitém ohledu lepší informace. Stejný mechanismus by však zdržoval u triviálních úloh, u kterých by programátor stejně dál preferoval sám určit a vysvětlit postup vykonání. Tedy, ručnímu zásahu by se nedalo vyhnout, pokud bychom hledali výkon.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Rada při návrhu db tabulek
« Odpověď #191 kdy: 02. 07. 2021, 00:31:01 »
Já se opravdu nechci bavit o tom, že aktuální ORM implementace mají velké problémy. Já se zajímám o prinicipielní problémy.

Možná se nesrozumitelně vyjadřuju, beru. Pokusím se tedy shrnout:

Principiální problém je v tom, že ORM je vrstva nad databází. Očekává se od ní trochu něco jiného než od té databáze.

Pokud bychom přijali, že ideální ORM bude 100% efektivní abstrakce nad databází, v podstatě pak už by databáze nebyla potřeba. Do ORM by se doimplementovaly storage operace a bylo by hotovo.
To je zajímavá úvaha, ale nevidím v ní potenciál. Já nemám problém s existencí db. Mě relační databáze maximálně vyhovují. Já chci na nich stavět. Podle mě to, že ORM je vrstva nad databází je cajk - jasně, nějakým mapováním z ORM do SQL se ztratí nějaká ta setinka (sic!), ale furt lepší, než reimplementovat ty mraky práce odvedených nad databázemi. Nehledě k tomu, že relační algebra je ideální (technologickej i mentální) základ.
Kdepak. Toto nechme být, tak je to správně.


ORM - jakožto pojem - má smysl jen právě proto, že nepřívětivé vlastnosti databáze mapuje do přívětivých objektových operací ve vyšším programovacím jazyce.
Přesně tak.

Toto nelze vyřešit jinak, než kompromisem. Tedy ztráta pramenící z principu, nikoliv z implementace.
Tuto příčinnost zde nepozoruji.


Pavel trefně zmínil absenci statistik (které samy o sobě nedávají 100% odraz skutečnosti). Taky to, že co má databáze při ruce s minimální režií, ORM může získat jen za cenu poměrně vysoké režie (síťová, a další mezivrstvy). Tedy další ztráta pramenící z principu a ne z implementace.
Ve skutečnosti to není ani pravda, ani směrodatné.
Pokud mají databáze statistiky, tak ať je mají. Já jim je přece nechci brát.
ORM tý databáze do ničeho nekecá. Jen ať dělá co nejlepšího umí.
Zde je naprosto mylně uvedený vztah. Nejedná se o ORM versus DB. Ale o ORM versus vývojář.
Pokud je třeba získat nějaké informace, tak se ptáme - kdo je dokáže získat lépe stroj=ORM, nebo vývojář?


A pak je tu ten třetí důvod, o kterém můžeme diskutovat, jestli je principiální, nebo implementační. To je volba strategie programátorem. Já ji považuji za principiální. U složitých úloh by se jistě dalo uvažovat o tom, že budoucí optimalizátory budou rychlejší a efektivnější. Jenže pořád tu zůstává velká řada triviálních úloh, u kterých může programátor strategii přímo určit a lze ji považovat za optimální. Tedy, můžeme diskutovat o tom, že by v budoucnu mohlo ORM (kdyby mělo statistiky a mohlo vytvářet hinty), mohlo být efektivnější ve složitých úlohách, než ploché SQL, protože ORM má o struktuře dat trochu jiné, a v určitém ohledu lepší informace. Stejný mechanismus by však zdržoval u triviálních úloh, u kterých by programátor stejně dál preferoval sám určit a vysvětlit postup vykonání. Tedy, ručnímu zásahu by se nedalo vyhnout, pokud bychom hledali výkon.
Výborně. Toto mi dává smysl.
Podle mého názoru, ORM je k tomu, abychom pracovali s nějakými daty nějakým jiným, snad lepším, způsobem. Tak, jak jsi to pěkně popsal o pár odstavců výše. A hlavně aby usnadnilo ruční práci co se mapování týče. Já vůbec nemám problém s tím, aby vývojář tomu ORM řekl, že v tomto a v tomto případě má zvolit jinou strategii. Ve skutečnosti si myslím, že schopnost ORM ukázat, jaký SQL nakonec do db posílá považuju za zcela nutnou funkci. Stejně jako možnost do toho ORMku kecat.
Zároveň si myslím, že kecat mu do toho bude muset jen v několika málo případech.

Možná by se to dalo popsat tak, že v kanceláři si v nějakém budoucím fantastickém ORM naklikají najaký datový model (samozřejmě blbě), ORM z toho syncne změny do databáze a vesele ukládá. Firma funguje, následně narůstají data, databáze se zadejchává, zavolají si Odborníka. Ten zkontroluje datovej model, upraví. Pak zkontroluje statistiky dotazů, a zhodnotí, že na tomto a tomto místě ORMko zvolilo nevhodnou strategii, a změní to.

Nevidím zde prostor pro optimalizaci v podobě constraintů v databázi, protože buď je ORM blbé, a programátor to tam teda doplní ručně a ORM mu nebrání; nebo je ORM schopné, a ví, že ten contsraint může vložit do databáze a udělá to.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #192 kdy: 02. 07. 2021, 14:31:37 »
Citace
Zde je naprosto mylně uvedený vztah. Nejedná se o ORM versus DB. Ale o ORM versus vývojář.Pokud je třeba získat nějaké informace, tak se ptáme - kdo je dokáže získat lépe stroj=ORM, nebo vývojář?
Ty, které může lépe získat stroj: tzn. statistiky atd...., ORM získat za rozumný čas nemůže, protože prostě na ně "nevidí". Nemá ty data, ty má DB. Proto je tato otázka chybně položená. Není problém v "STROJ versus VÝVOJÁŘ", problém je v tom, jaké možnosti má stroj na úrovni ORM vrstvy - a že kdybys chtěl ty problémy překonat, tak bys musel do té ORM vrstvy nutně zabudovat i celou databázi.
No a pak jsou informace, které prostě stroj (přinejmenším v dnešním stavu AI) získat prostě nemůže. To, co si od takového ORM představuješ je defakto schopnost programovat, a ta jestli je principiálně vůbec možná (asi jo), tak je úplně někde jinde, než co dneska umíme.
Jak píše Pavel: i SQL databáze, která řeší jednoduché a matematicky snadno popsatelné problémy relační algebry, řeší u každého přístupu jen pár vhodných strategií - a i tam občas selhává. A ty bys chtěl vlastně po ORM něco, co by umělo ne volit jednu strategii z pár "napevno zadrátovaných", ale které by umělo algoritmizaci. Jasně - teroreticky to asi možný je. Ale až to budeme umět, tak budeme umět konstruovat androidy - a programátoři přijdou o práci.... :-)

Re:Rada při návrhu db tabulek
« Odpověď #193 kdy: 02. 07. 2021, 14:43:01 »
@BoneFlute

Podle mě v té Vaší úvaze zanedbáváte právě to, co je skutečnou překážkou.

ORM, na to, aby mohlo dělat práci blízkou optimu, musí databázi znát. Dobře, strukturu zná, protože si ji spravuje. Co nezná, jsou ty statistiky (nikoliv dotazů, ale tabulek - jejich dat a rozložení). ORM netuší, jestli v jedné tabuli je 100 záznamů a v druhé milion, nebo naopak. Neví, jestli jsou hodnoty rozprostřené rovnoměrně, nebo nerovnoměrně.

S touto znalostí pracuje databáze (vy říkáte, že to jí tím neseberete). Ale pracuje s tím i programátor, protože ten podle toho volí způsob dotazu (Pavel vypisoval šířeji). ORM zvolí outer join tam, kde programátor usoudí, že může zvolit inner join. ORM zvolí subselect tam, kde programátor zvolí (lateral) join. ORM zvolí posloupnost dotazů tam, kde programátor jeden složený. ORM uzamkne příliš, tam, kde programátor může usoudit, že stačí méně. To jsou ta nepřekročitelná omezení (resp. překročitelná jsou jedině tak, že se v ORM stejně uchýlí k sestavení konkrétního dotazu).

Ani s tou milisekundou sem, milisekundou tam podle mě nemáte pravdu. Obecně ORM systémy generují vyšší počet dotazů. Když máte 50 dotazů na úkon, a na každém dotazu ztratíte 5 ms a k systému přistupuje 100 lidí, vytvoříte si lap 25 sekund. V lepším případě se to projeví jen tím, že každý uživatel čeká o čtvrt sekundy déle, což bývá přijatelné. V horším případě čekají transakce za sebou (kvůli ACID) a lap na uživatel je mnohem vyšší.

Podle mě v úvahách směřujete spíš od ORM k nějaké objektové databázi, která aspoň některé z problémů řeší (ale zase přináší trochu jiné).

Ale jinak fajn diskuse, dává mi to trochu větší vhled do toho, jak o tom přemýšlejí ORM uživatelé, a jak bídně umím popsat to, co jsem přesvědčený, že je hlavní a nepřekročitelný problém. Díky.

Re:Rada při návrhu db tabulek
« Odpověď #194 kdy: 03. 07. 2021, 07:22:28 »
Nejedná se o ORM versus DB. Ale o ORM versus vývojář.
Pokud je třeba získat nějaké informace, tak se ptáme - kdo je dokáže získat lépe stroj=ORM, nebo vývojář?
To ORM same od seba nedokaze ziskat ziadne data, za tym ze ziska nejake data stoji vyvojar.

Samozrejme by bolo mozne namietnut, ze na programovanie ORM staci jeden programator a ked mame ORM tak nam stacia lopaty.

I toto je omyl, programator ktory to ORM pouzije, by mal byt schopny vystup validovat. Ak nie je validny tak musi byt schopny porozumiet tomu co chce ORM dotazom poslanym do db povedat.

V kazdom pripade vyvojar musi byt schopnejsi ako to orm, inak bude len skusat na slepo a lovit na sof.

Jedine co moze priniest ORM vyvojarovi ze mapuje typy z rdbms na typy v aplikacnom jazyku, ktory je zvedsa typovo ovela slabsi ako rdbms. To ostatne je len zjednodusenie pre slabsich kolegov, da sa na tom zdanlivo usetrit. Co sa v buducnosti predrazi, ked to potom musi dlho riesit niekto z podstatne vyssou hodinovou sadzbou.