Názory k článku PostgreSQL 15: podpora ANSI SQL/JSON a další uživatelské novinky

Super clanok, dakujem. Priklady, odporucania, ... dlhsi rozsahom ale absolutne vyborny. Od profika pre profikov bez zbytocnych omacok.

Mohl by mi prosím někdo znalý uvést největší důvod proč zákzaníkum doporučit Oracle (nebo např DB2) a nedoporučit Postgres?
Mám tim na mysli co je ta "killer feature" Oraclu, aby to obhájilo ty miliony korun co to stojí?

MySQL nějaké ty složitější funkce chybí, ale Postgres se mi zdá už hodně "feature-full". A v mnoha případech co vím, tak si zákazníci sice koupí Oracle, ale ve výsledku tam mají skoro prd a za ty peníze se mi zdá že se to prostě nemůže vyplatit...

btw přidání možnosti security invoker VIEWs mi udělalo obvzláště radost :)

p.s. Moc děkuji za tyto články, které vždy skvěle shrnou co je v nové verzi PostgreSQL nového... jen tak dál prosím

4. 5. 2022, 10:51 editováno autorem komentáře

Postgres ma sice tie zlozitejsie funkcie, ale vzdy su akoby nedokoncene.

Navyse kupu komercnej databzy si nekupujete len DB engine, ale aj diagnostike tooly a tooly pre spravu (tu PG aj MySQL zlyhava na celej ciare, proste ten experience je hrozny, sice viete robit to iste, ale tak tazkopadne a mizerne,...) a kupujete si aj support.

Ono uz davno viem, ze databaza zadarmo moze byt drahsia ako ta platena.

Je ale pravda, že pro Postgres si uživatel ten support může koupit taky.

Rozhodně nejsem expert, ale mám pocit, že v extrémních zátěžích Oracle zvládá víc transakcí za sekundu, než Postgres (aspoň tomu tak dlouho bylo, nevím, jak jsou na tom poslední verze Postgresu). Hlavně to asi ale není o databázi jako takové, ale o všech nástrojích kolem. Například Oracle nabízí širokou škálu monitorovacích a bezpečnostních nástrojů, které nemají u Postgresu ekvivalent (leda snad nějaké proprietární). Na druhou stranu Postgres je nedostižný pokud jde o šíři podpory programovacích jazyků a kvalitu dokumentace.

O ten výkon asi dneska moc nejde. U zákazníků, s kterými spolupracuji, a kteří mají slušnější zátěž je na dnešním železe víc než slušná rezerva ve výkonu (s Postgresem moc nemusíte řešit počet CPU).

Oracle je víc konfigurovatelný a má dobré nástroje pro forézní analýzu. Pro Oracle existují už hotové architektury, jak navrhovat a realizovat komplexní řešení. Ekosystém Oracle je víc prefabrikovaný (unifikovaný). U Postgresu je to víc filozofie, ať si každý dělá co chce, jak chce, jak mu to vyhovuje.

4. 5. 2022, 12:59 editováno autorem komentáře

"že v extrémních zátěžích Oracle zvládá víc transakcí za sekundu"

Postgres muzete snadno nasadit na autoskalovatelnem HW jako AWS Aurora, nevim, jestli neco podobneho existuje pro Oracle.

Jenže tady právě nevím, jestli se to dá dohánět silnějším hw, nebo jestli Postgres má principiálně míň efektivní algoritmy/prováděcí plány, než Oracle.

5. 5. 2022, 00:18 editováno autorem komentáře

V OLTP si myslím, že rozdíl nebude tak velký - i v benchmarcích TPC-B se ukazovalo nějakých 20 procent (a tam se testuje to, co postgresu nedělá dobře - intenzivní UPDATE).

Ohledně optimalizace - při portaci aplikací z Oracle jsem musel upravovat jen pár dotazů. Jinak Postgres je typově striktní a pokud nesedí typy, tak Postgres nepoužije index (int versus numeric). Oracle je to jedno. V Postgresu mi aktuálně chybí 3 optimalizace - pushdown agregace, lepší optimalizace OR a index skip scan. Jinak nemám s optimalizátorem pg jediný problém.

