Názory k článku PostgreSQL 14: nové funkce, nástroje a interní optimalizace

"Linux databázového světa" není nic kacířského, ale asi je to otřelé klišé. Spíš mi připadá, že PostgreSQL je mezi databázemi tím, čím je Python mezi programovacími jazyky. Projekt dlouho existoval aniž by byl udělal díru do světa, a teprve po mnoha letech si najednou vývojáři všimli jeho kvalit, začali ho používat ve velkém a stal se tak referencí. To srovnání s Linuxem ale sedí v tom smyslu, že mnohým firmám se dneska opravdu víc vyplatí přispívat do PostgreSQL a tím ho zároveň přizpůsobovat vlastním potřebám, než interně vyvíjet vlastní databázi nebo být zcela závislí na Pračku, IBM nebo Microsoftu.

Hlavny uspech Postgre je ze je zadarmo a sucasne to nie je MySQL. Nic ine by som za tym nehladal. Vykonovo ani "UX"-om to na komercne databazy stale nema.

A s tym vendor lockom to tiez uz nie je nic hrozne ako pred 20-timi rokmi.

V OLTP si myslím, že Postgres je výkonnostně stejně jako komerční databáze. Ukazuje se to při migracích z Oracle, MS, nebo DB2. Většinou stačí upravit pár dotazů, poladit indexy a aplikace jede srovnatelně.

V OLAPu tam je to samozřejmě jiné - Postgres má zatím jen minimální podporu pro OLAP. Na druhou stranu u Postgresu nejsou licence. A tudíž nejsou ani licence na CPU. Tudíž něco se dá dohnat hardwarem. Sám MS používá Postgres pro analýzu Win telemetrie, kterou má postavenou nad Citusem (extenze do Postgresu). Chytře jde na to také Timescale (pro time series data).

Postgres není Oracle a MSSQL. Je to jenom databázový engine, kde je cílem, aby gro se dalo udělat jednoduše, a spolehlivě. Není to balík aplikací jako je Oracle nebo MSSQL. Postgres také není tak konfigurovatelný jako Oracle. U Postgresu se dost spoléhá na extenze (Postgres dokážu extenzemi přiohnout o 180°). Oracle má hromadu šikovných fíčur, ale také má dost nectností, a z dnešního pohledu ne dobře navržených vlastností (které nejde změnit z důvodu zachování zpětné kompatibility). Dneska už si nemyslím, že by Postgres byl pozadu za komerčními databázemi. Všechny ty databáze mají vlastní cestu. V něčem jsou porovnatelné a v něčem vlastně vůbec porovnávat nejdou, jelikož jdou vlastní cestou.

Ten vendor lock už není tak hrozný právě díky Postgresu (a MySQL, a Mongu, a Redisu, ...). Dost firem se přesvědčilo, že z toho Oracle lze zmigrovat.

19. 5. 2021, 11:16 editováno autorem komentáře

Pokud jde o OTLP a soucasny trend kdy se dava do DB cim dal mene logiky, tak v tehle oblasti uz prakticky neni kam rust. Neni jak zvysit vykon, tak max. jsou jeste mozne nejake IN MEMORY extenze a caching vysledku SQL dotazu primo v RAM. Jinak je na tom Postgres hodne podobne jako komercni databaze.

Oracle, MSSQL a dalsi komercni DB ted ziskavaji naskok diky nastrojum na administraci, active session history, capacity planning, post-mortem analysis, ...

Dalsi rozdil je v tom, ze dnes Oracle vlastni Javu a ovlivnuje jeji vyvoj. JDBC standarty 4.1,4.2 prinesly nektere zajimave vlastnosti ktere Oracle umel vzdy ale v Jave je nebylo mozne pouzivat - jako napr. setQueryTimeout().

19. 5. 2021, 11:52 editováno autorem komentáře

To je pravda. Postgres nejaké nástroje má pro zpětnou analýzu (ale je to jenom nejnutnější základ, bez jakýchkoliv interaktivních nástrojů). Co se týká capacity planningu, tam a) jednak není úplně jasné, jak problém dobře řešit v OLTP (omezení paměti vede k větší zátěži IO, CPU a delšímu držení zámků), b) předpokládá se řešení virtualizací. U Postgresu nemusím mít jeden db server, který obsluhuje desítky aplikací, u kterých musím řídit zdroje, ale mohu mít desítky virtuálních serverů s izolovanými pg servery dedikovanými jednotlivým aplikacím.

