Зашто креирати терабајтну Firebird базу података?

Многе компаније раде са великим Firebird базама података и ослањају се на њих за подршку важним пословним операцијама. Неке од Firebird база података већ су величине стотина гигабајта и настављају да расту (погледајте одељак „Ко је велики?“), и лако је предвидети тренутак када ће постати 2, 3 или 5 пута веће. Стога су администратори база података и произвођачи заинтересовани да истраже понашање Firebird-а са великим базама података и добију препоруке како да њима управљају.

Такође, важан разлог који смо имали на уму приликом креирања 1Tb Firebird базе података било је коначно елиминисање распрострањене перцепције Firebird-а као мотора базе података за „мале базе података“. Овај мит изгледа да је сада мртав, али га неки аналитичари и новинари редовно васкрсавају, и надамо се да ћемо коначно окончати ову смешну перцепцију.


## Хардвер

Firebird је познат по својој невероватној скалабилности и ово истраживање је то још једном потврдило. Почетна сврха овог експеримента била је само креирање Firebird базе података величине 1Tb, па смо користили обичан десктоп рачунар:

Табела 1: Хардвер


Компонента	Параметри
CPU	AMDAthlon 64 x2 5200
RAM	4GB
Матична плоча	MSI K9N Platinum
HDD1 (оперативни систем и привремени)	ST3160815AS, 160GB, SATA II
HDD2 (помоћни)	HDT721064SLA360, 640GB,SATAII
HDD2 (помоћни)	HDS728080PLA380, 80GB, SATA I
HDD3 (база података)	ST31500341AS, 1.5TB, SATA II (Firmware CC1H)

У суштини, ставили смо 1.5Tb HDD у један од наших канцеларијских десктоп рачунара, без икаквих других модификација. Овај HDD је форматиран са величином кластера 16Kb (истом као величина странице базе података, као што ћете видети испод).

Софтвер

Пошто је то десктоп рачунар, оперативни систем је Windows XP Professional SP3, 32bit. За стварно извођење теста користили смо учитавач из TPC-базираног комплета алата (преузмите га са http://ibdeveloper.com/tests/tpc-c/, доступни су и бинарни фајлови и изворни код).

Желимо да нагласимо да учитавач уноси податке онако како би били унети у реалном сценарију: записи се уносе и смештају унутар базе података (и на физичке области диска) у неколико master-detail-subdetail табела, не табелу по табелу.

Табела 2: Софтвер


Софтвер	Верзија
Оперативни систем	Windows XP Professional SP3, 32bit
Firebird	2.1.3 SuperServer (snapshot)
Учитавач	Прилагођени учитавач из tpc-базираног теста

План

Имали смо веома једноставан план за овај експеримент:

Креирати базу података и напунити је са 1Tb података, без индекса
Креирати примарне кључеве и одговарајуће индексе (тако да је стварна величина базе већа од 1Tb)
Прикупити статистику базе података
Покренути неколико SQL упита и проценити перформансе базе података

Конфигурација базе података и Firebird сервера

База података има величину странице 16384 бајта, исту као HDD кластер, да би се максимизовала пропусност диска (читање/писање 1 странице у једном I/O циклусу).

У Firebird конфигурацији конфигурисали смо додатни директоријум за привремени простор и усмерили га на диск од 640Gb (где је било ~300Gb слободно).

Корак учитавања

Подаци су учитани у ову базу у неколико корака. Рачунар је коришћен током операција учитавања као обичан десктоп (имали смо MS Office, Firefox, IBAnalyst, итд. - око 8-12 програма је радило истовремено). Да смо посветили хардвер само овом задатку, вероватно би било брже, па вас молимо да ове вредности сматрате само примером нижег ранга; дефинитивно нису најбољи резултати.

Табела 3: Операције учитавања

| |


Опис	Вредност
Време учитавања	~70 сати
Укупно уметнутих записа	6.2 милијарде
Просечна брзина уметања	24500 записа/секунди
Просечна величина записа	146 бајтова (мин 13 бајтова, макс - 600 бајтова)
Трансакције	646489

Потрошили смо ~4 дана на учитавање, и након тога смо имали Firebird базу података тачно величине 1Tb (тј. 1 099 900 125 184 бајта).

Испод можете видети раст базе података и динамику трансакција у FBDataGuard прегледачу:

Индекси

Креирали смо индексе један по један и измерили време њиховог креирања и одговарајућу величину привременог фајла коришћеног за сортирање.

Највећи индекс је креиран за табелу ORDER_LINE. Њен примарни кључ садржи четири поља (Smallint, Smallint, Integer и Smallint). Привремени фајл за овај индекс сортирања био је 182Gb, а коначна величина индекса у бази података је 29.3Gb.

Занимљиво је видети да чак и индекс за табелу са 3.8 милијарди записа има дубину = 3, јер је величина странице била 16384 бајта, тако да нема додатних трошкова приликом претраживања података коришћењем примарног кључа за ову табелу.

Статистика

Након тога смо прикупили статистику базе података. Трајало је 7 сати 32 минута 45 секунди.

Ставили смо кључне статистичке информације у једну табелу и укључили неке упите и мерења времена:

Табела 4: Консолидована статистика за 1Tb базу података


Назив табеле	Број записа	Величина, gb	*Време извршења select count()**	Време креирања индекса	Величина привременог фајла, Gb	Величина индекса, 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 |

Statistike baze podataka možete preuzeti ovde.

Možete koristiti besplatni FBDataGuard Community Edition Viewer za tumačenje tekstualnih podataka i videti ne samo metrike performansi baze podataka, već i potrošnju 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-verzione prirode Firebird-a, select count(*) za celu tabelu je skupa operacija za server jer zahteva posetu svake stranice, a iskusni Firebird programeri ne koriste select count(*), ali smo ga mi koristili da bismo demonstrirali ukupan odnos performansi baze podataka i hardvera.

Nakon select count upita, pokrenuli smo upite iz scenarija iz stvarnog života i, da budemo iskreni, bili smo zadivljeni tako dobrim rezultatima. Uverite se sami:


Upit	Statistike	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	Jednostavno spajanje tabela sa 12400 i 372000000 zapisa, bez WHERE uslova. „Avg fetch time = 6.08 ms“ je za dohvatanje 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	Spajanje istih tabela sa uslovom koji forsira selekciju skorašnjih zapisa. „Avg fetch time = 6.00 ms“ je za dohvatanje 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.8 milijardi zapisa). „Avg fetch time = 7.23 ms“ je za dohvatanje 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.8 milijardi zapisa), ali ovog puta smo dohvatili sve zapise (299245 zapisa dohvaćeno).

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	Spajanje tabela sa 1240 zapisa i 372 miliona 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

Sažetak

U ovom eksperimentu Firebird pokazuje sledeće rezultate

Nesumnjivu sposobnost rukovanja velikim bazama podataka. Prilično smo sigurni da je moguće kreirati i koristiti bazu od 32 Tb na odgovarajućem hardveru, i Firebird će pokazati iste visoke performanse kao što pokazuje za manje baze (tj. 1Tb i manje).
Dobru skalabilnost i neverovatno mali otisak. Baza 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 dohvatate milione zapisa, brzina upita je ista kao kod baza srednje veličine (10-15Gb).

Ovo nije kraj ovog eksperimenta: nameravamo da pokrenemo još upita, prikupimo dodatne statistike i uskoro objavimo detaljniji izveštaj. Molimo vas da ostanete u toku.

Kontakti

Pošaljite sva svoja pitanja i upite na [email protected]