Vlákno názorů k článku PostgreSQL 14: nové funkce, nástroje a interní optimalizace od klokan - "Linux databázového světa" není nic kacířského, ale asi...

Přiznám se, že jsem nepotkal za ta léta situace, kdy by se to vyplatilo.

Tak si vzpomeň, jak vypadal tvůj osobní počítač v roce 1999 a uvědom si, že servery na tom nebyly o moc líp.

výkon získala právě z transakcí a integrity

Eh? Transakce i referenční integrita jsou vždy režie navíc. Z toho opravdu výkon nezískáš, ani když se rozkrájíš na nudličky.

aby výkon získala právě z transakcí a integrity, aby neiterovali data v aplikaci a load přenesli na databázi, která má spoustu možností a schopností, jak úlohu vyřešit inteligentně

V té době (a často i dnes) webové aplikace používaly databázi jako hloupé uložiště, kam se data občas zapsala a vytáhla primitivním selectem. Tam moc prostoru pro inteligenci není, a právě proto trojková MySQL na svou dobu byla vynikající volba, protože sice toho moc neuměla, ale na tehdejší poměry to uměla velice rychle.

refernční integrita něco stojí. Ale transakce mohou databázi zrychlit, pokud se řeší zápis. MyISAM bylo tak rychlé protože zápis končil ve filesystémové cache.

V té době (a často i dnes) webové aplikace používaly databázi jako hloupé uložiště, kam se data občas zapsala a vytáhla primitivním selectem. Tam moc prostoru pro inteligenci není, a právě proto trojková MySQL na svou dobu byla vynikající volba, protože sice toho moc neuměla, ale na tehdejší poměry to uměla velice rychle.

Takových situací v reálném životě ani tehdy moc nebylo. Obvykle člověk potřeboval data setřídit, mít referenci na nadřazenou entitu, ... To vše se s MySQL řešilo na aplikační úrovni a daleko dráž. Ale souhlasím, že databáze o jedné placaté tabulce vyšla líp s MySQL.

Takových situací v reálném životě ani tehdy moc nebylo

Takovych situaci bylo nescetne mnoho. Delani ruznych primitivnich webu/CMS a e-shopu me tehdy docela slusne zivilo a bylo to porad na jedno brdo.

Na uvodni strance sis selectem vytahl prvnich deset clanku "select * from articles order by ts desc limit 10". A pak pomoci odkazu si mohl precist clanky. Z URL si clovek vytahl id a pak jel jeden jednoduchy dotaz za druhym, nejdriv "select * from articles where id = $id", ktery vytahl informace o clanku (v pripade e-shopu o produktu) a pak si clovek vytahl obrazky "select * from pics where article_id = $id", pripadne diskuze "select * from messages where article_id = $id". Trochu vetsi vzruso bylo kdyz se v e-shopu parovaly polozky v objednavce pomoci joinu, ale to je tak vsechno.

Neuveritelne nudne programovani, ktere opravdu plnotucny databazovy system nepotrebuje a prostor pro zrychleni, jak jsi tu tvrdil, tu opravdu neni.

Obvykle člověk potřeboval data setřídit, mít referenci na nadřazenou entitu, ... To vše se s MySQL řešilo na aplikační úrovni a daleko dráž.

A? Vsechno toto tehdejsi MySQL podporovala. Takze pokud byl nekdo tak mimo a resil to na aplikacni urovni, tak by mu opravdu ani Oracle nepomohl.

Neuveritelne nudne programovani, ktere opravdu plnotucny databazovy system nepotrebuje a prostor pro zrychleni, jak jsi tu tvrdil, tu opravdu neni.

S tím úplně nesouhlasím. Každá z těch vyjmenovaných entit má na sobě navázané další. Např. u článku chcete vidět jméno autora, tak máte referenci na tabuli autorů. U zpráv taktéž. Možná jste u komentářů řešil schvalování (někým dalším). Článek mohl být ještě nebo už neveřejný. Obrázek z článku tím pádem mohl být ještě / už znepřístupněný.

To všechno jsou běžné operace, které se už v devadesátkách řešily. Buďto jste si to navázal a joinoval, nebo jste data staticky duplikoval ze seznamů do obsahových tabulí, nebo jste je dotahoval dalším (sub)selectem. Duplikování informací je drahé, zejména při updatu - musíte updatovat všechny záznamy, které informaci převzaly. (Sub)select v rámci aplikace je taky drahý. Takže zbydou akorát ty joiny a tam už prostě MySQL pajdalo.

