Názory k článku
PostgreSQL 9.0: nový začátek

Za prvé, moc pěkný článek. Musím pochválit.

Chtěl bych se zeptat, zda je někde nějak přehledně popsána ta replikace, především všechny ty možnosti?

Typicky mi jde o to, že mám server, který bych případně chtěl rozdělit na víc (z výkonových důvodů). Do teď byla možnost jen Slony, ale naprosto se mi příčí přístup přes triggery. Ale netušíl jsem, že existje nějaké API s hooky na replikaci, jak to funguje?

Bohužel se mi zdá, že ten nový přístup nelze použít na nic jiného, než hot standby. Nebo je nějak řešena konzistence jednotlivých serverů? Například když udělám INSERT na master serveru a pak SELECT na libovolném stroji, dostanu již pokaždé i ten nový záznam?
Teoreticky by stačilo nějak server běžící readonly přesvědčít, aby zápisy přeposlal na master server a pokračoval ve zpracování až ve chvíli, kdy záznamy bude mít u sebe. Například případ, kdy založím nový záznam v tabulce faktur a hned si ho načtu zpátky a použiju.

Zatail experimentujem s nasledujucim setupom: slave ma shared file system ktory je mountovany read-only (master rw) a PGPool-II na distribuciu SELECTov na slave a vsetko ostatne na master. Ako shared fs mam GFS2.

Zatial vyzera ze vsetko funguje tak ako ma…

To je zajímavé, jen mám strach, aby to nebylo takové moc překombinované. Ikdyž tohle jeětě vypadá na únosnou mez :-)

Pochopil jsem to správně tak, že věechny ty DB stroje používají jeden sdílený adresář PG_DATA? Jestli ano, jak je pak zajištěno, že master postgres všechno víceméně okamžitě uloží na shared FS? To by se asi dalo vyřešit i tím hot standby, co umí 9.0, ale pořád mi tam chybí ta jistota, že např SELECT okamžitě po INSERTu vráti i nová data…

ano, PG_DATA je zdielany a zatial som nezaznamenal ziaden delay medzi insert/update a select.

docela bych se takového řešení bál – nikdo Vám negarantuje pořadí zápisu do datových souborů – díky write cache může dojít k porušení konzistence.

zaujimave, zatial to len testujem a tiez som mal podobne obavy. Ako som tak brosoval tak som nadobudol pocit ze data na disku budu vzdy konzistentne a teda ze z toho adresara moze citat viac instancii ale zapisovat iba jedna.

Data na disku konzistentní občas jsou – pokud přijde checkpoint což je v defaultu např. max 5 minut. Jinak jsou změny zachyceny pouze v cache (shared-buffers), a samozřejmě aby nedošlo ke ztrátě dat při výpadku, tak v transakčním logu. Rozdíl mezi uloženými daty a aktuálními daty je zachycen právě v transakčním logu. Nová instance db, i když pojede na daty jiné instance nebude sdílet shared-buffers. Když budete mít kliku, tak to fungovat může – ale nikdo a nic Vám to negarantuje.

Mě hlavně není jasné čeho tímhle setupem vlastně chcete dosáhnout …

I kdyby to nakrásně z nějakého záhadného důvodu fungovalo (přes Pavlovy argumenty proč to spolehlivě fungovat nebude), tak mi uniká smysl toho sdíleného disku. Replikace se v zásadě používá v případě že (a) potřebujete záložní systém a nebo (b) rozložit výkon na víc strojů:

(a) zálohování

V tomto případě většinou na slavech nepotřebujete provádět dotazy, stroj tam prostě jenom sedí a „čeká“ až produkce spadne a on se přepne do pozice mastera. Tudíž vás nějaké drobné zpoždění mezi zápisem na masteru a propagací na slave moc nevzrušuje (navíc s hot-standby to bude minimální).

Navíc ten sdílený disk představuje „single point of failure“ tj. například pokud selže hw nebo pokud master při odchodu nějak brutálně rozvrtá ten datový adresář (byť se mi nikdy nic takového nestalo), tak nemáte nic. A to je u zálohování trochu problém …

(b) rozložení výkonu

V případě databází je nejčastějším bottleneckem bezpochyby I/O (na HDD). Tím že používáte sdílený disk tak to zatížení I/O v podstatě nijak nerozkládáte protože všechno jde přes jeden diskový systém (řadič, fyzické disky, …). A navíc to jde ještě přes síť což přidává další latenci (jak moc záleží na síti, síťovkách, atd.).

