ARCHIV

jako jedina ma poradny support pro ESQL (ESQL pro postgresql je silene buggy), coz je pro rozumnou rychlost nepostradatelne.

Samozrejme, ze je to ale uplne jina liga, nez ty uvedene databaze.

SAPDB je strasne bugova, i kdyz se dodavala se sapem tak se pouzivala jen jako docasna db nez se zakoupi oracle a jeji nepouzivani doporucovali (pochopitelne neoficialne) i SAP partneri.

Kdyz byla sapdb uverejnena jako opensource tak taky po ni nestek ani pes. Je fakt, diky masivnimu MySQL marketingu ji nekdo pouzivat asi casem zacne.

... K dnesnimu dni je MaxDB u vice nez 3500 SAP-zakazniku v nasazeni. MaxDB ist optimalizovana pro OLTP provoz s nekolika tisici soucasnymi uzivateli a s velikosti spravovanych dat mezi 100 Gbyte az mnoha Tbyte ...

Tak si rikam, ze to neoficialni "doporucovani" asi moc nepomohlo..

Krome jineho je zajimave, ze SAPDB nepouziva ten MVCC a presto to funguje. Proc?

Je to drb, ale rozhodne SAP nema nejlepsi povest. A jelikoz SAP dokaze bezet i nad MySQL, tak zrovna asi nejmodernejsi DB featury nepouziva.

V prvni rade je potreba upozornit ze pocet instalaci o kvalite software nevypovida, vypovida o oblibenosti. O tom, co se nainstaluje rozhoduje management na zaklade barevnych marketingovych materialu.

V praxi je videt, ze podprumerny produkt s nadprumernym martketingem ma mnohem vic instalaci nez nadprumerny produkt s podprumernym marketingem. Prikladu je okolo nas cela rada.

Neni mne znamo zeby sap behal na mysql. pokud si dobre pamatuju beha na oracle, db2, sapdb, microsoft sql.

Zpet k tematu. Pokud mluvite o tomhle pdf, ja z z nej ctu neco jineho. Pisi tam ze SAP DB se pouziva v 3.5k instalaci SAPu na svete, jelikoz pocet SAP instalaci je cca 100k, tak je videt, ze SAPDB se prakticky nepouziva. Je take jeste soucasti SAP bundlu, ktery maj asi 7k instalaci, ale tech 7k lidi si nemohlo rozhodnout ze chce misto sapdb Oracle.

Pochybuju, ze by nekdo provozoval SAP nad MySQL, ale nekde jsem narazil na zminku, ze je MySQL certifikovana pro SAP.

Ahoj Marku,

"PgSQL, nebo FbSQL asi nebude příliš rozumné nasadit do míst, kde se často přepisují údaje. " - to jsem moc nepochopil. Znamená to, že vidíš jako nejvhodnější pro taková řešení MySQL? To mi přijde divné, vždyť kvůli multigenerační architektuře (kterou má Fb a víceméně i PgSQL) by to mělo být právě naopak, ne?

Jinak díky za článek, super.

Mno ten zádrhel je v té multigenerační architektuře (MVCC). Ty data prostě rostou rychle, anžto Ti tam všechno zůstává, byť se k tomu nedostaneš. MySQL takto neroste, to snad víš, prostě zamkne řádek, nebo tabulku, uděla změny a odemkne. Samozřejmě, že PgSQL a FbSQL je vynikající volba, ale je třeba udělat pár kroků navíc a ty starý, neplatný data čistit.

Jinak jak koukám na MySQL, tak se z toho stává dospělá databáze. Pavel Stěhule poznamenat, že až nasadí ten nový engine, tak z toho udělají PgSQL :-D.

Mno ten zádrhel je v té multigenerační architektuře (MVCC). Ty data prostě rostou rychle, anžto Ti tam všechno zůstává, byť se k tomu nedostaneš. MySQL takto neroste, to snad víš, prostě zamkne řádek, nebo tabulku, uděla změny a odemkne

Slo by to trochu exaktneji? Alespon ve me takovahle ex cathedra utrousena moudra moc duvery nevzbuzuji ...

Co je na tom neexaktního? PgSQL a FbSQL všechna UPDATE fyzicky převádí na INSERT, DELETE, kdežto MySQL dělá LOCK, UPDATE. To může vést k problémům se zabraným místem. Od toho je taky v PgSQL třeba to VACUUM, že? Na druhou stranu z toho vyplývají ty performance problémy MySQL při masivním konkurenčním přístupu.

Co je na tom neexaktního?