Pochopitelně, když popíšete příklad tak zjednodušeně, jako jste ho popsal, tak to působí úplně jinak. Ano, často systémy vznikaly z jednoduchých a vlastnosti, které jsem vyjmenoval, se dodělávaly. Ve výsledku to sežralo víc prostředků, než kdyby se to dělalo pořádně. To platilo i tenkrát.

S tím úplně nesouhlasím. Každá z těch vyjmenovaných entit má na sobě navázané další. Např. u článku chcete vidět jméno autora, tak máte referenci na tabuli autorů. U zpráv taktéž. Možná jste u komentářů řešil schvalování (někým dalším). Článek mohl být ještě nebo už neveřejný. Obrázek z článku tím pádem mohl být ještě / už znepřístupněný.

A? Co jsi tim chtel rict? Klauzuli where opravdu zvladala i MySQL a stejne jako bezne spojeni. Pokud to nekdo prasil na aplikacni urovni, lepsi databaze by mu nepomohla.

Pochopitelně, když popíšete příklad tak zjednodušeně, jako jste ho popsal, tak to působí úplně jinak. Ano, často systémy vznikaly z jednoduchých a vlastnosti, které jsem vyjmenoval, se dodělávaly. Ve výsledku to sežralo víc prostředků, než kdyby se to dělalo pořádně. To platilo i tenkrát.

Ano, ty aplikace byly opravdu tak jednoduche a na jedno brdo. Ty funkce navic, co popisujes, jsou jen banality, ktere jde resit (a resili se) pridanim par atributu, coz bylo to hlavni, v cem se jednotlive aplikace lisily.

Klauzuli where opravdu zvladala i MySQL

Where zvládalo i tenkrát. Join zvládá ještě dodnes s výkonnostními problémy.

Eh? Transakce i referenční integrita jsou vždy režie navíc. Z toho opravdu výkon nezískáš, ani když se rozkrájíš na nudličky.

Ak sa nemozem spolahnut na integritu dat, ktore dostanem z db, tak to musim poriesit v aplikacii. A to je spravidla daleko vyssia rezia naviac.

Nebo to nemusis resit vubec a muzes predpokladat, ze pracujes s validnimi hodnotami. V te dobe to bylo naprosto bezne a validni rozhodnuti, stejne jako treba obetovat transakce.

Z dnesniho pohledu to zni mozna desive, ale je potreba si uvedomit, ze tehdejsi pocitace mely procesory pracujici na pouhych stovka megahertz a pameti v radech desitek megabytu. Pro kontext je dobre zminit, ze teprve nekdy v druhe polovine devadesatych let se zacaly opoustet primitivni souborove databaze, kde transakce ani referencni integritu nikdo neresil a "bez problemu" na tom bezely obrovske prumyslove a obchodni spolecnosti, takze to z pohledu tehdejsi doby nebylo uplne mimo.

Nebo to nemusis resit vubec a muzes predpokladat, ze pracujes s validnimi hodnotami. V te dobe to bylo naprosto bezne a validni rozhodnuti, stejne jako treba obetovat transakce.

Nebylo. I v té době se vědělo, že je to hazard a programátorská prasárna. Už tenkrát, kdy bylo uživatelů internetu asi pět a půl, se docela pravidelně projevovaly nekonzistence vzniklé z tohoto "validního rozhodnutí". Obvykle se pak programátor před zákazníkem tvářil děsně důležitě a "opravoval data".

Z dnesniho pohledu to zni mozna desive, ale je potreba si uvedomit, ze tehdejsi pocitace mely procesory pracujici na pouhych stovka megahertz a pameti v radech desitek megabytu.

Přiměřeně malá byla i datová nálož i zatížení. Ke své době to zvládaly přiměřeně k potřebám.

transakce ani referencni integritu nikdo neresil a "bez problemu" na tom bezely obrovske prumyslove a obchodni spolecnosti, takze to z pohledu tehdejsi doby nebylo uplne mimo

Klam. Data se v takovém případě zamykala a čekalo se, než skončí úloha, která data mění. S tím se počítalo opravdu běžně, ale nikdo si netroufl zároveň zapisovat a číst (nota bene číst pro zápis).

