Vlákno názorů k článku PostgreSQL 16: hodně malých vylepšení a optimalizací od Honzucha - To ze je Postgres nejméně problemovou komponentou stacku,...
-
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.
-
Adam KaliszStříbrný podporovatelPostgreSQL 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.
