Neden terabayt boyutunda Firebird veritabanı oluşturmalı?

Birçok şirket büyük Firebird veritabanlarıyla çalışır ve önemli iş operasyonlarını desteklemek için bunlara güvenir. Bazı Firebird veritabanları zaten yüzlerce gigabayt boyutundadır ve büyümeye devam etmektedir (“Kim Büyük?” bölümüne bakın) ve bunların 2, 3 veya 5 kat daha büyük hale geldiği anı tahmin etmek kolaydır. Bu nedenle veritabanı yöneticileri ve satıcılar, Firebird’ün büyük veritabanlarıyla davranışını araştırmak ve bunları nasıl yöneteceklerine dair bazı öneriler almakla ilgilenmektedir.

Ayrıca 1Tb Firebird veritabanını oluştururken aklımızda tuttuğumuz önemli bir neden, Firebird’ün “küçük veritabanları” için veritabanı motoru olduğuna dair yaygın algının nihai olarak ortadan kaldırılmasıydı. Bu efsane artık ölmüş görünüyor, ancak bazı analistler ve gazeteciler onu düzenli olarak mezardan çıkarıyor ve bu gülünç algıyı nihayet sona erdirmeyi umuyoruz.


## Donanım

Firebird, inanılmaz ölçeklenebilirliğiyle iyi bilinir ve bu araştırma bunu bir kez daha doğrulamıştır. Bu deneyin başlangıçtaki amacı yalnızca 1Tb boyutunda bir Firebird veritabanı oluşturmaktı, bu yüzden sıradan bir masaüstü bilgisayar kullandık:

Tablo 1: Donanım


Bileşen	Parametreler
CPU	AMDAthlon 64 x2 5200
RAM	4GB
Anakart	MSI K9N Platinum
HDD1 (işletim sistemi ve geçici)	ST3160815AS, 160GB, SATA II
HDD2 (yardımcı)	HDT721064SLA360, 640GB,SATAII
HDD2 (yardımcı)	HDS728080PLA380, 80GB, SATA I
HDD3 (veritabanı)	ST31500341AS, 1.5TB, SATA II (Firmware CC1H)

Esasen, 1.5Tb HDD’yi başka hiçbir değişiklik yapmadan ofis masaüstülerimizden birine taktık. Bu HDD, 16Kb küme boyutuyla (aşağıda görebileceğiniz gibi veritabanının sayfa boyutuyla aynı) biçimlendirildi.

Yazılım

