To ze je Postgres nejméně problemovou komponentou stacku, bych vzal hodně s velkou rezervou. Z mého pohledu je to právě ta komponenta, která konzumuje hodně lidských zdrojů k tomu aby ji člověk udržel v rozumném stavu. Zde samozřejmě mluvím o multi node ha clusterech s replikaci do read-only BI instance například. A pak bychom se mohli dostat k údržbě, VACUUM je dlouhodobě bolestivé a pg_repack se ne vždy dá použít. Reindexace je další oříšek, a třeba z tohoto důvodu Bolt velice aktivně migruje z pg to TiDB a totéž v tuto chvíli aktivně prozkoumává i Wise. Také bychom mohli pokračovat shardingem, jeho resizing a rebalancing je také hodně velká bolest (ačkoliv tady je hodně zajímavý citus, nicméně ten vám zase vezme plnou kontrolu). Tedy pokud provozujete postgres v poměrně jednoduché topologii tak ano, ale pokud potřebujete provozovat postgres jako distributed multi-tenant system, připravte se na bezesné noci.
Ďábel je schovaný v detailech. Zde se koukáme na stejný problém stejnou optikou, ale z jiného úhlu. V primitivním setupu dokáže běžet v klidu snad úplně všechno. Ale důležité je jak systém dokáže bych relativně snadno udržitelný v netriviální topologii. Kromě toho bolesti v VACUUM a reindexaci nemají s topologii víceméně nic společného.
PostgreSQL je sice možná stabilní, ale v SQL a procedurálním jazyku se řeší spousta věcí opravdu nešikovně, takže se v některých ohledech poměrně špatně používá. Chodit do DB nebo nedejbože v DB dělat něco náročnějšího a to i na localhostu je nákladná operace, takže na určité věci potom člověk píše různé cache nebo řadu věcí člověk musí řešit až zbytečně do detailu.
Dost se mi líbí, jak se k řadě problémů staví https://www.datomic.com/ ale to je už dost jiný (a výrazně novější) projekt, který by asi řadu use casů PostgreSQL neobsloužil tak dobře.
Problém je, že Postgres nic jako multi-tenant multi node cluster nepodporuje nativně. A kdyby si vývojáři mysleli, že je možnost tuto podporu do Postgresu s rozumnými náklady efektivně napsat, tak už tam je. S nějakými nástroji jde víc nebo míň ohnout, ale stále to bude dost daleko do nativní podpory. Postgres jinou než jednoduchou topologii nepodporuje. Postgres je klasická relační databáze, a aby vám dobře fungovala, tak je potřeba ji používat jako klasickou relační databázi, případně je lepší jít vstříc Postgresu architekturou než ohýbat Postgres.
Používejte Postgres jako Postgres, a nebudete o něm vědět. Jakmile se z něj začne dělat něco, čím není, tak možná budete mít bezesné noci, nevím, ale z něčeho, co je jednoduché a robustní uděláte monstrum. Kdo mne zná, tak třeba potvrdí, že kdykoliv na to přijde řeč, tak já svým zákazníkům silně rozmlouvám pro Postgres nenativní architektury.
3. 5. 2023, 19:06 editováno autorem komentáře
Pouzivejte Postgres v aplikaci obhospodarujici miliony aktivnich uzivatelu (vyssi desitky tisic concurent users) a garantuji vam ze o nem rozhodne budete vedet. To ze nema master-master replikaci bych mu ani nezazlival, s tim bude vice starosti nez uzitku. Nicmene v enterprise nasazeni rozhodne nebudete mit jednoduchou topologi a v SAAS aplikaci se bez multi-tenant neobejdete pokud si chcete zachovat rozumne ROI a sublinear cost.
V GoodData mají kolem 100 serverů, na každém několik tisíc databází a cca několik TB na každém serveru. Jako databázový admin jsem toho zase až tolik neřešil. Skype stále běží nad Postgresem - ale je to několik set nezávislých serverů. I nad Postgresem se dají postavit velká řešení. Jde to postavit všelijak, a některá řešení jsou pro databázi lepší a jiná nikoliv.
Vyšší desítky tisíc aktivních uživatelů apky není málo, ale zase není to nic extra (samosebou záleží, co dělají a jak je napsaná aplikace). V 2008 job.cz dělal ve špičkách 10 tisíc uživatelů, a obsloužil to jeden Postgres server 8CPU, 8GB RAM.
Mne tam chybi alespon zakladni load-balancer, abych nemusel pro jednoduche pripady pouzivat pgbouncer/haproxy/pgpool etc.
Ze lze do pg_hba includovat dodatecne konfigurace, hura. Jen je to pouzitelny jen do doby, nez bude potreba predradit nejake pravidlo pred nektere z defaultnich, protoze zalezi na poradi. Pak uz je skoro lepsi generovat cely pg_hba.conf rovnou. Zejmena pri soubehu md5/scram to nezjednodusuje automatizaci.
Zajímala by mě případná zkušenost lidí s přechodem z Microsoft SQL Serveru na PostgreSQL pomocí https://babelfishpg.org/
Zkusil jsem si jejich kompas na jedné poměrně reprezentativní databázi a s mírnou úpravou, že by se jedna vzdálená tabulka pravidelně sychronizovala a pár v podstatě Copy&Paste úprav, se nástroj tvářil, že by to jelo.
Nemám s tímto nástrojem zkušenosti, ale mám zkusenosti s migraci Oracle -> mssql. Pokud mate triviální tabulky tak víceméně asi ano, pokud malte nějaké složitější views s komplexním T-SQL tak si myslím, že zcela určitě narazíte to jsou věci co budete asi muset přepsat. Také bych zkontroloval konverzi jednotlivých data typů. Dále bych se zaměřil na dotazy, které tam budete běžet, pg je by default case sensitive, mssql case insensitive, takže je dost možné, že se vám budou dotazy chovat jinak.
Zajímalo by mne, jestli někdo v tomto tisíciletí (i mimo PostgreSQL) opravdu použil osmičkovou soustavu pro zápis číselných literálů. V PostgreSQL jsou alespoň literály označené prefixem 0o
, takže to nikdo nemůže zadat omylem, je to spíš takové roztomilé dodržování tradice.
Třeba v JavaScriptu literál začínající 0
(když za tím není x
nebo b
, bez ohledu na velikost) označuje osmičkovou notaci – což rozhodně to způsobilo daleko víc problémů, než jaký to má přínos. Naštěstí funkce, které v JS parsují string (tj. používají se pro uživatelský vstup), nulu na začátku neberou jako příznak osmičkové notace. A JSON pro jistotu nulu na začátku integeru úplně zakazuje, pokud to není přímo 0 nebo -0 (fakt).
Pravda, na to jsem úplně zapomněl. Jenom se teda musíme tvářit, že nevíme, že kdyby se to napsalo jako tři číslice v desítkové soustavě napsané v parametru hned za sebou (podobně, jako se píšou práva pomocí znaků třeba jako rwx
), vypadalo by to úplně stejně ;-)
Ale můžu si říkat, že jsem tak mladý, že jsem nikdy kromě zápisu práv v unixovém systému nepoužil osmičkovou soustavu.
To já bych se klidně "oroval", zase tolik práce to není. Problém octalových čísel (v C apod.) je každopádně v tom, že se nula na začátku automaticky bere jako začátek osmičkového literálu a že třeba Vim s tím tak pracuje i v kontextech, kde to nedává smysl. Za mě měli udělat 0o a vše by bylo OK. Jinak s existencí octalů problém nemám.