Samozřejmě, že Oracle si může přiohnout JDBC podle potřeby Oracle. To není nic nového. Extenze JDBC už existují desítky let, např. pushování přístupových práv, atd. IT ale není jen o Javě. Ale proprietární extenzi JDBC má i Postgres - např. COPY API. Nastavení timeoutu pro dotaz, to asi není nic speciálního pro Oracle. Dnes to umí všechny databáze.

19. 5. 2021, 12:43 editováno autorem komentáře

Vykonovo ani "UX"-om to na komercne databazy stale nema.

Jde o to, co si představujete pod pojmem "databáze". Někdo si pod tím představuje výhradně balík programů na správu a tvoření dotazů a funkcí a zpracování dat. Někdo jen engine, ke kterému se připojí čímkoliv chce - programem, který vytváří, konzolí, GUI, ...

PostgreSQL byl výjimečný od začátku (pamatuji ještě, když se jmenoval Postgres95). Ve skutečnosti jsem nikdy nepochopil, proč se ujalo MySQL, protože nepřinášelo žádnou výhodu, pouze u celé generace začínajících programátorů zkazilo představu o tom, jak má databáze fungovat a co od ní má programátor požadovat.

Výkon je velmi solidní, nicméně mám pocit, že pro jeho dosažení musí člověk znát víc, než u komerčních databází. Ty šly daleko víc vstříc tomu, aby solidně obsloužily i SQL-prasátka. To se samozřejmě v praxi docela hodí, dá se pracovat aniž by byl v týmu jakýkoliv skutečný odborník (který jen ostatní "zdržuje svými nesmysly"). Ostatně, to souvisí i s tím, co píše Pavel, zaměření na OLAP.

LAMP byl dostupny na kazdem freehostingu, tak snadna je odpoved. Takze kdyz jsme delali prvni aplikace, pouzivali jsme tohle ;)

No, mysql sa ujalo hlavne preto ze je dalko menej striktne ako postgres. Mysql 8 uz ma sice defaultne zapnuty striktny mod, ktory ale vecsina adminov hned po instalacii vypne, pretoze vecsina aplikacii by nefungovala.

Proste postgres kladie na vyvojara daleko vacsie naroky, s mysql to zvladne kdejaky patlal.

Ve skutečnosti jsem nikdy nepochopil, proč se ujalo MySQL

Ten důvod byl prostý, jmenoval se MyISAM. Pro některé typy zátěže [čti webové aplikace] byl opravdu rychlý a to do té míry, že se vyplatilo obětovat transakce, referenční integritu i hromadu vlastností SQL a to vše dát na oltář výkonu, kterého na konci devadesátých let nebylo tolik jako dnes.

MyISAM. Pro některé typy zátěže [čti webové aplikace] byl opravdu rychlý a to do té míry, že se vyplatilo obětovat transakce, referenční integritu i hromadu vlastností SQL a to vše dát na oltář výkonu

Přiznám se, že jsem nepotkal za ta léta situace, kdy by se to vyplatilo. Obvykle to bylo spíš kvůli neznalosti programátora, který neuměl navrhnout aplikaci, 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ě. Obvykle se pak veškerý zdánlivě získaný výkon přeplatil zátěží aplikace (PHP není žádná výhra na práci s daty).

Děsně moc to zkazilo pojem "SQL" mezi začínajícími programátory. Když mi někdo řekne, že ovládá SQL, moje druhá otázka je, jestli MySQL a teprve třetí (pro jistotu), jestli ví o nových vlastnostech nových verzí mysql. Na tu třetí jsem ještě nepotkal nikoho, kdo by se orientoval.

Mozem mat sice schopnu databazu zadarmo, ale ak ten ekosystem nanic (ako v pripade Postgre, MySQL, Monga), tak v konecnom doledku mozem prerobit na plate vyvjarov, ked mi budu neumerne dlhu dobu riesit problemy, konzietnciu a vykon.

Ako chapem, ze pre mensie firmy sa viac oplati nieco co je zadarmo a za cas to bezi (mozno aj uspokoji ich potreby). Ale tie komercne databazy maju naozaj pridanu hodnotu, hlavne ak sa neriesi len nejaky prezentacny web.

