Stejně jako u článku o výsledcích TPC-H benchmarku na standardním disku se podívejme postupně na jednotlivé kroky TPC-H benchmarku, tj.

1. load dat do tabulek
2. vytvoření cizích klíčů a indexů
3. sběr statistik (ANALYZE s default_statistics_target=1000)
4. dotazy (22 dotazů definovaných TPC-H benchmarkem)

přičemž na srovnání srovnání výsledků se detailně můžete podívat tady.

Load dat

I u loadu dat na první pohled platí cca 1.5-násobné zvýšení výkonu oproti tradičním diskům

a je zřejmá i závislost výkonu na velikosti bloků - u bloků souborového systému i databáze platí "čím větší tím lepší." Obdobná je i situace i u různých módů souborového systému ext4 - ordered i writeback podávají totožný výkon (pro stručnost uvádím jen ordered)

ale u módu journal již přichází poměrně znatelný pokles výkonu

Souborový systém XFS opět podává velmi dobrý výkon, zhruba stejný jako ext4-writeback.

Indexy a cizí klíče

I u vytváření indexů a cizích klíčů je zřetelné zrychlení - jestliže s tradičním 7.2k diskem trvalo vytvoření indexů 60 až 76 vteřin (se 4kB bloky souborového systému), u SSD stačí 46 až 59 vteřin

Vytváření cizích klíčů trvalo na tradičním disku cca 44 až 66 vteřin, na SSD stačí jen 24 až 66 vteřin (tj. pro velké bloky je zrychlení nejvýraznější).

Sběr statistik

Obdobně pro sběr statistik - na tradičním disku 70 až 80 vteřin, na SSD stačí 60 až 70 vteřin.

Dotazy

Výsledky hlavní části benchmarku, tj. vyhodnocování SQL dotazů jsou velmi vyrovnané - omezíme-li se na 4kB bloky souborového systému, všechny souborové systémy podávají víceméně totožný výkon. Například u XFS je situace takováto

Je patrná nulová závislost na velikosti bloků souborového systému a cca o 30% vyšší výkon při 32kB databázových blocích oproti 1kB blokům.

V případě některých souborových systémů (ext4-journal, nilfs2) velikost bloků souborových systémů roli hraje, a malé bloky podávají výrazně horší výkon.

Poznámka: Pokud vás zarazilo že tento obrázek uvádí jiná čísla než obrázek na začátku článku (ačkoliv jsou oba označeny jako m-time pro XFS), jedná se o důsledek konstrukce m-time. Zatímco úvodní obrázek platí pro kompletní výsledky (SSD i HDD dohromady), takže množiny zahrnutých dotazů nejsou totožné. Podrobnosti o definici m-time najdete v tomto článku.

Závěry

Tato sekce může být poněkud zavádějící - uvědomil jsem si to díky komentáři Joshe Berkuse u anglické verze článku, Podrobnější vysvětlení najdete na konci článku.

Výkon v tomto TPC-H benchmarku je ovlivněn primárně rychlostí sekvenčních operací, které ale nepatří k přednostem SSD disků a s tradičními disky lze srovnatelného výkonu dosáhnout s nižšími náklady.

Například u 7.2k SATA disků se rychlost zápisu pohybuje okolo 80 MB/s, zatímco u testovaného SSD disku byla rychlost sekvenčního zápisu cca 130 MB/s. To je sice výrazný rozdíl ve výkonu, nicméně zdaleka ne tak výrazný jako u náhodných operací a rozhodně neodpovídá cenovému rozdílu. Za testovanou 120GB verzi SSD zaplatíte 3x tolik co za 7.2k disk s kapacitou 1TB.

Spojením 3 disků do RAID 0 pole (tj. cena se vyrovná SSD disku) získáte zhruba 3x vyšší sekvenční výkon, tj. téměř 2x tolik co poskytuje SSD.

Žádná databázová zátěž ale není čistě sekvenční nebo čistě náhodná - jedná se o kombinaci obou. Dá se očekávat že tradiční DSS/DWH zátěže budou využívat spíše sekvenční operace, nicméně nemusí to být pravda a například u operačních datových skladů (používáných pro BI) lze očekávat i nemalý objem náhodných operací. Ostatně i join tabulek může používat nested loop s vnořeným index scanem, tj. vyloženě náhodný přístup.

Každopádně je zřejmé že přínos SSD pro DWH databáze je znatelně nižší než u OLTP databází.

Poznámka: Primárním cílem tohoto benchmarku bylo srovnání různých souborových systémů, nikoliv SSD vs HDD, a to je třeba mít při interpretaci výsledků na mysli. V případě výsledků pgbenche to není problém, protože spouštěné dotazy jsou celkem jednoduché. Dotazy definované v TPC-H jsou celkem komplexní, a při změně velikosti bloku (a random_page_cost) se exekuční plán může výrazně změnit. Ale pokud chcete srovnat výkon souborových systémů, je třeba používat stejnou zátěž, jinak by to bylo srovnávání jablek s hruškami. A to je přesně důvod proč jsem m-time a m-score (zde) definoval pouze na základě dotazů které ve všech případech používaly stejný exekuční plán.

Takových dotazů je pouze 6 (z 22 definovaných v TPC-H), a shodou okolností se jedná o dotazy které provádí většinou sekvenční operace a jen málo náhodných I/O operací.

Takže tvrzení že "výkon TPC-H benchmarku je ovlivněn primárně rychlostí sekvenčních operací" je mylné (některé z dotazů totiž skutečně provádí hodně náhodných I/O operací). Ale část použitá pro srovnání je spíše sekvenční, takže závěr pro sekvenční zátěž nejsou SSD žádnou výhodou stále platí. Což mimo jiné znamená že byste měli pečlivě analyzovat zátěž, a pokud není dostatečně "náhodná" tak vám SSD nic moc nepřinesou.

Je tu ale ještě jeden háček - musíte uvažovat i indexy které by sice se SSD fungovaly dobře, ale s tradičním HDD by byly neefektivní (takže jste je nejspíše ani nevytvořili). To znamená že musíte nejen analyzovat stávající zátěž, ale musíte pečlivě revidovat indexy a možná i vytvořit nějaké nové.