Čili ani v jednom případě by použití sdíleného disku nebylo funkční řešení …

PS: Jako jo, mohli bysme se bavit o řešeních sdílených discích typu SAN apod. přes které by to teoreticky mohlo fungovat (ale ne pro PostgreSQL, viz. Pavlův příspěvek).

ad B

sdd disky tohle resi.

Ne zcela rozumím jak to SSD disky řeší …

Vycházím z toho že pokud mám I/O bottleneck na disku, nevyřeším ho tím že na stejném disku rozchodím další instanci databáze která tudíž bude užírat I/O z toho samého disku, čímž problém ještě zhorší. A to že se jedná o SSD na tomhle principu nic nemění, ne?

Navíc je otázka co je to za SSD disky (Flash vs. DRAM) a jaký typ zátěže to je (write vs. read). Např. flash SSD disky mají problémy při zápisu, kdy jsou dokonce pomalejší než tradiční disky – u DRAM SSD tohle samozřejmě neplatí.

Ale připouštím že SSD disky nijak detailně nesleduji a třeba se v poslední době udál nějaký zásadní koncepční zlom.

Nicméně SSD disky jsou obecně dražší a je otázka jestli to ve výsledku je rentabilní řešení. Navíc DB oblast je poměrně konzervativní.

Kdyz mate kvalitni storage s kterou jste se asi doposud jeste nesetkal kdyz porad trvdite ze je nejpomalejsi disk a udelate si z toho data sharing group na mainframech pripadne na POWER a nasadite shared disk db reseni  – DB2 Purescale na POWER nebo Oracle RAC. nebo DB2 for z/OS tak jeden node v takovem clusteru dela cca 15–25k transakci/sekundu a ma to do 32 uzlu prakticky linearni skalovatelnost.

Pokud narikate nad pomalym diskem tak si kupte lepsi storage a vice RAM, pod 64GB na uzel nema cenu dneska jit.

1) Všimněte si prosím že můj příspěvek je formulován ve smyslu „Pokud máte problém s I/O na disku, další instance přistupující na stejný disk nepomůže.“
Nechápu vaši argumentaci ve smyslu „Ale s kvalitní storagí typu … to problém není!“

Není, to máte samozřejmě pravdu, ale to také nebylo pointou mého příspěvku. Trochu mi to připomíná vtip končící „Ale vy zase bijete černochy!“

2) Pořád mi nějak uniká jakým zázračným způsobem se ty SSD disky vyhýbají uvedenému principu „když mám problém s I/O na disku, nemá cenu tam rozjíždět další instanci.“ Možná mají vyšší propustnost, nižší latenci atd. ale ten princip pro ně pořád platí …

3) Ano, máte pravdu že s uvedenými technologiemi (alespoň s výjimkou Oracle RAC) běžně do styku nepřijdu. Jste holt lepší. Nicméně tak nějak jsem – možná mylně – předpokládal že pisatel původního příspěvku se na takovém prostředí nepohybuje. A i kdyby pohyboval, formulace mého příspěvku s tím nijak v rozporu není (viz. první odstavec).

4) Tvrdím že disk je nejčastější příčinou výkonnostních problémů na DB. Netvrdím a nikdy jsem netvrdil že to tak je vždy, za každých okolností a na každém hw. Předpokládám ale že se shodneme že na standardním hw to tak je.

5) Bez ohledu na předchozí body je to v případě PostgreSQL bezpředmětná diskuse, protože PostgreSQL provoz více instancí nad sdíleným adresářem nepodporuje.

Hot standby je popsáno v dokumentaci http://developer.postgresql.org/pgdocs/postgres/index.html . Popis možných hooks bohužel nikde není – není to nic, pro běžného uživatele – ohledně replikací by bylo možné se inspirovat v Slony2. Jinak – jak slony, tak hot standby implementují asynchronní master/slave replikaci. Vy asi hledáte synchronní master/master replikaci – tu například poskytuje projekt pg_cluster – což je speciálně upravená verze PostgreSQL.

Ten popis hot standby jsem četl. Spíš jsem měl na mysli nějaký souhrn možností a jejich srovnání s nějakým výhledem do budoucna. Můj problém je podle mně docela běžný. Mám DB server, který už nestíhá, je možné pořídit více serverů, ale aplikaci není možné upravit tak, aby pracovala s více servery. A poměrně často se spoléhá na to, že pokud udělám insert/update/de­lete + commit, tak po commitu už tam ty data budou nebo nebudou (podle operace). Samozřejmě by se mi i líbilo, kdyby se to dostalo do stavu, kdy pád jednoho serveru pouze sníží výkon celého řešení.
Jako jediné použitelné řešení vypadá ten PgPool, který sice představuje SPOF (Single point of failure), ale to by se dalo vyřešit záložním serverem nebo nějakým záložním virtuálem.

