LINUXSOFT.cz Přeskoč levou lištu

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

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ů

28.11.2018 23:56 /František Kučera
Prosincový sraz spolku OpenAlt se koná ve středu 5.12.2018 od 16:00 na adrese Zikova 1903/4, Praha 6. Tentokrát navštívíme organizaci CESNET. Na programu jsou dvě přednášky: Distribuované úložiště Ceph (Michal Strnad) a Plně šifrovaný disk na moderním systému (Ondřej Caletka). Následně se přesuneme do některé z nedalekých restaurací, kde budeme pokračovat v diskusi.
Komentářů: 1

12.11.2018 21:28 /Redakce Linuxsoft.cz
22. listopadu 2018 se koná v Praze na Karlově náměstí již pátý ročník konference s tématem Datová centra pro business, která nabídne odpovědi na aktuální a často řešené otázky: Jaké jsou aktuální trendy v oblasti datových center a jak je optimálně využít pro vlastní prospěch? Jak si zajistit odpovídající služby datových center? Podle jakých kritérií vybírat dodavatele služeb? Jak volit vhodné součásti infrastruktury při budování či rozšiřování vlastního datového centra? Jak efektivně datové centrum spravovat? Jak co nejlépe eliminovat možná rizika? apod. Příznivci LinuxSoftu mohou při registraci uplatnit kód LIN350, který jim přinese zvýhodněné vstupné s 50% slevou.
Přidat komentář

6.11.2018 2:04 /František Kučera
Říjnový pražský sraz spolku OpenAlt se koná v listopadu – již tento čtvrtek – 8. 11. 2018 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tentokrát bez oficiální přednášky, ale zato s dobrým jídlem a pivem – volná diskuse na téma umění a technologie, IoT, CNC, svobodný software, hardware a další hračky.
Přidat komentář

4.10.2018 21:30 /Ondřej Čečák
LinuxDays 2018 již tento víkend, registrace je otevřená.
Přidat komentář

18.9.2018 23:30 /František Kučera
Zářijový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 20. 9. 2018 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tentokrát bez oficiální přednášky, ale zato s dobrým jídlem a pivem – volná diskuse na téma IoT, CNC, svobodný software, hardware a další hračky.
Přidat komentář

9.9.2018 14:15 /Redakce Linuxsoft.cz
20.9.2018 proběhne v pražském Kongresovém centru Vavruška konference Mobilní řešení pro business. Návštěvníci si vyslechnou mimo jiné přednášky na témata: Nejdůležitější aktuální trendy v oblasti mobilních technologií, správa a zabezpečení mobilních zařízení ve firmách, jak mobilně přistupovat k informačnímu systému firmy, kdy se vyplatí používat odolná mobilní zařízení nebo jak zabezpečit mobilní komunikaci.
Přidat komentář

12.8.2018 16:58 /František Kučera
Srpnový pražský sraz spolku OpenAlt se koná ve čtvrtek – 16. 8. 2018 od 19:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát jsou tématem srazu databáze prezentaci svého projektu si pro nás připravil Standa Dzik. Dále bude prostor, abychom probrali nápady na využití IoT a sítě The Things Network, případně další témata.
Přidat komentář

16.7.2018 1:05 /František Kučera
Červencový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 19. 7. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát bude přednáška na téma: automatizační nástroj Ansible, kterou si připravil Martin Vicián.
Přidat komentář

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

> Poslední diskuze

31.7.2023 14:13 / Linda Graham
iPhone Services

30.11.2022 9:32 / Kyle McDermott
Hosting download unavailable

13.12.2018 10:57 / Jan Mareš
Re: zavináč

2.12.2018 23:56 / František Kučera
Sraz

5.10.2018 17:12 / Jakub Kuljovsky
Re: Jaký kurz a software by jste doporučili pro začínajcího kodéra?

Více ...

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