Autoškálovatelný hardware je vám k ničemu, když narazíte na limit toho hardwaru.

Jeden z důvodů je placený formální support. Ne proto, že by support něco vyřešil, ale protože nefunkčnost mám na koho svést a tím nebudu platit pokutu když to nejede.
Když budu chtít tento placený support k Postgresu (tak abych se zbavil zodpovědnosti jako u Oracle), tak skončím na podobných částkách.
U Oracle všichni čekají že to bude drahé, ale u PostgreSQL to všem vadí.

Hoci sa moja skúsenosť týka inej oblasti (AIX vs. Linux), je veľmi podobná.
Pri komerčných riešeniach existuje veľmi silný motivačný faktor - peniaze. Významný (teda dobre platiaci) zákazník tak dokáže v prípade problémov "zobudiť draka" a pritiahnuť k vyriešeniu svojho problému všetky odborné zdroje príslušnej korporácie.
V prípade open-source SW je síce k dispozícii zdrojový kód a oprava sa tak dá urobiť priamo zákazníkom, častokrát ale na to nemá dostatočnú odbornosť a cesta k príslušnému odborníkovi nie je až taká priamočiara. Odborníci samozrejme existujú aj tu, ale napríklad na Oracle ich mám len v mobile desiatky (z toho polovica sú priamo zamestnanci Oracle), kým na PostgreSQL viem len o pánovi Stěhule (som rád, že som si mohol raz s ním aj podať ruku a prehodiť pár slov).
Jednému zákazníkovi som to raz vysvetlil na názornom príklade - je to ako rozdiel medzi manželkou a prostitútkou. Určité "neštandardné" praktiky síce vedia poskytnúť obidve, v tom druhom prípade ide ale o radikálne priamejší proces :-)

Tak určitě je tady Tomáš Vondra, Petr Jelínek, Tonda Houska, Aleš Zelený a určitě pár dalších. EDB tu má kancelář. Takže nejsem sám. Lidí na Oracle bude řádově víc, i když na expertní úrovni .. to už si nejsem jistý. Docela by mne zajímalo, kolik lidí z ČR vidělo zdrojáky Oracle nebo má svůj commit? Oracle je výrazně komplexnější, takže chca nechca na to musíte mít proškolený lidi (jinak je to katastrofa)

S Oraclem se dělá o možná několik řádů větší byznys než s Postgresem, tudíž se na něm uživí výrazně víc lidí. Jsou to dva světy, které nejsou úplně porovnatelné - z jedné strany klasické korporátní IT, a z druhé strany polopunkový nezávislý IT. U některých projektů potřebujete externí ručitele a externí autoritu. Samozřejmě, že Microsoft nebo Oracle hraje úplně jinou ligu než Postgresová komunita nebo EDB. Nevím jestli to umím vyjádřit - Postgres je fajn databáze, když se staví řešení odspoda nahoru. Oracle je naopak databází, když se řešení staví odshora dolů.

4. 5. 2022, 16:57 editováno autorem komentáře

"Postgres je fajn databáze, když se staví řešení odspoda nahoru. Oracle je naopak databází, když se řešení staví odshora dolů."

Díky za odpověď, věřím, že to asi tak zodpovídá ten můj původní dotaz. Podle reakcí kolem se mi zdá, že to opravdu není o jedné (nebo několika málo) killer feature, ale je to opravdu o tom, že Oracle dokáže poskytnout "záruky" a "enterprise-level služby" (za enterprise-level cenu). Překladám si vaší větu "řešení stavěné odshora dolů" jako projekty, kde se v návrhu systému nezačíná tím "co má databáze konkrétně umět", ale v podstatě se řeší "kdo bude partner co nám poskytne databázové řešení".

Můj problém je, že se na to dívám příliž mnoho z té technické stránky a málo z té netechnické.... :)

Každopádně díky všem za reakce

