Příspěvky

136

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 08:05:09 »

Případně, pokud chci transakčnost, tak:
- začni atomický blok
- najdi v poli požadovaný záznam
- uprav v něm co potřebuješ
- commit

Tohle zní slibně. Takhle nějak fungoval jeden z módů db4objects.

Tenhle postup je důvod, proč jsou objektové databáze i vlastně i věci napsané nad ORM pomalé. Pokud objekt není už v paměti, tak načtení objektů po jednom je drahé (počínaje diskovými operacemi a konče sítí). Částečným řešením je držet si objekty v RAMce - ale tím se dostanete do problémů s udržením konzistence, zamykáním a se správou cache. A navíc potřebujete kopii databáze v paměti. V momentě, kdy se mi hromadná operace změní na cyklus nad individuálními operacemi, tak jde výkon do háje.

Oproti objektovému přístupu SQL popisuje pouze hromadné operace (operace nad relacemi). Operace nad jedním záznamem je jen jeden speciální případ. Díky tomu má optimalizátor prostor pro výběr z implementací vhodné pro zpracování většího množství záznamů (seq scan, merge join) nebo naopak menšího množství (index scan, nested loop). Podle mne je tohle základní problém.

Když se pracuje s izolovanými hodnotami, tak objektové databáze nebo ORMka nemají jediný problém. Ale pro hromadné operace, tam vlastně není moc prostoru jak je implementovat efektivně (neduplikovat objekty v RAM, redukovat síťové operace, redukovat diskové operace). Řešitelné by to podle mne bylo - tytéž operace, které dělám nad objektem bych měl být schopen udělat nad kolekcí objektů - a mohlo by to fungovat pokud by vývojář použil tento interface. Jakmile programátor ale použije cyklus, tak tam není možná optimalizace - ledaže by se reimplementoval cyklus, a že by klient dokázal distribuovat volání operací na databázový server - a že by databáze dokázala pro implementaci cyklu použít vlastní optimální algoritmus (seq scan nebo index scan).

Chápu, že programátor chce být odizolován od implementace uložení dat. Nicméně je potřeba počítat, že data se mezi storage a aplikací nepřesouvají nekonečně rychle, a že je vždy režie na záznam, a na operaci. A totéž platí i o načítání dat. Pokud pak používám interface, který určuje, že mám pracovat s konkrétním záznamem, tak už neumožňuji efektivní implementaci (rozdíl v rychlostech v přístupech k izolovaným hodnotám a v hromadných operacích) může být i o řád nebo o dva. Pokud máte v datech milióny, desítky miliónů záznamů, tak rozdíl v efektivním a neefektivním zpracování bude v hodinách.

Co zaznělo v diskuzi, tak se vývojáři objektových databází zaměřili na co nejlepší bezešvou integraci databáze s objektovým prostředím. Ale pak naráží na  efektivitu přístupu ke uložišti. SQL databáze na to jdou úplně z druhé strany. V prvé řadě řeší efektivitu přístupu k datům (minimalizace random IO, minimalizace přenesených dat po síti). Pokud mám data uložená lokálně (nedochází ke sdílení, nemusím řešit síťovou komunikaci, data jsou na ssd - nemusím řešit random IO), tak ten objektový přístup může fungovat. V opačném případě si to moc nedovedu představit. SQL databáze se snaží vývojáře izolovat od některých implementačních detailů (nemusí řešit jestli se použije seq io nebo random IO, nemusí řešit síťovou komunikaci) - a tím končí. Vůbec se nesnaží o nějakou integraci s vývojovým prostředím. To ani nejde. Nemám a ani nechci Postgres pro Javu, a jiný pro C#.

137

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 23. 04. 2021, 05:40:55 »

Já vždycky trochu trpím, když vidím v nějaké databázi práci některých kolegů aplikačních vývojářů.
Databáze je plná vložených procedur, které jsou psané, jako by psali aplikaci - spousta proměnných, smyčky, kurzorové operace, user funkce, temporary tabulky do kterých postupně různě přidávají a odebírají záznamy,... aby z procedury po dlouhé době nakonec vypadl nějaký vcelku triviální výsledek.
Prostě jsou to zvyklí psát jako aplikaci a nevnímají, že rychlá a efektivní práce s daty v SQL má trochu jinou logiku.

Zní to banálně,  ale pokud chcete dělat dobře s relačními SQL databázemi, tak je potřeba znát něco o těch relačních databázích, a hlavně to SQL.

Docela dost programátorů přecházelo na SQL databáze s file databází jako FoxPro, u nás PC Fand nebo zmíněný ADABAS, a když zjistili, že jsou tam kurzory, a že se v tom dá programovat plus mínus stejně, jen ten message box tam není, tak převedly ty starší aplikace (a i sebe více méně 1:1) do SQL, a měli hotovo. Viděl jsem fakt otřesný věci v Oracle PL/SQL, zrovna tak v T-SQL. Znám i pár lidí, co ty věci napsali, a jsou to fajn lidi (a kolikrát neuvěřitelně i pracovití, a zkušení, kolikrát pokorní, skromní lidi). Problém je, že jim chybí znalostní fundament. Ti lidi si nepřečetli jedinou knížku o programování (vyjma nějakých úvodních manuálů a tutoriálů). A pak už si vystačí jenom s Googlem. Dokáží vyřešit lokální problémy, ale chybí jim znalost konceptu - a pak si nedokáží dobře zobecnit svoje zkušenosti. Google je peklo i nebe v tom, že umožní vyřešit problém, aniž by člověk musel mít znalosti.

