Vzhledem k tomu že všechny souborové systémy se chovají víceméně stejně, tento post se soustředí spíše na popis obecného chování a případně vypíchnutí systémů které nějak vybočují z řady. Máte-li zájem podívat se přímo na výsledky jednotlivých souborových systémů, můžete se podívat přímo na tato srovnání:

• srovnání přes všechny souborové systémy
• srovnání se zapnutými write bariérami
• srovnání s vypnutými write bariérami

Případně se můžete podívat na seznam výsledků a sami si zvolit které souborové systémy srovnat. V tomto článku jsou použity výsledky se zapnutými write bariérami, nicméně jejich vypnutí na chování nic moc nemění (na read-only části to nemá skoro žádný dopad, read-write části jsou vesměs konzistentně rychlejší).

TPC-H část benchmarku měla tyto základní kroky

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)

A tyto kroky jsou postupn rozebrány dále ...

Load dat

Nejdříve se podívejme na load dat, konkrétně na dobu (ve vteřinách) kterou zabralo vložení dat do prostých tabulek (bez indexů, cizích klíčů apod.), prováděné přes COPY z CSV formátu.

Je vidět že hlavní roli hraje velikost bloku souborového systému (4kB bloky dávají cca o 60% vyšší výkon než 1kB bloky), i když na velikosti bloku databáze také závisí (ale rozdíl mezi 1kB a 32kB bloky je jen 15%).

I zde ale platí že pro různé souborové systémy jsou tyto závislosti různě silné - například u XFS nemá velikost bloku souborového systému žádný vliv a závislost na velikosti DB bloku je velmi slabá.

Poměrně výrazné zlepšení je znát mezi souborovými systémy ext3 a ext4, a to pro všechny úrovně žurnálování. Například pro plné žurnálování je situace takováto

Tj. pro 4kB bloky souborového systému je ext4 cca o 10% rychlejší, pro 1kB bloky je rozdíl až 40%. Ještě o něco výraznější je zlepšení v módu "data=ordered"

Tj. rozdíl je cca 20% pro 4kB bloky a 50% pro 1kB bloky. Mód "data=writeback" se chová v podstatě stejně jako "data=ordered", takže tu nebudu zbytečně plýtvat místem.

Z dalších souborových systémů stojí za zmínku JFS, který je až neuvěřitelně rychlý - předstihl dokonce i prostý (nežurnálovací) ext2

Zbývající souborové systémy (btrfs, nilfs2) se víceméně pohybují v rámci průměru.

Cizí klíče a indexy

Stejná situace, t.j. velmi blízké kopírování průměru, platí i pro dobu vytváření cizích klíčů a indexů.

Jednotlivé souborové systémy se liší hlavně v případě malých bloků souborového systému - viz. srovnání. Pro velké bloky souborového systému si asi nejhůře vedl ext3 s "data=journal".

Naopak velmi dobře si v obou úkonech (vytváření indexů i cizích klíčů) vedl souborový systém XFS, který nejen že je velmi rychlý ale výkon v podstatě nezávisí na velikosti bloku souborového systému:

Nyní jsou data připravena (tj. načtena, jsou na nich vytvořeny indexy a cizí klíče) a přichází na řadu sběr statistik (a pak vlastní dotazy).

Sběr statistik

Sběr statistik spočíval v ANALYZE nad kompletní databází, přičemž hodnota default_statistics_target byla zvýšena na 1000. Ani v tomto kroku se výsledky jednotlivých souborových systémů v podstatě  nelišily a pohybovaly se je velmi blízko průměru

Jediný souborový systém který se tomuto průměru vymykal je nilfs2, a to spíše v negativním smyslu

ale jak vidět i zde to platí jenom pro malé bloky souborového systému, pro 4kB bloky se drží průměru.

Skóre

Dříve než se pustím do srovnání výkonu při vyhodnocování dotazů, musím ale vysvětlit jak je definováno skóre a proč je definováno právě takto.

TPC-H benchmark definuje 22 typů dotazů a v rámci tohoto benchmarku byl každý dotaz spuštěn právě jednou. Na první pohled by tedy bylo logické počkat na vyhodnocení všech dotazů a následně například sečíst celkový čas (to je ve výsledcích označeno jako time). Je zde ale několik háčků

