Vlákno názorů k článku Databázový server - základní konfigurace od Jerry III - Co vim tak to hlavni rozdeleni je data...

Co vim tak to hlavni rozdeleni je data a transakcni logy zvlast, ne data a indexy. Samozrejme tohle se netyka svobodnych systemu kterym veci jako transakce nic nerikaj.

A doporucovat na databazovy store RAID-0? Co k tomu rict, obetovat bezpecnost dat kvuli relativne malemu zlepseni vykonu muze jen silenec. Doufam ze s nekym takovym neprijdu do styku :)

no zalezi na tom - zrovna me ceka rozhodnuti, na co dat Informix. raid-5 nebo raid-0. Budou to samozrejme scsi disky. Doma mam ide a trochu jsem si hral, na IDE se rozhodne neda mluvit o relativne malem zvyseni vykonu, ale o drastickem, radovem zvyseni vykonu. Na scsi tomu tak samozrejme asi nebude. Jenze toho raid-0 se teda fakt bojim :). Takze asi raid-5, i kdyz to bude pomalejsi. Nebo mirrorovany raid-0 ? To by asi taky slo. Stejne je to o nabozenstvi :)

Pokud to mas jenom na hrani, je uplne jedno na jake disky to das. Pokud to mas na data pro nejaky web, ktery kdyz bude dva dny down, je to fuk, nijak zvlast na tom nezalezi taky. Pokud do dat bude pristupovat mnoho uzivatelu soucasne (=mnoho soucasnych transakci), je pitomost pouzit IDE/ATA/SATA disky. ATA z principu nezvlada vice soucasnych pristupu ani razeni pozadavku do async fronty. Takze jedine SCSI. No a co se tyce ruznych RAIDu ("RAID" na bazi ATA je hloupost na hrani), zalezi hodne na zpusobu vyuziti a pristupu. Kdybys cetl clanek pozorne, nektere odpovedi tam najdes. (Ladeni DBM neni trivialni zalezitost a ti, kteri to umeji, si sve znalosti a zkusenosti nechavaji vetsinou draze platit.) Obecne lze nadhodit, ze rozdelovani dat a indexu ma opodstatneni pouze ve velice specialnich pripadech. Rozhodne nepatri na stejne FYZICKE disky (ani stejny RAID) data a transakcni log. Duvody jsou nejmene dva - bezpecnost dat a vykon. Transakcni log byva nekolikanasobne vytizenejsi nez data pri zapisu, pri cteni je to opacne. A tady uz je potreba peclive planovat jak se s daty bude pracovat. Rozhodne se vzdy vyplati HW RAID. Obecne RAID1 na vetsi zatez pri zapisu (log), RAID5 na vetsi zatez pri cteni (data). Ale opravdu zalezi na konkretnim reseni, zcela obecny "navod" neexistuje. Maximalne jsou urcita pravidla, na ktera se vyplati myslet a ta najdes v tomto a predchozim clanku. I kdyz nektera jsou prinejmensim diskutabilni a ja treba zdaleka se vsemi zavery autora nesouhlasim. Nicmene znova opakuji, ze je to spis zalezitost daneho navrhu reseni v KONKRETNI situaci a nelze vsechno zobecnovat.

Zase nejakej pan chytrej. RAID na bazi ATA neni hloupost na hrani. Muj SATA RAID mi dela pri zapisu 94 MB/s. Mam na mysli zapis na disk, ne do cache, jedna se o soubory velikosti 2-4 GB. Cena disku cca 6000,- pri kapacite 240 GB, radic byl na desce za 3500,-

aha
tak si na to dejte databazi a nechte k ni pristupovat naraz 40 uzivatelu. zjistite, ze sekvencni cteni je dobre opravdu jen na mohutne kopirovani dvd obrazu, ale na opravdouvou DB potrebujete trosku jine vlastnosti, ktere IDE zatim postrada (imho nejpodstatnejsi z nich se schovava pod zkratkou TCQ)