Zrovna pro storky existuje jak pro MS velice kvalitní literatura (pro MS i v češtině), tak i pro Oracle - a to už 20-30 let.  Třeba knížky od Feuersteina jsou docela tenké a čtivé, a dají se přečíst za dvě odpoledne. Jako každá technologie, uložené procedury se nehodí na všechno, a ne každý styl programování je vhodný (jsou super na práci s daty, ale jakmile se začnou používat pro psaní UI, tak už to nefunguje). Je potřeba respektovat technologii (že se v Oracle programuje jinak než v MSQL a úplně jinak v PC FANDu nebo FoxPru, a úplně jinak s nějakým ORM), a je potřeba si o tom něco napřed načíst. V podstatě každý, kdo si přečtě dvě tři dobré knížky, tak je mezi programátorama za chvíli eso - protože skoro nikdo nečte (i mně dělá problém udržet koncentraci na nějakou knížku víc než pár dní - to by člověk potřeboval měsíc někde v klidu).

Programovat je jednoduché - a technicky zaměřený člověk na to může přijít intuitivně relativně rychle. Dobře programovat v něčem - to už intuitivní rozhodně není. Na to jsou potřeba zkušenosti, příležitost použít dostatečně dlouho nějakou technologii, mít možnost řešit problémy, řešit dostatečně komplexní úlohy. A je velký rozdíl jestli člověk začíná od nuly, nebo se opře o zkušenosti předchozích generací vývojářů.

138

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 21. 04. 2021, 13:23:00 »

Doplním, že vtipné jsou optimalizace databáze, které se neprovádí nad zdrojem / ve spolupráci s vývojem, ale nad hotovou databází u zákazníka. A jak to dokáže zčubčit data, až se tam nahraje update, který s ničím takovým nepočítá - to je teprve sranda. V tom úplně nejlepším případě aktualizace selže! V horším případě se aktualizaci povede někomu odblokovat nebo dokončit a děj se vůle boží. Člověk se snaží psát blbuvzdorně, ale bůh pořád vymýšlí důkladnější blbce :-D

A kdybyste používali relační databázi s constrainty definovanými na straně databáze, tak se vám nemůže nic rozjet.

139

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 21. 04. 2021, 11:42:50 »

Kdyby se aplikace napsala tak, že klíčové výpočty se provedou SQL nebo uloženými procedurami, tak by mohla být ještě o řád rychlejší.

Již tu zaznělo slovo kompromis. V reálu je databáze součástí celého řešení a troufnu si tvrdit, že aplikační část bývá podstatně složitější než úkoly prováděné databází. Budu-li honit maximální výkon s minimálními požadavky na HW, budu muset optimalizovat umístěním hodně logiky a výpočtů do stored procedures. Pokud to nemusím hrotit, budu se maximálně snažit udržet aplikační logiku v jednotném prostředí, nad kterým má plnou kontrolu IDE vývojářů (debugování, trasování, snadný refaktoring). Ano, třetí strana bude muset přistupovat přes aplikační API, ale to se obvykle stejně vytváří i z řady jiných důvodů. Pro mě je DB konzistentní storage, ideálně hodně rychlý pro složité joiny, ale aplikační logiku (tedy právě třeba ty zmiňované výpočty) chci držet ve zdrojáku aplikace, pokud mi to požadavky na výkon dovolí.

Uznávám, že tohle je už hodně kontroverzní téma. Jednak zdrojáky uložených procedur můžete mít ve zdrojácích aplikace, jen je jiný deployment. Ono nejde ani tak o maximalizaci výkonu. Častý (typický) problém je, že vývoj probíhá nad prazdnou databází, a nad ní jsou výpočty rychlé. V momentě, kdy se tam naimportují data, tak už je pozdě něco měnit. Určitě není důvod optimalizovat na krev, na druhou stranu to zpomalení dané tím, že se databáze bere jen jako storage, a že stěhujete data mezi db a aplikací je dost brutální. To může být o řád až  dva. Což může být znatelné u interaktivních aplikací - je rozdíl jestli mám výsledek za sec nebo za deset sec, je rozdíl jestli při 1000 aktivních uživatelů mám cpu na 10% nebo na 80%. A může to být problém i neinteraktivních věcí - pokud vám denní úzávěrka běží 10 hodin a musíte ji mít spočítanou do následujích 24 hod, tak už vám moc nezůstane času na údržbu. Pokud by vám běžela hodinu, tak máte výrazně větší rezervu.

Nemám rád přístup, kdy programátoři, kvůli svému pohodlí předají aplikaci, a pak dalších deset let kolem ní tancují admini,  a uživatelé se můžou učekat. A programátoři jsou v pohodě - mají zdrojáky na jednom místě.

140

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 21. 04. 2021, 11:16:01 »

Pavel Snehule:

Co si mysliteo tom, kdyz vyvojari kvuli performance problemum zacnou denormalizovat tabulky v databazi? Ja si myslim, ze to je spatny postup, ze to nefunguje, a ze to akorat zvysi bordel v aplikaci. Podle me u beznych 95% servis v SOA architekture jsou perfromance issue zpusobene bordelem, spatnymi indexy, spatnymi sql dotazy (bordel), blokujicimi transakcemi (kvuli bordelu v kodu), a nema to moc spolecneho s tim, ze tabulkuy jsou normalizovane. A denormalizace jenom prileva olej do ohne vseobecneho bordelu, ktery zpusobuje nejen problemy s performance, ale i bugy.