Když chcete mít hodně strukturovaných dat v jedné velké databázi (tj. nechcete řešit třeba distribuované transakce) a potřebujete řešit velkou škálou složitých operací (ať už složité selecty, nebo triggery, uložené procedury apod.). Zkrátka tam, kde je potřeba to umlátit hrubou silou.

(Jiná věc je, jestli je dobrý nápad v dnešní době nějaký nový systém řešit zrovna takhle.)

Měl jsem za to, že složité operace jsou právě to, v čem Postgres vyniká.

Důvody z pohledu business tu již zmíněny byly. Já zkusím přidat i nějaké technické.
U Oracle je to třeba Data Guard se zero data loss. Jsou situace, které jsou v Postgresu známé už třeba 10 let, kdy prostě může dojít ke ztrátě dat i když je nastavený synchronous_commit na remote_apply a dojde k výpadku sítě. V tomhle je Oracle opravdu o něco dál.
Velmi ale ocěňuji a těším se na první verzi dvoufázového commitu v 15ce. Jak psal Pavel, je to v tomhle směru velký krok kupředu a díky za něj.
U Db2 (beru LUW verzi ne mainframe) je to třeba PureScale, což je "multimaster replikace", kde si jednotlivé nody umí sahat do paměti jiných nodů. To pokud vím, tak PostgreSQL neposkytuje.
Oboje jsou ale velice specifické funkcionality, které upravdu využijí jen některé společnosti.
Jsem rád, že PG neusíná a postupuje dopředu. Zvláště u 2PC. Pokud se tohle za 2-3 verze dotáhne, tak věřím, že bude Postgres velká konkurence pro Oracle v core banking systems.

Napsal jsem to blbě, že PureScale je multimaster replikace... On je to sice "multimaster", ale má jedno úložiště společné pro všechny. Není tam tedy několik kopií dat. Od nějaké verze 10.5 nebo 11.1 to umí jet i v HADR, tzn., vy máte 2 PureScale clustery a 2 úložiště (většinou geograficky oddělené) a v případě výpadku jednoho datacenra tak převezme plně tu funkcionalitu to druhé datacentrum (cluster).
Pamatuji si první verzi PureScale (Db2 9.8). Tehdy to bylo celkem hloupé. Přidávání nodu, nebo aplikace fixpacku znamenala, že musí jít cluster dolů, byl tam požadavek na infiniband.
V současnosti přidávání a odebríání nodů i instalace fixpacků jdou dělat bez výpadku služby a jako siť "postačí" 10 Gb ethernet.

Jestli pak je nutné implementovat například zrovna ten Data Guard jako core funkcionalitu? Pokud by o to byl u Postgresu zájem, nešlo by to řešit formou rozšíření?

Z osobní zkušenosti v jedné bance... Ne. Nestačilo by to. V momentě, kdy databázisti z banky našli tu situaci o které jsem psal a dokázali jí pokaždé zreplikovat, tak to pro ně znamenalo stopku.

Ano Oracle je omnoho dalej, ten sa zlozi niekedy aj sam od seba. Neviem ake mate skusenosti s recovery Oracle po pade ale ja iba zle. A vsetci sa dnes hraju presne na tieto mega supa vychytane ficury ale pri tom zabudnu ze nemaju TX synchro messaging (tx monitor) ktorym chodia do app servra spravy a tak sa sice databaza nerozide ale spracovane spravy vs to co je v DB ano.
Potom uz iba drobnosti ako ze optimizer zacne fungovat v strede tyzdna uplne inac ako fungoval doteraz, support Oracle na vas dlabe lebo nie ste to 100 klient az sa nakoniec cez rozne pofiderne kanaly podari za pol roka pretlacit ticket niekam a pride vam zo supportu update nejakych ciselok v nejakej obskurnej oracle tabulke a spravanie sa vrati do povodneho. Tolko k supportu.
Pouzivame postgres na rozne druhy aj financnych aplikacii. Je to uplne bez problemov pokial sa vyhnete niektorym veciam pripadne viete ako ich riesit. Replikacia stale drhne a neda sa na to 100% spolahnut. Funkcne je to prakticky nedostihnutelne a skutocne jedinou konkurenciou je momentalne uz iba Oracle ktory ale obvykle nestoji za tie peniaze lebo kvalitu oracle nahradim kvantitou postgresu a este za nizsiu cenu. Klientom vzdy davame na vyber a mnohi aj v statnej sprave uz dnes pouzivaju postgres a niektori aj bez toho aby o tom vedeli ;-).

