Vlákno názorů k článku Čtení prováděcích plánů v PostgreSQL od Janco - Zas kvalitny clanok. Uz sa tesim na predstavenie...
-
LENIN POWER! (neregistrovaný)jestli pgsql neco chybi tak to rozhodne neni rychlost, ktera je pro OLTP workload srovnatelna s Oraclem. V OLAP workloadu na ne pgsql nema: pomalu sorti, pomalu joinuje a neumi ani OLAP queries. V oblasti velkych db taky ne, protoze nema hodne funkcionality potrebne pro efektivni spravu velkych db.
-
Zdenek Kotala (neregistrovaný)
No myslim, ze si v prvnich dvou vetach trochu protirecite. Ale ano mate pravdu, ze Postgres neni stejne rychly jako Oracle, ale to si kazdy musi rozhodnout sam, zda mu ta rychlost staci a nebo zda investuje usetrene penize za licence a koupi lepsi zelezo. Podle pruzkumu 80% aplikaci vyuziva pouze 30% vlastnosti enterprise databazi.
Co se tyka tech OLAP queries tak neco by se melo objevit jiz v 8.4. A pro datove sklady existuje bizgress, coz je upravena verze postgresu na zpusob Teradaty.
Zajimalo by mne co myslite velkou databazi a jakou klicovou funkcionalitu Postgres nema?
-
LENIN POWER! (neregistrovaný)pro workload ala lamp Webaplikace na male db stejne rychly je. asi pred tydnem jsme si delali benchmarky ktere to potvrdili. Realna rychlost pgsql8.3 a db2 9 byla uplne stejna pro interaktivni workload. takze rychlost pgsql rozhodne nechybi. Oracle byl pomalejsi, ackoliv ne moc vyrazne, tak o 20%. MySQL 4.1 bylo nejrychlejsi ale ne o moc, tak o 20% oproti pgsql.
pomalejsi je pgsql ve velkych sortech a joinech (rekneme na result setech 40m a vice radek), ale zase ne tak vyrazne, zhruba o 30-40%. zejmena hashjoiny v pgsql jsou velmi pomale pokud se nevejdou do pameti.
pri testovani se db2 nedovolilo aby rozhazovala zatez z 1 klienta mezi vice CPU, to by pak postgres vyklepla, protoze ten to neumi.
pod pojmem velka db si predstavuji databazi obsahujici rozumne velike tabulky, takhle
tablice ma treba ~ 740GB (coz je natolik malo ze se jeste nevyplati saskovat s table partitioningem)
C:\IBM\SQLLIB\BIN>db2 select count(distinct day) from adwords.searches
1
-----------
505
Bylo vybráno 1 záznamů.
C:\IBM\SQLLIB\BIN>db2 select count(*) from adwords.searches where day = current
date - 1 day
1
-----------
55810561
Bylo vybráno 1 záznamů.
Ted koukam ze tablice je nekomprimovana, nanestesti odhadovany space saving rowcompestimate table je 30%, coz mne dost zklamalo, cekal jsem tak 50%.
Take bych si pral zpracovavat takova data, co se smrsknou o 85% jako SAP tablice:
ftp://ftp.software.ibm.com/software/data/pubs/papers/DB2-SAP-compression.pdf
Ja bych tak rad premigroval SAP z Oracle na DB2... nanestesi se to neda udelat uplne bez downtime a my proste bez toho SAPu neprezijeme ani chvili, navic je tu riziko ze downtime bude vetsi nez se puvodne planoval a nejsme nespokojeni s Oracle/SAP ze by byl spatny, ale ze DB2/SAP je lepsi. Mohl bych to zkusit 1.ledna 2009, to snad zakaznici pochopi, kdyz jim to oznamime 3 mesice dopredu.
http://www.sapusers.org/newsletters/2/files/Migrate_your_SAP_solutions_to_DB2-Nov06.pdf -
Zdenek Kotala (neregistrovaný)No je pravda, ze tuplestore (takovy swapfile na radky) by si zadal vylepseni. Co se tyce toho rozlozeni zateze na vic CPU to je znacna slabina a je to jeden z cilu pro vyvoj do dalsich verzi. Velikost tabulky v PostgreSQL je omezena 32TB, coz zatim asi nikdo nezkousel :-) nicmene mame zakaznika co ma 2TB tabulku (+3TB v TOAST) bez partitioningu. Funguje to dobre i kdyz to neni uplne svizne.
-
LENIN POWER! (neregistrovaný)Nezlobte se ale radit podnikum (zakaznim v kategorii nesocek) aby si misto Oracle/Db2/mssql vzali zadarmo pgsql a za usetrene prachy za licence koupili lepsi hw muze jen ten kdo ma s IT velmi male zkusenosti nebo ten kdo je silne zainteresovan na prodeji HW.
Zeptejte se Oraclistu (v CR asi nejpocetnejsi skupina z techto db) proc preferuji prave Oracle. Najdete si zde thread LO, LP vs Stehule o tom zda je OSS database vhodna pro vetsi projekt. Je to totiz prilis rizikove a usetrene penize za licenci tohle nevyvazi.
Nedostatky pgsql jsem zde uz dostkrat rozebiral, zkuste vyhledavani. Ja vim ze diskuze s lidmi od Sunu nemaji cenu, absolvoval jsem jich uz mraky a oni moc dobre nechapou realne potreby zakaznika, ziji uplne v jinem svete.
http://www.mysql.com/tcosavings/ -> a ted maminko jeste tu o panu bendovi a o jestircich. Problem je ze lidi opravdu te masazi od Sunu uveri a pak jejich IT podle toho vypada. Pak prijdou k nam s tim svym hnojem a prosi abychom jim to predelali, coz se nam moc nechce, protoze mame prace vic nez stihame, tak si zakazky vybirame.
http://forums.mysql.com/read.php?60,190734,192723#msg-192723 -
Těchto diskuzí tu bylo několik - myslím si, že nemá cenu znovu argumentovat.
http://www.root.cz/zpravicky/prague-postgresql-developers-day-2008/
http://www.root.cz/zpravicky/dubnovy-termin-skoleni-postgresql/
Doporučuji si nepřehlédnout poslední dva příspěvky Radima Koláře
http://www.root.cz/diskuse/2927/204356/vlakno/#o204742
Z mého pohledu cca do 100G databází nejsou s PostgreSQL nejmenší problémy - PostgreSQL se používá i pro 24/7 systémy. Instalací nad 100G je minimum (v poměru k menším než 100G). Já sám se setkávám poměrně často s použitím PostgreSQL jako backendu k request tracker systémům středních podniků (cca do 500 zam) a jako backend ve větších e-shopech. Vím o fakturačních systémech v pekárnách, nemocnicích (ale i ve strojírenství), které běží nad Postgresem. Sám jste argumentoval relativně dobrým výkonem v OLTP. Což je primární segment užití pg - pro OLAP v Pg chybí podpora - budoucí analytické dotazy nebo CTE na tom moc nezmění. To je segment, kam se PostgreSQL netlačí. -
LENIN POWER! (neregistrovaný)Vas zpusob vyvoje SW je neefektivni. Vy ho sice povazujete za efektivni, ale to je dano tim ze jste inzenyr a ne manager a proto nevidite veci v sirsich souvislotech, ktere zahrnuji kuprikladu vynalozene naklady na lidskou praci, ztrata zpusobena nefukcnosti reseni, cas k realizaci, naklady na udrzbu. Proste spatne pocitate TCO a chybi vam management rizik.
Vzhledem k tomu ze pro pgsql soft prakticky neexistuje, tak predpokladam ze si vsichni zde vyse jmenovani nakodovali reseni inhouse. To je ale dost drahe a neni tu zaruka ze se to vubec uspesne dokonci. -
honzak (neregistrovaný)...reseni inhouse. To je ale dost drahe ...
ja uz delsi dobu sleduji vase vyplody a musism se priznat, ze tomu vasemu humoru nerozumim. To ze nikdy nepouzivate ironie-tags mi ani nezarazi, to patri k nasi ceske mentalite, presto si myslim, ze je vas humor tak zastreny, ze si nekteri zde mohou myslet, ze to myslite vazne. Navrhuji nejake stylisticke gramatikalni prostredky - slangove slovo, citat nejakeho americkeho herce a nebo neco podobneho, abychom se mohli proste neceho chytit a presne vedet na cem jsme.
Jinak k te vete nahore .... nemohl by jste nam prozradit, co stoji auto. -
LENIN POWER! (neregistrovaný)moje posledni auto stalo asi 32 klacku, mne auta nezajimaji, jinak bych si asi koupil neco drazsiho. Tedy jezdim v jedne licenci Oracle EE.
Jo krome auta mam jeste dve cryrnohe kocky, jednoho psa, spanelsky mluvici sluzku a cernocha zahradnika. Doma mam 2 notebooky, 3 pocitace a 12 Mbit DSLko. Barak ve kterym bydlim stal 450klacku. Dane platim, optimalizaci dani si ale sam nedelam. Dvakrat do tydne chodim strilet a v nedeli jdu do kostela a pred kazdym jidlem se poctive pomodlim. Rano cvicim a do prace jezdim autem. Z televize posloucham CNN a Discovery. Sluzku nebiju.
Potrebujete jeste neco vedet? Klidne se zeptejte. -
Pavel Stehule (neregistrovaný)Ja take netvrdim, ze PostgreSQL je idealni - chybi OLAP, chybi JDBC2 napriklad, implementace partitioningu je stale primitivni, online zalohovani je docela alchymie. Nicmene pro celou radu uloh se kterymi se setkavam, vyhovuje a osvedcuje se. Zalezi na usudku designeru, analytiku, programatoru, jestli PostgreSQL doporuci nebo ne.
-
nez se mi zmrsil post, mel jsem asi 35 bodu co se mi nelibi na pgsql. Krom toho ja vim ze neni vule tyhle problemy resit a kdyz delate velke projekty tak ty veci opravdu desne vadi, takze pgsql pro velke projekty se sice pouzit da, ale je to vicemene nouzovka nebo pozadavek zakaznika, ktery si mysli ze usetri, coz neusetri. Fajn budeme mit CTE a OLAP ale to nejak vyrazneji pozici pgsql mezi EE db nezlepsi. No a rozpocet velkych projektu ten uz vam dovoli si Oracle za $15k koupit, protoze je to kapka v mori, vzhledem k cene lidske prace.
Ja jsem s pgsql delal opravdu dost velky projekty, ale dneska po tech 5+ letech zkusenosti s nim bych ho jiz pro tenhle druh aplikaci nepouzil pokud by ho zakaznich neprosazoval. Neni to dobra volba. Existuje ovsem rada projektu kde by nevydelaly ani na licenci Oraclu, o jeho provoznich nakladech ani nemluve a tyto projekty by bez mysql/php/pgsql ani nevznikly.
Napriklad podpora toolu je v postgresql uplne tragicka, dale podpora profi zalohovacich systemu neni, pgsql nemi delat XA TM, SQLJ neni, diky flaky JDBC2 driveru nefunguji ani takove zakladni tooly jako BIRT i kdyz pravda reportovaci tooly pouzivaji casto JDBC3 api pro databaze metadata (ktere pgsql driver neumi).
Krom toho vyvojari pgsql nikdy nerespektuji de facto standardy dane Oraclem (kuprikladu jak se ma databaze semanticky chovat pro zamykani updatable cursoru). Kdyz si treba vezmeme zamykani v databazich tak kazda z db pouziva jiny model, zamykani dat je kriticke pro obranu pred races a prepisovat zamykaci model je pomerne narocna prace, protoze se to musi delat velmi peclive.
oracle (zamyka nejvice)
db2/cloudscape
firebird
postgres (zamyka nejmene)
Neexistence hintu dost vadi, nemuzete zamykat access plan aby se dal garantovat service level, replikace je primitivni, smutnym faktem je ze z replikaci pro pgsql je slony nejlepsi a neumi ani tak zakladni vec jako si vybrat ktere radky/sloupce vlastne chcete replikovat. Navic obnova databaze ze zalohy znici slony instalaci, takze musite ho odinstalovat, nainstalovat znova a znovu sesynchronizovat db.
Ta freeware DB2 co tu inzeroval lenin je velmi vyrazne lepsi nez pgsql a je za stejnou cenu (zdarma), ackoliv se za nejake featury (HA a Replikace) plati, ale dostanete k nim i 24/7 support, ktery by si zakaznik delajici vetsi projekt stejne koupil (navic musite zohlednit fakt ze slony1 je pomerne problematicke v produkci a support pro nej nikdo v cz neprodava). Prakticky je tak databaze zdarma a platite jen za support. Problem je ze Cesi DB2 nechteji, tuhle db vidim v produkci nasazenou ale opravdu velmi vzacne.
Ja vim databazi zase tak moc neni: mysql, db2, oracle, pgsql. Mysql ma ale vybornou podoporu nastroju, snad kazdy profi nastroj umi dneska i mysql a lidi co umeji delat s mysql jsou _velmi_ levni, dostupni a bohuzel take velmi nekvalitni, ostatne kvalita mysql je opravdu velmi nizka, donedavna jeste vracela pri joinech chybne vysledky a 5.0 ma problemy s views, ktere nekdy spatne vyhodnoti. Ja bych mysql ale neriskoval pro aplikaci ktera zachazi s penezi na blog/webforum je to ok, tam o nic nejde.
PGSQL ma tu vyhodu ze z vyse uvedenych databazich nejmene havaruje diky internim SW chybam, oracle a mysql nejvice. Idealni databaze pro install & forget aplikace. Ja Oracle sice vubec rad nemam pro znacnou poruchovost v produkci (zejmena pri nasazeni v RAC), ale cesi ho maji radi a dobre se pro nej programuje. -
Já bych také rád viděl některé funkce z Oracle nebo DB2 v PosgreSQL. To co není ve standardu se ale docela dost obtížně prosazuje - navíc standard neobsahuje některé zajímavé funkce, které jsou jak v DB2, tak v Oracle - ale jinak implementované. Je fakt dost velký odpor k implementaci duplicitní syntaxe - i když je to pár řádku v gramatice, a i když historicky PostgreSQL určitou kompatibilitu s Oraclem nabízel. S drivery je to jednoduché - v podstatě, co kdo napíše, to je. Fakt je ten, že .NET komunita je o dost aktivnější.
-
RK (neregistrovaný)Problem je ze zpusob jakym je pgsql projekt veden. Proste vedeni projektu kasle na lidi kteri by radi z pgsql meli databazi srovnatelnou s oracle/db2. Pod pojmem srovnatelna myslim to, aby byla pouzitelna pro vetsi projekty.
LO i Lenin maji pravdu s tou zpetnou vazbou, ktera proste bez penez nefunguje.
Pokud pridavate feature X (writeable cursory) tak zakaznici oceni zamykaci model kompatibilni s Oracle nebo v horsim pripade s DB2, protoze jim kompatibilita usetri mnoho casu (a tudiz i penez). Budou s produktem spokojeni a budou dale platit a neposilhavat po konkurenci.
Kdyz ovsem zpetna vazba od uzivatelu neni, tak vas nic nenuti se starat o jejich blaho a tak pokud danou vec nespecifikuje SQL standard presne, udelate si to proste podle sebe (t.j. nekompatibilne) a uzivatele maji smulu. Proste se musi prizpusobit.
Pritom mne lidi z EDB, kteri nejsou v pgsql komunite moc oblibeni nepripadaji jako ze by chteli neco nerealneho, proste chapou potreby svych zakazniku, kteri by se radi venovali svemu byznisu a ne ztraceli cas s databazi. Pokud ma ovsem nekdo vyvoj pgsql jako konicka tak ja ho chapu, tyhle problemy ho asi netrapi.
Kompatibilita s de facto standardem je dobra vec. A nechapu proc jsou opravdu tak zasadne proti syntax sugaru. Komu by vadilo ze pgsql umi i oracle kompatibilni syntax rekneme pro sekvence? mne ne. -
Problém s Oraclem je asi následující - Oracle si bere standard jen jako inspiraci - celkem logicky se snaží o vytvoření vlastního standardu a o vendor lock. Něco implementuje podle standardu, něco nikoliv (např. chybí operátor DISTINCT OF). Není problém implementovat dvě syntaxe (většinou, pokud nedojde ke kolizi). Problém je v dokumentaci a ve vývoji - výsledkem je takový kočkopes - (což už tedy PostgreSQL stejně je). V okamžiku, kdy jednu věc můžete napsat 4x trpí kvalita kódu a paradoxně přenositelnost (i když přenositelnost u komplikovanějších aplikací je utopie). Zavedením režimů kompatibility zase dost bobtná parser, což pak znamená vyšší režii na údržbu a vývoj. Existence EDB se ukázala jako docela přínosná v tom, že se nemusela řešit kompatibilita s Oraclem - tu si řešila EDB. Mimochodem - neoblíbenost EDB v komunitě není nijak zásadní - stále jsou v EDB zaměstnáni klíčoví vývojáři - a nikdo EDB nevyčítá, že používá kód PostgreSQL. Takových firem je více a EDB alespoň sponzoruje vývoj. Marketingu EDB se ovšem povedlo vyprodukovat několik nešťastných neobjektivních tiskových prohlášení - čímž si komunitu rozhodně nezískali.
-
je fakt ze existuje jeste informix, ktery ibm v soucasnosti marketingove tlaci pro OLTP aplikace aby se vratily naklady na jeho vyvoj. Argumentuje vykonem a HA featurama, ale zadne tpc benchmarky k dispozici nejsou a cena je stejna jako za db2. Ale i kdyby byl opensource, pochybuji ze by nekoho zaujal tak ze by na nej premigroval.
Driv se ho snazila ibm zbavit, ale ukazalo se ze nektere organizace (treba VISA) z informuxu migrovat nechteji, nechce se jim prepisovat aplikace. Presto pocet uzivatelu informixu rok od roku klesa, ja osobne bych informix pro nove aplikace jiz nepouzil.
Na trhu databazi jiz pro nej neni misto. Stejne tak neni misto pro SAPDB, na tu se pamatuji a bylo to tak zabugovane, ze mne neprekvapuje ze ji dneska nikdo nechce ackoliv je pod GPL a featurelist nema rozhodne nejhorsi. Pres 70% SAPu beha na Oraclu. IT prumysl potrebuje co nejmene ruznych databazi, ponevadz jsou navzajem nekompatibilni - protoze jak je videt na prikladu pgsql - oni se na vicemene standardu proste neschodnou a zamykani ma kazda databaze semanticky uplne jine. Kdyz kuprikladu hodite pgsql kod do db2, tak zamykani (select for update) nebude vubec fungovat. Prenositelnost i velmi jednoduchych aplikaci je proto utopie.
http://www.google.cz/url?sa=t&source=web&ct=res&cd=32&url=http%3A%2F%2Fevents.ibm-smb.cz%2Fforum2008%2F5_DatabazovaReseniIBM.pps&ei=M4jHSJyHFI--0gWTwJkT&usg=AFQjCNGFS6CxTM0XdybyHj81XluQ8VmLYg&sig2=yonFS1qy6sStT1lqdQe0CQ
ja jsem s informixem pracoval naposledy tak pred 10 lety a to byla hrozne zabugovana databaze. Osobne bych rad videl kdyby firebird, informix a sybase uz konecne odkraceli do vecnych lovist. Oni umiraji pomalu, protoze nikdo je uz pro nove aplikace je uz nechce.
Prekvapive mainframova IMS z roku 1960 je dodnes nejpouzivanejsi databazi na mainframech. Ukazuje to hezky na fakt, ze ne vzdy je SQL dotazovaci jazyk potreba. S IMS jsem jiz delal, ale jeste jsem nedelal zadnou aplikaci pro CICS, to bych si taky jeste chctel zkusit. -
honzak (neregistrovaný)ja skutecne nechapu, co s tim sledujete. Je to takovy povzdech nad nedokonalym svetem nebo si skutecne prejete, aby vznikla nejaka postgresql, ktera by mela vsechny klady tech ostatnich DB bez vsech vlastnich a cizich nevyhod?
Z toho co pisete by mel clovek dojem, ze bez DB2 nemuze byt lidstvo spokjeno. Ale napr. v Nemecku je 2 miliony firem, ktere maji mene nez 10 zamestnanci. Pak dalsi 1 milion firem, ktere maji do 50 zamestnancu nebo tak 20 milionu EUR obrat. Pro ty mensi firmy staci sprava dat ve filesystemu, ty vetsi (moje osobni zkusenost) maji tak do 10GB dat. Jenom nekolik stovek firem v nejakem state ma 100GB dat.
Otazka tedy musi znit, pro koho se tady vyviji a kdo bude nakukovat ty provadeci plany? -
LENIN POWER! (neregistrovaný)pgdump o velikosti 2.8 GB.
Doba zalohy - 779.46 real 27.62 user 15.41 sys
doba obnovy - 3392.39 real 25.33 user 16.72 sys
velikost db na disku:
originalni db 8.6 GB
obnovena db 7.1 GB
to jako platforma pro 100GB databaze nevypada, vzdyt by obnova znamenala alespon 1 denni vypadek. Takze se da pouzit pokud cena jednodeniho vypadku + slozitejsiho vyvoje < cena licence mssql/db2/oracle. Tedy jen pro amaterske pouziti.
Pro zajimavost restore 100GB DB2 ze stejneho diskoveho pole 19 minut. Jo, je to kapanek rychlejsi.
ČLÁNKY DO MAILU