OK, tak to asi jenom nevidim. Chapu rozdil mezi UPDATE v MySQL a postgresovym chovanim podobnem "copy-on-write" modelu, ale uz nevidim, ze je PostgreSQL nebo Firebird/Interbase mene vhodne do situaci, ve kterych se casto prepisuji data.

Strucne -- pro srovnani dvou ruznych pristupu mi prijde vhodnejsi to mit zmerene nez neco obecneho tvrdit.

Prakticka zkusenost je asi takova, ze nevadi ani tak moc, ze se meni hodne, ale ze se uvnitr jedne transakce meni hodne, to by i odpovidalo teoretickym predpokladum vychazejicim z me predstavy, jak vlastne to copy-on-write v postgresu funguje (ktere ovsem muzou byt uplne spatne).

Nicmene problem toho narustu objemu nespociva ani tak v tom samotnem narustu (disky jsou levne a tak vubec:)). Ale v tom, ze pokud tabulka tech starych revizi obsahuje mnoho, zacne byt ledasco velice pomale (a mam dojem, ze s timto zpomalenim optimalizator prilis nepocita).

Pri opravdu intenzivnim update zaznamu je MyISAM zhruba 10x rychlejsi nez MGA architektura. Jinak rychlost updatu samotne tabulky je vec jedna, zalezi take na rychlosti aktualizace indexu, poctu indexu, atd. atd.

Navic MyISAM zajistuje konstatnti rychlost. MGA architektura trpi, ze po urcite dobe ztraci vykon, a po dalsi dobe totalne odpada. A to jak Firebird tak PostgreSQL. Pak je potreba provest na Postgresu VACUUM a na Firebirdu se delalo kolecko back /restore (a mam pocit, ze na to maji nejaky prikaz). Dlouhou dobu diky tomu byla MGA architektura mimo 24/7. Od 7.4 VACUUM nevyzaduje excluzivni zamky, tak tak nevadi, nicmene jistou zatez predstavuje. Na 8.3 uz bude evidence stranek obsahujicich mrtve verze, takze se to zas o neco zrychli a nebude to tak bolet. Nikdy bych ale MGA databazi nenasadil jako HTTP cache.

Firebird se snazi verze radku ukladat do te same stranky (v soucasne dobe muze mit stranka tusim 2 az 16 kB) kde je radek, ale kdyz uz neni ve strance misto, musi se ulozit do jine stranky. Pokud jsou pak verze fragmentovane v ruznych strankach, na rychlosti to urcite neprida. Cisteni starych verzi pak probiha bud prubezne pri pristupu k seznamu verzi pri select, nebo pro kompletni vycisteni slouzi sweep databaze nebo backup/restore (ten to udela asi nejlepe, protoze nejen vycisti nepotrebne verze, ale i srovna radky aby v kazde strance bylo zase volne misto, ale samozrejme to znamena odpojit lidi z databaze).

To ze se meni data hodne uvnitr jedne transakce nevadi, mvcc db nemusi narozdil od row-locking db udrzovat seznam zmenenych radek. Optimalizer s mrtvymi radky pocitat umi, pokud ma k dispozici aspon trochu aktualni ANALYZE statistiku.

INFO: "data": scanned 3000 of 9001 pages, containing 354736 live rows and 0 dead rows; 3000 rows in sample, 1064326 estimated total rows

btw: co znamena 3000 rows in sample?

Problemem jsou dlouho bezici transakce, ktere blokuji odmazani starych verzi, ale ty jsou problemem v overwriting DB taky. Tam zase zpusobuji jine problemy.

MVCC architektura je v soucasnosti jasny vitez a nejen relacni, ale i objektove orientovane DB na ni prechazeji, protoze je to jediny zpusob jak solidne zvladat hodne aktivnich uzivatelu.

Dost se bavim, kdyz jeste dnes nekteri povazuji Table-level locking za dostatecny nebo dokonce nejlepsi pokud je tabulka hodne aktualizovana.
To bude fungovat snad jen na velmi malych tabulkach (kde je uplne jedno zda pouzivate rychlou nebo pomalou db, vse dobehne v rozumnem case) nebo pro velmi maly pocet aktualizovanych radek (najdou se relativne rychle pomoci indexu).

Porad tedy nechapu kde vidite problem

1.
pokud je v tabulce maly pocet dead rows, tak se vacuum na ni nevyplati (je nutny full table scan tedy generovat hodne io operaci) a zdrzeni zpusobene par radky navic je zanedbatelne.

