Názory k článku
Konference Prague PostgreSQL Developers' Day 2008
-
PostgreSQL je určena primárně pro Enterprise sféru a pro to je také tato databáze optimalizovaná. Pro jednoduché www služby se používá minimálně - php vývojáři preferují MySQL. Pokud je mi známo, tak se používá v několika předních českých e-shopech, bankovních a personalistických serverech. Veřejně se k PostgreSQL hlásí cznic http://fred.nic.cz/ - správa cz domén, Baťa a.s. http://www.vasemoznosti.cz/clanek/453, v zahraničí asi nejznámější je Facebook doporučuji prostudovat http://www.postgresql.org/about/users .www aplikace - kvalitní podpora MediaWiki, co vím existuje mizerná podpora Drupalu. Existuje kvalitní ERP http://en.wikipedia.org/wiki/Postbooks . Aktuálně se v konferenci debatuje o PhpBB, takže předpokládám, že tam podpora nechybí. Pokud se zastavíte, rád Vám osobně předvedu, co PostgreSQL dokáže a jaké jsou její přednosti - v místě konání jsem už od 8:30 na workshopu.
p.s. Tato konference je určena pro vývojáře a PostgreSQL je prezentována nezávislými vývojáři - není důvod používat PR slovník. Nikdo z nás není na prodeji PostgreSQL osobně zainteresován, přestože pro řadu z nás je to hobby a pro dva přednášející zaměstnání. -
Lenin (neregistrovaný)No ja myslel ze pro Enterpise je Oracle. To Bee co udajne pouziva BATA jsem nenasel vubec.
CZNIC jsou socky co nemaj ani na poradnej soft; maji v tom svem slavnem kodu buffer overflowy a jine chyby, je videt ze nastroj pro statickou analyzu kodu jim boss nekoupil. Holt pouzivame open source abychom usetrili. Prekvapuje mne ze se vubec vzmohli na sparca.
Banky jedou na PGSQL?, to asi na nas fakt uz dopadla ta hospodarska krize kapitalismu. Aha je to jen server o bankach, tak to jo to mne uklidnilo. Jinak sf.net uz davno na pgsql nejede, ted tam maji db2.
Ten postbooks to vypada zajimave. Jo media wiki umi pgsql taky, takze to je spolu s phpbb uz druha web aplikace. proti mysql je to zalostne malo. mysql vitezi tak 100:1. -
Pravděpodobně máte o Enterprise mylné představy. Řadu let se na Enterprise aplikace používá také SQLServer a DB2, a z OSS také PostgreSQL. Diskuze o výhodách a nevýhodách OSS tu proběhla nedávno, nemá cenu ji opakovat. sf jsem neuváděl (zrovna jim přechod na db2 vůbec nepomohl), vím, že Pg dávno nepoužívají. Uvedl jsem Facebook http://en.wikipedia.org/wiki/Facebook . Ještě je tu Drupal (základ chodí, problematické jsou moduly), Serendipity - http://www.s9y.org/ a možná některé další (www aplikace nesleduji). V každém případě je mysql mnohem častěji používaná pro www aplikace, a naopak pro zákaznické aplikace je častěji používaný Firebird a PostgreSQL. Proč tomu tak je, je opět na delší diskuzi. Aplikace pro PostgreSQL existují i na webu, ale jedná se o zákaznické aplikace - jenom ty, které znám v ČR mají několik set tisíc uživatelů, a tudíž si je nemůžete stáhnout a používat. Možná pochopíte, že existuje i jiný segment než www fóra.
-
Lenin (neregistrovaný)No kdyz se lognete na sf.net tak vidite jak jsou ty servery v lokalni siti zatizeny, load 8-20. To proste rychly byt ani nemuze, uptime maji navic velmi mizerny <1 mesic a kernel stary, takze jim to asi dost crashuje.
Krom toho maji nejakou podivnou infrastrukturu. mam na ne sice ping 60ms, ale strasne pomala odezva. Asi zacpana linka ci co. -
nešikovně napsaná aplikace, netuším nakolik je v tom databáze, ale nedivil bych se. Pomalé dotazy způsobí load jak na db serveru, tak na serveru neb je podstatně vyšší počet neobsloužených vláken, které bez rozumě nastavených limitů vyčerpají paměť - nestačí poolování a celkový výkon jde do háje - jedno s druhým - nehledě na to, že sync lokálního repozitáře a vzdáleného znamená relativně těžký síťový provoz, a na sf se commituje nepřetržitě.
-
BLEK. (neregistrovaný)Postgresql na WWW není vhodná, protože na každý požadavek spustí nový proces a nemá žádnou cache na výsledky požadavků (Mysql ji má, i když velmi primitivní).
Když jsem se vývojáře ptal, proč nemá cache na výsledky dotazů, odpověděl, že cachování se má dělat v middleware a ne v databázovém serveru. Jenomže typickému webovému vývojáři se nechce kvůli nějakému diskusnímu fóru instalovat ještě aplikační server. -
PHP5 podporuje cache a Apache podporuje connection pooling. Jinak jsou tu ještě projekty jako pgpool a pgmemcache. Nicméně o tom 99% web developerů neví - bohužel. PostgreSQL hlavně díky MVCC je pomalejší v raw čtení a zápisu než MySQL s InnoDB. Pokud dochází k extrémně častým operacím UPDATE a DELETE, tak je nutné volat často VACUUM a už je to neefektivní, u MyISAM dochází k fyzickému přepsání - data nejsou transakčně jištěna, což je jednodušší, mnohem rychlejší, ale můžete přijít o data. Běžná data se tak často nemění. www data ano - např. parametry session atd. Kešovat lze také: http://okbob.blogspot.com/2007/12/using-shared-as-table-cache-in-plperl.html ale to už je vyšší dívčí.
Kromě toho bylo minimum hostingů s podporou PostgreSQL a když už hosting byl, tak tam byl PostgreSQL mizerně nainstalován (PostgreSQL vyžaduje locales, MySQL nikoliv). -
BLEK. (neregistrovaný)A jak je u té externí cache zajištěna konzistence?
To ta cache zjišťuje, co který příkaz mohl přečíst nebo zapsat a podle toho se zneplatňuje? A co když třeba trigger nebo jiná procedura změní nějaká data a ta cache nemá možnost se dozvědět, že to bylo vůbec změněno? A naopak --- co když je proveden select z view, a ta cache neví, jak ten view vypadá (takže neví, kdy má výsledek dotazu zneplatnit)?
Na ty časté updaty teď udělali nějakou novou technologii, HOT či tak se to jmenuje.
Mně právě jeden člověk, co dělá WWW hostingy říkal, že postgres nechce nasazovat proto, že má na jednoho klienta jeden proces => udělá na serveru velkou zátěž a konzumaci paměti. -
Cache má smysl hlavně tehdy, když nepotřebuješ nezbytně aktuální data. Typicky nejrůznější žebříčky - top ten prodávaných knih apod, které ti stačí aktualizovat jednou za půl hodiny, jednou denně, ale zobrazuješ je na každé www stránce. Pokud potřebuješ skutečně aktuální data, tak +/- údržba univerzální cache je náročnější než opakované provedení dotazu - navíc má každá databáze datovou cache, takže když jdou po sobě dva podobné dotazy, tak se data naleznou ještě datové nebo souborové cache, čímž se ušetří neskutečně času. Externí cache můžeš znevalidnit skrz trigger - taky dost věcí, které v MySQL řešila cache, se v pg dají napsat s použitím triggerů a ty MySQL až do 5ky okázale ignorovala. HOT je až v 8.3, která je teď RC, neřeší to všechno, ale je to hodně účinná technologie. Spotřeba paměti nezáleží na modelu /thread, proces/ pro danou úlohu potřebuješ určité kvantum paměti bez ohledu na architekturu - navíc databáze jsou drobet specifické .. většinu paměti spotřebuješ pro hash tabulky, sort atd nikoliv pro samotný běh aplikace. Musí se vytvářet nový proces, což je na některých systémech náročné (typicky win, starší Unixy), zas když ti klekne proces, tak se nic nestane, spadne jen jeden klient. Nicméně stejně, pokud je vyšší zátěž, tak se pooluje - a pooluje se jak MySQL tak PostgreSQL, Oracle. Problém je spíš v tom, že většina administrátorů ví kulové o databázích - a v podstatě i dost programátorů ví málo o databázích.
-
BLEK. (neregistrovaný)Typickým případem, kdy je potřeba aktuální cache, je diskuzní fórum. Spousta lidí čte hlavičky příspěvků a občas někdo něco napíše.
Jde to zneplatňovat uměle --- ale pak už programátor musí myslet, co se smí cachovat a co ne a co kdy zneplatnint. Zatímco cache na serveru cachuje všechno automaticky a udržování její konzistence nestojí nic. Stačí při každém dotazu konstruovat seznam tabulek, z kterých se pro ten dotaz něco přečetlo a po skončení dotazu nechat v paměti strukturu popisující odpověď (oproti externím cachím, které data prvně načtou ze socketu, pak uloží do paměti, a pak pošlou na jiný socket)
Ta souborová cache --- ta zabrání opakovanému čtení z disku, ale neušetří konzumaci CPU. Pokud se desetkrát pošle tentýž dotaz ("zobraz diskuzi k článku X"), tak se desetkrát budou ty samé kusy indexů kopírovat z kernelové pagecache do adresního prostoru procesu, pak se to bude desetkrát v paměti procházet, jenom k tomu, aby se desetkrát došlo k tomu samému výsledku.
Kdyby chtěli cache udělat, tak by stejně museli udělat thready, protože mezi těmi procesy budou ta data nesdílitelná.
Ad ta bezpečnost při pádu procesu --- bezpečné to není, protože stejně může být poškozena sdílená paměť a tak se to stejně v takovém případě musí celé shodit. -
Cache na serveru neni zadarmo. Je to minimalne jeden trigger nad kazdou tabulkou, ktery se musi provest pri zmene dat. To, ze ty o nem nevis, neznamena, ze se nespusti a ze nema nejakou rezii. Navic musis udrzovat dalsi cache, ktera ti zabira shared memory. CPU je v porovnani s IO neskutecne lacine - navic si PostgreSQL udrzuje vlastni cache v shared memory - coz je pamet, ktera by se dala v pohode pouzit pro cache - tudiz thready nejsou potreba. Shared memory muze byt poskozena, v tom mas pravdu - ale ta situace se pomerne snadno identifikuje, ponevadz do shared mem se pristupuje pouze v kriticke sekci, a tudiz se sestreluje serever jen v pripade, ze subproces havaroval v kriticke sekci. A ten kod, ktery je v teto casti je hodne dobre odladen - nezalezi na nem jenom spolehlivost, ale hlavne vykon. Jeste se mi to nestalo, ze by mi na tomhle padnul server - teoreticky to ale mozne je. Rozhodne Pg nema safe demona, jehoz ukolem je bezpecne restartovat server, coz o necem vypovida. Vubec nechci hanet MySQL, je optimalizovana na podporu www aplikaci.
-
BLEK. (neregistrovaný)Ten trigger na cache je potřeba, pokud je ta cache externí. Ale kdyby byla interně v serveru, tak na to žádný trigger potřeba není --- stačí prostě při odpovědi zaznamenat transakční ID všech tabulek, které byly ke konstrukci odpovědí potřeba, a při dalším stejném dotazu porovnat daná transakční ID --- pokud sedí, tak se nemusí nic počítat a může se hned vrátit odpověď. (externí cache by takhle napsat nešla, protože externí cache nezjistí, jaké tabulky byly k řešení dotazu použity)
"PostgreSQL si udrzuje vlastni cache v shared memory"
Tam má cache na všechno možné (včetně cache na optimalizační plány), jen ne na výsledky dotazů.
"CPU je v porovnani s IO neskutecne lacine"
Jak kdy. Třeba zrovna to WWW drhne na všem možném, jen ne na fyzickém IO. Těch pár článků a zpráviček, co je na titulní straně roota, se do paměti zaručeně vejde. A pokud si 50 lidí současně zobrazí titulní stranu, tak by Postgresql udělalo to, že by vzalo 50 procesů (ať už předpoolovaných nebo nově spuštěných) a nechalo je počítat ty samé dotazy.
Ta cache Mysql je děsně primitivní (jako ostatně všecko v Mysql) --- např. dotaz musí být napsán syntakticky přesně stejně včetně mezer, aby poznalo, že je nacachovaný. Ale pro takovýhle jednoduchý případ to funguje a udělá to, co by člověk očekával --- vypočítá odpovědi pro prvního klienta a dalším předhodí ta samá data.
Mysql by nemělo smysl používat na hledání statistik nad terabyty dat, tam by se opravdu nějaká jeho tupost projevila a špatně by to dopadlo. Ale stejně tak si myslím, že Postgresql nemá cenu používat na web (člověk si leda přidělá práci, že bude muset instalovat externí cache a vymýšlet mechanismus na její zneplatňování --- a pokud to neudělá, tak mu odkaz ze slashdotu ten server sejme). -
Ten trigger na cache je potřeba, pokud je ta cache externí. Ale kdyby byla interně v serveru, tak na to žádný trigger potřeba není --- stačí prostě při odpovědi zaznamenat transakční ID všech tabulek, které byly ke konstrukci odpovědí potřeba, a při dalším stejném dotazu porovnat daná transakční ID --- pokud sedí, tak se nemusí nic počítat a může se hned vrátit odpověď. (externí cache by takhle napsat nešla, protože externí cache nezjistí, jaké tabulky byly k řešení dotazu použity)
V PostgreSQL neni transakcni id na tabulkach :(. a) by mne decentne zpomalilo vyhodnoceni provadeciho planu, protoze bych jej musel kontrolovat na shodu, b) by se mi zpomalil commit, protoze bych musel znevalidnit cache. Uznavam, ze u statictejsich www aplikaci to smysl ma. Je to jednodušší než použít cache v PHP. Nicméně php cache je ještě efektivnější, jelikož ušetřím connect (i poolovaný) do db a navíc většinou mám v cache html místo surových dat, která musím znovu zabalit do html.
Použitím pg na logicky jednodušších aplikacích nepřinese žádný efekt. Ten se dostaví až, když jsou db operace o něco komplikovanější - kdy se využití triggery, bohatší repertoár indexů, speciální datové typy (pole). Trochu komplikovanější e-shop už se v PostgreSQL vyplatí. Dost práce dokáži provést v databázi - a navíc jsou k dispozici externí uložené procedury v Perlu, Pythonu.
-
BLEK. (neregistrovaný)Nemyslel jsem ID transakce, ale takové to generační ID, podle kterého se určuje, které záznamy daná transakce vidí a které už ne. To by bylo na konzistenci cache jak dělané. Nemusela by se pak po každém updatu procházet cache, stačilo by při vyhledávání v cache porovnat ta ID. Případně, když už tam mají spoustu inteligentních algoritmů na optimalizátor, by asi nebyl problém udělat algoritmus, který bude hádat, zda daný typ dotazu má smysl cachovat nebo nemá.
Problém s tou cachí by spíš byl v tom, že by musela být ve sdílené paměti, a v současné době se výsledky dotazu nejspíš ukládají do privátní paměti procesu --- takže by se ta celá manipulace s pamětí musela předělat. Taky by se velikost sdílené paměti musela zvětšit a některé systémy na ni mají limit. -
zadne generacni ID neexistuje. Teoreticky by se ale nekam mohlo ukladat transactionId transakce, ktera naposledy danou tabulku modifikovala. Je otazka jestli by se nejednalo o nove hrdlo. Podle mne je mozne takove kesovani udelat - dnes navic klesa cena pameti, takze uz neni protiargument, ze lze pamet lepe vyuzit jinak. Data lze jednoduse prekopirovat do shared mem, moc by se toho predelavat nemuselo. Nikdo ale takovou cache nenapsal - to je ten problem. Pokud by nekdo pripravil prototyp, tak by se o nem dalo diskutovat.
-
Ještě doplním - Použití PostgreSQL ve firmě Baťa a.s.
* Pokladní systém - (vlastní aplikace je komerční POS od firmy NOV s.r.o. ze Slovenska), jako OS je využíván GNU/Linux jako datové úložiště PostgreSQL.
* Web - využíváme dnes už klasickou kombinaci Apache, PHP, MySQL na veřejném webu pro velkou část poboček fy. Baťa na světě a kombinaci Apache, modperl, PostgreSQL pro naše interní systémy ve střední Evropě
Bee - např. http://sourceforge.net/projects/bee/ -
p.s. Zřetelně posuzujete produkt pouze podle ceny, což je jedno z kritérií a to ještě ve stylu "čím dražší, tím lepší". Dalšími kritérii jsou užitné vlastnosti, shoda s normou, provozní a instalační náklady, spolehlivost, průchodnost, nároky na hw, adaptabilita, rozšiřitelnost, atd. Záleží na okolnostech, které kritérium má vyšší význam a které nikoliv. I když vzhledem k Vašemu tónu se dá soudit, že jste jeden z dalších trollu (třetí inkarnace LO) a objektivní argumenty Vás vůbec nezajímají.
-
Lenin (neregistrovaný)Trzni cena vypovida o produktu mnohem vice nez si myslite. Znamena to, ze si zakaznici tento produkt ceni natolik, ze jsou za nej ochotni zaplatit nemale castky. A to i treba desetitisice EUR.
Kdybychom umele srovnali cenu produktu MySQL, PGSQL a Oracle rekneme na $15k za serverovou licenci, myslite si ze by zakaznici kupovali PGSQL? Ani nahodou.
Takze vidite, ze hlavni vyhoda opensource reseni je nulova porizovaci cena. Vetsina open source softu neni konkurenceschopna. Open Source je alternativni reseni, ktere pouzivaji zakaznici co si nemohou dovolit poradny software. Proste komunitni reseni, ktere bude vzdycky oproti profi reseni strasne podfinancovane.
To, ze vetsina cechu radsi slohne komerci Photoshop, nez aby pouzila OSS Gimp rozhodne ve prospech kvality open source reseni nemluvi.
Stejne je to s hardwarem, kdo si ty SPARCy nemuze dovolit, holt jede linux na intelu. -
Platíte za to co potřebujete - případně za značku. Je to stejné jako v životě. Někdo si zaplatí Mercedes, jiný Opel, další Fiata. Pokud platíte za značku, tak obyčejně platíte mnohem víc. Pokud by se PostgreSQL prodával, tak by rozhodně nestál $5K na kterém se pohybuje Oracle. Hádal bych, že tak něco kolem $200 za které se prodává MySQL. PostgreSQL nemá obří knihovny a nemá ani OLAP podporu. Nicméně za $200 se nevyplatí vytvářet prodejní síť, takže PostgreSQL je zdarma. Z mých zkušeností PostgreSQL funguje bezproblémově jako vnitropodnikový server pro podnik zhruba s cca 2000 zaměstnanci, a vím také o www s cca 100K uživateli. V obou případech vytěžují server cca na 10%. Limity Oracle jsou jinde, díky clusteringu, podpoře OLAPU, a dalším technologiím. Na druhou stranu kolik je v Čechách administrátorů a programátorů, kteří jsou schopní tyto vlastnosti využít. Do provozní ceny Oraclu musíte zahrnout ještě školení, vyšší provozní náklady - rozjet Oracle tak aby běžel na libovolném hw optimálně není vůbec laciná záležitost. Nejde jenom o to na co mám, ale i o to, co potřebuji a co dokážu využít. Mám na to, tak si koupíme Oracle - typicky managerská úvaha - chlapů co k myšlení nepoužívají hlavu, když to napíšu kulantně. Jsem inženýr - používám s rozmyslem, to co je pro danou aplikaci, dané použití nejvýhodnější - a čím širší znám paletu prostředků, tím lepší řešení dokáži navrhnout - k oboustranné spokojenosti.
-
Lenin (neregistrovaný)Databazi za $200 na server by si nikdo do podniku nekoupil. Kdyz manager uvidi ceny $15K oracle $25K DB2 $200 PGSQL, tak si rekne ,,no to bude asi nejakej levne smejd'' a vubec se s tim nebude dal zabyvat.
Je to typicka managerska uvaha, ale to je fakt. Tak to ve svete chodi. Rozhodovaci pravo ma manager, ne inzernyr. Od inzenyra se ocekava, ze rozchodi to, co mu nanager zakoupil. Proc bychom si kupovali neco horsiho, kdyz si muzeme dovolit high-end technologii?
Kdyz se investovany prachy vrati tak je uplne jedno kolik to cele stalo. Tenhle problem vubec neresime. Penize jsou tu od toho aby se pouzivaly. -
Zdenek Kotala (neregistrovaný)Ano to funguje trosku jinak. Zadnej manazer si nekoupi Oracle. Manager si koupi reseni od firmy a soucasti toho reseni je databaze. A zalezi pouze na dodavateli te applikace jaky backend zvoli. Rada jich voli Oracle protoze tim nic neskazi a to i v pripade, kdy by tam stacila foxka. Ale nastesti je tu konkurencni boj, takze pokud prijde jina firma se stejnym resenim a jako backend pouzije treba PostgreSQL, tak cena reseni muze byt levnejsi a zakaznikovi je vetsinou jedno co jak je to udelane vevnitr dulezite jsou funkce co nabizi ta aplikace a pak samozrejmne zvoli stejnou funkcnost za levnejsi cenu. A to jeste dodavatel ma vetsinou z toho vetsi rabat.
-
j.peterka (neregistrovaný)predne bych rekl, ze ty hovadiny od Lenina neni treba komentovat (uz vubec nechapu, ze se pan Stehule necha tak lehce od trolu provokovat) ale k te vasi vypovedi bych mel namitky.
Jestli na nejake reseni staci foxka (a tech vidim na trhu pres 90%), tak je uplny nesmysl na to brat ale zrovna tak postgresql. Na to se proste vezme nejaka foxka (vista ci jak se to jmenuje). Ty ceny jsou zanedbatelne.
A jestli je to reseni takove, ze je zapotrebi power od postgresql, tak pak uz je ta cena tak daleko, ze licence oraclu nikoho nezabije. A mezi tim je takove to pasmo, kdy se jedna o jednoduchou aplikaci (levna) event. kombinovane s masou dat a mnozstvim licenci. A prave to je ten pripad, kdy se hodi pgsql. Ale v zadnem pripade se nejedna o plosne nasazeni. -
Zdenek Kotala (neregistrovaný)Ta foxka byl jen takove nadnesene prirovnani :-). Ale jinak skutecne v soucastnosti hodne uzivatelu Oracle (zvlaste verzi 7,8,9) prechazi radeji na PostgreSQL nez by upgradovali na Oracle 10,11. A druhou skupinou jsou nespokojeni uzivatele MySQL, kterym se rozrostla aplikace, tak ze MySQL prestala stihat. Viz napr. http://tweakers.net/reviews/649
-
Zdenek Kotala (neregistrovaný)Ano jak kdy. Pracoval jsem na vyvoji datawarehouse reseni, kde cena hardwaru a licence Oraclu dela mozna tak pres 70% ceny z celkove ceny reseni. Ono uz to, ze Oracle licencuje tusim per HW thread, tak pokud ho nasadite na Niagare, kde je 32 nebo 64 CPU tak se nestacite divit. Navic vetsina zajimavych zakazniku si spolecne s Oraclem koupi i support a to jsou dalsi nemale penize. A to nemluve ze rada zajimavych vlastnosti jako partioning je az v Enterprise verzi. Ja mam spis zkusenost, ze licence za Oracle je vyznamnou polozkou, ale zalezi na konkretnim reseni.
-
To si pouze myslíte. Dost často se používá MySQL jako doplněk k Oracle a to proto, že je to v určitém řešení výhodné a že v počtu licencí se ušetří několik desítek tisíc dolarů. Nevidím důvod, proč by si firmy pro projekty, které to vyžadují nenakoupily komerční soft. Pokud má projekt obrat nad $100000 10% na licence se obětuje. Pravda je ale taková, že do v případě projektů do půl miliónu Kč se handrkuje o koruny - zákazník chce řešení a zajímá jej celková cena - tudíž pro dodavatele to má ten efekt, že mu náklady na licence snižují příjem.
Peníze jsou tu od toho aby se používali efektivně. Je rozdíl vyhodit půl miliónu a investovat půl miliónu. Pokud investujete tisíce dolarů za licence, tak Vašich peněz si užívají akcionáři Oracle. Pokud se obejdete bez licencí, tak jsou to Vaše peníze, případně peníze, které zůstanou zákazníkovi, a které může investovat s větším ziskem. Řekl bych, že nejste ekonom. Pokud byste se někde prezentoval s tím, že si vystačíte s návratností ve výši investice, tak neuspějete. Těžce se sleduje návratnost. Je vidět, že Vy tento problém neřešíte a nemáte tušení, jaká je realita. -
Lenin (neregistrovaný)jenomze mysql to je uplne jiny kafe. Je na to mnohem vice aplikaci, jsou k tomu poradna administrativni rozhrani a navic za tim stoji velka firma ktera je schopna zajistit potrebny support. Od mysql existuje navic normalni komercni verze.
Chapu ze mohou byt male databaze cenove pritazlive pro startup nebo pro male firmy. Take je mi jasne ze aplikace nevyuzivaji zdaleka vsech moznosti highend db. Porad se ale nemuzu zbavit dojmu ze pouziti pgsql misto oracle je pro stredne velkou firmu (200 zamestnancu) setreni na spatnem miste. Par desitek tisic dolaru nehraje podstatnou roli a navic se ta investice rozlozi rekneme do 5li let. -
Každá investice, kterou nevyužijete je špatná investice. Když si koupíte mercedes, tak se s ním můžete aspoň předvádět na ulici, licence sw máte leda zavřené ve skříni a jejich cena rychle klesá. Evidentně nemáte představu o databázích a soudíte podle toho jestli je za databází komerční firma nebo ne. Funkce, které jsou důležité pro enterprise prostředí má už postgres 10 let, běžně se používají, zatímco u MySQL se ještě nestihly doladit. Interně je PostgreSQL postavená podstatně moderněji - s modernější a efektivnější správou paměti, s konceptem dovolující takovou rozšiřitelnost, kterou MySQL dlouho ještě mít nebude.
Komerční support PostgreSQL:
http://www.enterprisedb.com/support/index.do
http://www.commandprompt.com/
http://www.2ndquadrant.com/
Pokud chcete utrácet peníze, můžete si klidně koupit CD s PostgreSQL.
Domluvil jsem - slibuji, že nebudu krmit troly, slibuji, že nebudu krmit trotly, slibuji, že nebudu krmit troly, slibuji, že nebudu krmit trotly, slibuji, že nebudu krmit troly, slibuji, že nebudu krmit trotly, slibuji, že nebudu krmit troly, slibuji, že nebudu krmit trotly,slibuji, že nebudu krmit troly, slibuji, že nebudu krmit trotly,vvslibuji, že nebudu krmit troly, slibuji, že nebudu krmit trotly, slibuji, že nebudu krmit troly, slibuji, že nebudu krmit trotly, slibuji, že nebudu krmit troly, slibuji, že nebudu krmit trotly. -
Zdenek Kotala (neregistrovaný)Pripadne pokud chcete support od jeste vetsi firmy tak:
www.sun.com/postgresql
A je rada dalsich firem. Vyhoda podpory postgresu je takova, ze pokud Vas jedna firma nastve tak mate kam prejit. Kdezto u databazi jako Oracle, MySQL a dalsich jste odkazan na dobrodini jedne firmy. Zazil jsem nekolikrat reseni problemu se supportem Oraclu a slysel jsem jak funguje MySQL. U postgresql jsou ty firmy tlaceny byt lepsi nez ty ostatni, existuje tam konkurence a je to tak dobre. -
Zdenek Kotala (neregistrovaný)Ano budete se divit, ale rada bank ho pouziva a to vcetne celosvetovych gigantu. Samozrejmne je treba si uvedomit, ze v bankach je tech systemu stovky. Hodne se ted zacina rovnez rozjizdet nasazeni v Telco segmentu a tusim ze Heatrow airport to pouziva pro nejaky rezervacni system. A jak uz Pavel rekl, PostgreSQL je konkurence Oraclu ve smyslu nasazeni a pro radu aplikaci bohate staci. Rada uzivatelu migruje sve aplikace z Oraclu prave na PostgreSQL a neni to ojedinely jev. Co se tyce vykonu a objemu dat tak jsem videl nasazeni na nekolika terabajtech a Green Plum jede data warehouse s upravenym postgresem nad 100TB databazi.
Jinak k dalsim aplikacim, tak napriklad SunMC v nove verzi pouziva misto Oracle backendu PostgreSQL a mnoho dalsi Sunovskych aplikacich rovnez. Napriklad cely volebni system Noveho Zelandu bezi na PostgreSQL a velka obliba PostgreSQL v Japonsku je zcela zvlastni kapitola. -
účast není omezená, jen formálně není částí konference - 8:30-10:15 před zahájením vlastní konference - a není součástí konference proto, že nemám rád formality. Mám připravenou ukázku hackingu PostgreSQL - příklady vlastních funkcí v C a případně ukázku optimalizace dotazu. Co se bude dělat bude záležet na lidech, podle toho, kdo s čím přijde. Pokud byste měli nějaký zajímavý pomalý dotaz, tak se na něj můžeme podívat - pak si přineste vlastní notebook s nainstalovanou databází a hlavně daty. Jinak na http://www.pgsql.cz/index.php/PostgreSQL se o workshopu něco málo píše.
