díky

s tím JDBC driverem pro PostgreSQL je to ostuda, ale je to tak - projekt je postaven tak, že drivery nejsou jeho součástí - v rámci projektu je poskytován pouze jediný univerzální C driver. Nicméně komunita kolem Javy není schopná dát dohromady slušný driver. Což je paradoxní vzhledem třeba k .NET driveru, který je kvalitní, a je za tím jeden nadšenec a pár dalších.

Trochu mne napadá jestli to není tím, že za většinou o.s. projektů v Javě je IBM, a té se nechce financovat konkurenci - prostě v Javě o.s. bez IBM nefunguje.

Ještě přidám jeden dotaz - na IRC jsem zkusil popohnat dění ohledně JDBC (těch problémů je víc - např. chybí podpora statement timeoutu) - bylo mi řečeno, že prepared statements jsou podporovány - a že je někdo používá ve své aplikaci. Jak je to tedy? Tohle je něco, co jde absolutně mimo mne.

preparedStatementy z hlediska Java aplikace podporovany jsou, ale jsou stejne jako kurzory jen emulovane. JDBC driver neprelozi PreparedStatement class z Javy do prepared statementu PGSQL serveru, ale proste ten SQL prikaz odesle znova jako text jen s jinymi parametry. Kdyz si zapnete monitoring SQL prikazu tak vidite jake JDBC driver posila databazi.
Kdyby se ovsem na tom jdbc driveru maklo tak v OLTP na malych tabulkach tak do 10GB by byl pgsql srovnatelny s komercni spickou. Mela by vyvoj zacvakat ne IBM ale enterpriseDB.

Teď googluji a narazil jsem na connection parameter prepareThreshold, který se asi musí explicitně nastavit, pak podle všeho JDBC by měl použít server side prepared statementy.

Asi sám víte, jaký je teď přístup menších firem k financování externích projektů? Ještě tak před dvěma roky možná, ale teď to prostě není reálné. Navíc to vždy chce alespoň jednoho člověka, který by to vzal na sebe - udělal masivní část, a pak by jej možná EDB zaměstnala - nebo další podobné firmy. Bez někoho takového to prostě nemá cenu - a kvalitní programátoři v Javě buďto nevědí kam skočit nebo se snaží vydělat si na důchod a ostatní to prostě neprorazí.

Default hodnota je 5. Mne to ale stejne vzdy posila inserty misto execute, asi zalezi jeste na necem. Shrnuti je ze mi to out of box nefunguje.

EDB maji ledatak velkou hubu, jdbc driver jsem jim reklamoval a nic pro zlepseni neudelali "NENI TO NAS PRODUKT". Vyzkousel jsem taky ty jejich utility a rozhodne bych za to ty penize nedal. Realita ovsem je, ze staci aby tomu veril manager, protoze ten rozhoduje co se koupi.

Krize dopadla na vsechny. Tohle zari IBM zlevnila DB2, nejlevnejsi edice stoji se 24x7 supportem $1.5k rocne. Vynikajici cena, to uz vyjde levneji nez opensource databaze. Taky udelali novou edici DB2 AESE http://www-01.ibm.com/software/data/db2/linux-unix-windows/edition-advanced-enterprise-features.html kde davaji ty rozsireni co driv prodavali za hezke penize prakticky zdarma.

Taky je dobry tenhle report, zajimave ze MySQL prekonalo PGSQL. To dela sila znacky.
http://www.microsoft.com/presspass/itanalyst/docs/06-30-09EnterpriseDatabaseManagementSystems.PDF

Znáš ten vtip - že "tlustý budou hubený a hubený budou studený". IBM, Oracle, Microsoft mají z čeho dávat - zároveň si ale likvidují trh - po krizi se jim budou obtížně zvedat, udržovat marže. Nicméně pořád si myslím, že kvalitní JDBC driver pro PostgreSQL není otázka peněz, ale lidí. Je minimum lidí, kteří by rozuměli problematice, měli čas a ochotu něco s tím udělat. A vzhledem k tomu, že ten driver jakž takž funguje, tak je ochota ještě nižší.