Ze Oracle zmeni execution plan, je jeste relativne v pohode.
Ale na vetsine nasich ORA-600 a ORA-7445 (pro neznale - interni chyby db) jejich support totalne pohorel. Roky otevrene tickety a kecy, ze na tom jejich vyvojari makaji.
Na druhou stranu maji krasne propracovane pasticky s licencemi. Omylem pouzijete placenou funkci a po auditu se nedoplatite.

Já určitě nechci tvrdit, že nic lepšího než Oracle není, protože si to fakt nemyslím. :-) A je pravda, že zrovna to zálohování a obnova je podle mě na Oracle peklo.
Jen jsem zmínil oblasti, kde to mají Oracle a IBM dotažené trochu dál než jak je to v PostgreSQL. Že mají zase spoustu jiných neduhů mohu jen potvrdit. Oblast replikací/clusterů je určitě oblast kterou by stálo za to posunout v PostgreSQL trochu dopředu.
Ale je to komunitní projekt a chápu, že u některých věcí se hledá shoda složitěji, takže trvá déle, než se něco protlaří/vyřeší.
Stabilita prováděcích plánů v databázích je na samostatnou diskuzi. :-)

Ohledně těch replikacích se nám teď na PostgreSQL stalo, že začal vytvářet WAL a za 2 hodiny byl schopný vytvořit 100GB dat. Což je paráda, když vám to běží v Azure, kde lze prostor pouze přidávat a již nejde ubírat. Proč se to stalo netušíme, protože tam žádná změna nebyla. Pomohl obyčejný restart. Naprd je, že se hrozně špatně hledalo co jsou ty data, protože když je spravované Azure, tak nemáte přístup k filesystemu a přes DB se ta velikost zjišťuje dost špatně.

Oracle porad jeste nejake vyhody ma, ale jejich licencni politika a vztah k zakaznikum je cesta do pekel. Mezi temi vyhodami bych urcite nezminil vykon, ale jine veci na ktere se na zacatku projektu tolik nemysli. Vetsina tech vyhod jsou extra cost options, za ktere je potreba platit dalsi licence.
Tzn. Oracle v zakladni verzi je srovnatelny s Postgresem

- RAC cluster. Horizontalni skalovani, multi-master cluster.
- Ruzne HA featury JDBC driveru (navazane ja RAC a Dataguard)
- Post mortem analysis. Oracle Wait interface sampluje zatez databaze, z techto dat se pak da vytezit informace o tom co se kde rozbilo, ktery plan se zmenil, kdo koho blokoval, ...
- Pak jsou tu ruzne vyfikundace na export/porovna­ni/stabilizaci exec planu.
- Oracle ma celou sadu toolu, ktere umoznuji generovat diagnosticka data a poslat je supportu(popr. z nich neco vycist sam).

Pak jsou tu veci ktere Postgres ma, ale vlastne je to SW od 3. strany jako patroni, pgbouncer a ruzne tooly pro CDC.
Vyhoda Oracle je ze tyhle tooly jsou od stejnyho vyrobce(akorat se za ne musi platit dalsi tezky penize navic).

No právě, spousta pokročilých funkcí pro PG často existují jako produkty nebo rozšíření třetích stran, ale v Oraclu jsou extra cost, takže ve výsledku to cenově třeba dopadá podobně. Asi jde taky o klasické "nikdy nikoho nevyhodili za to, že koupil IBM" - v tomto případě Oracle. U Postgresu to třeba bude stát stejně a výskyt problémů bude stejný, ale když k nějakému dojde, tak to někdo odskáče, proč nepořídil "industry standard".

Hura, logovani do json!!!!!! Super.

DIky za clanek.

Tohle jsou nejlepsi clanky, diky.