DBAtlas · Veritabanı operasyon atlası

Referans Mimari: Çok-bölgeli / global

Kullanıcılar coğrafi olarak dağıldığında veya bölgesel felakete dayanıklılık gerektiğinde veri birden çok bölgeye yayılır. Bu ağaç; okuma yakınlığı (her bölgeye read replica), yazma topolojisi (tek-lider vs çok-lider vs quorum), veri yerelliği/uyumluluk (GDPR), çakışma çözümü ve RPO/RTO ile gecikme ödünleşimlerini adım adım ele alır. Temel gerçek: fizik yasaları nedeniyle düşük gecikme, güçlü tutarlılık ve çok-bölgeli yazma aynı anda tam sağlanamaz; bilinçli ödünleşim şarttır.

Çok-bölgeliye neden geçiyorsun: okuma yakınlığı mı, yazma/dayanıklılık mı, uyumluluk mu?

Çok-bölgeli mimari maliyetli ve karmaşıktır; motivasyonu netleştir. Uzak kullanıcılara düşük okuma gecikmesi mi istiyorsun, bölgeler arası yazma/felaket dayanıklılığı mı, yoksa verinin belirli ülkede kalması (yasal yerellik) mi asıl gereksinim?

  • Uzak kullanıcılara hızlı okuma; yazma tek bölgede kalabilir
  • Bölgeler arası yazma / bölge kaybına dayanıklılık gerekiyor
  • Veri yasal olarak belirli ülkede/bölgede kalmalı

Yazma topolojisi ne olsun: tek-lider mi, çok-lider mi, quorum mu?

Bölgeler arası yazmada temel karar liderlik modelidir. Tüm yazmalar tek bir bölgeye mi gidiyor (basit, tutarlı ama uzak yazma yavaş), her bölge yazabiliyor mu (düşük yazma gecikmesi ama çakışma), yoksa yazma bölgelerin çoğunluğunun onayıyla mı kabul ediliyor (quorum: tutarlı ama gecikmeli)?

  • Tek bölge yazsın, diğerleri okusun (basit ve tutarlı)
  • Her bölge yerel yazabilsin (düşük yazma gecikmesi)
  • Çoğunluk onayıyla yaz; tutarlılık öncelik

Öneri: Bölge başına okuma replikası (read locality)

Yazma tek bir primary bölgede kalırken, her kullanıcı bölgesine o bölgeden beslenen bir okuma replikası yerleştirirsin. Kullanıcılar en yakın replikadan okur, okuma gecikmesi düşer; yazmalar hâlâ tek merkeze gittiği için tutarlılık modeli basit kalır.

Öneri: Tek-lider (single-leader) yazma

Tüm yazmalar tek bir lider bölgeye gider; diğer bölgeler bu liderden asenkron beslenen okuma replikalarıdır. En basit ve en güçlü tutarlı modeldir; çakışma yoktur çünkü tek yazma noktası vardır. Bedeli, uzak bölgelerden yazmanın yüksek gecikmesidir.

Öneri: Çok-lider (multi-leader) yazma + çakışma çözümü

Her bölge yerel olarak yazabildiği için yazma gecikmesi düşüktür ve bir bölge kopsa bile diğerleri yazmaya devam eder. Bedeli ağırdır: aynı kaydı iki bölge farklı güncelleyebilir ve çakışma (conflict) çözümü tasarlamak zorundasın.

Öneri: Quorum tabanlı yazma (çoğunluk onayı)

Bir yazma, bölgelerin/kopyaların çoğunluğu (quorum) onayladığında kabul edilir; okuma da çoğunluktan yapılınca güncel değer garanti edilir. Bölge kaybına dayanıklı ve güçlü tutarlıdır; bedeli, her yazmanın çoğunluğa ulaşma gecikmesidir.

Öneri: Veri yerelliği / uyumluluk (data residency, GDPR)

Bazı verilerin (kişisel veri, sağlık, finans) yasal olarak belirli bir ülke/bölge sınırları içinde kalması gerekir (ör. GDPR). Bu durumda mimariyi 'her yere kopyala'ya göre değil, veriyi coğrafi olarak sabitleyecek şekilde tasarlarsın.

DBAtlas'ta aç →