Vlákno názorů k článku PostgreSQL 8.3: nejen razantní navýšení výkonu od Radim Kolář - 1. JDBC driver je porad slaby Neni moc kompatibilni...

1. JDBC driver je porad slaby

Neni moc kompatibilni se standardem JDBC3 a v nekterych pripadech se holt musi pouzivat workaroundy pro chybejici funkce. Nektere funkce jsou implementovany znacne neefektivne. Pritom JDBC3 neni zadna 'last technology'. Uz dlouhou dobu shanim nekoho, kdo by se nechal najmout na to, aby JDBC driver trochu dal do kupy a porad nic. Ale kdyz dotycna osoba zjisti, co se ma delat tak s tim flakne. Pravda, mohl bych zase postnout offer do postgresql-jobs, ale asi to uz nema cenu.

2. Replikace Slony1
Nestiha vetsi load na serveru, vyzaduje vicemene synchronizovane hodiny serveru VCETNE TIMEZONY!, dochazi cas od casu ke ztrate synchronizace, kdy proste obsah nekterych transakci zmizi ale servery si stale mysli ze jsou syncnuti, skalovatelnost je N*N, pro vice nez par serveru tudiz nepouzitelne, prikaz EXECUTE SCRIPT zejmena jeho obsluha chyb je bastl, nemoznost obnovit replikovanou databazi z backupu (rozhodi se mapovani objektu vazane na OID),
nutnost rucne vytvorit prazdne tabulky na slavech, velka zavislost na RTT,
zadna optimalizace pri provadeni zmen v cilove db, switchovani replikacnich
logu vice nefunguje nez funguje a jsou pouzity jen 2 ja mam naprikad v jednom
logu 80M radek a druhy prazdny. Velky log sejme replikaci protoze slave se uz nikdy nechytne (napr. vyber prvniho radku z 80M replikacniho logu trva cca 3 minuty a servery maji HB 60 sec - vice nastavit nejde)

3. VACUUM FULL
chce to online reorganizaci dat v databazi (Oracle ma, DB2 umi vcetne RAID0 mezi vice tablespaces), a pri indexy nad tabulkami je to velmi velmi pomale. Melo by to automaticky dropnout a pak vytvorit indexy pokud statistika rika ze bude potreba udelat hodne zmen.

4. Zlepsit system alokace diskspace
a) vracet volne misto preferovane ze zacatku tabulky
b) Alokovat diskspace pomoci extentu, misto alokace 8kb bloku to brat rekneme po 50MB (uzivatelem nastavitelne).

Se zamestavanim lidi so by pracovali na PGSQL, Slony1, JDBC to neni moc ruzove. OSS koderi vetsinou chteji delat na projektu ktery zajima je a ne zamestnavatele a krom toho maji znacne prehnane naroky na plat. Par jsem jich kontaktoval a chteli $8-15K nastupni plat.

Nejlepsi vec na PGSQL je ta, ze k tomu dela support Sun, takze je to jedna z mala OSS databazi co se da realne pouzit pro vetsi projekty, kde byl driv Oracle.

PostgreSQL ma daleko do idealu i do dokonceni. Uz ted je ve fronte dost patchu na verzi 8.4. Mne treba dost mrzi chybejici podpora COLLATES, coz vidim asi jako nejvetsi nevyhodu. A je pravda, ze replikace v pg, pri silne zatezi, vede dost k velkemu loadu a pak i k nestabilite systemu.

@1. Drivery nejsou soucasti projektu, coz tedy neomlouva. Zrovna tak jak je nedokonale JDBC je dost omezene i OLEDB. U JDBC bych rekl, ze je problem spis v lidech, u OLEDB jsou problemy v technologii, neb napsat korektni driver zrejme dovedou jen u Microsoftu. V nejlepsim stavu je patrne driver pro .NET.

@2. Teoreticky by se melo objevit slony II. Alespon 8.3 obsahuje nektere patche, ktere SlonyII vyzaduje. Jinak SlonyII je separatni projekt, takze se mozna objevi drive nez za rok. Jednim z cilu 8.4 je prepsani mechanismu LISTEN/NOTIFY, coz je prave to hrdlo, ktere limituje SlonyI. Realne si myslim, ze neni sance, ze by 8.4 obsahovala podporu replikaci. Patrne se bude pokracovat v lepsi podpore prubezneho zalohovani, ale to je vse. Je mozne, ze s necim prijde EnterpriseDB.

@3. Druhy cil 8.4 je nahrada FULL VACUA. Nicmene uz ted by melo dost pomoci HOT updates. Automaticke dropnuti indexu mi prijde jako docela drsna zalezitost. Mozna by stalo za uvahu vytvorit dalsi variantu vacua neco jako VACUUM FULL REINDEX ANALYZE :). V 8.4 by mela obsahovat evidenci stranek obsahujici mrtve zaznamy. Tudiz FULL FACUUM nebude skenovat celou tabulku, ale pouze prislusne stranky. To by melo celou operaci urychlit.

@4. Souvisi s evidenci volnych stranek. Kdyz naalokuji dopredu 500M, musim odpovidajicim zpusobem zvednout FSM. V podstate je to mozne uz ted .. napr. naplnit tabulku milionem zaznamu, dat delete, nechat jeden zaznam a VACUUM. Nesmi se spustit FULL VACUUM. A asi by to slo napsat i cisteji. Ale urcite to neni na poradu dne, pokud to neprijde od EDB a pokud nedokazi prokazatelne prinos. Zatim, bez evidence mrtvych stranek, by predbezna alokace znamena jen zpomaleni VACUUM.

