Dotaz: PostgreSQL skalovanie?

[Mike Stuffel]

Dobry den,

Mame dosluhujuci databazovy server PostgreSQL 8.3 s 12 jednoduchymi databazami, do ktorych sa ukladaju nejake statistiky + dalsie doplnkove udaje. Databaza sa vyuziva defakto ako datovy sklad. I/O performance je fajn. Backupy na deduplikovane ulozisko tiez funguju v pohode. Vseho vsudy je tam 80 tabuliek. Data zaberaju cca 800 GB. V priebehu dalsieho roka je predpoklad ze databaza narastie na cca 900 - 1000 GB

 

Aj ked podla dokumentacie max velkost tabulky je 32 TB co je pre nase potreby zrejme limit ktoreho nedosiahneme, mam trochu obavy z "magickej" hranice 1 TB

 

Testovali sme aj noSQL - lebo teraz je to in :) - data boli konvertovane do JSONu - couchDB a mongoDB ale tieto databazy zaberaju asi o 170 - 210% viac diskoveho priestoru ako data v PostgreSQL co sa mne osobne moc nepacilo.

 

Ma zmysel sa zaoberat nejakym skalovanim PostgreSQL (ciel: zvysenie bezpecnosti a integrity dat)? Alebo "magicku" hranicu 1 TB nechat plavat a pripravit sefa na kupu noveho dostatocne vykonneho servera a premigrovat na PostgresSQL 9.x?

 

Dakujem za nazory

---

---

Odpovědi

[okbob]

Při takto velkých datech by první otázkou mělo být, zda vše musí být v jedné tabulce, případně v jedné databázi?

1T bych se nebál - interně PostgreSQL používá soubory o velikosti 1G. Ale práce s takto velkými daty je nepraktická. Určitě se vyplatí myslet o partitioningu, ať už vlastním nebo vestavěném. A při větších objemech i o možnosti rozdělení dat na několik sereverů - mít rozdělené schéma do několika databází.

[Mike Stuffel]

Sak prave, ja sa hlavne obavam, ked budeme kupovat novy server, ci tych 1 TB na jeden PostgresSQL nebude prilis velke susto.

Neobavam sa nedostatocneho vykonu ani I/O kedze struktura dat je velmi jednoducha a ziadne komplexne SELECTy ani komplokovane JOINy sa nepouzivaju. Skor sa obavam o mnozstvo dat a zachovanie ich bezpecnosti a integrity a ci to PostgreSQL zvladne.

Pocitam so zivotnostou servera tak 3-5 rokov co by znamenalo ze za 5 rokov tam bude cca 2 - 2.5 TB dat. A ked uz sa to bude riesit tak poriadne.

V takom pripade sa naozaj javi ako dobre riesenie "rozdelenie" databaz na viacero serverov. da sa to vobec urobit tak aby bol jeden server na ktory sa budu pripajat klienti a databazy sa budu fyzicky nachadzat na inych serveroch? chcel by som zabranit aby jeden PostgreSQL sa staral o vsetky data - ked sa nahodou stane problem, aby to neposkodilo vsetky data ale prinajhorsom len tu konretnu databazu

[okbob]

2.5T není málo, ale zase na dnešek to není až tolik - samotné uložení je snadné - otázkou je zálohování, způsob zálohování, požadavky na dobu obnovy ze zálohy, reakční doba dotazů. Tam už se samozřejmě projeví velikost RAM a parametry IO. Bezpečnost a integritu bych neviděl jako problém. Ty největší databáze jsou ještě o dva řády dál.

Skype má distribuovanou databázi a o integraci se mu stará proxy uzel PL/Proxy. Osobně bych si pro jednodušší aplikaci (s minimem různých aplikací, které se připojují k db) napsal vlastní jednoduchý rozbočovač - obalil bych si driver databáze - PL/Proxy má význam pro složitější než triviální architekturu.

[Mike Stuffel]

Dakujem, nasiel som pekne PDF-ko ohladom PL/Proxy http://www.2ndquadrant.com/static/2quad/media/pdfs/talks/char10/plproxyandfriends.pdf je tam odprezentovana podobna situacia ako u nas.

[Heron]

Hranice bych se nebál a pokud vám to k vaší spokojenosti fungovalo do teď, tak v 9.x si výkonnostně polepšíte. V tomto roce jsem migroval asi 90 DB o celkové velikosti přes 200GB (upgrade 8.1 -> 9.2) a nárůst výkonu a zmenšení velikosti na disku (díky kompresi LO, toastu) je opravdu znát. Tímto upgradem jsme si ušetřili (posunuli) nákup HW o několik let.

[okbob]

dakujem... je dobre mat pozitivny feedback od ludi co uz migrovali :)

[Radim Kolář]

8.1 to byla historie. Oproti 8.4 je na 9.1 vykonostni rozdil minimalni.

8.4 je v RHEL6(tam jsou 2 verze pgsql), v RHEL7 je 9.2.

RHEL7 je oproti 6 o 10% rychlejsi.