Proč vytvářet terabajtovou databázi Firebird?

Mnoho společností pracuje s velkými databázemi Firebird a spoléhá na ně při podpoře důležitých obchodních operací. Některé databáze Firebird mají již stovky gigabajtů a stále rostou (viz část „Kdo je velký?“), a je snadné předpovědět okamžik, kdy budou 2, 3 nebo 5krát větší. Správci databází a dodavatelé mají proto zájem prozkoumat chování Firebirdu u velkých databází a získat doporučení, jak je spravovat.

Dalším důležitým důvodem, který jsme měli na mysli při vytváření 1Tb databáze Firebird, bylo konečné odstranění rozšířeného vnímání Firebirdu jako databázového enginu pro „malé databáze“. Tento mýtus se zdá být nyní mrtvý, ale někteří analytici a novináři ho pravidelně vzkřísí z hrobu, a doufáme, že s tímto směšným vnímáním konečně skoncujeme.


## Hardware

Firebird je známý svou neuvěřitelnou škálovatelností a tento výzkum to opět potvrdil. Původním účelem tohoto experimentu bylo pouze vytvoření databáze Firebird o velikosti 1Tb, takže jsme použili běžný stolní počítač:

Tabulka 1: Hardware


Komponenta	Parametry
CPU	AMDAthlon 64 x2 5200
RAM	4GB
Základní deska	MSI K9N Platinum
HDD1 (operační systém a temp)	ST3160815AS, 160GB, SATA II
HDD2 (pomocný)	HDT721064SLA360, 640GB, SATAII
HDD2 (pomocný)	HDS728080PLA380, 80GB, SATA I
HDD3 (databáze)	ST31500341AS, 1.5TB, SATA II (Firmware CC1H)

V podstatě jsme vložili 1.5Tb HDD do jednoho z našich kancelářských stolních počítačů, bez jakýchkoli dalších úprav. Tento HDD byl naformátován s velikostí clusteru 16Kb (stejnou jako velikost stránky databáze, jak můžete vidět níže).

Software

