Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Miroslav Šilhavý

Stran: 1 ... 5 6 [7] 8 9 ... 206
91
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 27. 06. 2021, 22:46:41 »
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.

Zkuste mi vysvětlit, v čem si myslíte, že může být aplikace efektivnější - třeba v tom případě více používaného fóra. Mně nenapadá nic, co bych dokázal udělat v aplikaci rychleji, než to přenést do databáze. Včetně označení uživatelem nepřečtených příspěkvů, včetně označení přečtených, ... (Pokud ovšem nezvolím, že to bude client-side logika, ale to asi není případ, o kterém hovoříme zde).

92
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 27. 06. 2021, 22:26:53 »
Jinak třeba přenos dat mezi klientem a serverem má také dost velkou režii - lokální výpočet může být v nanosec, výpočet na aplikačním serveru s execem jste v nejlepším případě na desetinách milisec.

pridani validaci na klientu naopak snizi prenos dat mezi klientem a serverem (nevalidni data se na server vubec nedostanou).

jinak databaze je uzke hrdlo temer u vsech aplikaci s trochu vetsim trafikem.

Vstupy musíte validovat, ale konzistenci dat taky. To se nevylučuje.
Ale hovořil jste o složitější validaci - a pod tou si představuji např. to, že k validaci potřebuji ověřit data v jiných strukturách, abych mohl říct, že vkládaný vstup je v pořádku.

To určitě nezpůsobuje úzké hrdlo.

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.

93
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 27. 06. 2021, 21:54:43 »
Čímž jsme se efektivně dostali na půdu čistého SQL a namapování dat do nějaké vyšší struktury.

mozna u 1% dotazu, u zbytku vam to usetri praci. Mel byste priklad takoveho dotazu, ktery nejde napsat v querybuilderu?

Typicky složité updaty, případně zřetězené s WITH.
Stačí mít UPDATE ... SET sl1.subquery.sl1, ..., FROM (SELECT ...) AS subquery, ...
Jakmile do toho subquery potřebujete zahrnout window funkce, řazení přes kostku, ..., tak už docela jistě narazíte. Pokud nenarazíte, bude ten zápis stejně nečitelný.

Zrovna tyto operace chcete přenést do databáze, protože zrovna na nich je řádově efektivnější.

databaze je vetsinou uzke hrdlo aplikace, aplikacni kod lze snadno horizontalne skalovat.

Což považuji za tradovaný omyl, pramenící z neschopnosti využívat vlastností SQL.
Prakticky nikdy nenaleznete případ, kdy by byla aplikace výkonnější, než databázový stroj. I ideálně napsaný aplikační kód bude mít hendikep ve zbytečném síťovém provozu a nárocích na další prostředky.

Situací, kde je nevyhnutelná potřeba horizontálního škálování, je tak málo, že je dost nepravděpodobné, že by se s tím programátoři setkávali. Obvykle je horizontální škálování z nouze ctnost.

94
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 27. 06. 2021, 21:40:59 »
Kdyz uz mate ORM schema, muzete z neho automaticky generovat webove formulare, REST API, GraphQL api. ORM umoznuje pridani informaci, ktere SQL nepodporuje, treba ruznych pokrocilejsich validaci.

To jsme zase u jádra pudla. Třeba ty "pokročilejší validace" obvykle obnášejí to, co psal Pavel - čtení dat a iterace v kódu programu. Zrovna tyto operace chcete přenést do databáze, protože zrovna na nich je řádově efektivnější.

Trochu mi uniká výhoda. Místo toho abych napsal exec("SELECT ..."), tak píšu cn.select("tablename").where(...)

Ono to obvykle naráží i na to, že takový query builder neumí celý dialekt dané databáze (nebo její verze), takže to stejně skončí u exec("SELECT ...").

query buildery umoznuji kombinovat raw SQL, takze umi cokoliv

Čímž jsme se efektivně dostali na půdu čistého SQL a namapování dat do nějaké vyšší struktury.

95
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 27. 06. 2021, 21:34:41 »
Trochu mi uniká výhoda. Místo toho abych napsal exec("SELECT ..."), tak píšu cn.select("tablename").where(...)

Ono to obvykle naráží i na to, že takový query builder neumí celý dialekt dané databáze (nebo její verze), takže to stejně skončí u exec("SELECT ...").

96
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 27. 06. 2021, 00:48:46 »
...

Proč si myslím, že to nejde: dotaz, aby byl jasné "co chci" se určitě dá sestavit jednoduše. SQL či přes ORM - to jsou jen dva způsoby, jak sdělit svoje přání o tom, jaká data chci naservírovat. (query-language)

