LINUXSOFT.cz Přeskoč levou lištu
Uživatel: Heslo:  
   CZUKPL

> 100MB TPC-B test databází

Podíváme se jak obstály testované databáze na TPC-B datasetu se scale faktorem 10.

4.11.2010 00:00 | Radim Kolář | Články autora | přečteno 5216×

100MB TPC-B test

Tento test není vlastně TPC-B (protože nejsou splněny jeho podmínky na škálovatelnost) ale TPS test. Tedy pouhý počet transakcí za sekundu. Pravidla jsou jednoduchá - připravíme si TPC-B dataset se scale faktorem 10 (100MB dat, 1M záznamů) a budeme 2 minuty provádět TPC-B transaction profile ve 4 vláknech současně. Pak vyhodnotíme průměrný počet transakcí za sekundu. Databáze dostanou dostatek paměti na to aby udrželi celý dataset včetně indexů v buffer cache.

Protože TPC-B vyžaduje ACID kompatibilní databázi tak během ukončením transakce pomocí COMMIT musí dojít k zapsání dat na disk předtím než je uživatelskému programu vráceno oznámení o úspěšném dokončení transakce. Pokud dojde k havárii databáze, operačního systému nebo paměti tak musí být k dispozici data změněná touto transakcí - nesmí se nic ztratit.

Podle typu databáze se změněné hodnoty mohou zapsat přímo do datových a indexových souborů nebo se zapíší jen do log souboru aby byly k dispozici údaje pro obnovu databáze po havárii. Metoda s log souborem je v současné době nejpoužívanější, protože je potřeba méně diskových operací. Za ideálních podmínek totiž zapisujeme do log souboru sekvenčně (tedy u mechanických disků velmi rychle). Jelikož je rychlost zápisu do logu pro transakční výkon kritická tak bývají log soubory umisťovány na RAID 0 diskové pole. Log soubory se také musí chránit před poškozením z důvodu výpadku disku a tak se buďto zrcadlí pomocí RAID 1 na úrovní HW/OS nebo se zrcadlí pomocí SW prostředků databáze. Bez nepoškozených log souborů totiž nelze poslední transakce v databázi obnovit.

Datové soubory aktualizujeme jen čas od času pokud vyčerpáme databázové buffery nebo při checkpointech kdy zapíšeme všechny zbývající data do datových a indexových souborů a do logu si poznačíme že máme všechno úspěšně zapsáno. Checkpointy urychlují obnovu databáze po havárii protože nemusíme procházet celý log soubor a zapisovat v něm uložená data do příslušných souborů. Stačí nám projít záznamy od posledního checkpointu. Protože zápis všech dat při checkpointu na disk trvá delší dobu byly vymyšleny algoritmy jak dosáhnout podobného efektu bez nutnosti při checkpointech ukládat všechna změněná data. Nejznámějším tímto algoritmem je ARIES (patentovaná technologie) který se používá v produktech firmy IBM - DB2, Lotus Notes, IMS, Websphere MQ, Apache Derby.

V našem prvním testu tedy jde o to jak rychle a efektivně dokážeme zapisovat data do transakčního logu a jak často (v ideálním případě vůbec) budeme muset zapisovat data a indexy. Jelikož máme pro test dostatek RAM tak číst z disku nebudeme muset nikdy a čím s větším zpožděním dokážeme zapisovat datové stránky tím lépe.

Naprosto ideálního výkonu bychom dosáhli tím, že data budeme zapisovat jen do logu protože sekvenční zápis je velmi rychlý. Toto umí velice dobře dělat takzvané in memory database, které jsou optimalizovány pro práci s datasety které jsou tak velké, že se dají načíst kompletně do paměti RAM. Žádnou takovou databázi sice v testu nemáme, ale obvykle tyto databáze dosahují až desetinásobné rychlosti oproti klasickým databázím.

Commit Groups

Další metoda pro zrychlení transakcí se nazývá commit groups. Jelikož nejpomalejší částí zakončení transakce je čekání než relativně pomalý disk zapíše data do logu, vyplatí se při zakončování transakce chvilku počkat jestli náhodou některá z ostatních právě prováděných transakcí také neskončí a pak zapsat jednou diskovou operací na disk obě dvě transakce.