Jelikož se jedná o stolní počítač, operační systém je Windows XP Professional SP3, 32bit. K samotnému testu jsme použili loader z nástroje založeného na TPC (stáhněte si ho z http://ibdeveloper.com/tests/tpc-c/, k dispozici jsou binárky i zdrojové kódy).

Rádi bychom zdůraznili, že loader vkládá data tak, jak by byla vkládána v reálném scénáři: záznamy jsou vkládány a umísťovány uvnitř databáze (a na fyzických oblastech disku) do několika tabulek master-detail-subdetail, ne tabulku po tabulce.

Tabulka 2: Software


Software	Verze
Operační systém	Windows XP Professional SP3, 32bit
Firebird	2.1.3 SuperServer (snapshot)
Loader	Vlastní loader z testu založeného na tpc

Plán

Měli jsme velmi přímočarý plán pro tento experiment:

Vytvořit databázi a naplnit ji 1Tb daty, bez indexů
Vytvořit primární klíče a odpovídající indexy (takže skutečná velikost databáze je více než 1Tb)
Shromáždit statistiky databáze
Spustit několik SQL dotazů a odhadnout výkon databáze

Konfigurace databáze a serveru Firebird

Databáze má velikost stránky 16384 bajtů, stejnou jako cluster HDD, aby se maximalizoval výkon disku (čtení/zápis 1 stránky v jednom I/O cyklu).

V konfiguraci Firebirdu jsme nakonfigurovali další adresář pro dočasný prostor a nasměrovali ho na disk s 640Gb (kde bylo volných ~300Gb).

Krok načítání

Data byla do této databáze načítána v několika krocích. Počítač byl během načítání používán jako běžný stolní počítač (máme MS Office, Firefox, IBAnalyst atd. - současně běželo asi 8-12 programů). Pokud bychom hardware věnovali pouze tomuto úkolu, pravděpodobně by to bylo rychlejší, takže tyto hodnoty berte prosím pouze jako příklad nízké úrovně; rozhodně to nejsou špičkové výsledky.

Tabulka 3: Načítací operace

| |


Popis	Hodnota
Čas načítání	~70 hodin
Celkem vložených záznamů	6,2 miliardy
Průměrná rychlost vkládání	24500 záznamů/sekundu
Průměrná velikost záznamu	146 bajtů (min 13 bajtů, max - 600 bajtů)
Transakce	646489

Strávili jsme ~4 dny načítáním a poté jsme měli databázi Firebird o přesné velikosti 1Tb (tj. 1 099 900 125 184 bajtů).

Níže můžete vidět růst databáze a dynamiku transakcí v prohlížeči FBDataGuard:

Indexy

Vytvořili jsme indexy jeden po druhém a zaznamenali čas jejich vytvoření a odpovídající velikost dočasného souboru použitého pro třídění.

Největší index byl vytvořen pro tabulku ORDER_LINE. Její primární klíč obsahuje čtyři pole (Smallint, Smallint, Integer a Smallint). Dočasný soubor pro tento třídicí index byl 182Gb a konečná velikost indexu v databázi je 29.3Gb.

Je zajímavé vidět, že i index pro tabulku s 3,8 miliardami záznamů má hloubku = 3, protože velikost stránky byla 16384 bajtů, takže při vyhledávání dat pomocí primárního klíče pro tuto tabulku nevzniká žádná režie.

Statistiky

Poté jsme shromáždili statistiky databáze. Trvalo to 7 hodin 32 minut 45 sekund.

Klíčové statistické informace jsme vložili do jedné tabulky a zahrnuli některé dotazy a měření času:

Tabulka 4: Konsolidované statistiky pro 1Tb databázi


Název tabulky	Počet záznamů	Velikost, gb	*Doba provádění select count()**	Doba vytvoření indexu	Velikost tmp souboru, Gb	Velikost indexu, Gb
WAREHOUSE	1240	0.002	0s	0	0	0.0
ITEM	100000	0.012	0.7s	-	-	0.0
DISTRICT	124000	0.017	0.7s	6	-	0.0
NEW_ORDER	111600000	32	20m 00s	23m 00s	4.56	0.8
CUSTOMER	372000000	224	-	41m 00s	-	2.6
customer_last				1h 52m 32s	12.4	2.3
fk_cust_ware				2h 10m 51s	-	2.3
HISTORY	372000000	32	-	-	-	-
ORDERS	372000000	25	32m 00s	45m 41s	15.2	2.5
STOCK	1240000000	404	-	3h 34m 44s	41.5	9.2
ORDER_LINE	3720051796	359	-	12h 6m 18s	182.0	29.3

Statistiky databáze si můžete stáhnout zde.

K interpretaci textových dat a zobrazení nejen metrik výkonu databáze, ale také spotřeby CPU a paměti můžete použít bezplatný prohlížeč FBDataGuard Community Edition.

Dotazy

Nejprve jsme spustili dotazy select count(*) na několika tabulkách (viz 4. sloupec v tabulce 4 výše). Jak víte, kvůli multi-verzní povaze Firebirdu je select count(*) pro celou tabulku nákladnou operací pro server, protože vyžaduje návštěvu každé stránky, a zkušení vývojáři Firebirdu select count(*) nepoužívají, ale my jsme ho použili k demonstraci celkového výkonnostního poměru databáze a hardwaru.

Po dotazech select count jsme spustili dotazy z reálného scénáře a, abychom byli upřímní, byli jsme ohromeni tak dobrými výsledky. Posuďte sami:


Dotaz	Statistiky	Popis
select w_id, w_name, c_id, c_last from WAREHOUSE, customer where c_w_id = w_id	PLAN JOIN (WAREHOUSE NATURAL, CUSTOMER INDEX (FK_CUST_WARE)) ------ Informace o výkonu —— Čas přípravy = 15ms Čas provedení = 79ms Průměrný čas načítání = 6.08 ms Aktuální paměť = 272 264 476 Maximální paměť = 272 514 048 Paměťové buffery = 16 384 Čtení z disku do cache = 82 Zápisy z cache na disk = 0 Načtení z cache = 3 648	Jednoduché spojení tabulek s 12400 a 372000000 záznamy, bez podmínek WHERE. „Průměrný čas načítání = 6.08 ms“ je pro načtení prvního řádku.
select w_id, w_name, c_id, c_last from WAREHOUSE, customer where c_w_id = w_id and c_w_id = 10000	PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE)) ------ Informace o výkonu —— Čas přípravy = 16ms Čas provedení = 78ms Průměrný čas načítání = 6.00 ms Aktuální paměť = 272 266 148 Maximální paměť = 272 514 048 Paměťové buffery = 16 384 Čtení z disku do cache = 88 Zápisy z cache na disk = 0 Načtení z cache = 3 656	Spojení stejných tabulek s podmínkou, která vynucuje výběr nedávných záznamů. „Průměrný čas načítání = 6.00 ms“ je pro načtení prvního řádku.
select count(*) from WAREHOUSE, customer where c_w_id = w_id and c_w_id = 10000 Výsledek = 30000	PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE)) ------ Informace o výkonu —— Čas přípravy = 0ms Čas provedení = 453ms Průměrný čas načítání = 453.00 ms Aktuální paměť = 272 263 844 Maximální paměť = 272 514 048 Paměťové buffery = 16 384 Čtení z disku do cache = 1 048 Zápisy z cache na disk = 0 Načtení z cache = 60 024	Počet záznamů pro předchozí dotaz

