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

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ů

23.5.2018 20:55 /Ondřej Čečák
Od pátku 25.5. proběhne na Fakultě informačních technologií ČVUT v Praze openSUSE Conference. Můžete se těšit na spostu zajímavých přednášek, workshopů a také na Release Party nového openSUSE leap 15.0. V na stejném místě proběhne v sobotu 26.5. i seminář o bezpečnosti CryptoFest.
Přidat komentář

20.5.2018 17:45 /Redakce Linuxsoft.cz
Ve čtvrtek 31. května 2018 připravuje webový magazín BusinessIT ve spolupráci s Best Online Média s.r.o. pátý ročník odborné konference Firemní informační systémy 2018. Akce proběhne v kongresovém centru Vavruška (palác Charitas), Karlovo náměstí 5, Praha 2 (u metra Karlovo náměstí) od 9:00 hod. dopoledne do cca 15 hod. odpoledne. Konference je zaměřena na efektivní využití firemních informačních systémů a na to, jak plně využít jejich potenciál. Podrobnější informace na webových stránkách konfrence.
Přidat komentář

14.5.2018 7:28 /František Kučera
Květnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 17. 5. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát na téma: Audio – zvuk v GNU/Linuxu.
Přidat komentář

7.5.2018 16:20 /František Kučera
Na stránkách spolku OpenAlt vyšla fotoreportáž Pražské srazy 2017 dokumentující srazy za uplynulý rok. Květnový pražský sraz na téma audio se bude konat 17. 5. 2018 (místo a čas ještě upřesníme).
Přidat komentář

17.4.2018 0:46 /František Kučera
Dubnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 19. 4. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tématem tohoto srazu bude OpenStreetMap (OSM) aneb svobodné mapy.
Přidat komentář

16.3.2018 22:01 /František Kučera
Kulatý OpenAlt sraz v Praze oslavíme klasicky: u limonády a piva! Přijďte si posedět, dát si dobré jídlo a vybrat z mnoha piv do restaurace Kulový blesk, který najdete v centru Prahy nedaleko metra I. P. Pavlova na adrese Sokolská 13, Praha 2. Sraz se koná ve čtvrtek 22. března a začínáme v 18:00. Heslo: OpenAlt. Vezměte s sebou svoje hračky! Uvítáme, když si s sebou na sraz vezmete svoje oblíbené hračky. Jestli máte nějaký drobný projekt postavený na Arduinu, nějakou zajímavou elektronickou součástku, či třeba i pěkný úlovek z crowdfundingové akce, neváhejte. Oslníte ostatní a o zábavu bude postaráno.
Přidat komentář

13.2.2018 0:41 /František Kučera
Únorový pražský sraz OpenAltu se koná 15. 2. 2018 a tentokrát se vydáme na návštěvu do jednoho pražského datacentra. Sejdeme se v 17:50 v severovýchodní části nástupiště tramvajové zastávky Koh-I-Noor. Po exkurzi se přesuneme do restaurace U Pštrosa (Moskevská 49), kde probereme tradiční témata (svobodný software a hardware, DIY, CNC, SDR, 3D tisk…) a tentokrát bude k vidění i IoT brána od The Things Network.
Přidat komentář

11.2.2018 23:11 /Petr Ježek
Hledáte lehký a rychlý prolížeč PDF souborů? Pokud vás již omrzelo čekat na načítání stránek či jiné nešvary, zkuste xreader.
Přidat komentář

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

> Poslední diskuze

20.2.2018 18:48 / Ivan Majer
portal

20.2.2018 15:57 / Jan Havel
Jak využíváte služby cloudu v podnikání?

16.1.2018 1:08 / Ivan Pittner
verejna ip od o2 ubuntu

15.1.2018 17:26 / Mira Harvalik
Re: Jak udělat HTML/Javascript swiping gallery do mobilu?

30.12.2017 20:16 / Michal Knoll
odmocnina

Více ...

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