Masaüstü bilgisayar olduğu için işletim sistemi Windows XP Professional SP3, 32bit’tir. Testi gerçekten gerçekleştirmek için TPC tabanlı araç setindeki yükleyiciyi kullandık (http://ibdeveloper.com/tests/tpc-c/ adresinden indirin, hem ikili dosyalar hem de kaynak kodlar mevcuttur).

Yükleyicinin verileri gerçek hayat senaryosunda ekleniyormuş gibi eklediğini vurgulamak isteriz: kayıtlar tablo tablo değil, birkaç master-detail-subdetail tablosuna ekleniyor ve veritabanı içinde (ve fiziksel disk alanlarında) konumlandırılıyor.

Tablo 2: Yazılım


Yazılım	Sürüm
İşletim sistemi	Windows XP Professional SP3, 32bit
Firebird	2.1.3 SuperServer (snapshot)
Yükleyici	tpc tabanlı testten özel yükleyici

Plan

Bu deney için çok basit bir planımız vardı:

Veritabanı oluştur ve indeksler olmadan 1Tb veriyle yükle
Birincil anahtarları ve uygun indeksleri oluştur (yani aslında veritabanı boyutu 1Tb’den fazladır)
Veritabanı istatistiklerini topla
Birkaç SQL sorgusu çalıştır ve veritabanı performansını tahmin et

Veritabanı ve Firebird sunucu yapılandırması

Veritabanının sayfa boyutu 16384 bayttır, disk verimini en üst düzeye çıkarmak için HDD kümesiyle aynıdır (tek bir G/Ç döngüsünde 1 sayfa okumak/yazmak için).

Firebird yapılandırmasında geçici alan için ek bir dizin yapılandırdık ve onu 640Gb’lik diske (yaklaşık 300Gb’lik kısmı boştu) yönlendirdik.

Yükleme adımı

Veriler bu veritabanına birkaç adımda yüklendi. Bilgisayar yükleme işlemleri sırasında normal masaüstü olarak kullanıldı (MS Office, Firefox, IBAnalyst vb. vardı - aynı anda yaklaşık 8-12 program çalışıyordu). Donanımı yalnızca bu göreve adasaydık, muhtemelen daha hızlı olurdu, bu yüzden lütfen bu değerleri yalnızca düşük seviye bir örnek olarak değerlendirin; kesinlikle en iyi sonuçlar değiller.

Tablo 3: Yükleme işlemleri

| |


Açıklama	Değer
Yükleme süresi	~70 saat
Eklenen toplam kayıt	6,2 milyar
Ortalama ekleme hızı	24500 kayıt/saniye
Ortalama kayıt boyutu	146 bayt (min 13 bayt, maks - 600 bayt)
İşlemler	646489

Yüklemeye ~4 gün harcadık ve bundan sonra tam olarak 1Tb boyutunda (yani 1 099 900 125 184 bayt) bir Firebird veritabanına sahip olduk.

Aşağıda FBDataGuard Viewer’da veritabanı büyümesini ve işlem dinamiklerini görebilirsiniz:

İndeksler

İndeksleri tek tek oluşturduk ve oluşturulma sürelerini ve sıralama için kullanılan geçici dosyanın uygun boyutunu saydık.

En büyük indeks ORDER_LINE tablosu için oluşturuldu. Birincil anahtarı dört alan içerir (Smallint, Smallint, Integer ve Smallint). Bu sıralama indeksi için geçici dosya 182Gb’ydi ve veritabanındaki nihai indeks boyutu 29,3Gb’dir.

Sayfa boyutu 16384 bayt olduğu için 3,8 milyar kayıtlı bir tablonun indeksinin bile derinliğinin = 3 olduğunu görmek ilginçtir, bu nedenle bu tablo için birincil anahtar kullanılarak veri aranırken hiçbir ek yük yoktur.

İstatistikler

Bundan sonra veritabanı istatistiklerini topladık. 7 saat 32 dakika 45 saniye sürdü.

Temel istatistik bilgilerini tek bir tabloya koyduk ve bazı sorguları ve zaman ölçümlerini ekledik:

Tablo 4: 1Tb veritabanı için birleştirilmiş istatistikler


Tablo adı	Kayıt sayıları	Boyut, gb	*select count() çalıştırma süresi**	İndeks oluşturma süresi	Geçici dosya boyutu, Gb	İndeks boyutu, 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

Veritabanı istatistikleri buradan indirilebilir.

Metin verilerini yorumlamak ve yalnızca veritabanı performans metriklerini değil, aynı zamanda CPU ve bellek tüketimini de görmek için ücretsiz FBDataGuard Community Edition Viewer’ı kullanabilirsiniz.

Sorgular

Her şeyden önce, birkaç tablo üzerinde select count(*) sorguları çalıştırdık (yukarıdaki Tablo 4’teki 4. sütuna bakın). Bildiğiniz gibi, Firebird’ün çok sürümlü doğası nedeniyle tüm tablo için select count(*) sunucu için pahalı bir işlemdir çünkü her sayfayı ziyaret etmeyi gerektirir ve deneyimli Firebird geliştiricileri select count(*) kullanmaz, ancak biz bunu veritabanı ve donanımın genel performans oranını göstermek için kullandık.

select count sorgularından sonra gerçek hayat senaryosundan sorgular çalıştırdık ve dürüst olmak gerekirse, bu kadar iyi sonuçlara hayran kaldık. Kendiniz görün:


Sorgu	İstatistikler	Açıklama
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	12400 ve 372000000 kayıtlı tabloların basit birleşimi, WHERE koşulu yok. “Avg fetch time = 6.08 ms” ilk satırı getirmek içindir.
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	Son kayıtların seçilmesini zorlayan koşulla aynı tabloların birleşimi. “Avg fetch time = 6.00 ms” ilk satırı getirmek içindir.
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	Önceki sorgu için kayıtları say

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	En büyük tabloya (3,8 milyar kayıt) sorgu. “Avg fetch time = 7.23 ms” ilk satırı getirmek içindir.

	`<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 | En büyük tabloya (3,8 milyar kayıt) yapılan aynı sorgu, ancak bu sefer tüm kayıtları çektik (299245 kayıt çekildi). | | | | | 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))
------ Performans bilgisi ——
Hazırlama süresi = 0ms
Yürütme süresi = 125ms
Ortalama getirme süresi = 9,62 ms
Mevcut bellek = 272 270 824
Maksimum bellek = 272 514 048
Bellek tamponları = 16 384
Diskten önbelleğe okuma = 91
Önbellekten diske yazma = 0
Önbellekten getirme = 3 659 | 1240 kayıtlı ve 372 milyon kayıtlı tabloları birleştirir. | | select count(*)
from WAREHOUSE, customer
where c_w_id = w_id and (c_w_id > 8000) and (c_w_id < 10000)
Sonuç = 59 970 000 | Plan
PLAN JOIN (WAREHOUSE INDEX (WAREHOUSE_PK), CUSTOMER INDEX (FK_CUST_WARE))
------ Performans bilgisi ——
Hazırlama süresi = 0ms
Yürütme süresi = 13dk 4s 718ms
Ortalama getirme süresi = 784 718,00 ms
Mevcut bellek = 272 268 532
Maksimum bellek = 272 514 048
Bellek tamponları = 16 384
Diskten önbelleğe okuma = 2 332 583
Önbellekten diske yazma = 0
Önbellekten getirme = 119 977 902 | Önceki sorgu için kayıtları sayar |

Özet

Bu deneyde Firebird aşağıdaki sonuçları gösterir

Büyük veritabanlarını işleme konusunda tartışmasız yetenek. Uygun donanımda 32 Tb veritabanı oluşturmanın ve kullanmanın mümkün olduğundan ve Firebird’ün daha küçük veritabanlarında (yani 1Tb ve altı) gösterdiği aynı yüksek performansı göstereceğinden oldukça eminiz.
İyi ölçeklenebilirlik ve şaşırtıcı derecede küçük ayak izi. 1Tb veritabanı sıradan bir masaüstü bilgisayarda oluşturuldu ve daha da önemlisi, genel sorguları gerçekleştirmek için kullanılabilir: milyonlarca kayıt çekmezseniz, sorgu hızı orta büyüklükteki veritabanlarındaki (10-15Gb) ile aynıdır.

Bu deneyin sonu değil: bazı sorgular çalıştırmayı, ek istatistikler toplamayı ve yakında daha ayrıntılı bir rapor yayınlamayı planlıyoruz. Takipte kalın.

İletişim

Tüm sorularınızı ve taleplerinizi [email protected] adresine gönderin