Potrebuju nejakou munici na vyvojare, az budou pindat ze serivce ma performance issues a budou chtit jako prvni stupidni reseni co je napadne delat denormalizaci.

Na to se nedá jednoduše odpovědět. U OLAPu, když máte star schema nebo snowflake schéma, tak se běžně pracuje s silně denormalizovanými daty (a k tomu se používají databáze optimalizované pro OLAP - sloupcové analytické databáze - vertika, monet nebo snowflake. Tím, že máte předem známé schéma, tak pak můžete používat generické nástroje pro tvorbu MD reportů. OLAP databáze jsou ale sekundární - nejsou primární, a pracuje se tam s transformovanými daty, takže zřejmé nevýhody nenormalizované databáze jsou potlačené.

Pokud máte OLTP databázi s dobře navrženým schématem, tak si myslím, že denormalizace je blbost. Pak mraky dotazů jsou naprosto nesmyslný typu SELECT ... WHERE id = x LIMIT 1. To rozhodně výkonnostně nepomůže. Databáze má evidenci o tom, které hodnoty jsou unikátní, a dokáže tuto informaci využít. Denormalizací redukujete počet unikátních indexů. Nehledě na to, že pak, pokud musíte, tak napsat SQL v ruce bolí, a je neskutečně nečitelné, protože musíte redukovat duplicity - musíte nadužívat DISTINCT, případně zbytečně používat agregace MIN, MAX. To všechno blokuje optimalizaci a má velkou režii. Určitě denormalizací něco zrychlíte, ale dost věcí jinde si zkomplikujete a zpomalíte. Někdy na opravdu velkých tabulkách může mít smysl si přikopírovat sloupec, podle kterého budete filtrovat (někdy se vyplatí data před filtrovat před JOINem, nebo předagregovat). Ale to se bavíme o tabulkách, které mají desítky možná stovky miliónů záznamů.

Pokud se JOIN provádí na úrovni aplikace (díky ORM - kdy v cyklu v aplikaci se volá nějaká metoda, která stahuje data z db), tak se implementuje ta nejpomalejší metoda JOINu, která existuje - nested loop - navíc zpomalený velkou režií vzdálené komunikace. Stáhnout si z jakékoliv databáze 1M hodnot po jednom řádku je neskutečně pomalé. Tím, že denormalizuji, abych získal lepší výkon s ORM, tak já si myslím, že ten nejhorší způsob, co může být. Bohužel ORMka jsou natolik komplikovaná, že tahle dementní cesta, je jediná, která je dosažitelná pro běžného programátora. SQL neumí, a přetlačit ORM také ne - to není o změně ORM, ale o změně patternů (jak to ORM použít).

Pokud si nešikovně namapujete objekty do relační databáze (snažíte se o implementaci dědičnosti na úrovni databáze), tak se může stát, že ve vašem schématu nebude entitě odpovídat tabulka. Pak někdo dělá denormalizaci - ale to není denormalizace, ale materializace entity. V podstatě se dostáváte do správného stavu.

Pokud máte správně znormalizované schéma (a vaše aplikace je OLTP), tak je denormalizace blbost (defakto se snažíte vytvořit jakési materializované pohledy) pro ORM, ale pak se ta databáze hrozně blbě používá. To máte osypky, když máte napsat SQLko.

Je to podobné jako s typovým systémem. V podstatě si můžete vystačit s varcharem (a také jsem viděl takové databáze), ale ve výsledku je to dost pomalé (neefektivně uložená data, neustálé konverze), všechno si musíte udělat sami, a neupozorní vás to na chyby, na které by vás to upozornit mohlo.

141

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 21. 04. 2021, 10:31:21 »

Ty problémy by měla každá databáze - ...... A)

V IT dělá každý, kdo má ruce. .... B)

A)
moje zkusenost je takova, ze kdyz se nepouzije SQL tak zadne problemy s SQL nejsou. U databazi jako ADABAS, SAP-DB, SolidDB, SAP Advanced Server, Faircom, BerkeleyDB nemusite vubec nikoho skolit na SQL , nikdo nevi co je referencni integrita a normalni formy, kdy se u jake databaze smi a nesmi pouzit jaky trigger   a presto je vsechno vpohode a ACID 
Aplikacni programatori si prectou na A4 papiru, jak se jmenuji ty funkce , ktere prectou data z databaze a jak se jmenuji ty, ktere neco zapisuji. Jedine co musi clovek mentalne uchopit je pojem indexu a k cemu je to dobre - ale to se dozvi kazdy programator v prvnim prikladu, kdy ma vytahnout z databaze vsechny faktury s datumem XX.XX.ZZZZ.

Pokud budete používat denormalizované tabulky, a na nich si vyrobíte indexy, tak máte ADABAS. Se všemi výhodami a zejména nevýhodami. Je to jen podmnožina relačního modelu, která má dvě zásadní nevýhody: a) konzistenci si musíte ošetřit na aplikační straně, b) nad files jde dělat jenom omezený počet reportů. Pokud se do toho vlezete, tak to bude rychlé. Pokud ne, tak musíte udělat výrazně víc práce, a ještě report bude pomalý. 

