Cassandra ve Dağıtık Veritabanı Mimarileri: Uygulanabilir Bir Geliştirici Rehberi

Dağıtık veritabanlarına geçiş çoğu zaman "tek sunucu yetmiyor" cümlesiyle başlar, ama asıl mesele ölçek değildir. Cassandra özelinde iş; veri modelini sorguya göre kurmak, tutarlılık seviyesini bilinçli seçmek ve hata durumlarını baştan tasarlamaktır. Bu rehber, ilişkisel veritabanı ve temel dağıtık sistem kavramlarına aşina orta seviye geliştiriciler için pratik bir yol haritası sunar.

Önkoşullar ve Kapsam

• İlişkisel veritabanları ve SQL ile çalışmış olmak.
• Replikasyon, bölümleme (partitioning) ve tutarlılık kavramlarına temel düzeyde aşina olmak.
• Komut satırı ve Docker kullanımına yatkınlık.

Kapsam notu: Cassandra sürüm numarası burada verilmemektedir; aşağıdaki kavramlar ve CQL söz dizimi Cassandra'nın uzun süredir korunan temel yapı taşlarıdır. Kullandığınız sürümün resmi dokümantasyonundan söz dizimini ve varsayılanları doğrulayın. Farklı sürümlerde bazı ifadeler ve varsayılanlar değişebilir.

Cassandra'yı Diğer Dağıtık Modellerden Ayıran Nedir?

Dağıtık veritabanı mimarileri kabaca birkaç eksende ayrılır:

• Paylaşımlı disk (shared-disk): Tüm düğümler aynı depolamaya erişir. Ölçekleme sınırlıdır, tek darboğaz noktası riski yüksektir.
• Paylaşımsız (shared-nothing) / bölümlenmiş: Her düğüm kendi verisini ve diskini yönetir. Cassandra bu gruptadır.
• Ana düğüm (primary/replica) tabanlı: Bir yazma otoritesi vardır; yük devretme ve tutarlılık yönetimi uygulama katmanına veya bir koordinatöre düşer.
• Lider seçimli (consensus) sistemler: Yazma için çoğunluk onayı gerekir; tutarlılık güçlüdür ancak gecikme ve erişilebilirlik ödünleşimleri farklıdır.

Cassandra, halka (ring) topolojisinde çalışır, veriyi tutarlı karma (consistent hashing) ile düğümlere dağıtır ve eşdüzey (peer-to-peer) mimarisiyle merkezi bir koordinatör olmadan çalışır. Her yazma, anahtara göre belirlenen düğümlere replike edilir. Bu model yatay ölçeklenmeyi ve yüksek yazma verimini kolaylaştırır; karşılığında sorgu esnekliği ve güçlü tutarlılık konusunda ödün verir.

1. Adım: Veri Modelini Sorguya Göre Kurun

İlişkisel düşüncede önce tabloyu normalize eder, sonra sorgularız. Cassandra'da sıra terstir: önce erişim desenini (access pattern) tanımlar, sonra tabloyu ona göre kurarsınız. Aynı veri, farklı sorgular için birden fazla tabloda (denormalize) tutulabilir.

Birincil anahtar iki parçadan oluşur:

• Partition key: Verinin hangi düğüme/halka dilimine gideceğini belirler.
• Clustering key: Aynı bölüm içindeki satırların fiziksel sıralamasını ve sorgu sırasını belirler.

-- Kullanıcı bazlı son olayları tutan tablo
CREATE TABLE events_by_user (
    user_id     uuid,
    event_time  timestamp,
    event_type  text,
    payload     text,
    PRIMARY KEY ((user_id), event_time)
) WITH CLUSTERING ORDER BY (event_time DESC);

user_id partition key, event_time clustering key'dir. Bu tablo, tek bir kullanıcının son olaylarını zamana göre tersten getirmek için tasarlanmıştır. Aynı veriyi event_type bazlı sorgulamak istiyorsanız, ayrı bir tablo (events_by_type) oluşturmanız gerekir.

