ARCHIV

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 7242×

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áze	Postgresql 8.3	DB2 9.7	MySQL 5.0	Oracle 10R2	Derby 10.3	Derby 10.6
	465	2304	109	612	1022	855
	511	2352	114	572	1125	919
	546	2363	117	594	1341	875
	469	2435	105	600	1212
	508	2363	115	564	1192
Medián	508	2363	114	594	1192	875

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

DISKUZE VACUUM 4.11.2010 08:37 Tomáš 'Heron' Crhonek   konfigurace db 4.11.2010 09:44 Radim Kolář   Re: VACUUM 4.11.2010 10:36 Radim Kolář Zobrazit označené Zobrazit vše Příspívat do diskuze mohou pouze registrovaní uživatelé.