Ked som v roku 2013 prvykrat skusil MS SQL 2008, tak som ukazal MySQL prostrednik a povedal som si, ze open source databazu uz nikdy. Nestoji to za tie nervy, mizeny vykon a hlavne, ze free edicie MS SQL zvladnu viac dat ako MySQL/MariaDb.

Postgre nehodnotim ako zlu databazu, ale MS SQL to stale nie je (vid clanok a CTE), a to hlavne ekosystemom okolo, plus response time (pri rovnakych datach, rovnakych indexoch a rovnakych nicim spacialnych selectoch dava horsie casy).

No, na transact sql sa da zvyknut - spolupracoval som nejaku dobu na mssql kde bola bussines logika v db... ak to mam porovnat s postgresom, tak jednoznacne postgres. A ekosystem okolo... ako licencia na max 64 jadier, draha jak svina? Za tie prachy ta db fakt nestoji...

Rád sleduji nové technologie a tyhle články se mi líbí a cítím že jich vychází bohužel čím dál méně (např. o využití technologie NVMe over Fabrics),.

Bude problém, že zjevně nebude, kdo by je psal. Myslím, že redakce ráda uvítá podobné příspěvky (a my všichni vlastně)

Pekny clanek. Diky za nej.

...a docela mi udělalo radost, že PostgreSQL byla úspěšně použitá na několika větších (kritičtějších) projektech v ČR, kde by se dříve uvažovalo pouze o Oracle nebo MS SQL.

Urcite by jich bylo mnohem vic, kdyby se vyresil naprikad problem s moznou ztratou dat pri synchronnich replikacich a vypadku komunikace mezi nody, ale jak jsem poznal, tak problem je, ze na to neexistuje konsenzus, jak to resit. Smutne je, ze ten konsenzus se nenasel ani za vic jak 10 let co ten problem neexistuje. Chapu, ze je to okrajova oblast a jeji vyreseni je celkem komplexnejsi ukol, ale Oracle v urcite konfiguraci dokaze zabezpecit RPO=0. To PostgreSQL zatim nedokaze. Bohuzel.
Snad se to tedy nekdy v budoucnu vyresi. Drzim PostgreSQL palce.

Mám pocit, že tohle téma se řešilo cca před měsícem v mailing listu.

Když něco takhle dlouho trvá, tak to znamená, že nikdo na to netlačí nebo že se neví, jak to správně udělat. Můžete mít např dvě validní řešení, které se navzájem vylučují, a pak z důvodu zachování zpětné kompatibility nebude možné ten návrh v budoucnu změnit. Tam asi vůbec nejde o technické řešení, ale o argumentaci pro/proti toho správného řešení. O to jak ten problém uchopit, aby bylo možné se správně rozhodnout.

V komunitním Postgresu fíčury nevznikají samy od sebe. Někdo musí udělat návrh, musí ho obhájit (a řeší se jenom věcná správnost a udržitelnost do budoucna), a musí to také naprogramovat. A musím říct jako autor desítek patchů do Postgresu, že obecně komunita (vývojáři) jsou lidé, kteří umí komunikovat, jsou velice chytří, ale mají dost nízkou (prakticky nulovou) toleranci ke kompromisům. Což na jednu stranu garantuje dlouhodobou kvalitu a udržitelnost vývoje, na druhou stranu, některé věci se nemusí pohnout 10 let (komunita vůbec neřeší byznys, řeší jen kvalitu). Takže některé věci musí uzrát, na něco potřebujete infrastrukturu, na něco lidi, kteří umí uchopit nějaký problém nějak, a mají dostatečnou motivaci).

U komerčních forků jako je EDB nebo PostgresPro, tak tam se byznys a byznysové fíčury samozřejmě řeší, a tam pak je větší šance, že si koupíte, co potřebujete, pokud potřebujete něco, co v komunitní verzi není.

Nejsem si úplně jistý o jakém problému s potenciální ztrátou dat při sync replikaci je řeč, ale je fakt že replikace / failover / HA nejsou úplně uživatelsky přívětivé, zejména ne bez nějakých dalších nástrojů které se postarají o management toho clusteru.