Relační databáze - návrh normálních forem vychází přesně z těch zkušeností s databázemi jako byl ADABAS, a snaží se řešit problémy, které na těchto databázích byly. Byly to jednoduchý stroje, a nijak zvlášť nepodporovali kreativitu. Což je do jisté míry výhoda - nikdo si moc nevymýšlí, a nestaví vzdušné zámky. Pokud jste věděli, co to zvládne, a pokud jste zadání i realizaci s tímto vědomím, tak to mohlo fungovat. Ale to platí na 100% i o dnešním SQL. Dnešní problém je paradoxní. Výkon dnešních databází jak po stránce hw, tak po stránce sw je někde úplně jinde. Ale znalosti a schopnosti vývojářů dost degradovaly a určitě se posunuly. V dobách ADABASu se neřešil uživatelský interface - výsledkem byl papírový report. Dneska programátoři primárně řeší UI, případně integraci komponent, a skrz ty komponenty už nevidí databázi. Díky výkonu dnešních databází se to ještě většinou urve. S nějakým lehkým tuningem (indexy) většina aplikací funguje relativně dobře. Ale ten styl programování je z pohledu db ještě horší než jak se psalo vůči ADABASu. Kdyby se aplikace napsala tak, že klíčové výpočty se provedou SQL nebo uloženými procedurami, tak by mohla být ještě o řád rychlejší.

Nechci se vás dotknout - ale řekl bych, že si ty předrelační databáze idealizujete :-). V té době se fůra věcí nedělala - a) na tehdejším hw vůbec nešla dělat, b) nebyli lidi, c) nebyla data.

142

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 20. 04. 2021, 17:38:30 »

Ty problémy by měla každá databáze - ...... A)

V IT dělá každý, kdo má ruce. .... B)

A)
moje zkusenost je takova, ze kdyz se nepouzije SQL tak zadne problemy s SQL nejsou. U databazi jako ADABAS, SAP-DB, SolidDB, SAP Advanced Server, Faircom, BerkeleyDB nemusite vubec nikoho skolit na SQL , nikdo nevi co je referencni integrita a normalni formy, kdy se u jake databaze smi a nesmi pouzit jaky trigger   a presto je vsechno vpohode a ACID 
Aplikacni programatori si prectou na A4 papiru, jak se jmenuji ty funkce , ktere prectou data z databaze a jak se jmenuji ty, ktere neco zapisuji. Jedine co musi clovek mentalne uchopit je pojem indexu a k cemu je to dobre - ale to se dozvi kazdy programator v prvnim prikladu, kdy ma vytahnout z databaze vsechny faktury s datumem XX.XX.ZZZZ.

B)
jestli tomu rozumim, tak ten rozpor na ktery upozornuji - totiz SQL je jednoduchy koncept versus SQL nikde nefunguje poradne - vysvetlujetezrovna tak  jako nekolik ostatnich kolegu tim, ze uroven lidi v IT je spatna?
Ale co proti tomu delat? Udelat si lepsi lidi?
Nebylo by skutecne mozne, ze ta SQL technologie nastavuje prece jenom pro siroke vrstvy prilis vysokou latku?

Ty databáze, které tu zmiňujete jsou buďto jednoúčelová ořezávátka, nebo hodně jednoduché kousky, které toho moc neuměly, a o to víc musel umět programátor, aby z toho na tehdejším železe něco vyrazil. A zákazník si nemohl moc vymýšlet. A také bylo mnohem méně dat. Nevěřím vám, že na tehdejších databázích nebyly problémy. Hodně projektů mělo problémy, a je pravda, že železo na kterém tyto databáze běželo, tak nebylo nic moc (z dnešního pohledu), ale uživatelé byli rádi, když dostali výsledek (v hodinách). A programátoři, kteří se k těmto databázím dostali, tak nejspíš měli hodně intenzivní znalosti tunění operačního systému, možná i psaní v assambleru.

Dneska si zákazník navýmýšlí, obchodník a projekťák bez znalosti technologie odkývá všechno, a programátor musí aplikaci do dvou měsíců předat. To, co se v době ADABASu psalo 2 roky se dneska píše 2 týdny. A zákazník očekává, že na TB dat dotazy pojedou interaktivně do vteřin (protože mu to obchodníci naslibovali). Navíc tehdejší aplikace byly jednoduché - skládaly se z pár komponent, pár vrstev - žádné železo by to jinak neutáhlo. Dneska tam máte tuny balastu. A když něco nefunguje, tak dá dost práce poznat co nefunguje. Teď měl zákazník problém s lagy, a dost možná (a možná ne) byl na vině REDIS (inmemory databáze), a nebo možná poddimenzovaný virtuál, na kterém to běželo. Klobouk dolů, co se před 30 rokama naprogramovalo, a v čem. Ale z dnešního pohledu mi to přijde jako idyla.

143

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 20. 04. 2021, 15:26:15 »

V USA si můžete na VŠ vybrat čistě teoretické obory i čistě praktické nebo mezi.
Dis. má u nás asi stejný respekt jako maturita.

Podle vaší logiky by chirurg měl být diplomovaný specialista, co se to naučí "ještě navíc k maturitě", ale politolog musí být trojitý Dr. To rozhodně odmítám.

