Zašto kreirati terabajtnu Firebird bazu?

Mnoge kompanije rade sa velikim Firebird bazama i oslanjaju se na njih za podršku važnim poslovnim operacijama. Neke Firebird baze su već stotine gigabajta velike i nastavljaju da rastu (pogledajte odeljak „Ko je velik?“), i lako je predvideti trenutak kada postanu 2, 3 ili 5 puta veće. Zato su administratori baza i dobavljači zainteresovani da istraže ponašanje Firebird-a sa velikim bazama i dobiju neke preporuke kako da njima upravljaju.

Takođe, važan razlog koji smo imali na umu prilikom kreiranja 1Tb Firebird baze bio je konačno otklanjanje preovlađujuće percepcije o Firebird-u kao motoru baze podataka za „male baze“. Ovaj mit izgleda da je sada mrtav, ali neki analitičari i novinari ga redovno vraćaju iz groba, i nadamo se da ćemo konačno završiti sa ovom smešnom percepcijom.


## Hardver

Firebird je poznat po svojoj neverovatnoj skalabilnosti i ovo istraživanje je to još jednom potvrdilo. Prvobitna svrha ovog eksperimenta bila je samo kreiranje Firebird baze veličine 1Tb, pa smo koristili običan desktop računar:

Tabela 1: Hardver


Komponenta	Parametri
CPU	AMDAthlon 64 x2 5200
RAM	4GB
Matična ploča	MSI K9N Platinum
HDD1 (operativni sistem i temp)	ST3160815AS, 160GB, SATA II
HDD2 (pomoćni)	HDT721064SLA360, 640GB,SATAII
HDD2 (pomoćni)	HDS728080PLA380, 80GB, SATA I
HDD3 (baza)	ST31500341AS, 1.5TB, SATA II (Firmware CC1H)

U suštini, stavili smo 1,5Tb HDD u jedan od naših kancelarijskih desktop računara, bez ikakvih drugih modifikacija. Ovaj HDD je formatiran sa veličinom klastera 16Kb (isto kao veličina stranice baze, kao što možete videti ispod).

Softver