Ale nemyslím že by to bylo nějakou nechutí ke kompromisům v rámci komunity - spíš jde o to že filozofií PotgreSQL vždycky byla flexibilita, tj. snaha poskytnout infrastrukturu a "API" na kterých pak mohou vznikat řešení s různými vlastnostmi atd. Tj. místo toho aby se "zadrátovala" jedna varianta jak dělat HA, tak existují různá externí řešení (asi každá firma poskytující PostgreSQL služby má dnes vlastní tool). Což je na jednu stranu trochu "hloupé" pokud chcete prostě nějaký "default" HA cluster, ale součaně je prostě pravda že každé to řešní má trochu jiné silné/slabé stránky, a nic jako očividně "správné" řešení neexistuje. Např. mohou vznikat HA řešení "na míru" pro různá prostředí (např. různé cloudy, kubernetes, ...).

Je nicméně pravda že občas to může způsobovat "zaseknutí" vývoje protože bez ukázky řešení se těžko formuluje API. To je jeden z důvodů proč tak dlouho trvalo než se v PostgreSQL objevila pořádná nativní replikace, protože snaha byla udělat API, ale nikdo nevěděl jak přesně to API má vypadat protože neexistovalo žádné replikační řešení.

U toho co jsem uvadel, jde o situaci, kdy PostgreSQL vrati nasledujici varovani.

WARNING: canceling wait for synchronous replication due to user request
DETAIL: The transaction has already committed locally, but might not have
been replicated to the standby.

Tam pak v pripade vypadku site synchronniho nodu muze dojit k tomu, ze data jsou commitnuta a pristupna dalsim aplikacim na master nodu, ale nejsou zpropagovana na standby nodu (i v pripade synchronni replikace).
Kdyz se pak o mastera prijde, tak se prijde i o ta "nova" data.
Tady je to bych spise rekl na urovni PostgreSQL nez na to resit na urovni nejakeho HA frameworku.
Reseni jsem v mailing listu videl ruzna, ale zadne (pokud jsem neco neopomenul nebo nepreskocil) samo o sobe nedokazalo resit vsechny situace, ktere mohly nastat. Coz je mozna duvod, proc ten problem existuje dodnes.

Tak jistě, ale to určitě nejde brát jako ztrátu dat - pokud se rozhodnete nečekat na COMMIT, tak vám *žádná* DB nemůže za nic ručit. V principu je to úplně stejná situace jako když pošlete COMMIT a než vám přijde odpověď tak zavřete spojení. Pak taky nevíte v jakém stavu ta transakce je.

Problém je, že vy na standby nemáte věrohodnou informaci o tom, že na masteru ta data byla commitnutá. Je to 50 na 50. Kdyby to byla opačná situace, tak by se mohlo stát, že transakce se na masteru rollbacka a na odpojeném standby commitnula. Má to úplně tu samou pravděpodobnost. Aby to bylo úplně korektní, tak by se musel použít 2PC commit, a to by bylo zoufale pomalé. Uznávám, že jsou situace, kdy tenhle způsob měl smysl, ale bohužel, nikdo to nenaimplementoval.

U dvou serveru nikdy nebudes mit quorum. To je jako split brain a resi se obdobne jako u ostatnich distribuovanych systemu. Nahodis ty repliky dve a reknes, ze prvni ziva z nich je synchronni:

alter system set synchronous_standby_names = 'FIRST 1 ("db-2", "db-3")';
select pg_reload_conf();

@Pavel Stehule: Dakujem za skvely clanok. Skvely obsah, vhodna forma. Kludne by som vydrzal aj priebezne detailnejsie informacie o pripravovanych vlastnostiach v novych verziach. Este raz vdaka za tieto skvele clanky.
Taktiez ak mas informacie o specialnych konfiguraciach a architekturach ako bol PostregSQL pouzity (napr. to o SK poste) pripadne by ma zaujimalo ako prebieha oddelovanie storage engine a ci su tam nejake zaujimavosti.

Je to záležitost cca 4 roky zpátky, kdy asi trochu experimentovali, a zkoušeli ušetřit, a použili Postgres pro evidenci balíků. Skrz tento systém se řeší případné reklamace. Používá to samo doma vyrobené HA založené na sdíleném disku (zajištění unikátního write přístupu na disk, startování postgresu) řešil pacemaker. Vzpomínám si, že jsme tam nějak testovali jak share all, tak share nothing. A co používají, to už vlastně nevím.

