Vlákno názorů k článku
Konference Prague PostgreSQL Developers' Day 2008 od Lenin - $subj nebo nas tam zase bude krmit prednasejici...

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.

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.

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.

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

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.

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.

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.

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.

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

Odpověděl jste si sám. Proč dodavatel zvolí Oracle i když by nemusel? Protože tím nic neskazí. Cena řešení obvykle značně převyšuje cenu za licenci a v mnoha případech lze použít již existující Oracle a know-how.

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.

Oracle se licencuje per core.

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.

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.