Tu analýzu od Forresterů jsem viděl cca před rokem, kdy se řešila. Osobně si myslím, že některé položky ujely: data types and data integrity - MySQL: 2.81, PostgreSQL: 2.13. Diskutovalo se to v konferenci - PostgreSQL doplatilo a) možná na JDBC, možná na implementaci úrovně SERIALIZABLE - testovací aplikace, které Forrester používá s pg údajně nedoběhne. b) modulární strukturu - forrester hodnotí krabici, což pro pg není a nebude výhodné - gro je v externích modulech. Příští rok by v pg měl být upravená úroveň SERIALIZABLE, tak aby skutečně nedocházelo ke konfliktům - což bude znamenat aktivnější zamykání :(, replikace již pg interně obsahuje, tak by se v hodnocení měla posunout výše.

Na IRC jsem probíral JDBC. Někteří lidé se tvářili docela překvapeně - vždyť JDBC je úplně v pořádku. Chybí use-case, chybí reálné bug reporty, podle jejich feedbacku od vývojářů je JDBC něco, co není třeba řešit. Zatím to vypadá tak, že pokud se JDBC používá přímo, tak k zásadním problémům nedochází, problémy nastávají s použitím ORM. Můžeš mi, prosím, poslat sumář s čím máš problémy, pokud možno konkrétní problémy.

S tim data integrity maji pravdu v serializable neprojde TPCB test na isolaci transakci, muzete si to zkusit, odkomentujte

System.out.println("Isolation test "+ t.isolationTests(null));

Takze podle oficialnich pravidel bychom nemohli pgsql v tpcb testovat vubec, on ale i v read commited vraci konzistentni vysledky, coz je ale dano tim ze UPDATE umi vracet hodnotu.

Stahnete si Eclipse, naimportujte do nej ten testovaci soft tpc-b z lauchpadu, stisknete run a podivejte se co z toho za prikazy leze.

Když jsem do connection stringu přidal ?prepareThreshold=1, tak se skutečně začaly používat server side prepared statementy - lze to poznat z logu - nastavenéím log_min_duration_statement = 0.

Mate pravdu s
d = new driver();
d.setJDBCURL("jdbc:postgresql:postgres?prepareThreshold=1");

je to opravdu uz v poradku co se tyce server side prepared statementu, znova jsem to prekontroloval cele rucne v logu. Ten monitorovaci tool co jsem pouzival predtim to totiz ukazoval spatne. Takze server side prepared statementy muzeme ze seznamu nedostatku smazat jako funkcni.

Jen je to porad pomaly. 1m radku to vklada 2 - 2,5minuty podle toho jak tam prekazi vacuum. Oracle to ma za 23 sekund, DB2 okolo triceti. Oracle desitka ma vubec hodne rychly inserty, pokud nema tabulka index tak jsou dokonce az 4x rychlejsi nez v DB2 9.5. DB2 ma ale zase vyrazne rychlejsi UPDATE a DELETE. Oracle 11r1 ma ale inserty abnormalne pomale, jedenactka se moc nepovedla.

Napadá mne několik možností a) autocommit - ale to by bylo možná ještě pomalejší, b) používáte defaultní konfiguraci? ta vůbec není nastavená na intenzivní zápis a z hlediska paměti je hodně podstřelená - pro soudobé počítače - např. maintenance_work_mem je dobré nastavit na 10násobek def, wal_buffers na 1MB, checkpoint segments alespoň na 20. Tady je pg v nevýhodě - defaultní konfigurace je taková, že si pg vezme něco kolem max. 40 MB paměti - a to se projeví samozřejmě v rychlosti i zápisu. Zajímalo by mne, jestli by se Vám rozjel Oracle s 28MB SGA.