Když jsem se o této metodě dozvěděl byl jsem z ní dost nadšen protože jsem předpokládal že povede k razantnímu nárůstu výkonu. Když místo jedné transakce zapíšeme na disk dvě tak by se měl odpovídajícím způsobem zvednout i celkový výkon. Bohužel v praxi to takto růžově nevypadá. U databáze PostgreSQL jsem manipulováním konfigurace s touto feature spojenou nebyl schopen dosáhnout žádného měřitelného výsledku který by byl větší než odchylka při měření.

U DB2 jsem měřitelného zlepšení sice dosáhl, ale zlepšení bylo jak dále uvidíte jen pár procent. V literatuře jak ladit výkon u DB2 se zmiňují, že nechat databázi zapisovat dvě transakce najednou je z hlediska výkonu bezpečné - výkon by to nemělo oproti normálnímu stavu snížit. Nárůst výkonu je ale relativně malý, ve všech případech co jsem viděl to bylo pod deset procent. Pokud necháme DB2 zapisovat na disk 3 transakce najednou tak tam se nám již může v závislosti na zátěži stát, že o větší výkon přijdeme čekáním na dokončení ostatních transakcí než získáme ušetřením io operací při zápisu na disk. Pokud má totiž databáze dobře soubory rozvržené a na log je použita odlišná skupina disků od dat (což je základní poučka pro ladění výkonu databází), tak zápis do logu bude sekvenční a tudíž velmi rychlý. Na log zařízení se proto nepoužívají ani v high end systémech SSD disky, jak se můžeme přesvědčit z prvních dvou výsledků v TPC-C. Literatura nedoporučuje nechávat databázi zapisovat 4 či více transakcí najednou, tam k propadu výkonu dochází vždy.

Výsledky

DatabázePostgresql 8.3DB2 9.7MySQL 5.0Oracle 10R2Derby 10.3Derby 10.6
46523041096121022855
51123521145721125919
54623631175941341875
46924351056001212
50823631155641192
Medián50823631145941192875

Jak vidíme tak v testu vyhrála s velkým náskokem DB2 následovaná Apache Derby. Obě dvě databáze používají algoritmus ARIES pro zápis do transakčního logu a nemusí tudíž dělat checkpointy, což jim přineslo výraznou rychlostní výhodu z důvodu ušetření diskových operací oproti klasickým databázím PostgreSQL a Oracle. MySQL podle očekávání naprosto propadlo.

U DB2 bylo použito automatického nastavení pomocí STMM (self tuning memory manager); databáze se dokáže do zhruba 20 minut optimálně nastavit pro aktuální zátěž bez nutnosti zásahu db administrátora. To je velký plus, protože už prakticky nikdy nebudete muset ladit výkon databáze jinak než vytvářením chybějících indexů. Z DB2 můžeme vyrazit ještě drobné zrychlení pokud použijeme commit group o velikosti 2. Výsledky pak budou 2451, 2424, 2422, 2433, 2372. Použitím commit group 3 jsem dostal zhruba stejná čísla jako u základního nastavení. Výkon se tedy mírně snížil.

Zajímavé je srovnání PostgreSQL a Oracle u disk io bound testu. Zatímco když jsme testovali čas potřebný k vytvoření databáze kde záleželo především na efektivní práci s cache pamětí a spotřebě CPU času a Oracle byl více než 4x rychlejší tak zde vidíme že Oracle není zase o tak moc lépe zoptimalizován pokud je zátěž io bound. Pomalejší čas PostgreSQL lze vysvětlit prováděním VACUUM na pozadí.

Člověk by za ty peníze za Oracle licenci čekal výrazně lepší výsledek jako například měla DB2, která byla více než 4x rychlejší než PostgreSQL. Souboj Oracle vs Postgres je zajímavý zejména z důvodu, že u PostgreSQL si za cenu ušetřených databázových licencí můžeme pořídit výrazně lepší hardware. Pokud používáme relační databázi jen jako backend k hibernate tak můžeme Oracle Postgresem bez problémů nahradit, ačkoliv si pak musíme zvyknout na výrazně horší administrativní nástroje.