Není důvod ponižovat praktické obory, pokud se člověk naučí vše potřebné pro svojí praxi.
Podle mého názoru jsou teoretické obory na prd a buližník.

Každý ať studuje, to co mu vyhovuje, a co si myslí, že má pro něj smysl. Nejde mít všechno. Můžete míť buďto šírší záběr nebo větší hloubku. Každé má svoje pro a svoje proti. A zrovna tak každý člověk je nějaký, někomu od začátku vyhovuje specializace a jinému ne. A zrovna tak v práci - je dobré mít specialisty, a je dobré mít i lidi, kteří mají širší přehled. Důležité je, aby člověk věděl, co ví, a co neví. Ve stavařině nebo ve strojařině, když něco pokurvíte, tak to může zabít lidi, takže člověk by měl vědět, co dělá.

144

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 20. 04. 2021, 14:31:14 »

A většina programátorů vůbec netuší, jak databáze ale i aplikační servery mohou být rychlé.

Ač jsem jeho názorový oponent - NoSQL databáze považuji za velký přínos a těším se, až MySQL přijde s hybridním řešením SQL i NoSQL databáze - musím se tady pana Stěhule zastat

V USA přijdete do školy na obor programátor a řeknete "chci být specialista na databáze".
Oni vám to umožní.

Poznámka pod čarou: Peníze zde nehrají roli, protože vzdělání v USA i ČR je z pohledu nákladů stejně drahé. V USA zaplatíte víc, ale tam mají také mzdy násobně vyšší. Budovy mají ve skvělém stavu a školy jsou někde mezi lunaparkem, hotelem a vědeckým sympózime.

V ČR přijdete na školu, vyberete si obor a oni do vás řežou klackem, dokud ze školy nevypadnete nebo dokud se nevlezete do krabičky navržené před deseti lety a schválené úředníky s myšlením T602. Výsledek? Na mnoha školách vás nenaučí vlastně nic, protože investujete spoustu času do naučení se toho, co jsou síta a proč vás mlátí klackem, protože to musíte umět.

V zahraničí a není to jen USA, přijdete na školu a věnujete se PŘEDEVŠÍM tomu, co je vám milé. Mnoho lidí má třeba jen tři semestry a velmi rádi na školu vzpomínají. NIKDO je nevyhodil, zaplatili si prostě tři semestry a studovali to, co je TĚŠILO. U nás jsme měli Komenského a jeho škola hrou, ale to je výsměch...

Já žádnou školu v USA nemám - jsem stavební inženýr - ČVUT Praha, Systémové inženýrství. Měl jsem kliku na kantory, měl jsem kliku na dobu, kdy jsem tam byl. Neučili nás produkty, ale učili nás technicky (inženýrsky) myslet (a i když jsem zápasil s geologií, tak aspoň člověk ví, co je buližňík, a co křemen nebo čedič). Databáze jsem se pořádně naučil, až když jsem se dostal k vývoji Postgresu - teprve, když člověk pozná vnitřek, tak pak věci začnou dávat smysl. Dobrý programátor by měl mít i technický cit, aby odhadnul, co je možné, zvládnutelné, akceptovatelné, atd. Aby včas poznal, co je blbost, a co ne.

Každý člověk potřebuje něco jiného, a každý člověk je kolem té 20tky jinak vyspělý, řeší jiné problémy. České vysoké školy (zvlášť ty inženýrského typu jsou víc o obecném přehledu, a o technickém rozvoji než o naučení konkrétních technologií a postupů). Naopak na praxi jsou zaměřené vyšší odborné školy, což je asi to, co byste si představoval (případně firemní vysoké školy - jako je ta škola od Unicornu). Mně ČVUT vyhovoval - ve svých 20 jsem rozhodně nevěděl, co chci dělat, co budu dělat, ani co je zajímavé, a co je všechno možné. To vlastně nevím dodněška. Ale fůra lidí je postavená jinak, a je na nich aby si našli školu, která jim vyhovuje (pokud chtějí studovat). Není to nutnost - je to jen jeden ze způsobů, jak se něco naučit (u těch komplikovanějších věcí moc alternativ není - asi bych nechtěl jezdit po mostu, který navrhoval samouk :-)).

145

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 20. 04. 2021, 12:59:36 »

kdyz uz se ta diskuze rozbehla obecnejsim smerem, tak bych taky rad na neco upozornil.

Mnozi, kteri zde jiz desetileti ctou si jiste vsimli, ze pan Stehule a ostatni relacni evangeliste neustale hovori o tom, jak jsou relacni databaze bezvadne a jak je to vlastne jednoduche. A v dalsi vete pak poznamenaji, ze kazdy den chodi k zakaznikum a opravuji u nich ty spatne navrzene modely, doplnuji chybejici indexy a jsou zdeseni, ze obrovska vetsina uzivatelu  neni s to napsat i jednoduchy prikaz s nejakym joinem. Jak pan Stehule zde v diskuzi uvedl, pred nedavnem u zakaznika zrychlil chod rel. databaze 50x. To je zajimave, predstavte si, ze pouzivate produkt, jehoz jedna zakladni vlastnost se muze i 50 x lisit.
Ja si myslim, ze tady neco skutecne nehraje. Budto je ta technologie tak spatna, ze vetsina uzivatelu/programatoru neni schopna ty relacni databaze rozumne pouzivat a nebo je to skutecne tak jednoduche a slo by to naucit, ale ta technologie vyzaruje jakousi karmu, ktera odrazuje i ty, kteri by se to naucit chteli.
Presto je mozno na zaklade diskuze odpovedet tazateli nasledovne:
- at uz se zvoli jakakoliv jmenovana databaze, tak ten navrh a provedeni bude statisticky mizerne a vykon suboptimalni
- budto to bude statcit a pak je to OK
- nebude to stacit a je treba zavolat ty odborniky pro tu kterou databazi - u postgresql  vime ze existuji minimalne 4 lide
Tazatel tedy musi pouze zjistit, jake kontakty jsou k te ktere databazi k dispozici. Je to vlastne jednoduche.