Jinak pro intenzivní import by postgresisti použili spíš COPY než INSERT (bulk load pro komerční databáze), které je ještě cca 10x rychlejší. Navíc pg nemá nijak zvlášť optimalizovanou kontrolu referenční integrity při načítání hromadných dat - tam se musí zákonitě projevit sofistikovanější cache Oraclu nebo DB2.

mam:
shared_buffers=1000MB
maintenance_work_mem = 100MB
checkpoint_segments = 25
wal_buffers = 10MB

takze by mela byt konfigurace ok.

Oracle 10 potrebuje neco pres 70MB SGA aby vubec nastartoval. DB2 ma paradoxne default buffer 4MB a 0MB read ahead buffer a kupodivu dosahuje i s nim velmi dobrych vysledku pokud dela full tablescany nebo inserty do tabulky bez indexu. Oracle ten neumi pri malych velikostech RAM prakticky vubec pracovat, minimalni rozumna SGA je 200MB jinak je to priserne pomaly.

Direct loady jsem netestil to ani nemelo cenu tam by vyhrala DB2 co zvlada miliony radek/sec. Musi ovsem pred tim nez zacne loadovat data zasyncovat buffer cache, coz trva u busy serveru desitky sekund, nekdy to neprojde vubec protoze tam aplikace porad cpou nova data.

Tak pak asi to co jsi dostal z pg je maximum. Možná bych zkusil ještě 9 nebo alespoň 8.4 - rychlost zápisu by měla být minimálně stejná, ale měla by se o dost snížit režie spojená s VACUUM.

p.s. Ještě mne napadl docela zajímavý experiment - vzhledem k tomu, že tvoje aplikace je TPC-B v Javě a pgBench je TPC-B napsaný v C, dalo by se docela snadno zjistit jaká je režie prostředí Javy. Jelikož se nevyznám v tvé aplikaci a zrovna tak v metodice TPC-B - a vstával jsem v pět hodin ráno, takže mi to nějak nemyslí, tak se do podobného srovnání pouštět nebudu - dávám to tu jen jako námět. Zkoušel jsem porovnat čas vytvoření databáze - pgbench je cca 3x rychlejší než tvoje aplikace - patrně rozdíl je jedině v indexování - pg_bench vytváří indexy až po importu a je to relativně pomalá záležitost - takže to asi bude hrdlo v pg - aktualizace indexu.

pgbench nebezi s tabulkama vyvorenyma mojim programem. Musel bych si nainstalovat do widli C prekladac coz se mi nechce.

pgbench by měl být normálně v instalaci, když už instalátor od edb obsahuje i PostGIS, tak by měl obsahovat i pgbench. Je to tam, kde se v instalaci nastavují rozšiřující moduly.

pgbench tam je, jen vyzaduje jine databazove schema. potreboval by proto poeditovat a ja nemam na widlich c kompilator ponevadz delam v Jave.

Zkontroloval jsem log, autocommit je vypnutý - problém je v defaultní konfiguraci. V def. jsem měl čas pro generování 10M řádků (cca G db) kolem 34 min. Po nastavení "checkpoint_segments=30, wall_buffers=1924kb, maintenance_work_mem=160MB jsem se dostal na čas 12 min - cca 1/3 - takže by to u Vás vycházelo kolem 50 sec - možná 40. Hrdlem by měl být určitě zápis na disk - což si myslím, že může být čas Oracle. Je otázkou kolik z těch zbývajících 30 sec padne na vrub JDBC?

nevim jak se zjisti ve windows kolik sekund CPU casu spotrebovala data aplikace, to jest ekvivalent unixoveho prikazu time.

To já nevím také - ty to testuješ ve win? Windows mají speciální požadavky - někde jsem četl, že se doporučuje mít shared_buffers co nejmenší - a víc bohužel nevím - tady moc lidí není, kteří by věděli, co potřebuje pg na win.

