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

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ů

8.5.2016 17:19 /Redakce Linuxsoft.cz
PR: Dne 26.5.2016 proběhne v Praze konference Cloud computing v praxi. Tématy bude např. nejnovější trendy v oblasti cloudu a cloudových řešení, cloudové služby, infrastruktura cloudu, efektivní využití cloudu, možné nástrahy cloudů a jak se jim vyhnout
Přidat komentář

21.4.2016 8:01 /František Kučera
Spolek OpenAlt zve na 127. distribuovaný sraz příznivců svobodného softwaru a otevřených technologií (hardware, 3D tisk, SDR, DIY, makers…), který se bude konat ve čtvrtek 28. dubna od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

2.3.2016 22:41 /Ondřej Čečák
Letošní ročník konference InstallFest již tento víkend!
Přidat komentář

14.2.2016 16:39 /Redakce Linuxsoft.cz
O víkendu 5. a 6. března 2016 proběhne na pražském Strahově 8. ročník tradiční konference InstallFest. Celkem za dva dny uvidíte ​30 přednášek​ a ​6 workshopů.
Přidat komentář

5.2.2016 17:38 /Petr Ježek
Utilitka z XFce "xfce4-power-manager" nejen umožňuje nastavení lhůty pro uspání či hybernaci, ale i zapínání a vypínání prezentačního módu pro nerušené sledování videí. Stačí ji nastavit v každém vybavenějším panelu a v jakémkoli nontiled WM/DE.
Přidat komentář

10.1.2016 11:32 /Pavel `Goldenfish' Kysilka
LinuxMarket změnil provozovatele. Nově jej provozuje Marek Pszczolka. Více info a detaily #1 a #2.
Přidat komentář

29.12.2015 11:38 /Ondřej Čečák
Ještě posledních pár dní můžete přidávat příspěvky nebo nápady na Install Fest 2016, který se bude konat 5. a 6. března 2016.
Přidat komentář

8.12.2015 11:36 /Petr Ježek
Logické se stává realitou. LibreOffice a Thunderbird se mají dle článku na Redditu stát protiváhou MS řešení (MS Office a Outlook).
Přidat komentář

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

> Poslední diskuze

7.5.2016 14:58 / Teodor Komárek
Soubory

20.4.2016 0:07 / Jakub Cleing
Sázkový panel PHP FUSION

9.4.2016 9:43 / jiwopene@gmail.com
Re: problém s dpkg a nemožností instalovat

9.4.2016 9:41 / jiwopene@gmail.com
Re: změna velikosti disk.oddílu

9.4.2016 9:40 / jiwopene@gmail.com
Re: Přenesení starého OS Win7 na virtuál v Debianu

Více ...

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