Ty problémy by měla každá databáze - nejen SQL, ale i NoSQL. Jde jen o to, jakým způsobme přistupujete k datům - jestli sekvenčně nebo použijete index. Možná u NoSQL by bylo problémů míň, protože nepálíte výkon kontrolou referenční integrity, a ACIDem (ale pak ani nechci představit, v jakém stavu budou data).

V IT dělá každý, kdo má ruce. A většina programátorů vůbec netuší, jak databáze ale i aplikační servery mohou být rychlé. Aplikační servery z dob před 20 roky, na kterých běžely bankovní aplikace pro tisíce uživatelů měly výkon dnešních mobilů. Výkon se místo znalostí dohání silou. Je to pomalé - tak tam dáme cluster 10 serverů. Co na tom, že provoz bude 10x dražší a P.B. ví o kolik administrativně náročnější (a kolikrát stačí přidat 5 indexů - na tom snad žádná magie není). Relační databáze neškálují, jít na ně silou prostě nejde. Mongo se moc nevzpírá. Ale je blbost mít 10 serverů, když by se vám jeden flákal.

146

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 18. 04. 2021, 08:39:50 »

Můžeme si poplakávat po rameni, že vývojářům chybí znalosti, anebo je to můžeme zkusit naučit. SQL a relační databáze vymýšleli chytří lidé, a měli ještě dost času, aby to mohli vymyslet důkladně a důsledně (a od té doby uteklo 40 let, takže byl čas na to aby uzrálo).

Máš nápad, co s tím reálně? V rámci svých omezených schopností a možností to dělám pro své lidi - a povětšinou s úspěchem. Jsou pak pro to zapálení a využívají to rádi, automaticky, bezbolestně. Jenže mi přijde, že je to málo a poměrně drahé (užit každého nováčka extra).

Já si myslím, že je základ se vykašlat na nějaké čistě ekonomické kalkulace. Tenhle měsíc jsem pomohl jedné firmě - jenom indexama a identifikací špatných dotazů (špatně napsaných, zapomenutých) jsme snížili zátěž na db serveru co se týče CPU 50x. Tím se jednak odstranila nutnost implementace horizontálního škálování (čímž se dost zjednodušil provoz, a ušetřilo se za tu implementaci), druhak na stávajícím železe se zvládá provoz s velkou rezervou (praktickou pro nečekané špičky, nečekané situace). Tipoval bych, že pro tu firmu jsou to úspory v řádek stovek tisíc (od pracnosti, nákladů na železo, až po snížení rizika platby penále). Přitom jsem nedělal nic, co by se nedalo proškolit za dva tři dny - a lidi se kterými jsem pracoval nejsou nějaká ořezávátka. Ale jak by se to reálně vyčíslilo. Ve firmách potkávám lidi bez energie, projekty se oddalují protahují, nikdo se nechce pustit do některých věcí, protože tomu nerozumí, ale nahrne se to na ně. Jak tohle by se ekonomicky vyčíslilo? Je celá řada nákladů a benefitů, které nejdou ekonomicky vyčíslit, takže je potřeba se odprostit jen od ekonomického uvažování.

Potom, každý člověk ve firmě by pro to, co dělá, měl dostat adekvátní proškolení (od někoho, kdo umí školit, a kdo má požadované znalosti), a to dřív než začne cokoliv dělat (a dejme jednou jednou do roka přeškolení na novější verze případně zopakování). Může to být klidně interní člověk, pokud je v dané technologii na slušné úrovni. Normální člověk nemá čas, prostor se věnovat svojí práci a ještě si udržovat přehled a udržovat kvalifikaci. To je utopie. Dejme tomu, že mám nějakou zkušenost v databázích, a stejně nemám přehled o všech novinkách. Ale se svojí kvalifikací zvládnu odfiltrovat sračky a marketingové žvásty, kterých je 99% kolem nás. To člověk, pro kterého nějaké téma není koníček a denodenní práce (a ještě musí mít nějakou kvalifikaci) nemůže dát.

Myslím si, že se tohle dost podceňuje - ve slušnějších firmách firmy platí školení - ale kolikrát už neřeší, jestli na tu práci, kterou člověk dělá je proškolený, a neřeší, že člověk zapomíná (když se nějaká znalost dennodenně nepoužívá), neřeší, že lidé stárnou, a že se dost mění technologie. Firmy by si měli budovat týmy, kde každý by měl mít základní přehled všech technologií, se kterými se může setkat (a měli by to vysvětlovat lidi, co učí - nikoliv lidi, co dělají marketing), a minimálně pro každou technologii by měl být v týmu člověk, který aspoň ví, co neví. Samozřejmě, že je to drahé, ale jak je drahé mít v týmu lidi, co neví, co dělají. Buďto neudělají nic, anebo udělají blbost (v dobré víře). Změnou algoritmu jsem vyřešil problém (za den), na kterém jiný programátor pracoval (intenzivně) půl roku.

