Vlákno názorů k článku Novinky v připravovaném PostgreSQL 9.3 od Lenin POWER! - Za zminku stoji 2 featury: 1. soucty diskovych stranek...

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).