SELECT * FROM ORDER_LINE WHERE OL_W_ID = 500	Plán PLAN (ORDER_LINE INDEX (ORDER_LINE_PK)) ------ Informace o výkonu —— Čas přípravy = 0ms Čas provedení = 94ms Průměrný čas načítání = 7.23 ms Aktuální paměť = 136 445 536 Maximální paměť = 136 592 176 Paměťové buffery = 8 192 Čtení z disku do cache = 150 Zápisy z cache na disk = 0 Načtení z cache = 2 402	Dotaz na největší tabulku (3.8B záznamů). „Průměrný čas načítání = 7.23 ms“ je pro načtení prvního řádku.

	`<br>Plán<br>` `<br>PLAN (ORDER_LINE INDEX (ORDER_LINE_PK))<br>` `<br> <br>` `<br>------ Informace o výkonu ------<br>` `<br>Čas přípravy = 0ms<br>` `<br>Čas provedení = 3s 438ms<br>` `<br>Průměrný čas načítání = 0.01 ms<br>` `<br>Aktuální paměť = 136 445 496<br>` `<br>Maximální paměť = 136 592 176<br>` `<br>Paměťové buffery = 8 192<br>` `<br>Čtení z disku do cache = 1 840<br>` `<br>Zápisy z cache na disk = 0<br>` `<br>Načtení z cache = 598 636<br>`

| SELECT * FROM ORDER_LINE
WHERE OL_W_ID = 500 | Stejný dotaz na největší tabulku (3,8 miliardy záznamů), ale tentokrát jsme načetli všechny záznamy (načteno 299 245 záznamů). | | | | | select w_id, w_name, c_id, c_last
from WAREHOUSE, customer
where c_w_id = w_id and (c_w_id > 8000) and (c_w_id < 10000) | Plán
PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))
------ Informace o výkonu ——
Čas přípravy = 0 ms
Čas provedení = 125 ms
Průměrný čas načítání = 9,62 ms
Aktuální paměť = 272 270 824
Maximální paměť = 272 514 048
Paměťové buffery = 16 384
Čtení z disku do mezipaměti = 91
Zápisy z mezipaměti na disk = 0
Načtení z mezipaměti = 3 659 | Spojení tabulek s 1240 záznamy a 372 miliony záznamů. | | select count(*)
from WAREHOUSE, customer
where c_w_id = w_id and (c_w_id > 8000) and (c_w_id < 10000)
Výsledek = 59 970 000 | Plán
PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))
------ Informace o výkonu ——
Čas přípravy = 0 ms
Čas provedení = 13 min 4 s 718 ms
Průměrný čas načítání = 784 718,00 ms
Aktuální paměť = 272 268 532
Maximální paměť = 272 514 048
Paměťové buffery = 16 384
Čtení z disku do mezipaměti = 2 332 583
Zápisy z mezipaměti na disk = 0
Načtení z mezipaměti = 119 977 902 | Počet záznamů pro předchozí dotaz |

Shrnutí

V tomto experimentu Firebird prokázal následující výsledky

Nespornou schopnost zpracovávat velké databáze. Jsme si docela jistí, že je možné vytvořit a používat 32 TB databázi na odpovídajícím hardwaru a Firebird bude vykazovat stejně vysoký výkon jako u menších databází (tj. 1 TB a méně).
Dobrou škálovatelnost a úžasně malou paměťovou stopu. 1 TB databáze byla vytvořena na běžném stolním počítači a, což je důležitější, lze ji použít pro provádění běžných dotazů: pokud nenačítáte miliony záznamů, rychlost dotazů je stejná jako u databází střední velikosti (10-15 GB).

Tím tento experiment nekončí: máme v úmyslu spustit další dotazy, shromáždit dodatečné statistiky a brzy zveřejnit podrobnější zprávu. Sledujte nás prosím.

Kontakty

Veškeré dotazy a připomínky zasílejte na [email protected]