Já sám, kromě komerčních školení, školím co to jde, a každého, kdo chce poslouchat. Ale to gró je na firmách. Které by si měli pamatovat, že odbornou práci maji dělat odborníci. A že ti na stromech nerostou. Je potřeba si je vychovávat, a držet si funkční týmy. Není to jen o penězích, je to o kultuře ve firmě, o atmosféře. Znám šikovný tým, co mně překvapuje, co dokáže dělat, a je to parta ve státním podniku. V podstatě stačí jenom myslet a používat hlavu.

147

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 18. 04. 2021, 05:43:15 »

@Pavel Stěhule

Ahoj,
docela rád jsem si přečetl, cos psal kolem MySQL 8. Nikdy jsem se na to nedíval (mysql / mariadb jdou skoro úplně mimo mě). Nicméně jsem zavětřil, že Oracle s tím jde dopředu - onehdy jsem chtěl trochu zlepšit práci se SQL na jednom cizím projektu, a zjistil jsem, že MySQL už má implementované lateral joiny (nevím jak dobře), MariaDB zatím ne. Takže s jistotou se ty databáze od sebe odklánějí.

Trabl je, jaks psal, práce s MySQL se obyčejně pojí u programátora s neznalostí relační práce, takže nevím, jestli to v praxi moc pomůže. Ten, kdo relační databáze aspoň trochu umí, tak se MySQL vyhýbá obloukem. I ta nejasnost, jaké záměry Oracle s MySQL má, je trochu nepříjemná.

Pro NoSQL nenašel žádné rozumné použití. Jak se zde psalo, ten, kdo umí relační databáze, pro něj to moc velký přínos není. Nicméně, ani mysql, ani nosql nezatracuju. Docela chápu, že v dnešní době je potřeba hrnout projekty a není možné sehnat znalé pracovníky. Při zaměření na projekt, bývá zajímavější ho rychleji vypálit a nežádat si velké odborníky na všechny oblasti. Průšvih nastává, když se projekt stane úspěšným - pak se rychle naleznou slepé uličky, na přepis není čas a peníze, takže se to (často marně) dohání železem a různými nesystematickými urychlováky.

No, taková je doba.

Můžeme si poplakávat po rameni, že vývojářům chybí znalosti, anebo je to můžeme zkusit naučit. SQL a relační databáze vymýšleli chytří lidé, a měli ještě dost času, aby to mohli vymyslet důkladně a důsledně (a od té doby uteklo 40 let, takže byl čas na to aby uzrálo). Ale bylo vymyšlené pro policajty, a pro agenty FBI, pro obyčejné lidi. A navíc dneska po 40 letech nemusíme řešit stejná omezení jako tehdy - kdy na nejlepších univerzitních počítačích byl 1MB paměti a 1GB disk byl sen.

To je jediná cesta. Všechny ostatní cesty vedli k tomu, co máme teď. Problém je, že v téhle době většina lidi (včetně mne), používá různé technologie bez dostatečných znalostí (někdy ty informace nejsou, někdy nejsou uspořádané, ...) ale dost často je to jen z toho důvodů, že si neumíme uspořádat práci nebo život, a udělat si čas, abychom dřív než něco začnem dělat, se naučili ovládat ty technologie, které jsou potřeba. A tím, že napřed děláme, a pak se učíme, tak je fůra věcí špatně - věci jsou špatně navržené, špatně realizované, lidi mají horší produktivitu a jsou vyčerpaní, a flegmatičtí, všichni si zvykli, že každý rozumí všemu (nějak - málo). Je rozdíl dělat něco a rozumět tomu, co dělám, nebo dělat něco a netušit která bije.

148

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 17. 04. 2021, 14:05:46 »

Původní vývojáři jsou v MariaDB foundation a ORACLE to nějak nechává žít zřejmě pro své korporátní zákazníky.
Smysl tedy má bavit se o MariaDB 10.x

Tady se musím zastat Oracle - Nabrali nové lidi, a 8čka rozhodně není databáze, kterou bych označil jako dožívající. Vůči 5.7 verzi je to ohromný pokrok. Samozřejmě, že je to Oracle - a nikdo neví, co mají v plánu.

Microsoftí server jsem odepsal dávno a popravdě častěji se narazí na ORACLE když už klient má peníze na rozhazování.
Není mi zcela jasné, jestli někdo má nějaký use-case, kde to dává smysl.

Tady hodně záleží, kde se člověk pohybuje - jsou oblasti a firmy, kde MSSQL dominuje - a když si vzpomenu na rozhovor s kamarádem, který je špičkový Oraclista, a dnes už zkušený a dobrý Postgresista, tak cca před dvěma roky velice pozitivně hodnotil MSSQL vůči Oracle. Oracle je jednak drahá databáze a druhak relativně náročná na administraci. Administrace MSSQL je výrazně jednodušší - a navíc Oracle začal dost brutálně tlačit svoje zákazníky do Oracle cloudu. A komu se do něj nechce, tak tomu hodně znepříjemňuje život.

149

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 17. 04. 2021, 05:59:24 »

A když použiju PG, v něm tabulku nosql, obsahující sloupce id a data, a do data budu ukládat dokumenty jako json; v čem jsem hůř než když bych použil MongoDB?