Pošto je to desktop računar, operativni sistem je Windows XP Professional SP3, 32bit. Za samo izvršavanje testa koristili smo loader iz TPC-baziranog alata (preuzmite ga sa http://ibdeveloper.com/tests/tpc-c/, dostupni su i binarni fajlovi i izvorni kod).

Želeli bismo da naglasimo da loader ubacuje podatke kao što bi bili ubačeni u scenariju iz stvarnog života: zapisi se ubacuju i smeštaju unutar baze (i na fizičke oblasti diska) u nekoliko master-detail-subdetail tabela, a ne tabelu po tabelu.

Tabela 2: Softver


Softver	Verzija
Operativni sistem	Windows XP Professional SP3, 32bit
Firebird	2.1.3 SuperServer (snapshot)
Loader	Prilagođeni loader iz tpc-baziranog testa

Plan

Imali smo vrlo jednostavan plan za ovaj eksperiment:

Kreirati bazu i napuniti je sa 1Tb podataka, bez indeksa
Kreirati primarne ključeve i odgovarajuće indekse (tako da je stvarna veličina baze veća od 1Tb)
Prikupiti statistiku baze
Pokrenuti nekoliko SQL upita i proceniti performanse baze

Konfiguracija baze i Firebird servera

Baza ima veličinu stranice 16384 bajta, isto kao klaster HDD-a, da bi se maksimizirale performanse diska (da se čita/piše 1 stranica u jednom I/O ciklusu).

U Firebird konfiguraciji smo konfigurisali dodatni direktorijum za temp prostor i usmerili ga na disk sa 640Gb (gde je ~300Gb bilo slobodno).

Korak učitavanja

Podaci su učitani u ovu bazu u nekoliko koraka. Računar je korišćen tokom operacija učitavanja kao običan desktop (imamo MS Office, Firefox, IBAnalyst, itd. - oko 8-12 programa je radilo istovremeno). Da smo posvetili hardver samo ovom zadatku, verovatno bi bio brži, pa molimo vas da ove vrednosti smatrate samo kao primer nižeg ranga; one definitivno nisu najbolji rezultati.

Tabela 3: Operacije učitavanja

| |


Opis	Vrednost
Vreme učitavanja	~70 sati
Ukupno ubačenih zapisa	6,2 milijarde
Prosečna brzina ubacivanja	24500 zapisa/sekundi
Prosečna veličina zapisa	146 bajtova (min 13 bajtova, max - 600 bajtova)
Transakcije	646489

Proveli smo ~4 dana na učitavanju, a nakon toga smo imali Firebird bazu sa tačno 1Tb veličine (tj. 1 099 900 125 184 bajtova).

Ispod možete videti rast baze i dinamiku transakcija u FBDataGuard Viewer-u:

Indeksi

Kreirali smo indekse jedan po jedan i merili vreme njihovog kreiranja i odgovarajuću veličinu temp fajla korišćenog za sortiranje.

Najveći indeks je kreiran za tabelu ORDER_LINE. Njegov primarni ključ sadrži četiri polja (Smallint, Smallint, Integer i Smallint). Temp fajl za ovaj indeks sortiranja bio je 182Gb, a konačna veličina indeksa u bazi je 29,3Gb.

Zanimljivo je videti da čak i indeks za tabelu sa 3,8 milijardi zapisa ima dubinu = 3, jer je veličina stranice bila 16384 bajta, tako da nema dodatnog opterećenja pri pretraživanju podataka pomoću primarnog ključa za ovu tabelu.

Statistika

Nakon toga smo prikupili statistiku baze. To je trajalo 7 sati 32 minuta 45 sekundi.

Stavili smo ključne informacije statistike u jednu tabelu i uključili neke upite i merenja vremena:

Tabela 4: Konsolidovana statistika za 1Tb bazu


Naziv tabele	Broj zapisa	Veličina, gb	*Vreme izvršavanja select count()**	Vreme kreiranja indeksa	Veličina tmp fajla, Gb	Veličina indeksa, 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 |

Statistika baze podataka može se preuzeti ovde.

Možete koristiti besplatni FBDataGuard Community Edition Viewer za tumačenje tekstualnih podataka i pregled ne samo metrika performansi baze podataka, već i potrošnje CPU-a i memorije.

Upiti

Pre svega, pokrenuli smo select count(*) upite na nekoliko tabela (pogledajte 4. kolonu u Tabeli 4 iznad). Kao što znate, zbog multi-version prirode Firebird-a select count(*) za celu tabelu je skupa operacija za server jer zahteva obilazak svake stranice, i iskusni Firebird programeri ne koriste select count(*), ali smo ga koristili da demonstriramo ukupni odnos performansi baze podataka i hardvera.

Nakon select count upita pokrenuli smo upite iz realnog scenarija i, iskreno, bili smo zadivljeni tako dobrim rezultatima. Uverite se sami:


Upit	Statistika	Opis
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)) ------ Performance info —— Prepare time = 15ms Execute time = 79ms Avg fetch time = 6.08 ms Current memory = 272 264 476 Max memory = 272 514 048 Memory buffers = 16 384 Reads from disk to cache = 82 Writes from cache to disk = 0 Fetches from cache = 3 648	Jednostavan join tabela sa 12400 i 372000000 zapisa, bez WHERE uslova. „Avg fetch time = 6.08 ms“ odnosi se na preuzimanje prvog reda.
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)) ------ Performance info —— Prepare time = 16ms Execute time = 78ms Avg fetch time = 6.00 ms Current memory = 272 266 148 Max memory = 272 514 048 Memory buffers = 16 384 Reads from disk to cache = 88 Writes from cache to disk = 0 Fetches from cache = 3 656	Join istih tabela sa uslovom koji forsira selekciju skorašnjih zapisa. „Avg fetch time = 6.00 ms“ odnosi se na preuzimanje prvog reda.
select count(*) from WAREHOUSE, customer where c_w_id = w_id and c_w_id = 10000 Result = 30000	PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE)) ------ Performance info —— Prepare time = 0ms Execute time = 453ms Avg fetch time = 453.00 ms Current memory = 272 263 844 Max memory = 272 514 048 Memory buffers = 16 384 Reads from disk to cache = 1 048 Writes from cache to disk = 0 Fetches from cache = 60 024	Brojanje zapisa za prethodni upit

