layout: default title: 600,000 Gerçek IMDb Kaydıyla Büyük Veritabanı Benchmarkı - AmberDB vs SQLite 3 description: 600,000 gerçek IMDb filmi üzerinde AmberDB ve SQLite 3 karşılaştırmalı performans, derin sayfalama (read_all), ters dizin arama, çoklu alan filtreleme ve nokta okuma benchmark raporu.
🏠 Ana Sayfa • 📖 Hakkında • 📘 Tutorial • 📊 Benchmark Raporu • 🌐 Locale • 🇬🇧 English
600,000 Gerçek IMDb Kaydıyla Büyük Veritabanı Benchmarkı: AmberDB vs SQLite 3
Yayın Tarihi: Eylül 2026 (Sürüm 5.24.0)
Yazar / Proje: Maruf Çetin (AmberDB Projesi)
Test Ortamı: Ubuntu 24.04 LTS (Linux Kernel 6.8.0) | 8 vCPU | 8 GiB RAM | Ext4 Dosya Sistemi
Test Edilen Motorlar: AmberDB v5.24.0 (Saf Perl + Berkeley DB) vs SQLite 3 (v3.45.1 / DBD::SQLite + FTS5)
Veri Kümesi: %100 Gerçek Dünya IMDb Resmi Dökümleri (600,000 Uzun Metraj Sinema Filmi)
1. Giriş ve Motivasyon
Bir veritabanı motorunun mimarisini ve sınırlarını anlamanın en sağlıklı yolu, onu sentetik oyuncak verilerle değil, gerçek dünyanın karmaşık ve hacimli verileriyle sınamaktır.
AmberDB ve SQLite arasındaki bu karşılaştırmalı benchmark çalışması, resmi IMDb dökümleri (datasets.imdbws.com) üzerinden 600.000 gerçek film verisi ile icra edilmiştir.
Bu raporda;
- Yazma ve okuma bağlantılarının bellek önbelleği hilesini önlemek için nasıl fiziksel olarak ayrıldığı,
- AmberDB'nin sabit 8-bayt ikili indeksleme yapısı sayesinde derin sayfalamada (
read_all) SQLite'ı nasıl 10 kat geride bıraktığı, - Noktasal rastgele okumada (Point Read) 1.7 mikro-saniye ile SQLite'ı 5.3 kat geçtiği,
- Çoklu alan filtrelemesinde (Multi-Field Filter) 10.2 kat daha hızlı yanıt verdiği,
- Omnibox çapraz blok aramasında milisaniyenin altında tam satır çözümleme yeteneği
tüm şeffaflığı ve ölçüm tablolarıyla belgelenmiştir.
2. Metodoloji ve Adil Test İlkeleri
A. Yazma ve Okuma Oturumlarının Fiziksel Olarak Ayrılması (Severed Lifecycle)
- SQLite: Veriler eklendikten sonra
PRAGMA wal_checkpoint(TRUNCATE)komutuyla WAL günlüğü ana veritabanı dosyasına yazıldı, tüm ifade tanıtıcıları ($sth) serbest bırakıldı ve veritabanı bağlantısı ($dbh->disconnect) tamamen kapatıldı. - AmberDB: Tüm veri ve indeks tabloları (
table_close) ile diske yazılıp kapatıldı ve nesne bellekten düşürüldü. - İzole Süreçler (Isolated Processes): Her iki motor tamamen ayrı işletim sistemi süreçlerinde çalıştırıldı ve süreçler arasında 3 saniyelik CPU/RAM soğuma payı bırakıldı.
B. %100 Gerçek Dünya Verisi (IMDb Dökümleri)
Resmi IMDb CloudFront sunucularından indirilen arşivler birleştirilerek 600.000 gerçek film, 227.000 yönetmen, 540.000 oyuncu ve gerçek IMDb puanları haritalandırılmıştır.
C. SQLite Transaction ve Senkronizasyon Yapılandırması (ACID Güvencesi)
- Tek Büyük Transaction: Toplu ekleme tek bir transaction içinde yapılmıştır.
PRAGMA synchronous = NORMAL;(OFFDeğil): SQLite'ta disk dayanıklılığını feda eden hileli ayarlar kullanılmamış; üretim standardı olan WAL modu veNORMALsenkronizasyon kullanılmıştır.
3. Karşılaştırmalı Ölçüm Tablosu (600,000 Kayıt)
Aşağıdaki ölçümler, Linux Ext4 dosya sistemi üzerinde önceden diske yazılmış gerçek 600.000 film verisi üzerinden taze süreçlerle alınmıştır:
| Test Senaryosu / Metrik | SQLite 3 (FTS5 İndeksli) | AmberDB v5.24.0 (İndeksli) | Kazanan / Fark |
| :--- | :---: | :---: | :---: |
| Toplam Kayıt Sayısı | 600,000 film | 600,000 film | — |
| Noktasal Okuma (Point Read Latency) | 9.0 µs | 1.7 µs | 🏆 AmberDB (5.3 Kat Daha Hızlı - 588K ops/s) |
| Sayfalamalı Derin Tarama (offset=430K, limit=20) | 32.59 ms | 3.26 ms | 🏆 AmberDB (10 Kat Daha Hızlı!) |
| Çoklu Alan Filtreleme (Yönetmen + Tür + Dil) | 91.84 ms | 8.96 ms | 🏆 AmberDB (10.2 Kat Daha Hızlı!) |
| Tek Blok Çekme (Yönetmenin Tüm Filmleri) | 24.05 ms | 21.99 ms | 🏆 AmberDB (Daha Hızlı) |
| Tarih Aralığı Filtresi (1990–2016) | 0.22 ms | 2.79 ms | İkisi de son derece hızlı (sub-3ms) |
| Çapraz Blok Arama (Canadian Moore) | 0.32 ms | 1.00 ms | İkisi de milisaniye seviyesinde |
| Omnibox Arama (beyaz 2012 ölü) | 0.23 ms | 0.46 ms | ⚡ İkisi de yarım milisaniyenin altında |
| Omnibox Arama (venky 2003 nenu) | 0.22 ms | 0.44 ms | ⚡ İkisi de yarım milisaniyenin altında |
| Omnibox Arama (natale 1996 green) | 0.38 ms | 0.99 ms | ⚡ İkisi de 1 milisaniyenin altında |
| Disk Ayak İzi (Tüm İndeksler Dahil) | 488.91 MB | 522.95 MB | Neredeyse eşit (AmberDB sadece %7 fark) |
| Toplu Veri Yükleme (Bulk Ingest) | 12.55 sn (47,814 k/sn) | 433.64 sn (1,384 k/sn) | SQLite (Derlenmiş C) |
4. Mimari Analiz ve Bulgular
A. Noktasal Okumada 1.7 Mikro-Saniye: Doğrudan C-Seviyesi Anahtar Erişimi ve ABR v5
AmberDB, table_readid veya read_id ile rastgele bir kayıt kimliği sorguladığında:
- SQL ayrıştırma (parsing), execution plan hazırlama veya ifade tanıtıcısı (
$sth) maliyeti tamamen sıfırdır. - Berkeley DB (
DB_File) C kütüphanesi üzerinden doğrudan anahtar erişimi ($db->get($id, $rec)) yapılır. - Alınan ham kayıt verisi, AmberDB v5.24.0'ın yüksek başarımlı ikili serileştiricisi (ABR v5) ile tek hamlede çözülür.
- Bu sayede AmberDB tekil okumalarda 1.7 mikro-saniye gecikme süresine ve saniyede 588.000 sorgu hızına ulaşarak SQLite'ı (9.0 µs / 111.000 ops/sn) 5.3 kat geride bırakır.
B. read_all Derin Sayfalamada Neden AmberDB 10 Kat Hızlı?
Modern web uygulamalarında derin sayfalama (örn: 600K kaydın 430.000'inci satırına atlamak) B-Tree motorları için zordur:
- SQLite: B-Tree yaprak düğümlerinde 430.000 kaydı tek tek yürümek (traverse etmek) zorundadır. Bu işlem C seviyesinde bile 32.59 ms sürer.
- AmberDB:
.inxsıralı anahtar dosyasında430.717 * 8 bayt = 3.445.736baytlık noktaya anında atlar ve sadece hedef 20 kaydın ID'sini çıkarır. İşlem 3.26 ms sürer (10 kat daha hızlı).
C. Çoklu Alan Filtrelemesinde 10.2 Kat Hız: Saf İndeks İkili Arama
Yönetmen + Tür + Dil gibi birden fazla koşul kesiştiğinde:
- SQLite FTS5 ve B-Tree birleşiminde 91.84 ms harcarken;
- AmberDB v5.24.0, 8-bayt hizalı ikili indeks üzerinde Adaptive Binary Search Pruning (
bin_crop) uygulayarak dev union hash'leri kurmadan işlemi 8.96 ms'de bitirir.
5. Testi Kendi Ortamınızda Çalıştırma (Reproducibility)
Tüm testler ve sürücüler benchmark/ dizininde açık kaynak olarak yer almaktadır:
# 1. Depoyu klonlayın
git clone https://github.com/marufcetin/amberdb.git
cd amberdb
# 2. 600K benchmark testini izole süreçlerde başlatın
perl -Ilib benchmark/run_benchmark.pl total=600000 motors=amberdb,sqlite -with-index -random action=read
6. Genel Değerlendirme
SQLite, C dilinde 24 yıldır mikrosaniye düzeyinde optimize edilmiş bir başyapıttır. Derlenmiş C motoru sayesinde toplu veri yüklemede (ingest) tartışmasız bir hıza sahiptir.
Buna karşın, saf Perl ile yazılmış AmberDB v5.24.0'ın ortaya koyduğu sonuçlar yazılım mimarisi açısından tarihi bir ders niteliğindedir:
"Doğru algoritma ve veri yapısı seçimi, saf C derleme avantajını bile geride bırakabilir."
AmberDB'nin 600.000 gerçek sinema filmi üzerinde:
- Derin sayfalamada SQLite'ı 10 kat geride bırakarak 3.26 ms'de yanıt vermesi,
- Noktasal okumalarda 1.7 mikro-saniye ile 5.3 kat daha hızlı olması,
- Çoklu alan filtrelemesinde 10.2 kat fark atarak 8.96 ms'de tamamlaması,
- Serbest metin ve Omnibox aramalarında 0.4 - 0.9 ms bandında tam satır döndürmesi,
AmberDB'nin gömülü veri yönetimi ve NoSQL dizinleme alanında ne kadar yenilikçi ve güçlü bir alternatif olduğunu somut olarak kanıtlamıştır.