Na storage enginech se dál pracuje - asi nejdál je práce na column store od green plumu (pořád se objevují zprávy, že na tom dělají). Nevím, co se stalo, ale engine s implementací undo logu se přesunul od EDB k Cybertecu. Někde jsem se dočetl, že timescale něco plánuje, ale ještě nic jsem neviděl. Viděl jsem jeden experimentální append only storage, který rovnou komprimoval. Nemám pocit, že by se už dalo něco použít produkčně.

Jak letos nejsou konference, tak je hůř vidět, co se dělá.

Teď Citus (Microsoft) oznámil dostupnost sloupcového engine (je to zatím jenom append only). Pokud se použije uložení po sloupcích, tak lze komprimovat i skalární hodnoty (Citus zmiňuje 7x menší data). DELETE by se dal nahradit dropnutím partišny. Mělo by to dobře fungovat pro IoT

https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/postgres-with-columnar-compression-in-hyperscale-citus-on-azure/ba-p/2373870

Ad uváděné historické "zkušenosti" s mysql. Kolem r. 2002 jsme vybírali DB pro náš systém. Mysql (samozřejmě InnoDB, žádné myisam, referenční integrita přes všechny tabulky, držela ORM mapování) na joinech přes cca 10 tabulek (každý atribut objektů má vlastní tabulku + tabulky přístupových ACL k objektům, hromadná vyhledávací query objektů s kritérii na různé atributy ) nám vycházela v těch testech tehdy 5 - 10x rychlejší než PostgreSQL. V té době byla pro nás volba zcela jasná. Je docela možné, že dnes by to již vyšlo nastejno, už jsme testy neopakovali. Pro náš účel (veškerá byznys logika záměrně v aplikaci, aby se netříštily používané technologie a snadno se přidávaly nové funkce/úpravy) nám na mysql (dnes samozřejmě mariadb) chybí "jen" použitelný fulltext, který je opravdu zásadní nedostatek. Kdyby byl fulltext postgresu OK a rychlost srovnatelná, byl by to důvod k přechodu, než řešit synchronizaci fulltextu třeba v ES.

Tohle IMHO už dávno neplatí. Fulltext Postgresu mi přijde dobrý, včetně rychlosti a podpory pro češtinu (taky to už je nějaký čas, co jsem s tím pracoval).

Mam skusenost (prakticku) s tym ze ak to porovnanie DB robi clovek ktory tak tak zvlada mysql (pozna iba zaklady) tak postgres vzdy vyjde podstatne neefektivne proti mysql. Ak to porovnanie urobi niekto kto dokaze postgres vyuzit na rozumnej urovni, tak postgres vyjde vyrazne lepsie... je to ako porovnavat stihacku s praskovacim lietadlom, ak do stihacky posadis pilota praskovacieho lietadla tak sa vecsiny cudlikov a pacok ani nechyti a v porovnani stihacka vyjde horsie ako praskovacie lietadlo ;)

Mam skusenost (prakticku) s tym ze ak to porovnanie DB robi clovek ktory tak tak zvlada mysql (pozna iba zaklady) tak postgres vzdy vyjde podstatne neefektivne proti mysql. Ak to porovnanie urobi niekto kto dokaze postgres vyuzit na rozumnej urovni, tak postgres vyjde vyrazne lepsie

Je to přesně tak. Pokud byla aplikace napsaná pro mysql, nebo byla napsaná univerzálně (což asi byla, když šlo vyměnit DB na zkoušku), nemohl být Postgres rychlejší. Kdyby byla napsaná přímo pro Postgres a využívala pokročilé možnosti SQL, pak by to dost pravděpodobně PG vyhrál. Stejným neduhem trpí povětšinou cokoliv, co používá ORM.

Rozdíl ve výkonu je pak spíš daný tím, že Postgres má hodně robustní komunikační protokol, a režie na dotaz je o něco větší. To se běžně "navrátí" tím, že dotazy mohou být komplikovanější a kvalitní databáze dotaz zoptimalizuje, využije správně indexy a navrátí spoustu výsledků zpracovaných naráz. Pokud však aplikace sází desítky malých dotazů pro získání jednotlivých dat, které pak zpracovává aplikace, tak to mysql vyhraje. Ušetří se totiž ten čas na režii protokolu.

Vtip je prave v tom ze to volanie do postgresu, ak je spravne naprogramovane, vrati tych udajov daleko menej. Nemusi totiz prenasat udaje ktore potrebuje bussines logika napisana napriklad v hypertextovom preprocesori (bez hate, php k tomu comu je urcene pouzivam casto) ktory na hromadne spracovanie dat nie je moc dobre optimalizovany. Miesto toho medziudaje spracuje funkcia v pgplsql ktore je pre hromadne spracovanie udajov optimalizovane a vysledok su relevantne udaje. Toto v mysql nie je proste mozne.

....a v porovnani stihacka vyjde horsie ako praskovacie lietadlo ;) ...

jestlize jsou ale v beznem zivote potreba z 99% praskovaci letadla, tak pak jsou ty ficurky tech stihacek presto k niceemu ...

No od stihacky necakameze bude praskovat, rovnako ako od praskovacieho lietadla necakame ze bude niest rakety. Takze predmetom porovnania budu ine vlastnosti. Dolet, rychlost, manevrovatelnost...
I ked si viem ovela lepsiepredstavit stihacku v nebojovom nasadeni ako cmeliaka v bojovom nasadeni :D

nojo, ty priklady ...
Pripustme, ze ta pgsql je 10 x yykonejsi nez mysql. (pan stehule rika, ze to dnes vlastne uz ani tak neni, ale budiz).
Co jsem chtel rici bylo, ze kdyz se 99% vsech aplikaci, ktere potrebuji nejak ulozit data spokoji s 10% vykonosti mysql , tak pak je to uz jedno, ze existuje dalsi moznost, ktere je jeste 10 x vykonnejsi. Vpodstate takhle prehnanou vykonnost nikdo nepotrebuje.

jestlize jsou ale v beznem zivote potreba z 99% praskovaci letadla, tak pak jsou ty ficurky tech stihacek presto k niceemu ...

Ono to není úplně trefné přirovnání. Spíš bych to přirovnal k dálkové dopravě. Pokud budete posílat z Číny malé jednotlivé balíčky do Evropy poštou, tak si moc nepomůžete ani tím, když si pronajmete celý kontejner na lodi. Nepomůžete si ani tím, že přijmete do firmy tři další sekretářky, které budou balíčky evidovat a řešit poštou zpět do Číny reklamace.

Výkon získáte teprve tím, když se Vám podaří zajistit, že už ve fabrice zabalí zboží na palety v předem dohodnutém pořadí. Když palety nastrkají do kontejneru taky v dohodnutém pořadí. Když v přístavu bude čekat tahač s kontejnerovým návěsem a když na celnici dorazí deklarace ve stejnou chvíli, jako zboží. Když kamion pak zastaví ve čtyřech distribučních místech a vyloží z kontejneru vždy paletu nejblíž u dveří. Když v každém skladu budete brát z palety seshora. Když budete mít rovnou doručených X % zboží navíc, přesně podle vypozorované míry reklamací.

Oba přístupy (jednotlivé balíčky přímo z Číny do Evropy), nebo srovnané kontejnery, palety a zboží na paletách plní účel na 99 %. Rozdíl je v tom, že na dopravě individuálních balíčků už nemáte co zrychlit. Na tom druhém způsobu ano, můžete dávat jiné pokyny (např. velké kusy balit vespod, malé nahoru, měnit procenta kusů navíc pro reklamace, můžete lépe označovat zboží v rámci palety)...

To je právě ten rozdíl mezi SQL. Jedna databáze Vám poskytuje funkce pro to urychlení (transakce = kontejner, rychlé agregáty = správně balení palet, ...), zatímco druhá databáze tyto funkce neposkytuje. Ale ten výkon získáte až teprve se změnou přístupu k dopravě. Dokud nezměníte přístup a budete posílat individuální balíky zboží (tj. práci si odedřete až v cílovém místě), tak výměna RDBMS nijak zásadně nepomůže. Účelem SQL je, aby data šla utříděná, zpracovaná, transformovaná už od zdroje a tam leží klíč k výkonu.

pochopil jsem to spravne v tom Vasem priklade, ze ...'Když budete mít rovnou doručených X % zboží navíc, přesně podle vypozorované míry reklamací.' - tim myslite ty lepsi statistiky u pgsql oproti mysql?
Pan Stehule dole rika, ze se to dnes vpodstate vyrovnalo. Ale hlavne co rika (neustale) je, ze kdyz je dostatek vykonu, tak se ty databaze vlastne nelisi.