Stroj musí úlohu provést. To dokáže vždy - i na tom se (asi) shodneme. Nám jde o to, aby to dělal efektivně.

Výkon není závislý na tom, jak dobře napíšu dotaz.
Výkon je závislý na tom, jak dobře napíšu dotaz pro daný způsob, jakým jsou data uložena (zindexována apod.).

Těch způsobů, jak uložit a zindexovat data a jak sestavit plán pro vykonání dotazu, je nepřeberné množství. I kdybychom uvažovali o prostém sekvenčním čtení, musí se engine rozhodnout, v jakém pořadí načte entity, aby bylo filtrování kritérií efektivní. Jakmile se objeví možnost užití indexů a přidají se vnořené smyčky, roste závratně množství možností, jak to hardware zpracuje. Z těchto možností potřebujeme co nejdřív eliminovat ty, ke kterým máme dostatek informací, že efektivní být nemůžou a u zbylých odhadnout, jak by takový postup trval, kolik paměti by vyžádal apod. (query-plan)

Vyjadřuju se trochu srozumitelně?
Dál budu odpovídat až zítra, teď dobrou noc. :-)

97
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 26. 06. 2021, 23:55:35 »
Mám zájem řešit, že zda dokáže stroj vytvořit stejně kvalitní dotaz do relační databáze jako člověk; to ale nemáš zájem řešit ty.

Zredukoval jste tu otázku až příliš. Kvalitní dotaz - co si pod tím představujete? Zkusím popsat, co si před tím představuju já.

Každá databáze se dá na úrovni uložení dat realizovat různě - vazbami, sloupci, složenými strukturami. Ta samá data, s tím samým smyslem, můžete uložit mnoha způsoby. Ten způsob volí programátor, který má představu, jak data porostou, jak budou rozložené hodnoty a jak budou používána (transakčně, pro častý zápis, pro čtení). Dál potřebuje DB nějaké indexy, aby dohledání hodnoty bylo rychlé. To taky musí rozhodnout člověk.

Nic z toho nejde nechat na stroji, protože vstupem jsou předpoklady (nejde to vyčíst z dat samotných).

Dovedu si však představit situaci, že databázi řeknu (nějakým způsobem - ať už přes SQL, nebo ORM nebo whatever else) vše potřebné. Popíšu jí data, aby je ultimativně chápala. Sdělím jí, jak budou užívána a jak budou rozložené hodnoty, jak data porostou do délky.

Pokud toto všechno splním, pak si dovedu představit, že stroj dokáže sestavit ideální dotaz a databáze ideální plán na vykonání.

A to je to, k čemu jsem se vyjadřoval a možná neuměl vysvětlit. Takto ultimativně popsat situaci, aby stoj mohl sestavovat dotazy ideálně, by podle mě bylo složitější, než je současný stav RDBMS / SQL.

98
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 26. 06. 2021, 22:06:42 »
(omyl, smazáno)

99
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 26. 06. 2021, 22:01:05 »
Na druhou stranu když vidím lidi, čeho všeho jsou neschopni s databází, tak nevidím důvod, proč by to nemohl dělat stroj. Tak blbej dokáže bejt taky.

Já mám právě ten pocit, že to celé je řešení falešného dilematu: dělat to blbě a složitě vs. dělat to blbě a aspoň jednoduše.

V tom ORM a objektové databáze vítězí - a v praxi je přebytek programátorů bez znalostí do hloubky, a nedostatek se znalostmi. To mluví pro ORM.

Ono je takové hloupé udělat aplikaci nad ORM nebo objektovou databází, a pak si vzpomenout, např., že chci hlídat konzistenci. Třeba i složitý mechanismus na hlídání konzistence. Pak se to musí psát v aplikaci a doufat, že aspoň něco z toho ORM přenese na databázi. Zbytek poběží v aplikaci - tj. data se budou muset po síti nebo socketem přenést z DB do aplikace a odedřít to, co může být out-of-box.

Stejně tak, databázový systém (ať už to je RDBMS nebo něco jiného) může optimalizovat svoji práci teprve ve chvíli, kdy má nápovědy. Kdy ví, že určitá hodnota "zde" má nějaký vztah k hodnotě "onde" (0:n - m:n). Toto si ten stroj nemůže domyslet, protože maximálně ví, jak to s daty vypadalo před chvílí (statistiky), ale nemá jistotu, jestli to platí ještě teď, nebo bude platit za sekundu. Aplikace to vědět může, ale ta už stojí v místě, kam je potřeba na takovou práci data přenést (zdlouhavé, rozežrané).

Ale jako taky znám případy, kdy se nic takového nemusí řešit a je úplně jedno, jestli jsou data sourodá v čase, neřku-li v transakci. Tam pak může nerelační přístup k problému ušetřit práci programátora. Obvykle to ale tíhne spíš k ACID požadavkům.