Celému týmu za skvělou práci. A Pavlovi za jeho články. Už se těším.

Paradni souhrn diky moc. Snazim se procpat PostgreSQL v novem zamestnani (v predchozim se podarilo :-)) tak se novinky jako argumenty vzdycky hodi.

Problém mass hostingů je ten, že všichni uživatelé se mohou dostat k celkovému seznamu uživatelů a databází na serveru. Je to již nějak vyřešeno?

je a není – pro každého takového uživatele je nutné založit db cluster, čímž je izolovaný od ostatních. Se správou rolí per db (tak jak to má např. MySQL) se nepočítá.

Ak to naozaj potrebujete vyriesit skuste:
http://linux-vserver.org
Nepredstavuje to velku zataz pre server a je to spolahlivejsie ako cokolvek aplikacne riesene. My bezibe niekolko desiatok virtual servrov bez problemov.

problem? to asi jenom v tom pripade, ze budete chtit uzivatelum tvrdit, ze na tom serveru jsou sami.

Najprv by som chcel podakovat za pekny clanok. Pouzivame PostgreSQL uz dlhe roky pre nase Java aplikacie. Strucne:
1) Existuje nejaka statistika ako sa PostgreSQL bezne pouziva? Java backend, ine web aplikacie, … .
2) Vsetky tieto vlastnosti su fajn ale existuje plan ako ich napriklad integrovat do Hibernat-e?
3) Bude sa riesit optimalizacia JDBC drivera?

Sme focusovany na Javu ale napriklad uz iba hlupe ‚like‘ medzi cislom a retazcom bol v 8.3 zakazany. Pritom chcem obycajne „345 like 3 = true“ alebo „345 like ‚3%‘ = true“. Ano v cistom SQL sa to robi lahko tak ako to popisujete zo vselijakymi SQL extensiami ale skuste to urobit tak aby to fungovalo cez Hibernate → JDBC → Databaza. Mate problem. Takze nakoniec zistite ze mate silnu databazu s roznymi skvelymi funkciami ku ktorym sa neviete dostat.

Podpora sequncer per table – out of box, BLOBy, to su veci ktore sa stale s Javy robia dost tazko obzvlast cez Hibernate. Nesuvisi to priamo s databazou dokonca ani s JDBC drivrom ale keby ste to vyriesili vela Java developerov by vam boli vdacnych. Je pekne ze sa zaoberate partitioningom ale pokial sa potom musite potykat so zakladnymi problemami ako je BLOB a byte[] a musite si koli tomu citat 3 hodiny clanky na internete aby ste to spravne nastavili tak vas humor prejde. Pritom v Oracle a MySQL to ide bez problemov.

Napriek tomu drzim palce a dakujem za skvelu databazu.

No, on ten JDBC driver má víc much, například doporučuji dávat si velký pozor při práci s kurzory (v podstatě je vůbec nepoužívá, takže například HOLD_CURSORS_O­VER_COMMIT není podporováno) a s dávkami.

V podstatě, pro nejaké „pokročilejší“ použití je potřeba zapnout debugování a zkoumat jak vlastně komunikuje se serverem.

Disclaimer: tyto zkušenosti jsou více než rok staré, dnes již může být situace lepší.