SELECT * FROM ORDER_LINE WHERE OL_W_ID = 500	Plan PLAN (ORDER_LINE INDEX (ORDER_LINE_PK)) ------ Performance info —— Prepare time = 0ms Execute time = 94ms Avg fetch time = 7.23 ms Current memory = 136 445 536 Max memory = 136 592 176 Memory buffers = 8 192 Reads from disk to cache = 150 Writes from cache to disk = 0 Fetches from cache = 2 402	Upit na najveću tabelu (3.8B zapisa). „Avg fetch time = 7.23 ms“ odnosi se na preuzimanje prvog reda.

	`<br>Plan<br>` `<br>PLAN (ORDER_LINE INDEX (ORDER_LINE_PK))<br>` `<br> <br>` `<br>------ Performance info ------<br>` `<br>Prepare time = 0ms<br>` `<br>Execute time = 3s 438ms<br>` `<br>Avg fetch time = 0.01 ms<br>` `<br>Current memory = 136 445 496<br>` `<br>Max memory = 136 592 176<br>` `<br>Memory buffers = 8 192<br>` `<br>Reads from disk to cache = 1 840<br>` `<br>Writes from cache to disk = 0<br>` `<br>Fetches from cache = 598 636<br>`
SELECT * FROM ORDER_LINE WHERE OL_W_ID = 500	Isti upit na najveću tabelu (3.8B zapisa), ali ovog puta smo preuzeli sve zapise (preuzeto 299245 zapisa).

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)	Plan PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE)) ------ Performance info —— Prepare time = 0ms Execute time = 125ms Avg fetch time = 9.62 ms Current memory = 272 270 824 Max memory = 272 514 048 Memory buffers = 16 384 Reads from disk to cache = 91 Writes from cache to disk = 0 Fetches from cache = 3 659	Join tabela sa 1240 zapisa i 372M zapisa.
select count(*) from WAREHOUSE, customer where c_w_id = w_id and (c_w_id > 8000) and (c_w_id < 10000) Result = 59 970 000	Plan PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE)) ------ Performance info —— Prepare time = 0ms Execute time = 13m 4s 718ms Avg fetch time = 784 718.00 ms Current memory = 272 268 532 Max memory = 272 514 048 Memory buffers = 16 384 Reads from disk to cache = 2 332 583 Writes from cache to disk = 0 Fetches from cache = 119 977 902	Brojanje zapisa za prethodni upit

Rezime

U ovom eksperimentu Firebird pokazuje sledeće rezultate

Nesumnjiva sposobnost rukovanja velikim bazama podataka. Prilično smo sigurni da je moguće kreirati i koristiti bazu podataka od 32 Tb na odgovarajućem hardveru, i Firebird će pokazati iste visoke performanse kao što pokazuje za manje baze podataka (tj. 1Tb i manje).
Dobra skalabilnost i neverovatno mali otisak. Baza podataka od 1Tb kreirana je na običnom desktop računaru i, što je još važnije, može se koristiti za izvršavanje opštih upita: ako ne preuzimate milione zapisa, brzina upita je ista kao za baze podataka umerene veličine (10-15Gb).

Ovo nije kraj ovog eksperimenta: nameravamo da pokrenemo još neke upite, prikupimo dodatnu statistiku i uskoro objavimo detaljniji izveštaj. Ostanite sa nama.

Kontakti

Sva vaša pitanja i upite šaljite na [email protected]