Neznám moc dobrých programátorů, kteří by - po dobrém poznání obou způsobů - preferovali objektový přístup. Většinou se to pojilo s tím, že RDBMS uměli mizerně (jak jste psal), a objektový přístup byl záchranný kruh.

100
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 26. 06. 2021, 20:41:44 »
Ve skutečnosti si s něčím takovým hraju, takže to mám z první ruky. Napsat pravidla, kdy tomu ORM řeknu, že v tomto případě má použít tuto nebo jinou strategii je trivka.

Ona je trivka i data rozložit do RDBMS - to je asi o osobní preferenci.
Pointa je v tom, že obě práce vedou k tomu samému - jen jinými prostředky, jiným jazykem a v jiných momentech popisujete totéž.

U objektových databází a ORM máte rychlý start a problémy lze dlouho řešit triviálními "hinty". Pak to narazí na mantinel, kde už s tím nejde hnout jinak, než refactoringem aplikace a horizontálním škálováním.

U RDBMS strávíte nějaký čas na začátku a v průběhu optimalizací. Na opravdový limit, kdy by bylo potřeba refactorovat aplikaci narazíte o mnoho později.

Abyste rozuměl, nehádám se o tom, že jeden přístup exceluje nad druhým. Pro oba mám pochopení a u obou vidím nevýhody i výhody.

Z části vznikají flamewary i z toho, že pro spoustu lidí je MySQL / MariaDB jediný RDBMS, který kdy poznali. Pokud bychom zúžili diskusi na MySQL, pak bych stál taky prakticky bezvýhradně na straně ORM a objektových databází.

101
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 26. 06. 2021, 20:28:20 »
Vysvětlit ORM (namapovat) strukturu, aby to vůbec umělo, by bylo stejně složité, jako využívat přímo SQL.
V tomto se hrubě neshodneme.

Těžko nad obecnou (objektovou) strukturou dat vysvětlíte stroji, co a jak má/může optimalizovat. DB engine to může leda odhadovat nad vytipovanými statistikami. Když to necháte na takové empirii, buďto to bude neefektivní (nikdy nemůže vyzkoušet všechny možné přístupy ve všech možných kombinacích), nebo to bude ubírat výkon. Nebo dáte enginu hinty. Pokud by ty hinty měly být ideální, budou stejně složité jako v RDBMS / SQL.

Proto dnes vídáme horizontální škálování prezentované jako výhodu i v situacích, ve kterých by RDBMS stíhal i před dvaceti lety a s tehdejším hardwarem.

(Ovšem nerozporuji, že někdy může být takový přístup efektivnější, i z hlediska financí)
Vůbec nereagujete na to co píšu.

A na co tedy? Psal jsem, že stejně definitivně namapovat v ORM nebo jiné abstrakci datové struktury, aby byly srovnatelné výkonné, by byla stejně složitá práce, jako rovnou používat SQL.

102
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 26. 06. 2021, 20:07:38 »
Vysvětlit ORM (namapovat) strukturu, aby to vůbec umělo, by bylo stejně složité, jako využívat přímo SQL.
V tomto se hrubě neshodneme.

Těžko nad obecnou (objektovou) strukturou dat vysvětlíte stroji, co a jak má/může optimalizovat. DB engine to může leda odhadovat nad vytipovanými statistikami. Když to necháte na takové empirii, buďto to bude neefektivní (nikdy nemůže vyzkoušet všechny možné přístupy ve všech možných kombinacích), nebo to bude ubírat výkon. Nebo dáte enginu hinty. Pokud by ty hinty měly být ideální, budou stejně složité jako v RDBMS / SQL.

Proto dnes vídáme horizontální škálování prezentované jako výhodu i v situacích, ve kterých by RDBMS stíhal i před dvaceti lety a s tehdejším hardwarem.

(Ovšem nerozporuji, že někdy může být takový přístup efektivnější, i z hlediska financí)

103
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 25. 06. 2021, 14:30:55 »
A ještě bych přidal, že bohužel dosti často majitelé Audi haněj letadla, že je to neflexibilní řešení, a Ti co létají haněj Audi, že jsou drahé. A to zpravidla Ti, co třeba nikdy tím letadlem neletěly, takže nevidí jeho výhody a jen nevýhody - a naopak.

Mám stejný pocit. Mám dokonce častou zkušenost, že když se zavilým příznivcům ORM a NoSQL na konkrétních usecasech ukáže ekvivalent v RDBMS, tak pochopí, že výsledná složitost není vyšší a potenciál výkonu vyšší je ("kdybych býval věděl, co budu potřebovat a jak se projekt vyvine, tak bych použil RDBMS od začátku, protože by to byla stejná práce a výsledek lepší").