Moje poznamka (a viz take vyse) byla smerem k tomu, ze u 99% aplikaci jsou ty pozadavky tak male, ze ten vykon dostacuje vzdycky.
Nakonec i u Vas v tom priklade -> kdyz se bude z Ciny posilat 5 baliku za rok, tak se to zvladne rucne a to sofistikovane reseni nebudei potreba.

Ve Vasem priklade je jeden zajimavy aspekt.
' že už ve fabrice zabalí zboží na palety v předem dohodnutém pořadí. Když palety nastrkají do kontejneru taky v dohodnutém pořadí. '
To je takovy klasicky problem, ktery ukazuje hranice moznosti SQL. Nejen, ze se to do toho kontejneru ma dat v tom poradi, ale melo by se to tam take smysluplne vejit a vyplnit ten kontejner optimalne. A zde by byl zapotrebi nejaky takovy hypoteticky SQL statement jako:

select * from a,b,c where 'az bude kontejner plny' :-)

To zatim stavajici SQl systemu myslim neumi. Obecne u vsech takovych prikladuj jde o to, ze nelze nijak rozumne omezit tu vysledkovou mnozinu. A pak se musi sahnout k tomu imperativnimu pristupu a prohnat kus po kuse nejakym algoritmem - tedy presne to co kritizujete, kdyz hovorite o tom posilani individualnich baliku ...

Ale ten arguument sa da obratit.
Ak robi porovnaia clovek co sa vyzna v Postgrese, tak vyjde lepsie.

Podla vasho argumentu potom plati, ze sa neda povedat, ze by Postgre bolo lepsie.

Podle mě je to myšleno jinak.
Potřebujete splnit nějaký úkol - řekněme, naprogramovat web a CMS.

Ten samý úkol můžete řešit dvěma způsoby:
a) neumíte SQL a nerozumíte RDBMS a namastíte dotazy "nějak", případně použijete ORM
b) umíte SQL a rozumíte svému RDBMS a dotazy a transakce vytvoříte tak, aby vyhovovaly zvolené databázi

Porovnání dvou databází pak můžete provést různě. V případě ad a) nemusíte dělat žádné úpravy. Zde dost často vyhraje mysql nad postgresql, právě díky menší režii a datům rychle dohledatelným podle primárního klíče.

V případě ad b) už ale můžete najít obrovské rozdíly. Troufnu si tvrdit, že i kdybyste se rozkrájel, tak s mysql nedokážete práci s daty zoptimalizovat k podstatně vyššímu výkonu. V případě postgresql naopak ano.

Konkrétně využijete mnohonásobné joiny (10 joinů není nic, co by bylo považováno za "velký dotaz"), využijete agregáty, SQL funkce, window funkce, lateral joiny. Tedy vlastnosti, které mysql buďto umí pomalu, nebo nenabízí vůbec.

Typický příklad z praxe: tři pracovníci, prodávající u McDonald's. Každý prodej je zaznamenán formou účtenky - ví se kdo, kdy a jaké zboží prodal. Chcete zjistit, který pracovník prodává zboží s nejvyšší marží (na cheeseburgeru víte, že vyděláváte méně, než na zmrzlině a pracovníci mají pokyn nabízet zmrzku). Chcete tu statistiku znát za poslední směnu a za posledních 10 směn. Směny jsou nepravidelné (některý den někdo nepracuje, každému začíná pracovní doba jindy). Zajímá Vás jak to, jestli nabízejí úspěšně zmrzlinu, ale i to, jestli jsou celkové výkonní (jeden může dobře prodávat zmrzlinu, ale obsluhuje pomaleji, takže ani ta zvýšená marže nevynahradí jeho pomalost).

V mysql taková data nemáte šanci získat jinak, než že si oddělenými dotazy vytaháte jednotlivá data (kdy měl kdo posledních 10 směn - jeden je bude mít v předcházejících 10 dnech, jiný je bude mít rozložené na 20 dní). Zcela nezávisle spočítáte součty a marže pro poslední směnu a nezávisle pro 10 směn. Do databáze budete z aplikace posílat minimálně tři dotazy a mezi nimi bude aplikační logika. Na konci pomocí vnořených smyček vytisknete tabulku.