2.
Pokud tabulka obsahuje napr. 100 live rows a 50000 dead rows, tak uz ty dead rows provoz znatelne brzdi a vacuum tabulky se vyplati, coz autovacuum zjisti a spusti ho. Pokud to autovacuum zjisti prilis pozde tak ho spoustejte casteji nez defaultnich 60 sec.

Pokud batch importy generuji mnohem vice dead rows oproti bezne zatezi aplikace (a tudiz autovacuum reaguje prilis pozde) tak do nich vlozte cas od casu vacuum na nejupdatovanejsi tabulku nebo se smirte s tim, ze pobezi pomaleji. Pokud se neimportuji gigabajty dat nebo stamiliony radek doba importu nehraje zas takovou roli, kdyz diky MVCC neblokuje ostatni uzivatele.

Provozuji nad pgsql nekolik www vyhledavacich enginu a databaze bez MVCC je nepouzitelna. Nemuzete nechat web uzivatele, ktery neco hleda cekat nez se zpracuje import dat nebo naopak odmazani dat, jedna takova davka muze trvat desitky sekund az desitky minut. Vetsina web uzivatelu chce vysledky od vyhledavace do sekundy nebo priste jde jinam.

Asi se trochu mijime. Psal jsem o pouziti databaze, jako jednoduche kese. V tomhle pripade mam zpravidla jednu tabulku, kde kazda transakce meni jen jeden zaznam navic pod indexem. Samotna operace je tak rychla, ze se nenarazi na zamky (vetsinou). V Postgresu takovou tabulku musite co pul hodiny vacuovat, navic update bude (co tak mam odkoukano 5-10x pomalejsi nez u MyISAM). V kesi drzim jenom session data. Navic vsechny dotazy jdou na primarni klic.

Jakmile zacnu databazi pouzivat jako databazi, pak by MGA mela s prehledem starsi architektury porazet. Pokud databazi pouzivam jako cache, tak MGA pusobi vic skody nez uzitku.

Zhruba, MyISAM pri UPDATE, DELETE zamkne tabulku, a zaznam na disku prepise. PostgreSQL pri UPDATE, DELETE vytvori kopii zaznamu a zaradi ji do linearniho seznamu. Potom az do provedeni operace VACUUM PostgreSQL musi prochazet linearni seznam a hledat platny zaznam. Pokud linearni seznam prilis neroste, tak je MGA vyhodnejsi nez prepisovani zaznamu. Skoro odpada nutnost zamykani. Pokud se provadi intenzivni update, delete tak seznam roste a listovani v seznamu uz ma znatelnou rezii. Resenim je castejsi pouziti operace VACUUM. MGA databaze jsou vhodne pro ukladani deletrvajicich dat, pro ukladani docasnych hodnot s pulhodinovou zivotnosti, jako jsou napr. http cache je naopak MyISAM to prave orechove.

Firebird nema transakcni log, ale zmeny uklada primo v DB, kazdy radek v tabulce je vlastne seznam zmen s tim, ze nejaktualnejsi verze je na zacatku seznamu. V seznamu zmen jsou pak nejen samotna data, ale i cislo transakce, ktera zmenu provedla. Pri cteni se pak precte bud nejaktualnejsi potvrzena zmena pri izolaci Read Commited, nebo pri izolaci Repeatable Read nejblizsi potvrzena zmena s mensim cislem transakce nez ta co cte.

Vyhodou je, ze transakce ma snadny a rychly pristup ke sve verzi dat a neblokuje pri tom zmenu dat ostatnim, dobre hlavne pri paralelnim pristupu nekolika transakci a soubeznem zpracovani dat. Dalsi vyhodou je moznost spustit zalohu za plneho provozu, zaloha bezi ve sve transakci a opet podle cisel a stavu jednotlivych transakci pozna, co zalohovat a co uz je novejsi.

Jako nevyhodu vidim asi to, ze zalohuju vzdy celou databazi (FB2 uz ma i inkrementalni backup) a v pripade havarie a obnovy db se dostanu jen do mista zalohy, ale bez transakcniho logu uz se nedostanu do stavu tesne pred havarii db. A dalsi nevyhoda je prave to, ze stare uz nepotrebne verze radku stale zustavaji v databazi, pak je vhodne obcas spoustet sweep databaze, nebo udelat zalohu a obnovu, tim se stranky zase procisti od nepotrebnych verzi.