Na druhou stranu ale neignorujme, že někdy je flexibilita řešení cennější, než jeho výkon. Mnohdy, v reálném životě, je lepší hrnout rychle neoptimální řešení. Často se v praxi přijde na to, že včerejší nápad je potřeba dnes stejně přehodnotit (ne kvůli technickým nedostatkům, ale prostě v životě nefunguje) - a to se stihne 2x udělat rychleji, než v RDBMS rozmyslet první změnu ve schematu.

104
Vývoj / Re:Rada při návrhu db tabulek
« kdy: 25. 06. 2021, 13:52:17 »
SQL je dostatečně expresivním jazykem, většina ORM toho nedosahuje.
Neni, je to jazyk nizke urovne abstrakce...

SQL je poměrně primitivním dotazovacím jazykem, Kit měl asi na mysli PL/SQL. To je taky primitivní jazyk, stačí si uvědomit, že nemá jakékoliv složitější datové struktury (např. něco jako struct/record, seznamy!), pouze primitivní typy, takže např. volání procedur či funkcí s nějakým obsahem v parametrech je zoufalé, jakákoliv práce se seznamy znamená opakované čtení dat z tabulek. Ladění otřesné. Vlastně ani žádnou podobnost s vyššími jazyky nevidím.
Naproti tomu vždy jde vytvořit nějaké ORM, které jedním příkazem s pár parametry provést (různě) složitou operaci s mnoha dotazy SQL a jejich sestavením na pozadí. Ale to ORM musí nejdřív někdo vyvinout.

Problém všech abstrakcí je, že zjednodušují vývoj, ale zhoršují výkon oproti práci s normalizovanými datovými strukturami. Ideální ORM by umělo dokonale převádět požadavky do SQL, rozhodovat se, kdy užívat transakce a kdy ne, jak uzamykat záznamy, ... Vysvětlit ORM (namapovat) strukturu, aby to vůbec umělo, by bylo stejně složité, jako využívat přímo SQL.

ORM a NoSQL volí určitý kompromis, někdy přidávají možnost horizontálního škálování výkonu.

To, co vyvolává hádky mezi zastánci těchto dvou přístupů je právě to, že ten kompromis je od určitého okamžiku už nepřekročitelný, a schopnosti RDBMS databáze se suplují na úrovni aplikace (či jazyka). Z pohledu vývoje je to možná pohodlnější (možná jen zdánlivě, vedou se o tom spory).

Funguje to dobře, když vývoj i zadavatel aplikace jsou srozuměni s tím, co to obnáší a bude obnášet do budoucna. Srážka nastává, když pak přijdou požadavky, nápady, nebo kritika řešení, které by se daly řešit mnohem efektivněji pomocí RDBMS.

Pak si taky všímám, že někteří schopnosti databáze posuzují z pohledu, jak pohodlně jim naservíruje výsledky až k cílovému zpracování. Jiní zase vnímají, že uvnitř těch mechanismů musí být spousta práce (= ztraceného výkonu), která se vynakládá vzdáleně od optima.

Podle mě je ten myšlenkový souboj nerozsouditelný, podobně jako se nedá najít jednoznačná odpověď, jestli koupit levnou Dacii nebo drahé Audi, když jsou obě auta stejně velká a ve městě jezdí stejně rychle (50-80 km/h) a argumentovat tím, "co kdyby přišla potřeba jezdit napříč Evropou". Jeden koupí preventivně Audi, druhý si koupí letenku a oba jsou spokojení se svým řešením.

105
Hardware / Re:PC sestava pro grafickou práci (Adobe)
« kdy: 24. 06. 2021, 10:14:21 »
V roku 2021 mu radíte stroj s Intelom?, srsly?
Na Adobe určitě Intel ano.
Myslím, že už to dnes neplatí.
Zdroj: https://www.pugetsystems.com/recommended/Recommended-Systems-for-Adobe-Photoshop-139/Hardware-Recommendations

V článku jsou hezky shrnuté i další komponenty, takže doporučuji tazateli si to přečíst.

Názory se různí. Někteří tvrdí, že AMD už není problém, někteří říkají, že není problém, ale že má nižší výkon. Adobe údajně málo optimalizuje pro AMD, možná je to i tím, že mnoho úloh stejně nejde dobře rozložit na velký počet jader.

Asi už jsou pryč doby, kdy se Photoshop hroutil na AMD, neřku-li na Cyrixu.
Přesto je Intel bezpečná volba, která určitě fungovat bude tak, jak je slibováno a dá se očekávat.

Stran: 1 ... 5 6 [7] 8 9 ... 206