Databáze Apache Derby nedopadla špatně. Na jedné straně je ve výhodě protože JDBC driver nemusí s databází komunikovat přes TCP/IP, volá totiž přímo příslušnou proceduru v db. V nevýhodě je Derby tím, že není optimalizováno pro rychlost jako H2 databáze. Nejpoužívanější řadou Derby je 10.3 a z výsledku testu můžeme vidět proč - je dobře odladěná a rychlá.

Verze pro tisk

pridej.cz

 

DISKUZE

VACUUM 4.11.2010 08:37 Tomáš 'Heron' Crhonek
  |- konfigurace db 4.11.2010 09:44 Radim Kolář
  L Re: VACUUM 4.11.2010 10:36 Radim Kolář




Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků

13.9.2017 8:00 /František Kučera

Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt – tentokrát netradičně v pondělí: 18. září od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).


Přidat komentář

3.9.2017 20:45 /Redakce Linuxsoft.cz
PR: Dne 21. září 2017 proběhne v Praze konference "Mobilní řešení pro business". Hlavní tématy konference budou: nejnovější trendy v oblasti mobilních řešení pro firmy, efektivní využití mobilních zařízení, bezpečnostní rizika a řešení pro jejich omezení, správa mobilních zařízení ve firmách a další.
Přidat komentář

15.5.2017 23:50 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt, který se bude konat ve čtvrtek 18. května od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

12.5.2017 16:42 /Honza Javorek
PyCon CZ, česká konference o programovacím jazyce Python, se po dvou úspěšných ročnících v Brně bude letos konat v Praze, a to 8. až 10. června. Na konferenci letos zavítá např. i Armin Ronacher, známý především jako autor frameworku Flask, šablon Jinja2/Twig, a dalších projektů. Těšit se můžete na přednášky o datové analytice, tvorbě webu, testování, tvorbě API, učení a mentorování programování, přednášky o rozvoji komunity, o použití Pythonu ve vědě nebo k ovládání nejrůznějších zařízení (MicroPython). Na vlastní prsty si můžete na workshopech vyzkoušet postavit Pythonem ovládaného robota, naučit se učit šestileté děti programovat, efektivně testovat nebo si v Pythonu pohrát s kartografickým materiálem. Kupujte lístky, dokud jsou.
Přidat komentář

2.5.2017 9:20 /Eva Rázgová
Putovní konference československé Drupal komunity "DrupalCamp Československo" se tentokrát koná 27. 5.2017 na VUT FIT v Brně. Můžete načerpat a vyměnit si zkušenosti z oblasti Drupalu 7 a 8, UX, SEO, managementu týmového vývoje, využití Dockeru pro Drupal a dalších. Vítáni jsou nováčci i experti. Akci pořádají Slovenská Drupal Asociácia a česká Asociace pro Drupal. Registrace na webu .
Přidat komentář

1.5.2017 20:31 /Pavel `Goldenfish' Kysilka
PR: 25.5.2017 proběhne v Praze konference na téma Firemní informační systémy. Hlavními tématy jsou: Informační systémy s vlastní inteligencí, efektivní práce s dokumenty, mobilní přístup k datům nebo využívání cloudu.
Přidat komentář

15.4.2017 15:20 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě IoT a radiokomunikace? Přijď na sraz spolku OpenAlt, který se bude konat ve středu 19. dubna od 18:30 v Šenkovně (Sokolská 60, Praha 2).
Přidat komentář

5.3.2017 19:12 /Redakce Linuxsoft.cz
PR: 23. března proběhne v Praze konferenci na téma Cloud computing v praxi. Hlavními tématy jsou: Nejžhavější trendy v oblasti cloudu a cloudových řešení, Moderní cloudové služby, Infrastruktura současných cloudů, Efektivní využití cloudu, Nástrahy cloudových řešení a jak se jim vyhnout.
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

18.9.2017 14:37 / Rojas
high security vault

15.9.2017 7:33 / Wilson
new zealand childcare jobs

31.8.2017 12:11 / Jaromir Obr
Re: ukůládání dat ze souboru

30.7.2017 11:12 / Jaromir Obr
Národní znaky

27.7.2017 12:24 / Jaromir Obr
Cteni/zapis

Více ...

ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2017) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze