PostgreSQL 9.6 (diskuse)

[Franta]

Uber přešel od Postgresql k MySQL. Snad by k těm důvodům mohl někdo z pgsql nadšenců řict něco bližšího. Celý svět utíká k Postgresql (i od Oracle) a najednou takový omyl.

[nyan]

https://eng.uber.com/mysql-migration

TL;DR Postgres trpi (v jistych situacich) write-amplification, ktera v MySQL neni.

I kdyz osobne mi prijde pouzivani NoSQL nad MySQL (nebo Postgresem) jako skrabat si prave ucho levou rukou... celkem nechapu proc nepouzili nejakou NoSQL databazi, nicmene *shrug*.

[ehmmm]

Hodne zajimavy odkaz. Dekuji.

[trekker.dk]

The bug we ran into only affected certain releases of Postgres 9.2 and has been fixed for a long time now.

Zajímalo by mě, jestli to znamená "už dávno jsme pomohli tu chybu opravit a už tam není", nebo "neaktualizovali jsme a postihla nás chyba, která byla v upstreamu dávno opravená"

[Filip Jirsák]

Stačí si přečíst část Postgres Upgrades, tam je to napsané a vysvětlené. Protože PostgreSQL používá pro repliky binární log, který se mění mezi verzemi, není možné replikovat data mezi různými (hlavními) verzemi PostgreSQL. Tím pádem nebyly schopni přejít bez výpadku na novější verzi.

[Ivan2]

Obavam se, ze na podobne problemy narazi u vsech databazi. Jedine snad u Informixu je mozne vzit verzi 7 nechat ji zreplikovat do verze 11 a pak provest preklopeni na novou verzi s minimalnim downtime.

A pokud jde o ty problemy s implementaci MVCC, tak by me zajimalo jak to ma udelane InnoDB, ze jim to nevadi. Dazda implementace MVCC prinasi nejake problemy, protoze jednoduse nic na svete neni zadarmo.

[trekker.dk]

Ano, tam je napsané a vysvětlené, proč jim činilo problémy přejít na novější verzi v řadě 9.x. Na mojí otázku, jestli aktualizovali v rámci 9.2.x, to ale neodpovídá.

[Filip Jirsák]

Žádný omyl. Kdo potřebuje SQL databázi, použije PostgreSQL. Kdo potřebuje úložiště záznamů s rychlým zápisem, použije NoSQL databázi, a pokud z nějakého důvodu potřebuje k té NoSQL databázi použít SQL přístup, použije MySQL.

[RomanV]

Doporučuji tento článek: http://blog.2ndquadrant.com/thoughts-on-ubers-list-of-postgres-limitations/

[okbob]

Uber kompletně zahodil SQL a přešel na vlastní ORM - navíc hodně specifické ORM - v podstatě databáze je jenom storage pro JSONy. Intenzivní write operace nad denormalizovanou databází fakt není to pravé ořechové pro Postgres. Těch důvodů je víc - čím více se db používá jako storage a méně jako db, tím má větší smysl používat InnoDB a naopak.Navíc Uber se rozhodl řešit rozklad zátěže databázovou replikací - a tam mu přirozeně musí vyhovovat vestavěná logická replikace v MySQL. Ve verzi Postgresu, kterou Uber používal se logická replikace (slony) reálně použít nedala. => Postgres je relační databáze a má smysl tam, kde se relační databáze používá. Jako storage nemá žádné zvláštní výhody. V takovém use case se InnoDB chová lépe (což není překvapivé - InnoDB je storage).

[ehmmm]

Bylo by nejake dalsi info?

Ukladat JSON do DB (respektive to SQL DB) musi byt docela zoufalost, nebo ne?

Proc to delali? Co v tech JSONech meli? Jak to indexovali, jak v tom hledali?

[Odin1918]

HSTORE ?

[Pavel Stěhule]

HSTORE by se neměl používat pro důležité atributy - je to jen pomůcka, abych neměl zbytečně řídké, nepřehledné a široké tabulky. Je to výrazně lepší než univerzální EAV nebo lidová tvořivost v položkách jako je poznámka, popis atd. Nicméně ty základní atributy, podle kterých se vyhledává, počítá, tak by měly být uložené relačně. Postgres je a bude primárně relační SQL databáze - ale díky chytrému uložení dat se dá částečně používat i jako dokumentová databáze - musí být ale splněné určité podmínky - jako, že např. data jsou převážně statická.

[Pavel Stěhule]

Jednak něco se objevilo na blogu Uberu, něco i v diskuzích v Postgres mailing listu. Proč to dělali a co tím zamýšleli, to nikdo neřekne. Už to, co měli nad Postgresem nebylo úplně nejšťastnější. Co vím, tak v JSONu mají nyní všechno. Takže se asi pokouší o vlastní NoSQL přístup - případně možná časem doiterují k event zpracování dat ale LinkedIn. Při opravdu velké zátěži (ala LinkedIn) je klasický databázový přístup omezující - už se neřeší databáze, ale proudy dat + big data (třeba Hadup) analytika.