Názory k článku Novinky v připravovaném PostgreSQL 9.3

Masivní článek, to si o víkendu počtu. Díky za shrnutí, zrovna jsem tento týden nahazoval PSGS cluster a mezitím browsoval po netu co je novýho k 9.3 beta1... a na rootu takovéto pěkné pojednání.

Děkuji za článek. Jako vždy prfektní a užitečná práce. Jen houšť a větší kapky.

Za zminku stoji 2 featury:

1. soucty diskovych stranek - bylo implementovano v oracle 6
2. materializovane pohledy - Oracle 8

Tak a ted mi napiste ze tohle vyviji 50 lidi a jak jde vyvoj skvele rychle.

Dobra zprava, rek bych ze jste s tou replikaci vicemene dohnali INFORMIX, ten je ale tuhej od doby co ho IBM koupilo v 2001 za miliardu a porad jeste do jeho vyvoje investuje - zoufalci. Neznam zadneho NOVEHO zakaznika ktery by si nainstaloval INF.

Vývoj Postgresu začal o dekádu později (až dvě dekády později) - na hw s úplně jinými parametry a pro úplně jiné programátory - takže chybějící součty a chybějící materializované pohledy nikoho extra netrápily. V Oracle zase není typ Range nebo indexace regulárních výrazů - a když ukazuji Oraclistům nenáročnost instalace, konfigurace nebo pohodlí a možnosti SQL konzole, tak jenom smutně koukají.

Ale cílem Postgresu není napsat "Oracle zadarmo", ale vytvořit dlouhodobě a s minimálními nároky udržovatelnou výkonnou a spolehlivou databázi, která nabízí vysokou shodu se standardem a jednoduše se používá, a kterou lze jednoduše rozvíjet, případně jednoduše forkovat (EnterpriseDB, Greenplum, ..).

"1. soucty diskovych stranek - bylo implementovano v oracle 6"

Je otázkou, zda tohle vůbec patří do DB vrstvy. Podlě mě ne. I mezi vývojáři Psql se o tom vedla dlouhá disku.

Vzhledem k tomu, že o checksum bloků se dneska starají systémy souborů a i samotná bloková zařízení, tak mi nedává smysl tohle ještě duplikovat na softwarové vrstvě.

Teoreticky je to pochopitelne na hovno. Prakticky ale umet opravit ze zalohy pouze vadne bloky a navic online je velmi dobra vec.

Tady vidite rozdil mezi teorii a praxi. Teoreticky stavite mrakodrapy prakticky neumite ani zatlouct rebik.

Stačí jeden nešikovný UPDATE tabulky, a tuto metodu už nemůžete použít, případně musíte pracně z transakčního logu rekonstruovat možné změny nabořené stránky. To už je docela dobrá cesta, jak totálně rozbít konzistenci databáze.

Takze o implementaci v oracle nevite nic, ale jste presvedcen ze je spatna neli uplne nemozna.

Lidi s timhle pristupem vyhazuju a je mi jedno kolik let pro mne vzorne pracovali. Jakmile takhle zmagori tak uz nedokazi vubec nic.

Moje uspechy zaviseli na presne tehle veci. Zatimco mnoho chytrych lidi rozumovalo proc je neco nemozne, tak ja trouba si to sel zkusit a dal jsem to.

To je asi na dlouhou diskusi - v mailing listu se hrozně dlouho diskutovalo jestli to vůbec dělat, a jestli to skutečně nepatří do filesystému.

Jeden z důvodů proč to nestačí na úrovni souborového systému je že fs (na x86) pracují tradičně s max. 4kB bloky, zatímco PostgreSQL defaultně s 8kB (menší se v podstatě nevyplatí, naopak větší mohou být výhodné pro DWH aplikace).

No a potom už checksum na úrovni fs nestačí, protože zápis 8kB stránky může spadnout "uprostřed" - jedna 4kB stránka se zapíše, druhá ne. Obě mají na úrovni filesystému správný checksum, ale z pohledu DB nikoliv.

Navíc implementace v DB by mohla poskytovat potenciálně větší flexibilitu v reakci (ale to už vařím z vody).

Každý rok 1. dubna někdo přijde s podobným návrhem. Teoreticky by to ale neměl být velký problém - ještě z dob před SQL podporuje Postgres tzv FastCall API (a protokol) a napsat extenzi, která by obalovala INSERT, UPDATE, DELETE je práce tak na dva dny (interní API tam je). Možná ještě méně. Jenomže proč to dělat? Postgres je ACID MGA relační databáze. Key value CAP databáze budou řádově rychlejší - pro jednořádkové INSERT, UPDATE, DELETE, SELECT operace - i kdyby se jednoduše obešlo SQL (většina relačních databází je optimalizovaná pro hromadné operace). Přepsat Postgres pro CAP by znamenalo napsat skoro celou novou databázi, což mi přijde zbytečné, když už tu CAP nebo memory NoSQL databáze jsou.

Technicky to možné je, zatím to nikdo nezkusil. A osobně jsem docela skeptik. U dobře napsaných aplikací má SQL zanedbatelnou režii, a u špatně napsaných by to ničemu moc nepomohlo, bo by se rychle narazilo na limity způsobené podporou ACID. Ale třeba to někdo někdy dá. Může to být i zajímavý test jestli někde v pg není třeba nějaká performance bota.

Pár odkazů k tomuto tématu

* http://www.postgresql.org/message-id/AANLkTikkg5R9QP3rzhFRvGLAAhYqjsyWqD6+YJHYyo9S@mail.gmail.com
* http://www.infoq.com/news/2010/10/MySQL-HandlerSocket-VoltDB

Pokud jde opravdu o co nejrychlejší emulaci ISAM engine, tak pak potrebujete obejít protocol a komunikovat s db přímo - což by teoreticky nyní šlo snáze díky background worker processu - a dál už by bylo volání lowend funkcí pro přístip k datům. Potom nejsou potřeba ani PP statements. Pořád si netroufám odhadnout o kolik by tento přístup byl rychlejší - možná výrazně, pokud budete mít data v cache. Reálně by ovšem mělo být hrdlem IO operace.

Přetypujte na numeric (za cenu výrazného zpomalení výpočtu :-( )

select sum(count*length::numeric) from xx;

A nebo můžete místo ::numeric zkusit ::bigint, tj. 64-bitový integer který umí hodnoty až do cca 10^19.