• V případě nevhodně zvoleného plánu může dotaz běžet velmi dlouho, což by neúměrně prodloužilo benchmark. Při stanovení časového limitu ale zase není známa doba běhu dotazů které ho překročily a byly zabity (víme jen že běžely déle než timeout).
• Cílem benchmarku je srovnat efektivitu souborových systémů - v důsledku změn velikosti databázových bloků ale dochází ke změně exekučních plánů (v důsledku změny odhadů cen - podrobněji viz. zde). Jeden dotaz tedy může být pro různé velikosti bloků vyhodnocován různě.. Srovnání takových výsledků ale o efektivitě souborových systémů neříká téměř nic.
• Jsou preferovány běhy s rychlým vyhodnocením nejdelších dotazů - uvažujme například dva dotazy, první běh je vyhodnotí za 1s a 50s, druhý za 10s a 40s. To znamená že celkový čas prvního běhu je 51s a druhého 50s, tj. druhý běh je  "rychlejší." Přitom ale při prvním běhu byl první dotaz 10x rychlejší a druhý dotaz jen o 20% pomalejší.

První dva body jsou vyřešeny tak že do skóre jsou vždy započteny jen a pouze dotazy které doběhly pro všechny srovnávané varianty, a pro které byl exekuční plán neměnný. To současně znamená že skóre vždy platí jen pro zvolený seznam souborových systémů - zvolíte-li jiné souborové systémy, bude se skóre lišit.

To lze samozřejmě provést i pro čas - tímto způsobem je odvozován m-time (aka "modified time"), tj. jedná se o součet časů dotazů které doběhly pro všechny zvolené souborové systémy a ve všech srovnávaných bězích byly vyhodnoceny dle stejného exekučního plánu.

Poslední bod je vyřešen zavedením "skóre" které srovnává časy vyhodnocení dotazu oproti nejlepšímu dosaženému času, tj.

minimální_čas_dotazu / čas_dotazu

Nejrychlejší běh tak dostane skóre 1, ostatní běhy získají nepřímo úměrné skóre vyjadřující relativní rychlost oproti tomu nejrychlejšímu.

Příklad - dva běhy, tři dotazy (tučně je vyznačeno minimum pro daný dotaz)

	dotaz č. 1	dotaz č. 2	dotaz č. 3
běh č. 1	10 s	15 s	100 s
běh č. 2	20 s	20 s	75 s

z čehož pro jednotlivé dotazy plynou tato ohodnocení a celkové skóre

	dotaz č. 1	dotaz č. 2	dotaz č. 3	celkové skóre
běh č. 1	10/10 = 1	15/15 = 1	75/100 = 0.75	2.75
běh č. 2	10/20 = 0.5	15/20 = 0.75	75/75 = 1	2.25

Při aplikaci všech tří pravidel je získáno m-score ("modified score"). Je třeba si také uvědomit že toto skóre není absolutní ale je vždy platné jen pro dané srovnání - například pokud srovnáte běhy A a B, získáte jiná skóre než když srovnáte běhy A a C.

Chcete-li srovnávat celkovou dobu běhu, používejte m-time. Pokud chcete lépe zohlednit relativní rychlost pro jednotlivé dotazy, používejte m-score.

m-time a m-score

Průměrné hodnoty m-time a m-score jsou takovéto

V obou případech je výkon zřetelně vyšší s velkými databázovými bloky. Mezi jednotlivými souborovými systémy nejsou výrazné rozdíly.

Stejně jako v případě loadu dat podává ext4 znatelně lepší výsledky než ext3 - například pro "data=journal" platí (všímejte si zejména menších bloků souborového systému):

Velmi dobrý výkon standardně podává XFS, konzistentní přes všechny velikosti bloků

Bohužel stejně jako analýzy vybočuje negativním směrem nilfs2

Závěr

Z výše uvedeného je zřejmé že

• Stejně jako u OLTP zátěže je evidentní že nemá smysl používat malé velikosti bloku souborového systému - blok 4kB nemusí nutně znamenat lepší výkon (např. u XFS), nikdy ale výkon nesnižuje.
• Závislost na velikosti databázového bloku je jasná - čím větší tím lepší, nejlepšího výkonu (a je jedno zda uvažujeme skóre nebo čas) je dosahováno pro 32kB bloky. Pokles výkonu při zmenšování bloků je víceméně postupný.
• Pokdu bych měl vybrat vítěze, byl by jím XFS - nejen že je v podstatě ve všech případech výrazně rychlejší než průměr, ale hlavně si udržuje vyrovnaný výkon pro bloky od 8kB do 32kB což ulehčuje situaci při kombinovaném workloadu.