Jinak pokud jde o zkusenosti, Interbase jsme zacali pouzivat ve spojeni s Delphi 3, tehdy slo o IB 4, pak pres IB 5.5 a 6 jsme presli na Firebird 1 a nyni jedem na 1.5, FB 2 zkousime. Asi hlavni, co nam na tom bezi je system duchodoveho pojisteni, tedy samotny vypocet vyse davek, mesicne vyplaceni cca 45000 duchodu a davek, z toho srazky, obstavky a pohledavky, uctovani dle polozkove skladby a tak. DB ma v soucasne dobe cca 5 GB, server je na Linuxu, klienti jsou v Delphi na Win a beha to velmi pekne (tuk tuk tuk :-). Hlavne ta sprava DB je nenarocna, o vse se stara gbak, tar a scp ve spojeni s cronem - staci mit hohy na stole a kazde rano se podivat na mail, co prijde od cronu :-).

Přesně tak, já Firebirdu dosti fandím a nedám na něj dopustit. Jinak, hezký článek o popisu MGA je na http://www.firebirdsql.org/doc/whitepapers/fb_vs_ibm_vs_oracle.htm

Válka mezi přístupem LOCK - UPDATE - UNLOCK a verzováním je dosti stará a nemá vítěze; samozřejmě by bylo zajímavé podrobit jednotlivé databáze testům kdy několik klientů čte a jiných několik zapisuje. Tam by pak rozdíly byly veliké. Ale pro weby? Většinou bude stačit kterákoli ze tří zmíněných databází úplně v pohodě.

V posledni dobe se mi jevi, ze verzovani zacina pomalu ale jiste vitezit, protoze podobny pristup pouziva mnoho souborovych systemu. Drive spise ve specialnich aplikacich kde to jinak moc nejde (BSD LFS, uloziste ruznych distribuovanych FS, linuxove JFFS, FTL nejruznejsich kusu hardware...) ale v posledni dobe i royumne obecne unixove FS jako je treba solarisi ZFS nebo linuxovy Reiser4.

Zajimave, je ze Rosenblum a Ousterhout v "The Design and Implementation of a Log-Structured Filesystem" uvadeji presne opacne argumenty proc je tento pristup lepsi nez pan Olsavsky, nicmene lze usuzovat, ze u souboroveho systemu (vsechny pristupy prochazeji jednim mistem) lze problem s odstranovanim starych revizi resit vyrazne jednoduseji a efektivneji, nez u databazovych systemu jako je FB ci postgresql (kde je synchronizace mezi uzivateli uloziste minimalni).

Nicmene pravdepodobne lze souhlasit s tim, ze pro jiste aplikace je takovyto pristup nevhodny a jednou z nich bude vetsina verejne pristupnych webu, kde je to cele budto uplne jedno, nebo se zacne projevovat overhead spojeny s hledanim poslednich verzi hodnot.

V tom dokumentu (zajimave cteni) je nekolik chyb. Oracle7 v zadnem pripade mvcc neni, to umi az devitka. Sedmicka porad blokuje reader, pokud writer stoji s cursorem na zmenenem radku.

Oracle krome ORA-1555 (pomerne rare chyba, na tohleto vypadava kdyz ma jeste misto v rollback segmentu) vypadava mnohem casteji na rollback segment full. DB2 rollback segmenty nepouziva.

Ten pripad s transakcema ukazuje ze v Oracle 9i je MVCC implementovano spravne. Takhle se to ma chovat. Pokud toto chovani je v konkretnim pripade naskodu, aplikace si ma radek zamknout nebo switchnout isolation level.

Jedine co mne zaujalo, je to, ze firebird pravdepodobne odstranuje stare radky prubezne. t.j. kdyz na ne narazi napr. pri tablescanu. Tohleto sice usetri read io potrebne pro vacuum v pgsql, ale pravdepodobne to bude generovat vice zapisu protoze k prepisu stranek bude dochazet tim padem casteji, a zapisy jsou na diskovych polich vyrazne pomalejsi nez ready.

Je otazkou nakolik to bude efektivni. Cituji z Pavla Cisare "ackoliv jsou nepotrebne verze radku odstranovany prubezne, je vhodne pravidelne provadet vycisteni databaze (sweep)." Navic zalezi na architekture Firebirdu. U Super Serveru jsou mrtve zaznamy oznacene pouze ke zruseni. O samotne zruseni se stara separatni proces. V pripade, ze by na vytizenem serveru automaticky sweep zpusoboval problemy, lze jej potlacit. Krapet mi to pripomina VACUUM v blede modrem baleni.

Velmi pěkné... Nedávno vyšlel Pavlovi výborný článek o Postgresu na rootu, zhruba ve stejný čas také podobný čánek na linuxexpresu. Jen tak dál...

http://www.root.cz/clanky/zakys-jmenem-flattening
http://www.linuxexpres.cz/software/srovnani-databazovych-serveru