Yaygın hata: Partition key olarak düşük kardinaliteli bir alan (örneğin event_type veya country) seçmek. Bu, tüm yükün birkaç düğüme yığılmasına — yani sıcak bölüme (hot partition) — yol açar. Partition başına satır sayısı da kontrol edilmelidir; çok büyüyen tek bir partition, düğümler arası dengesizliğe neden olur.

2. Adım: CQL ile Sorgu Yazarken Kuralları Bilin

Cassandra Query Language (CQL) SQL'e benzer, ancak önemli kısıtları vardır:

• WHERE ifadesinde partition key kısıtlanmadan tam tablo taraması yapılamaz.
• ALLOW FILTERING kullanmak çoğu zaman yanlış veri modelinin işaretidir; üretimde kaçının.

-- Partition key tam verildiği için verimli
SELECT event_type, payload
FROM events_by_user
WHERE user_id = 550e8400-e29b-41d4-a716-446655440000
LIMIT 20;

-- Clustering key aralığı ile zaman dilimi sorgusu
SELECT event_time, event_type
FROM events_by_user
WHERE user_id = 550e8400-e29b-41d4-a716-446655440000
  AND event_time >= '2024-01-01'
  AND event_time <  '2024-02-01';

İkinci sorgu, tek bir partition içinde sıralı tarama yapar; bu Cassandra'nın en verimli çalıştığı senaryodur.

Beklenen davranış: Aynı partition içindeki sorgular hızlıdır ve tek düğüme (artı replikalarına) gider. Partition key'i belirtilmeyen sorgular ise istisna ile reddedilir veya ALLOW FILTERING ile tüm düğümleri tarar; bu ölçekte çöker.

3. Adım: Tutarlılık Seviyesini Bilinçli Seçin

Cassandra'da tutarlılık, sorgu başına ayarlanabilir. Okuma ve yazma için ayrı seviyeler seçilir:

• ONE: Tek replikadan onay yeterlidir. Hızlı, ama tutarlılık zayıf.
• QUORUM: Replikaların çoğunluğu onay verir. Yaygın denge noktası.
• ALL: Tüm replikalar onay verir. En güçlü tutarlılık, en yavaş ve tek replika düşerse başarısız.

Kritik kural: Yazma ve okuma seviyelerinin toplamı replikasyon faktörünü (RF) aşarsa güçlü tutarlılık elde edilir. Örneğin RF=3 için yazma QUORUM + okuma QUORUM güçlü tutarlılık sağlar (2+2 > 3).

-- Tutarlılık seviyesini oturum bazında ayarlama
CONSISTENCY QUORUM;

-- Tek bir sorgu için geçici ayar (sürüme göre söz dizimi değişebilir)
SELECT * FROM events_by_user
WHERE user_id = 550e8400-e29b-41d4-a716-446655440000
USING CONSISTENCY QUORUM;

Ödünleşim: ONE seçmek gecikmeyi düşürür ama eski (stale) veri okuma riskini artırır. ALL seçmek tutarlılığı artırır ama bir replika düştüğünde yazma/okuma başarısız olur ve erişilebilirliği azaltır. Dağıtık sistemlerde tutarlılık ve erişilebilirlik arasındaki bu gerilim, CAP teoreminin pratikteki yansımasıdır.

4. Adım: Hata ve Onarım Mekanizmalarını Tanıyın

Cassandra, "her zaman yazılabilir" felsefesiyle çalışır. Bir replika geçici olarak erişilemezse yazma, erişilebilir replikalara yapılır ve düğüm geri döndüğünde farklar çözülür:

• Hinted handoff: Erişilemeyen düğüm için yazma, başka bir düğümde geçici olarak saklanır.
• Read repair: Okuma sırasında replikalar arası fark tespit edilirse güncel veri yayılır.
• Anti-entropy repair (ör. nodetool repair): Periyodik olarak replikalar arasındaki tutarsızlıkları giderir. Düzenli çalıştırılması operasyonel bir gerekliliktir.

Bu mekanizmalar güçlü tutarlılığı garanti etmez; nihai tutarlılık (eventual consistency) sağlar. Uygulamanızın bir yazmadan sonra hemen güncel veriyi okuması gerekiyorsa, tutarlılık seviyelerini buna göre ayarlamalısınız.

5. Adım: Silmeyi ve Zaman Aşımını (TTL) Doğru Kullanın

Cassandra'da silme işlemi veriyi hemen diskten kaldırmaz; bir mezar taşı (tombstone) yazar. Tombstone'lar okuma sırasında filtrelenir ve belirli bir süre sonra (grace period) sıkıştırma (compaction) sırasında temizlenir. Çok fazla tombstone birikmesi, okuma performansını ciddi biçimde düşürür.

-- 30 gün sonra otomatik silinecek kayıt
INSERT INTO events_by_user (user_id, event_time, event_type, payload)
VALUES (550e8400-e29b-41d4-a716-446655440000, toTimestamp(now()), 'login', '{}')
USING TTL 2592000;

-- Belirli bir kaydı silme (tombstone oluşturur)
DELETE FROM events_by_user
WHERE user_id = 550e8400-e29b-41d4-a716-446655440000
  AND event_time = '2024-01-15 10:00:00';

Yaygın hata: Yüksek yazma hacimli tablolarda satır satır silme yapmak. Sürekli silinen ve yeniden yazılan veri, tombstone birikimine yol açar. Zaman serisi verilerde satır silmek yerine TTL tercih edin.

Güvenlik Etkileri

• Kimlik doğrulama ve yetkilendirme: Cassandra varsayılan olarak kimlik doğrulamayı devre dışı bırakabilir. Üretimde kimlik doğrulamayı açın ve rol tabanlı erişim (RBAC) ile tablo/seviye bazlı yetki verin.
• Ağ izolasyonu: Düğümler arası ve istemci-düğüm trafiği güvenilmeyen ağlardan geçmemelidir. Düğümler arası iletişim için şifreleme ve istemci bağlantıları için TLS kullanın.
• Hassas veri: Cassandra veriyi varsayılan olarak diskte şifrelemez. Disk şifrelemesi ve uygulama katmanında alan bazlı şifreleme değerlendirin.
• Sorgu enjeksiyonu: CQL de parametreli sorgularla yazılmalıdır; kullanıcı girdisini string birleştirme ile sorguya eklemeyin.

Operasyonel Kontrol Listesi

• Partition key'i kardinalitesi yüksek ve erişim desenine uygun seçin; sıcak bölümlerden kaçının.
• Her sorgu için tutarlılık seviyesini bilinçli belirleyin; QUORUM çoğu senaryo için dengeli bir başlangıçtır.
• nodetool repair gibi anti-entropy bakımını düzenli planlayın.
• Tombstone birikimini izleyin; zaman serisi verilerde TTL kullanın.
• Kimlik doğrulama, yetkilendirme ve ağ şifrelemesini üretimde zorunlu tutun.

Sonuç

Cassandra'nın gücü, veri modelini sorguya göre kurduğunuzda ve tutarlılık seviyelerini bilinçli seçtiğinizde ortaya çıkar. İlişkisel alışkanlıklarla yaklaşmak — normalize şema, serbest WHERE, varsayılan tutarlılık — en sık yapılan hataların kaynağıdır. Dağıtık mimarinin ödünleşimlerini baştan kabul edip tasarımı buna göre yaptığınızda, sistem hem ölçeklenir hem de öngörülebilir davranır. Sürüme özgü ayrıntılar için mutlaka kullandığınız Cassandra sürümünün resmi dokümantasyonunu referans alın.