V postgresu na to použijete jeden jediný velký dotaz. Směny si získáte subselectem, který využijete pro join. Pro součty za poslední směnu a za 10 směn využijete window funkce a agregáty. Data nakonec naformátujete do kostky. Jeden jediný dotaz, který má databáze možnost zoptimalizovat a zpracovat rychle (nemusí třikrát číst ta samá data, když ví, že je má sečíst pro poslední směnu a pro posledních 10 směn). V aplikaci vypíše data z kostky, aniž byste použil vnořené smyčky.

[@Pavel Stěhule k článku: zrovna toto je šikovné užití grouping sets a na DISTINCT se docela teším, protože při těchto operacích fakt vznikají duplicity, které sice vznikají logicky, ale pro výstup dat nepřinášejí žádnou hodnotu]

Právě v tom, kde jsou limity schopností databáze tkví to porovnání, která je výkonnější při správném užití.

Ja neobhajujem MySQL (je to priserna a pomala databaza), len som poukazal na nevalidny argument.

Existují univerzální testy - TPC-B, TPC-H, které můžete pustit vůči libovolné SQL databázi. Předpokládám, že v TPC-B bude mít MySQL navrch, a v TPC-H zas bude mít navrch Postgres. V reálném světě asi minimum aplikací budou generovat zátěž podobnou záteži generované těmito syntetickými testy.

Když znám MySQL a znám PostgreSQL, tak samozřejmě dokáži vymyslet test, ve kterém bude MySQL 10x rychlejší než Postgres, a zrovna tak dokáži vymyslet test, kde bude Postgres 10x rychlejší než MySQL. Nicméně, když znám obě databáze, tak také dokážu se vyhnout slabým stránkám MySQL a dokáži se vyhnout slabým stránkám Postgresu. Případně dokáži v aplikaci použít obě databáze, abych využil silné stránky obou databází.

MySQL má jednodušší optimalizátor, stejně tak má relativně hloupé statistiky, a až do verze 8.0 i hloupý executor (interpret jazyka prováděcích plánů). Interpret uložených procedur také není extra rychlý (a až do verze 8.0 postrádal i relativně základní funkce). Tudíž komplexnější dotazy, které vrací větší počet řádků na větších datech budou na MySQL pomalé (aplikačně budou ještě pomalejší). Ale InnoDB tabulky jsou uspořádané podle primárního klíče. V podstatě InnoDB tabulka je indexem nad primárním klíčem. Díky tomu všechny operace nad primárním klíčem budou v InnoDB výrazně rychlejší než nad pg. Pokud potřebujete jen transakční storage, a neděláte reporting, tak MySQL poslouží špičkově.

Postgres je defacto pravý opak. Postgresové tabulky nejsou organizované podle primárního klíče. Tudíž operace nad primárním klíčem budou vždy pomalejší než v MySQL. Ale má chytřejší optimalizátor, chytřejší statistiky, uložené procedury jsou naprosto jiná liga, má chytřejší datové typy. V postgresu mohu dost výpočtů udělat na úrovni db, a nemusím data stěhovat po síti, provádět konverze, atd.

A když toto vím, tak tomu mohu přizpůsobit návrh aplikace nebo volbu databáze, nebo volbu testů. Pro některé aplikace se hodí víc Postgres, a pro jiné MySQL, a někdo preferuje styl a strategii, která vyhovuje MySQL, a někde jiný ho dost nemusí.

Pri povolenom innodb_file_per_ta­ble je pri primarnom kluci rychlejsia. Ale ak je ta moznost zakazana, co vo vedsine pripadov je, tak po naboptnani tabuliek uz nie je cesty spat, nepomoze ani optimize table. To je ten zlomovy okamih, ked ide vykon prudko dole.

@ oss

Nie je to vseobecny nazor ale reakcia. Ked opomeniete kontext, ktory urcuje to na co som reagoval, tak to vyznie ako blbina. Ako kazdy text vytrhnuty z kontextu.

Ked tak pointa, problem je vo vedsine pripadov medzi klavesnicou a stolickou. Nie v postgres alebo mysql...

21. 5. 2021, 09:55 editováno autorem komentáře

"a docela mi udělalo radost, že PostgreSQL byla úspěšně použitá na několika větších (kritičtějších) projektech v ČR"

Prosím, sú niekde nejaké zaujímavé odkazy na tieto projekty ?

Bohužel o žádných odkazech nevím. Jsou to projekty pro státní správu a telco.

Doba čtení: 46 minut

Pochybuji ze bych si jinde precetl tak obsahly report. Myslim jinde na svete. Diky.

;-)