Posledni pokus jsme delali pred mesicem. Na stejne sestave dual opteron jsme vyrobili: a) SATA hw mirror 2x120G; b) RAID5 na starem hp netraid3si a tri stare SCSI disky z nichz jeden ani nebyl ultra2. V kazde konfiguraci jsme provedli tri druhy testu: umele, testovaci utilitou od vyrobce db a realnou databazi. Podle ocekavani umele testy (ruzne sandry atd) dopadly tezce pro SATA mirror. Vzhledem k tomu, ze na tom mela bezet MS SQL, pustili jsme na tom MS SQLIOStress. SATA stale o 10% az 15% lepsi ale zatez obou procesoru 2,5x az 3 x vetsi nez u netraidu (75-90%x30%). No a realna databaze ? Netraid skoro vzdy lepsi, pouze jednou SATA mirror. V prostredi realne db se simulovalo 6 nejvice zatezujicich cinnosti a 5 soucasnych uzivatelu. Proste starej krap v horsi konfiguraci ve finale zvitezil. Jasne, ze nejde o nejake rigorozni testy, jasne, ze SATA mirror nebyl "kesovanej" :) (to by predpokladam mohlo snizit zatez cpu) ale rozhodne ty testy bereme na zretel. Jinak dokud budu cist, ze nekdo na ide polich nameril 195 terabajtu za pikosekundu, mohu zustat klidny. Takovy vysledek nemuze pochazet z realnych db testu, ze. Takze uzijte si tech 18 milionu dvd na vasem poli, ale neinstalujte tam databazi ! :)

S mnoha vecmi co pises souhlasim. S cim ale nesouhlasim je ten HW RAID. SW RAID co je v kernelu je proste lepsi. Vzdy mam prehled co se v poli deje, mohu s nim manipulovat jak se mi zachce, coz v pripade HW raidu dost dobre nemohu (vyrobci se jaxi moc neobtezuji a nehodlam mit tainted kernel nejakym modulem, ktery je urcen jen a pouze pro 2.4.5-patch-2.6.axm/9 ;-). Zatizeni PCI by nemelo byt o mnoho vetsi nez pro HW RAIDU a pro SMP stroj je XORovani hrackou. Ano, bude to SCSI, jak jsem psal, neni to na hrani, ale je to hlavni informacni system pomerne velke firmy. Dam se do testovani, abych zjistil, nakolik je RAID0 vykonnejsi nez RAID5, oboje na SCSI. Pokud by se ukazalo, ze i na SCSI je RAID0 vyrazne rychlejsi, mam problem :) jak se rozhodnout. Pokud rychlost bude vyssi jen o desitky procent, necham RAID5. Ted vubec neresim rozlozeni DBSPACE, to bude dalsi krok. TMP DBSPACE klidne muze byt na RAID0, logy a hlavni DBSPACE oboje zvlast, o logy by se nemelo prijit, ze. No uvidim, jak dopadne to testovani rychlosti RAID0 vs RAID5 na stejnem stroji.

Jenze hw RAID controller neni jenom o distribuovani redundantnich dat po jednotlivych discich. Zapominas na podstatne veci pro realne nasazeni: podpora hot-swap, hot-spare (rezervni disky bez dat, ktere radic automaticky pouzije v pripade vypadku jineho disku a automaticky tak udrzi cele pole v konzistentnim stavu), baterii zalohovane cache, automaticky resync pole po havarii, definovatelne priority obnovovacich procesu... Je toho hodne. A co hlavne: NEZAVISLOST NA OPERACNIM SYSTEMU, JEHO SPRAVNE FUNKCI A STAVU. Dokud je vsechno v poradku, je mozna celkem jedno jestli hw nebo sw radic (nicmene me nekolikalete prakticke zkusenosti rikaji, ze hw radic je nejmene o 30% vykonnejsi nez sw v jadre 2.4, nemluve o nezanedbatelne zatezi CPU v pripade sw reseni). Jakmile se objevi skutecny problem, softwarove reseni je hrave prevalcovano tim hardwarovym! Takze pokud potrebujes uklidnit jenom svedomi a nezatizit prave ted penezenku, pouzij si sw RAID, pokud chces opravdu bezpecnost dat, zachovani kontinuity provozu a nechces se v noci budit hruzou, co by se stalo, kdyby to doopravdy kleklo, nemas jine reseni nez hw radic a pokud mozno zadne siditko, ktere si na hw RAID jenom hraje a sidi to kusem firmwaru bez podpory v chipech (99.9% ATA RAIDu)... :-)