S příchodem webových aplikací bylo naprosto jasné, že takový přístup k řešení už není možný. Souborové databáze se opouštěly ne kvůli jejich "souborovosti" (ta by nebyla zas až tak na obtíž), ale právě kvůli tomu, aby se daly úlohy bezpečně zpracovávat souběžně a v kódu dokola neřešit zamykání a co v takovém případě dělat.

I v té době se vědělo, že je to hazard a programátorská prasárna. Už tenkrát, kdy bylo uživatelů internetu asi pět a půl, se docela pravidelně projevovaly nekonzistence vzniklé z tohoto "validního rozhodnutí".

Uplny stroj casu. Tyto pohadky patrily do programatorskeho folkloru tehdejsi doby, ale realita byla nekde uplne jinde, a opravdu to nebyl realny problem.

Tyto pohadky patrily do programatorskeho folkloru tehdejsi doby, ale realita byla nekde uplne jinde, a opravdu to nebyl realny problem.

Já jsem tyto "pohádky" sledoval v přímém přenosu. Obvykle se ten "neproblém" (ne)řešil nějakou obezličkou, která měla za účel snížit pravděpodobnost výskytu, Pak to byla zase jen otázka času, kdy datová nálož a vytížení doběhly tu obezličku. Ve výsledku takto slátaná aplikace běhala pomaleji. Ale je fakt, že už tenkrát se našli experti, co tvrdili, že to není potřeba dělat, a že by to bylo pomalé a kdovíco ještě. Ještě obvyklejší bylo, že tehdejší matláci ani netušili, že existují nějaké relační databáze, které se o celý problém postarají - jen se je naučit. Tento folklór přetrvává dodnes - a dodnes nerozumím tomu, proč je tak velký mentální problém se naučit několik málo zásad pro práci se SQL a RDBMS (pro začátek stačí jen BEGIN a COMMIT). I kdyby se to nenaučili nijak oslnivě a využili jen základy, aplikace by rozhodně nebyla pomalejší.

Ono něco fungovalo, a něco nefungovalo. Na jednu stranu, kamarád adminoval roky relativně bezproblémový provoz reality.cz, co snad dodnes běží na MyISAM. Na stranu druhou, když jsem dělal v IlikeThis, tak jedna aplikace rozesírala db tak často, že člověk, co jí měl na starosti ji dokázal dát dohromady během čtvrt hodiny. Měl natrénováno, jelikož to dělal tak 2x 3x do týdne.

Mohli být zabugované některé verze, některé operace, a vzhledem k tomu, že na MyISAM se fsync nevolá, a je na filesystému, kdy si flushne, tak bylo ve hvězdách, jak a co se rozbije při havárii. Vybavuji si ohromnou nechuť tehdejších adminů (cca rok 2004) k jakému koliv upgrade MySQL.

Něco podobného pamatuji se starými verzemi MS Accessu. To se rozbíjelo, jen když se na to člověk špatně podíval. Když ale člověk věděl, co nedělat, a držel se toho, tak mohl napsat docela velkou aplikaci. Dost aplikací pro kupónovou privatizaci běželo nad MSAccessem, docházkové systémy, systémy pro agendy v pojišťovnách. A MS Access byla chuťovka. To MySQL byl držák vůči accessu :).

Z dnesniho pohledu to zni mozna desive...

V "devedesiatkach" som bol uz IT aktivny. Obrovske spolocnosti uz vtedy neriesili ako server pc zavrete niekde pod schodami, ale bezali na mainframoch.

Z dnesneho pohladu je skor desive to, ze vedsina mladsich vyvojarov akoby ani len netusila ze server na ktorom bude aplikacia bezat sa diametralne lisi od pc na ktorom vyvijaju. Napr, jeden argument za vsetky "io operacie su inrelevantne, pretoze dnesne disky su neuveritelne rychle". Ako takej trubke vysvelit ze na servri ma ten disk spravidla mountnuty cez siet z diskoveho pola a aj napriek rychlosti je to blokove zariadenie, kde je sice mozny nahodny pristup ale rychlost io operacii bude klesat umerne k tomu kolko uzivatelov bude pozadovat data? Neda si vysvetlit ze k datam ulozem v zdielanej pamati serveru ma viacero uzivatelov okamzity paralelny pristup...

V "devedesiatkach" som bol uz IT aktivny. Obrovske spolocnosti uz vtedy neriesili ako server pc zavrete niekde pod schodami, ale bezali na mainframoch.

