VoltDB, saklı yordamlar ve SQL üzerine kurulu, bellek içi (in-memory) çalışan, dağıtık ve ACID uyumlu bir ilişkisel veritabanıdır. Temel amacı, saniyede çok sayıda küçük işlemi (OLTP) düşük ve öngörülebilir gecikmeyle karşılamaktır. Bu yazıda sistemin mimarisini, veri modelini, dayanıklılık mekanizmalarını ve hangi senaryolara uygun olduğunu dengeli biçimde ele alıyoruz.
VoltDB Nedir?
VoltDB, çevrimiçi işlem işleme (OLTP) yükleri için tasarlanmış bir NewSQL veritabanıdır. NewSQL, geleneksel ilişkisel veritabanlarının SQL ve ACID garantilerini korurken NoSQL sistemlerin yatay ölçeklenme yeteneğini hedefleyen bir yaklaşımı tanımlar. VoltDB bu çizgide; verinin büyük bölümünü diskte tutan klasik motorların aksine, aktif veri kümesini bir küme (cluster) boyunca dağıtılmış olarak bellekte tutar.
Sistem, kısa ömürlü ve iyi tanımlı işlemlerin çok yüksek hızda yürütülmesini önceliklendirir. Bu yüzden uzun süren analitik taramalar (OLAP) yerine, ödeme yetkilendirme, telekom ücretlendirme, dolandırıcılık kontrolü veya reklam açık artırması gibi milisaniye altı yanıt bekleyen iş akışlarına odaklanır. İlişkisel model, birincil anahtarlar, dizinler ve SQL sorguları tümüyle desteklenir; dolayısıyla veri modeli SQL geliştiricilerine tanıdık gelir.
Kısa Tarihçe ve NewSQL Bağlamı
VoltDB'nin kökeni, veritabanı araştırmacısı Michael Stonebraker ve ekibinin yürüttüğü H-Store akademik araştırma projesine dayanır. H-Store, geleneksel disk tabanlı motorların OLTP yüklerinde harcadığı kilit (locking), tampon yönetimi ve günlükleme ek yükünü sorgulayan; bunun yerine bellek içi, tek iş parçacıklı ve bölümlenmiş bir tasarımı savunan bir çalışmaydı. Bu fikirler daha sonra ticari VoltDB ürününe dönüştü.
VoltDB, sektörde NewSQL olarak anılan yaklaşımın erken ve tipik örneklerinden biri kabul edilir. İlerleyen yıllarda ürün ve şirket Volt Active Data adıyla yeniden markalandı; literatürde ve topluluk içinde hâlâ sıklıkla "VoltDB" olarak anılır. Benzer felsefeyi paylaşan başka dağıtık SQL sistemlerini merak ediyorsanız Google Cloud Spanner ve OceanBase yazılarımıza da göz atabilirsiniz.
Mimari: Bellek İçi ve Paylaşımsız Tasarım
VoltDB, paylaşımsız (shared-nothing) bir küme mimarisi kullanır. Her düğüm (node) verinin yalnızca kendi payına düşen bölümünü yönetir; düğümler ortak bir disk ya da bellek havuzunu paylaşmaz. Aktif veri esas olarak RAM'de tutulduğundan, disk erişiminin getirdiği gecikme büyük ölçüde ortadan kalkar.
Tasarımın en ayırt edici yanı, her bölümün (partition) işlemleri tek iş parçacığında sırayla yürütmesidir. Bir bölüm içinde aynı anda tek işlem çalıştığı için, geleneksel motorlarda yüksek eşzamanlılıkta maliyetli hâle gelen satır kilitleri ve latch mekanizmalarına ihtiyaç kalmaz. İşlemler kilit beklemek yerine hızlıca başlayıp biter. Bu, yüksek üretim (throughput) elde etmenin bilinen bir yoludur; karşılığında geliştiricinin iş yükünü bölümlere temiz biçimde ayırabilmesi beklenir.
İşlemlerin sıralı ve belirlenimci (deterministic) yürütülmesi, çoğaltma ve kurtarma açısından da önemlidir: aynı işlem çağrıları aynı sırada çalıştırıldığında her kopya aynı sonucu üretir. Bu özellik, aşağıda değindiğimiz komut günlüğü ve K-safety mekanizmalarının temelini oluşturur.
Bölümleme ve Veri Modeli
VoltDB'de tablolar iki şekilde ele alınır. Bölümlenmiş (partitioned) tablolar, seçilen bir bölümleme sütununa (örneğin müşteri kimliği) göre küme boyunca parçalara ayrılır; her satır tek bir bölümde yaşar. Çoğaltılmış (replicated) tablolar ise küçük, seyrek değişen başvuru tabloları için uygundur ve tüm bölümlere kopyalanır; böylece birleştirme (join) işlemleri yerel olarak yapılabilir.
İşlemler de bu ayrıma göre iki gruba düşer. Tek bölümlü işlemler yalnızca bir bölümdeki veriye dokunur ve en yüksek performansı verir. Çok bölümlü işlemler birden fazla bölümü koordine etmeyi gerektirir; doğru ve tutarlıdırlar ancak ek koordinasyon maliyeti taşırlar. İyi bir şema tasarımı, sık çalışan sorguları mümkün olduğunca tek bölümde tutmayı amaçlar.
- Bölümleme sütununu, en sık erişilen işlemlerin doğal erişim anahtarına göre seçin (örn. hesap no, kullanıcı no).
- Küçük ve nadiren değişen başvuru tablolarını çoğaltılmış (replicated) yapın.
- Çok bölümlü işlemleri, gerçekten gerekli olmadıkça sıcak yoldan (hot path) uzak tutun.
- Tüm aktif veri kümesinin küme belleğine sığacağını kapasite planında öngörün.
Saklı Yordamlar ve İşlem Modeli
VoltDB'de işlemlerin ana birimi saklı yordamlardır (stored procedure). Bir saklı yordam çağrısı tek başına bir işlem (transaction) olarak ele alınır: ya tümüyle uygulanır ya da hiç uygulanmaz (atomiklik). Yordamlar genellikle Java ile yazılır ve içlerinde parametreli SQL ifadeleri çalıştırır; ayrıca basit senaryolar için doğrudan SQL de çalıştırılabilir.
Bu modelin avantajı, işlem mantığının veriye yakın (sunucu tarafında) çalışması ve ağ gidiş-dönüşlerinin azalmasıdır. Belirlenimci yürütme kuralı gereği, saklı yordamların çıktısı yalnızca girdilerine bağlı olmalı; rastgele değerler veya kontrol dışı yan etkiler önerilmez, çünkü kopyalar arasında tutarlılığı bozabilir.
Örnek: Tablo Tanımı ve Bölümleme
Aşağıda basit bir ilişkisel şema ve bölümleme bildirimi görülüyor. PARTITION TABLE ifadesi, tablonun hangi sütuna göre bölümleneceğini belirtir.
-- Islem tablosu, hesap kimligine gore bolumlenir
CREATE TABLE hesaplar (
hesap_id BIGINT NOT NULL,
ad_soyad VARCHAR(128) NOT NULL,
bakiye DECIMAL NOT NULL,
PRIMARY KEY (hesap_id)
);
PARTITION TABLE hesaplar ON COLUMN hesap_id;
-- Kucuk basvuru tablosu tum bolumlere kopyalanir
CREATE TABLE para_birimleri (
kod VARCHAR(3) NOT NULL,
ad VARCHAR(64) NOT NULL,
PRIMARY KEY (kod)
);
-- (bolumleme bildirimi yok => replicated)Tek bölümlü bir güncelleme, çağrı sırasında bölümleme anahtarını (hesap_id) alır ve doğrudan ilgili bölümde çalışır:
-- Ornek: tek bir hesabin bakiyesini guncelleyen SQL
UPDATE hesaplar
SET bakiye = bakiye - 100
WHERE hesap_id = 42;Dayanıklılık: Komut Günlüğü ve Anlık Görüntüler
Bellek içi bir sistemin en büyük sorusu, elektrik kesintisi ya da düğüm arızasında verinin nasıl korunacağıdır. VoltDB bunu iki mekanizmayla ele alır. Anlık görüntüler (snapshot), veri kümesinin belirli bir andaki tutarlı bir kopyasını diske yazar. Komut günlüğü (command logging) ise değişen satırları değil, çalıştırılan işlem çağrılarını kaydeder.
Komut günlüğünün satır günlüğü yerine çağrı günlüğü olması, belirlenimci yürütme sayesinde mümkün olur: kurtarma sırasında son anlık görüntü yüklenir, ardından günlükteki çağrılar aynı sırayla yeniden oynatılarak sistem son tutarlı duruma getirilir. Bu yaklaşım, yazma yolundaki günlükleme maliyetini düşürmeyi amaçlar.
Yüksek Erişilebilirlik: K-safety ve Çoğaltma
VoltDB, yüksek erişilebilirlik için K-safety adı verilen bir çoğaltma modeli sunar. K değeri, her bölümün kaç ek kopyasının kümede tutulacağını belirtir; K=1 bir düğüm kaybına, daha yüksek K değerleri birden fazla eşzamanlı kayba dayanıklılık sağlar. Belirlenimci yürütme sayesinde her kopya aynı çağrıları işleyerek senkron kalır.
Felaket kurtarma senaryoları için, veri merkezleri arası çoğaltma (cross-datacenter replication) gibi kurumsal özellikler de sağlanabilir. Bu tür yeteneklerin kapsamı sürüm ve lisansa göre değişebileceğinden, güncel ürün belgelerini esas almak gerekir.
VoltDB'yi Diğer Yaklaşımlarla Karşılaştırma
Aşağıdaki tablo, VoltDB'yi geleneksel disk tabanlı ilişkisel veritabanları ve tipik anahtar-değer NoSQL sistemleriyle kaba hatlarıyla karşılaştırır. Amaç bir sistemi yüceltmek değil, hangi işin hangi araca daha uygun olduğunu netleştirmektir.
| Özellik | VoltDB (NewSQL) | Geleneksel disk RDBMS | Anahtar-değer NoSQL |
|---|---|---|---|
| Veri yerleşimi | Ağırlıklı bellek içi | Ağırlıklı disk (bellek önbellekli) | Değişken |
| Veri modeli | İlişkisel + SQL | İlişkisel + SQL | Anahtar-değer / doküman |
| İşlem garantisi | ACID | ACID | Genelde sınırlı / nihai tutarlılık |
| İşlem birimi | Saklı yordam / SQL | SQL işlemleri | Tek anahtar işlemleri |
| Ölçekleme | Yatay (bölümleme) | Genelde dikey + replika | Yatay |
| İdeal iş yükü | Yüksek hacimli kısa OLTP | Genel amaçlı OLTP/OLAP | Basit, çok yüksek hacimli erişim |
Klasik ilişkisel motorların nasıl çalıştığını hatırlamak için Oracle Database yazımız; bellek içi ilişkisel yaklaşımın başka bir örneği için ise Oracle TimesTen yazımız iyi bir karşılaştırma zemini sunar. Sütun temelli bellek içi analitik için SAP HANA yazısına da bakabilirsiniz.
Tipik Kullanım Senaryoları
VoltDB, verinin "anlık" olduğu ve kararların milisaniyeler içinde verilmesi gereken alanlarda öne çıkar:
- Telekom: gerçek zamanlı ücretlendirme, kota ve oturum kontrolü
- Finans: ödeme yetkilendirme, risk ve limit kontrolü
- Dolandırıcılık tespiti: işlem anında kural ve skor değerlendirme
- Reklam teknolojisi: gerçek zamanlı teklif (bidding) ve bütçe takibi
- IoT ve telemetri: yüksek hacimli olay alımı ve anlık toplulaştırma
- Oyun ve dijital hizmetler: skor tabloları, sanal ekonomi işlemleri
Ortak nokta, iş yükünün doğal bir anahtara (hesap, kullanıcı, cihaz) göre bölümlenebilmesi ve işlemlerin küçük, iyi tanımlı olmasıdır. Bu koşullar sağlandığında tek iş parçacıklı, bölümlü model verimini gösterir.
Güçlü Yönler ve Sınırlamalar
| Güçlü yönler | Dikkat edilecek sınırlamalar |
|---|---|
| Kısa OLTP işlemlerinde yüksek üretim ve düşük gecikme | Aktif veri kümesinin küme belleğine sığması gerekir |
| Tam SQL ve ACID desteği | Ağır OLAP taramaları için birincil tasarım hedefi değildir |
| Kilit/latch yükü olmadan belirlenimci yürütme | İyi bir bölümleme stratejisi tasarım disiplini ister |
| Yatay ölçekleme ve K-safety ile erişilebilirlik | Çok bölümlü işlemler ek koordinasyon maliyeti taşır |
Ne Zaman VoltDB Düşünülmeli?
VoltDB, iş yükünüz yoğun biçimde kısa işlemlerden oluşuyorsa, gecikme bütçeniz darsa ve veri doğal bir anahtara göre temiz şekilde bölümlenebiliyorsa güçlü bir aday olur. Buna karşılık, karmaşık raporlama ve geniş analitik taramalar ağır basıyorsa ya da veri kümesi belleğe sığmayacak kadar büyükse, disk tabanlı bir ilişkisel motor veya analitik bir sistem daha uygun olabilir.
Karar verirken tek bir ürüne kilitlenmek yerine iş yükünüzü tanımlamak daha sağlıklıdır. Farklı veritabanı ailelerini ve hangi işe hangisinin uyduğunu bir arada görmek için Veritabanı Türleri Rehberi yazımız iyi bir başlangıç noktasıdır.
Sık Sorulan Sorular
VoltDB tüm veriyi bellekte mi tutar?
Aktif veri kümesi ağırlıklı olarak bellekte tutulur; performans buradan gelir. Buna karşılık dayanıklılık için anlık görüntüler ve komut günlüğü diske yazılır. Yani "her şey uçucu bellekte kaybolur" demek doğru değildir; disk, kalıcılık ve kurtarma için kullanılır.
VoltDB ile Redis arasındaki fark nedir?
Her ikisi de bellek içi çalışsa da amaçları farklıdır. Redis çoğunlukla anahtar-değer ve veri yapısı deposu olarak kullanılır; VoltDB ise tam SQL, ilişkisel şema ve çok ifadeli ACID işlemleri sunan bir veritabanıdır. Karmaşık, tutarlı işlemler gerektiğinde bu ayrım belirleyici olur.
VoltDB açık kaynak mı?
Geçmişte açık kaynak bir topluluk sürümü ile ticari bir sürüm birlikte sunulmuştur; ancak lisans koşulları ve sürüm ayrımı zaman içinde değişebildiğinden, güncel ve bağlayıcı bilgi için resmi ürün belgelerini esas almak gerekir.
Özet
VoltDB, ilişkisel modeli ve ACID garantilerini bellek içi, paylaşımsız ve belirlenimci bir yürütme motoruyla birleştiren bir NewSQL veritabanıdır. Tek iş parçacıklı bölüm modeli, saklı yordam merkezli işlemler ve komut günlüğü tabanlı dayanıklılık, sistemi yüksek hacimli ve düşük gecikmeli OLTP için optimize eder. Doğru iş yükü ve iyi bir bölümleme tasarımıyla önemli avantaj sağlar; genel amaçlı her senaryonun çözümü olduğu iddiasından ise uzak durmak gerekir.