...chtel bych pouze upozornit, ze ja mel s Informixem na raid-5 velky problemy, alespon u verzi 7.x, nevim, jestli se to v 9.x uz nezlepsilo, schvalne si pockam na vysledek... (IFX mel asi nejakou averzi vuci cislu 5, pac me napada, ze dlouho neumel MD5 hesla... :-))

Jedeme 9.21 na aixu a raid5 (jsou tam SSA disky), bezi to normalne. Ten novy ma byt 9.30, testuju to zatim na obycejne parcele obycejneho IDE disku na linuxu. S verzi 7 byly problemy, treba se nikdy nepovedlo udelat restore i s logy; byli jsme radi, kdyz se to zrestorovalo z archivu.

tak tak ,
pokud mi jde o data a rychlost ,tak jedine raid 1+0.
Na 5ku zapomente...
PS: vzdyt disky jsou tak levne...

Ehm, opravdu jsou i FC disky tak levne?

Da se to udelat v linuxu ? To jako ze si udelam RAID1 na /dev/md0, dalsi na /dev/md1, /dev/md2 a /dev/md3 a z techto 4 zarizeni udelam RAID0 na /dev/md4 ? nebo obracene, ze bych udelal /dev/md0 (RAID0), /dev/md1 (stejne velky RAID0) a pak je zmiroroval (RAID1 na /dev/md2) ? Nebo to jde jinak ? (myslim SW RAID). ?

Dovolil bych si upozornit, ze vlivem distribuovaneho rozlozeni zateze neni RAID-5 moc vhodna na DB - lepe receno db ma malou kotrolu nad samotnym rozlozenim zateze - proto temer vsechny databazove servery NEDOPORUCUJI byti provozovany na RAID-5

Oh jeeee demagogicky widlak JerryIII se zase predvadi.
Za prve pokud nutne potrebujes vsem demonstrovat jak jsou ty widloidni systemy/aplikace dokonale a ty free/open/... systemy/aplikace na houby, vrat se na portaly, kde ti ty kecy zerou. Nechapu proc tak casto opruzujes na serverech, ktere jsou evidentne mimo obor tvych znalosti/schopnosti a predvadis se.
Za druhe pri svem vychvalovani komercnich proprietarnich aplikaci zapominas zduraznit fakt, ze zatimco porizovaci naklady na tva reseni dosahuji astronomicke vyse, stejny parametr pro nase reseni se blizi nule. TCO je vec diskutabilni, protoze zavisi na metodice, ktera neni jednoznacna a proto nema smysl o tom flejmovat. Zajiste bys argumentoval "nezavislymi" studiemi, ktere si zaplatil MS.
Za treti - konecne k veci - (zamerne?) vynechavas zminky o "free" enterprise SRBD jako jsou SAPDB/MaxDB nebo Interbase/Firebird. Tem transakce ROZHODNE rikaji hodne. Ostatne takovy PostgreSQL a MySQL transakce zvladaji taky, i kdyz jejich cilovy sektor je nekde jinde.
Takze kdyz necemu rozumis jako koza petrzeli, aspon neprud. Jakztakz jsem to prekousl u rozhovoru s M. Kyselou, ale tady uz to prehanis. IMHO.

PostgreSQL transakce umi a dokonce je umel drive nez samotne SQL:

postgres-v3r1/src/access/transam$ ls -g trans*
........ 18556 1991-11-22 09:31 transam.c
........ 19936 1991-11-22 09:31 transsup.c

Jinak na universite v Berkeley se pred Postgres pracovalo na Ingres a tam v dokumenataci z roku 1980 se clovek docte o transakcich. I kdyz zatim moznost sdruzovat bloky prikazu do jedne transakce je tam jen popsano s tim, ze to zatim nejde imlementovat. Kazdopadne je to tam popsano s pouzitim prikazu "BEGIN/END TRANSACTION". Je zajimave, ze PostgreSQL tyto prikazy jako synonyma BEGIN/COMMIT podporuje dodnes.
(zdroj: http://db.cs.berkeley.edu/source.html)

Co se mi podarilo najit tak Oracle podporuje transakce od roku 1982 (v3) -- (zdroj http://www.orafaq.com)

Kazdopadne i Firebird/Interbase/MySQL transakce umi.

Vulgarni pripominky pro vas a vam podobnym obstaraji v teto debate jini i kdyz i ja jich mam par na jazyku....

Dekuji za usetrenou praci. Uz jsem mezi praci a obedem zacinal strachat podklady. Pokud mam hlas, pridavam ho k vasemu:-)

Co se tyce prikazu BEGIN/END transaction, to samo osobne moc neznamena :)
Jinak Oracle je seriozne pouzitelny tak od verze 7.3.4

Ale no tak, projdete si materialy na Berkeley, zdrojove kody atd. PostgreSQL neni nejaka usmudlana SQL, ale je primim naslednikem vyvoje ktery stal u u zrodu vetsiny SQL serveru (druhou vetvi pak byla DB2 a Oracle). Pochopitelene, ze ty transakce mely nejaky vyvoj, ale ta idea jejich funkce je dost stara. Jinak prave v transakcich je PG velmi dobre srovnatelny s libovolnou podobnou DB (vcetne Oracle).

MySQL od verze 4 podporuje transakce naprosto s prehledem. A databazove systemy s RAID 0 jsou v nekterych pripadech velice rozumne reseni, napr. databaze ktera zpracovava stovky dotazu za vterinu, zde uz je vykon naprosta priorita a data se musi zalohovat oddelenym systemem. Az zacnede delat opravdove databaze, tak asi s nekym takovym do styku prijdete :)

No tak nevim, v praci mame v soucasny dobe kolem 18 TB dat v databazi, mam pocit ze to uz se da nazvat opravdovou databazi. Co se tyce zaloh - plna zaloha trva v soucasny dobe kolem 3 tydnu, musis sam uznat ze RAID-0 a doufat ze to nespadne proste nepripada v uvahu. Pokud je neco pomaly tak se na to proste vrhne vic HW (doufam ze si nikdo nemysli ze to bezi na jednom boxu), ale bezpecnost dat se proste kompromitovat neda.

To by me schvalne zajimalo, co provozujete za system a jaky pouzivate nastroj na backup. My mame cca 500GB dat v db, jedeme Informix a full backup mi trva v soucasnosti 20 hodin i s komprimaci = vysledne mam asi 40 GB zaloh... A to mame data na diskovy poli od Comparexu, 7 GB disky.

ja bych rek ze ty cisla vice mene sedej, my mame 36x tolik dat a zalohy nam trvaj zhruba 25x tak dyl, ale je mozny ze dneska uz trvaj dyl, tohle sou udaje tak rok stary. Jede se na Oraclu, ale detaily fakt nevim, ja delam front end. Na backendu zacinam delat az za dva tydny a to jeste budu delat novej na maly casti tech dat, zhruba 200GB co vim. A to pobezi na MSSQL pokud bude po mym (porad to patri do ty kategorie mala databaze a navic tam nebude nic dulezityho jako treba billing) nebo na Oraclu pokud bude podle velkych sefu.