Od toho je open source, ze lidi delaji na tom, co je bavi. Budto delaji zadarmo ale bez zavazku nebo komercne (za standardnich podminek). Za 3K$ mesicne si myslim, ze by se nekdo mel najit (tady nebo na vychod od nas). Kdybych umel javu, tak bych do toho sel sam :).

Sun urcite dela pro PostgreSQL hodne, ale take z toho ma profit. Diky Sunu, resp. vyvojaru z Prazske pobocky, PostgreSQL na Solarisu bezi docela dobre (hlavne je rychle fixovan) a je tu jeden nebo dva experimetalni projekty. Na Solarisu a na Sun serverech se s Postgresem uz ted delaji veci nad kterymi zustava rozum stat. Ostatne o tom byla Joshova prednaska v Praze.

Vsimnete si, kolik ze Softu co dela Sun (vetsina je napsana v Jave) podporuje PGSQL. Mam tim na mysli treba Directory Server, Glassfish aplikacni server, Sun Identity manager, Sun web server, atd.

Odpoved zni: NIC. Podporuje se Oracle, MySQL, DB2.

Protoze je v seznamu i OSS MySQL, tak verte tomu ze kdyby to na PGSQL chodilo, tak by to bylo podporovano taky. PGSQL Sunem podporovan je, ale ne pro tyto produkty.

Ale treba Python driver Psyco pro PGSQL je fakt svely a v PHP s nim taky nejsou problemy. O ODBC driveru bych taktez taktne pomlcel.

O neefektivite JDBC driveru jsem nemel na mysli efektivitu na Java urovni t.j. efektivitu parsovani dat ze serveru a tak, tu jsem nemeril. Mel jsem na mysli efektivitu na DB urovni. Tim mam na mysli napriklad neposilat pri zavolani jedne fce driveru db serveru 3 statementy pokud se daji sloucit do jednoho. Protoze autori z nejakeho prapodivneho duvodu pozaduji kompatibilitu s 8 let starou pgsql verzi. Krom toho taky nechapu proc je soucasti stable driveru kod, o kterem se vi, ze nefunguje. Lepsi je ten kod ze stable vetve vyhodit a hazet prislusnych fci Exceptions("Not supported").

Ten driver by se mel procistit. Podporovat stejne jako Sun PGSQL 8.1, 8.2. A zamerit se pouze na JDBC3. Je to ale utopie, to se pokud se nezmeni project leader ktery na vetsinu bugreportu odpovida nemam cas nebo to nekdo neforkne nikdy nestane. Tim chci rict kdyby se ten cas, ktery vynakladaji ti co na jdbc obcas delaji k uceni lidi pouzivat workaroundy, radsi vyuzil pro kodovani vypadalo by to dneska jinak.

Problem je ze ve vetsine OSS projektu jsou developeri zcela mimo realitu. Realita je, ze nejpozivanejsi aplikacni server pro J2EE je jboss/hibernate a kdyz ma hibernate s pgsql problemy, tak misto matlani podpory pro JDBC4 by bylo dobre konecne opravit leta stare bugy. Ale chapu kdyz maji lidi psani JDBC driveru jako konicek, podpora pro JDBC4 je vice sexy.

Kdyz se mne nekdo pta zda PGSQL nebo Oracle pro JBoss odpovidam v kazdem pripade Oracle, PGSQL by sice jako databaze bez problemu stacil, ale ma spatny JDBC driver. Pokud nechcete Oracle dejte tam MySQL.

Tohle už je o pravidelné bušení do lidí, kteří dělají JDBC driver, případně jim sem tam poslat nějaký patch, by si o člověku nemysleli, že je kverulant. Co se týče podpory starých verzí Postgresu, tak svůj podíl viny má RedHat a Debian, kteří za boha nechtěli přejít na 8.x řadu. Jinak by už sedmičková řada dávno odešla do krajiny zapomnění. Jelikož Sun začal s 8.1, tak se nedivím, že podporuje pouze 8.1,8.2. Zkus kontaktovat Zdeňka Kotalu .. ten má u Sunu PostgreSQL - přijde mi, že se s ním dá mluvit,

No ja vidim jedinou realnou sanci na zlepseni situace ohledne JDBC, ze to proste nekdo forkne. Patche nejake jsem jim poslal, ale nic necommitnuli protoze to nechodilo ve starych pgsql verzich, krom toho mne uz nudi poslouchat jejich reci jako je to opensource oprav si to sam. Stavajici team na to fakt nema.

Napriklad zakaznici by mohli bombardovat Sun bug reporty ohledne JDBC v PGSQL a tim padem presvedcit Sun, aby to forknul na java.net. Pote co by se to forklo a vyhazela by se podpora pro stare pgsql verze myslim ze by z toho mohl byt decentni driver tak za 2 mesice, kdyby na tom nekdo delal denne.

hmm kdybych mel alespon tyden abych na tom mohl neco udelat, tak bych to forknul a on by se uz (doufejme) nekdo chytil, idealni by bylo kdyby sun dodal tak jednoho az dva kodery, ten driver neni zase tak velky.

Tedy jeste mne zajima jaky JDBC driver ma ten komercni PGSQL, ten jsem jeste nezkousel.

ACT NOW!
http://www.java.net/request_project.csp