Ano, testuji to na win32

Na Win32 je pg maximálně znevýhodněn - samozřejmě, v nevýhodě jsou všechny db, ale vzhledem k architektuře, která nepoužívá vlákna - a v defaultu ani pooling conexí (i když o to se stará možná JDBC) je to asi nejznatelnější - trojková řada je navíc snad ještě kompilovaná (sice už nativně) cygwinem - další už jsou překládané v Visual C++. Hlavně je pg ve verzi 8.3 teprve třetím rokem pro win32 - zrovna u win se asi nejvic reviduje, záplatuje, optimalizuje - je to nejmladší z podporovaných platforem. Docela by bylo zajímavé udělat graf např. pgbenche mezi 8.0 až 9.0.

Doba zakladani db spojeni je irelevantni pro vyse uvedeny test, protoze se po kazde transakci neodpojujeme od db.

Článek opět na vysoké úrovni, ale drobná výtka týkající se části s dokumentací k Oracle. V ní to totiž vypadá na velmi neumělý automatický překlad. Min. dvě věty v této části prostě nedávají smysl a chtěly by přeformulovat. Takže 8/10 ;-)

Mne se ta cast taky nezdala, ale nenasel jsem zpusob jak to opravit s vynalozenim male namahy tak jsem to tam nechal s oduvodnenim ze Oracle dokumentace by si lepsi praci stejne nezaslouzila.

Ono to s temi kurzory v pgSQL vubec neni tak jednoduche. Ten PQ protokol ma pomerne netypickou (dle meho nazoru vlastne dobrou) vlastnost, ze vysledky dotazu predava naraz jako jeden velky paket. Tudiz mi prijde, ze emulovat ResultSet/Cursor na klientske strane je vlastne zadouci chovani, protoze se to pak chova vicemene stejne jako libPQ. Treba driver pro pythonove DBAPI (minimalne ten nejpouzivanejsi, jsou asi 3) ma tu vlastnost, ze pro kazdy kurzor opravdu vytvari portaly a pouziva je, coz mi prijde ve vetsine pripadu jako zbytecne plytvani casem. Je otazkou jak to rozumne resit, podle me by to melo byt nejak konfigurovatelne, idealne per-dotaz, nicmene do tech API obvykle neni kam takovou volbu nacpat.

Myslím si, že kurzory určitě mají svoje místo - zvlášť, když zpracováváš větší data z klientů, kteří mohou mít problémy s pamětí - PHP, Java, ... Navíc dochzází k určitému souběhu - server může začít posílat data relativně brzo, klient se rychle dostane k výsledku - na druhou stranu, klient může brzdit server, zvyšuje se i síťová komunikace. Kdyby klient si bral data ze severu řádek po řádku, tak by to bylo skutečně neefektivní a také se to nedělá - obyčejně se zavolá FETCH s parametrem 100 nebo 1000. Další výhoda kurzoru může být relativně rychlé a bezbolestné ukončení provádění dotazu - v okamžiku, kdy najdeš data, která tě zajímají, tak můžeš skončit - to se někdy nedá udělat jinak než skrz kurzor.

Ja netvrdim, ze nemaji vyhody. Ja tvrdim, ze je lepsi, kdyz se defaultne driver chova stejne jako libPQ, jednak kvuli konzistentnosti a jednak s ohledem na to, ze pro 90% aplikaci (treba asi cokoli weboveho) ma to chovani smysl.

Fakt je, ze je to cele o tom, ze to API co prezentuje JDBC/DBAPI/temer cokoli objektoveho ma tu vlastnost, ze tenhle rozdil v nem neni rozumne postihnuty (uz jenom proto, ze postgres je asi jedina databaze, kde existuje).

v JDBC je mozne rici kolik vysledku ma nacist na jeden zatah do pameti, jen to JDBC driver pgsql neumi.