Osobně mám pocit, že se teď pg používá nejvíc právě s Javy – bohužel v core týmu není nikdo, kdo by Javě rozuměl a měl ji v oblibě – a ti lidé, kteří píší JDBC driver mají asi dost specifický přístup :(. Je to Open Source – ta kvalita je dána lidma, kteří to píší a záleží jak moc to berou osobně. Core pg jsou všíchni céčkaři. Je to dost vidět na .NET driveru, za kterým je jeden nadšenec, a který je o dost dál.

Uz ma PG subtransakce? Tohle je vec ktera mi nejvic chybi – jak v prikazove radce (preklep v prikazu shodi celou transakci) tak i v aplikacich – treba pokud chci zmenit nejaky radek (nebo vlozit pokud neexistuje), muzu delat INSERT a v pripade vyjimky UPDATE.

A pak jeste packages – hlavne kvuli per-session promennym. Napriklad takto muze komunikovat for-each-row trigger s after-statement triggerem. Mozna se to da emulovat pomoci docasnych tabulek.

-Yenya

Subtransakce? Co CREATE SAVAPOINT?

Packages nejsou, což je škoda, ale jde to celkem bez problémů řešit přes temporary tabulky. Navíc package state (session proměnné) jsou u Oracle zdrojem problémů s discardováním package state (po rekompilaci).

SAVEPOINT zda se funguje, diky. Ted jeste aby kazdy SQL prikaz mel implicitni SAVEPOINT v sobe.

Jo, rekompilace package je problem, ale nevnimam to jako neco zasadniho.

-Yenya

Packages chtějí všichni, ale nikdo neví jak na to – díky tomu, že PL v PostgreSQL není jen PLpgSQL, ale také PLPerl, PLPython a další. Osobně nečekám příliš velký pokrok – ale třeba se něco změní.

Podívej se na ON_ERROR_ROLLBACK nastavení v konzoli – mám pocit, že je to, to co chceš, nicméně jistý si nejsem – možná to bude funkční až v kombinaci s AUTOCOMMIT ON.

Jo, taky bych packages chtěl – hlavně jako nástroj pro rozumnou organizaci zdrojáků, takhle je to všechno „na jedné hromadě.“ Ale záleží jak velká část logiky se v DB implementuje – já to většinou používám jenom na triggery takže se s tím dá žít.

používám schémata – myslím, že jsme docela dobře zvládli projekt o několika set funkcích – i když samozřejmě packages to nejsou.

Nehodil byste sem nějaký nástin co se osvědčilo?

a) používat schémata
b) procedury psát do obyčejného souboru – jako klasický zdroják a importovat do db příkazem \i v konzoli.
c) používat kombinaci PL jazyků sql, plpgsql a plperl (případně výjmečně plperlu)
d) do kódu přídávat trasovací body – příkaz RAISE NOTICE, které jsme nemazali ale zakomentovali

+ klasika sw inženýrsví – čítelné komentáře, rozumně dlouhé procedury, atd atd další informace viz slajdy ze školení http://www.postgres.cz/index.php/Jednodenn%C3%AD_%C5%A1kolen%C3%AD_PostgreSQL#PostgreSQL_efektivn.C4.9B.2C_v.C3.BDvoj_.28ulo.C5.BEen.C3.A9_procedury.29

Nojo, fakt. \set ON_ERROR_ROLLBACK dela presne to co chci (bez autocommitu, resp. po BEGIN WORK). Jak dlouho toto v PG je? Vzdyt ja po necem takovem volam v mnoha ruznych diskusich o PG, a zatim mi to nikdo neporadil. Zda se ze na 8.1 mi to funguje, zatimco na 8.0 ne.

-Yenya

No je to tam dlouho – 8.1 za chvíli vyprší pětiletá podpora :)

jinak s dotazy ohledně pg http://groups.google.com/group/postgresql-cz?hl=cs

Pavel

Tak ono vytvářet spoustu savepointů asi taky není úplně optimální. V PL/pgSQL se to dá řešit celkem elegantně pomocí ošetření exceptions, s obyčejným SQL asi jenom ty savepointy).

Souhlasím že rekompilace package zásadní problém není – je ale potřeba aby všichni klienti počítali s tím že mohou po rekompilaci dostat exception a uměli na to správně zareagovat.

Postresql má už hodně dlouho savepointy a fungují dobře (dokonce i přes JDBC). Používám to právě pro obcházení té feature že chyba provede automaticky rollback (přeci jen jsem zvyklý na databáze, kde chyba transakci nijak neovlivní).

Od 8.0 tj vice nez 5 let ma SAVEPOINTy.

…za vyčerpávající článek. Nemůžu se už 9 dočkat :-)

jsem na pg9 zvedav

Zdravim,
diky za pekny clanek, jsem sice Oraclista, ale je dobre vedet, jak jsou na tom ostatni ;-)
list_agg v Oracle: nevim o tom, ze by bylo mozne nativni Oracle funkcni agregovat retezce, jedine si napsat vlastni funkci…nebo se mylim?

Nejspíš jsem to napsal špatně, omlouvám se – funkce se jmenuje listagg a je v 11 Oracle např. http://karenmorton.blogspot.com/2009/09/11gr2-listagg.html

paci sa mi
SELECT * FROM (values(10,20,30)­,(40,50,60)) x(a,b,c)

nevie niekto ako toto spravim v oracli??