Blahopreji. Jsou lidi, kteri v devadesatkach resili informacnich systemy ve FoxPro, na kterych bezely prumyslove i obchodni spolecnosti se stovkami zamestnancu a miliardovymi obraty.

Jsou lidi, kteri v devadesatkach resili informacnich systemy ve FoxPro, na kterych bezely prumyslove i obchodni spolecnosti se stovkami zamestnancu a miliardovymi obraty.

Jj, tiez sme mali zopar ludi ktori neriesili nic ine len podivnost zvanu foxpro, hovorili sme im pacienti... To ale nebola celkom len databaza, pretoze foxpro riesila aj aplikacnu vrstvu.

Koncem 90 let byla MySQL jediná dostupná databáze pro webové aplikace. Komerční databáze byly pro internet brutálně drahé. A MySQL dlouho neuměl transakce - MySQL byl bastl MyISAM + SQL interpret. Byl to bast, ale umělo to SQL (což tehdy představovalo vyšší třídu), a bylo to zadarmo, a běželo to na každém PC. Stejně jako PHP. Člověk se na to musí dívat jinak. Dnešní MySQL a dnešní PHP jsou úplně jiné produkty než tehdy, ale tehdy umožnili dost lidem začít programovat a uživit se tím. A je fakt, že v té době existovali i o dost horší technologie, a i profi programátoři, kteří používali MSSQL, které jsem znal, mi tvrdili, že transakce a zámky jsou zbytečné záležitosti.

@Pavel Stěhule

Já si teda ty devadesátý léta pamatuju, a ani tenkrát nebyl problém používat Postgres pro webové aplikace. Jakmile člověk potřeboval pět, šest tabulek, nějaké číselníky, tak mohl zvolit buďto MySQL a sloučit si data v aplikaci, nebo je sjoinovat v Postgresu. Co si pamatuju, v postgres95 nebo postgresql 6 (to už si nevzpomenu) byl jen cross join, ale podmínky to řešily a indexy se s malou nápovědou chytaly (bylo to komické, ale fungovalo to dobře: SELECT ... FROM a, b WHERE a.id=b.fk AND a.id > 0 AND b.id > 0 [bez posledních dvou podmínek se index nechytl]). To dalo už tenkrát MySQL spolehlivě na gatě.

Já jsem začal s Postgresem až od sedmičky. Nicméně ty raný verze Postgresu svoje mouchy měly. Do přepsání memory managementu měl Postgres problémy s memory leakama (ale to MySQL taky - vzpomínám si na jeden incident s MySQL u zákazníků u jednoho z prvních eshopů u nás, MySQL se restartnul každých 50K dotazů). Hlavně Postgres neběžel na windows (což byl takový paradox - www aplikace drtivě běžely na Linuxu, ale drtivě se psaly ve win), a nebyl na hostinzích (poněvadž Postgresovou db jednoduše někomu nenasdílíte. Záloželo, co člověk dělal. Jako storage MySQL mohlo fungovat docela dobře. Jakmile se ale začalo joinovat nebo používat subselecty, tak to MySQL nedávalo. V roce 2011 jsem dělal pro GoodData testy Postgresu a MySQL a na pár MB tabulkách byl Postgres řádově rychlejší. 100MB tabulky už pro MySQL příliš velké (pro JOIN) a museli jsme si pomáhat workaroundem (když se použila inmemory tabulka, tak MySQL uměl hashjoin, ale když máte 10K tabulek a víc, tak inmemory tabulky jsou průser).

MySQL 5 vypadala docela nadějně (přidali tam pár funkcí kvůli možné podpoře SAPu). Ale pak SAP tuhle cestu definitivně zavřel, a MySQL spálilo fůru let na vývoji Falconu (a vývoj MySQL se posunul dopředu až za Oracle).

Koukám, že to ve free databízích bylo tehdy prašť jako uhoď. Já byl nucen okolo roku 2000 dělat na Interbase resp Firebirdu a to byl tedy také zážitek - Ta db se brutálně zpomalovala od cca 250 uživatelů. Takže X měsíců běželo všechno parádně a pak najednou ze dne na den bum...

Lebo bussines logika v databaze je chyba databazy...

Lebo bussines logika v databaze je chyba databazy...

Proč?

To bol sarkazmus :D