C# dovoluje objekt uložit přímo do Monga.
Stejně tak dovoluje tyto objekty z Monga získat.
Navíc mi dovoluje z Monga získat jen věci, které chci.
Vrať mi objekty, jejichž hodnota typ = auto a cena > 100000 a < 200000.

Nevím jak cizí, ale moje programy fungují tak, že uvedu referenci na Mongo, určím si objekty, které se ukládají do Monga a pokud chci provést změnu objektu, řeknu objektu "ulož se" a on se uloží. Vůbec se o nějakou databázi nezajímám.
Vlastně mě to zajímá jen v případě "SELECTU", kdy si na základě vlastností řeknu, které objekty chci z databáze načíst.

Ale pořád pracuji jen se svým objektem.
Práce s MongoDB je mnohem blíž NHibernate než práci s SQL databází bez ORM.
Měl byste si to zkusit, abyste to pochopil, to je nejsnazší.

To je otázka interface - a když použijete Linq, tak ani nemusíte vědět, co je pod tím. Ale pokud nepoužijete opravdovou objektovou databázi, tak stejně bude docházet k nějakému mapování. U serializace objektů si můžete vybrat, jak budete serializovat - jestli jednoduše a použijete dokumentový model nebo zkusíte ORM. Obojí ale vede k tomu, že moc nebudete umět provést hromadnou operaci (vždy musíte provádět deserializaci celého objektu). Pokud nepotřebujete hromadné operace - ok, je to jedno - ale ono je většinou potřebujete - a pokud máte víc než desítky tisíc operací, tak je objektový přístup zoufale neefektivní.

Dneska už mají zákazníci s kterými pracuji větší data - TB (a to jsou strukturovaná data, nejedná se o BLOBY), a tam je parádně vidět, jak omezený je objektový přístup. U SQL databází se to dá někdy zachránit, tím že vyskočíte z ORM a ručně napíšete SELECT, někdy je to tak zmršené, že ani to nejde. A přístup k optimalizaci Monga - tak tam dejte víc serverů, to nefunguje - vy potřebujete databázi zrychlit 10x - 100x. 10 serverů vám nikdo nezaplatí. Ne každý eshop má TB dat - drtivá většina eshopů budou mít v databázi možná pár GB - a tudíž pomalá hromadná operace bude v horizontu desítek sec, což je ještě akceptovatelné - tak tam asi nemá cenu extra řešit jestli SQL nebo NoSQL. Pokud vám SQL nejde nebo se nedokážete utrhnout od OOP, tak ok, použijte NoSQL nebo SQLite, nebo dokumentový model v MySQL. Ale u větších dat to fakt nefunguje (pokud děláte hromadné operace).

Viděl jsem aplikace, které velkou část dat cpala do NoSQL databáze - kde nebyl potřeba ACID, a hodilo se horizontální škálování, a bokem tlačila přes kavku data do relační databáze pro reporting a pro účetnictví. 

150

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 17. 04. 2021, 05:34:43 »

Já rozhodně nepropaguji NoSQL jako lék na všechno.
Jen tvrdím, že hřebík by se měl zatloukat kladivem a kombinačky použít na štípání drátu.
Vy svým způsobem tvrdíte, že můžete hřebík zatloukat pomocí kombinaček (strčit pod eshop SQL databázi) a že vám to půjde, s jistou praxí, stejně rychle jako s kladivem. No ano. S jistou praxí hřebík pomocí kombinaček zatlučete.
Ale jestli není náhodou lepší použít kladivo. Já eshopy dělal docela dlouho a když jsem pak začal pracovat s Mongo DB, jen jsem vrtěl hlavou, kolik kódu jsem zbytečně napsal.

Popravdě nevím, co je na eshopu tak speciálního, že by tam nešla nasadit relační databáze. A čím by se eshop měl lišit od účetnictví, aby bylo tak skvělé pro NoSQL databázi. Moderní relační databáze vám umožní (z pohledu datového modelu) totéž jako dokumentová databáze.  Nemyslím si, že to je správný přístup, protože degradujete databázi na storage, ale někomu to může vyhovovat. A jsou use cases, kde se dokumentový přístup hodí (nebo kde se hodí nějaký hybridní přístup).

Já v Postgresu můžu mít jak relační tak dokumentový model (podle toho co se mi hodí, a podle toho, jaké operace budu nad daty dělat - např. třeba hromadné operace). V mongu máte jen dokumentový model, a když chcete dělat hromadné operace, tak si musíte před materializovat data, aby to mělo vůbec nějakou rychlost.

Ta degradace databáze na storage má svoje výhody (máte méně kódu), ale i svoje nevýhody (nikdo jiný než vaše aplikace) neumí s daty pracovat - nemáte garantováno, že vám někdo externě naleje data ve správném formátu. A při exportu musíte načítat generické json - ta data mohou být relativně komplikovaná, protože mícháte víc entit do jednoho dokumentu. U relační databáze máte vstupně výstupní formát mnohem jednodušší (není rekurzivní) a garantuje vám ho databáze.

Věřte mi, že SQL je jedna z nejlépe navržených věcí v IT. To, že ho někdo neumí používat je jen jeho mentální blok, nebo smůla, že měl špatné učitele, nebo lenost, že si neudělal čas (4-8 hodin), aby se jej naučil.