Veritabanı Ölçekleme: Replica, Sharding ve CQRS Kararları

Veritabanı ölçeklemede doğru sıra nedir?

Ucuzdan pahalıya: önce sorgu ve indeks disiplini, sonra önbellek, sonra okuma kopyaları, sonra partisyonlama — ve ancak bunlar ölçülebilir biçimde tükendiğinde sharding. Bu sıra keyfî değildir; her adım bir sonrakinden daha az operasyonel karmaşıklık satın alır. Sırayı atlayan ekipler, sorgu problemini altyapı problemi sanıp en pahalı çözümü en erken öder.

Strateji haritası: kazanç ve bedel

Okuma kopyaları: gecikmeyle yaşamayı öğrenmek

Read replica, okuma-ağırlıklı sistemlerde ilk büyük kazançtır; tek gerçek maliyeti replikasyon gecikmesidir: kopya, birincilin birkaç yüz milisaniye-birkaç saniye gerisinde olabilir. Bu yüzden yönlendirme kuralı iş semantiğiyle yazılır: 'kendi yazdığını okuma' gereken akışlar (sipariş verdim → siparişlerim listesi) birincilden veya oturum-yapışkan kopyadan okur; katalog ve raporlama gibi tazeliğe toleranslı okumalar kopyaya gider. Spring tarafında bu ayrım, işlem salt-okunur işaretleriyle (readOnly) veya açık yönlendirme katmanıyla kurulur; gecikme metriği panoya bağlanmadan kopya trafiğe alınmaz.

Partisyonlama: büyük tabloyu yönetilebilir kılmak

Yüz milyonlarca satıra ulaşan tablolar (sipariş, olay, log) partisyonlamanın doğal adayıdır. Zaman veya kiracı anahtarıyla bölünen tablo; indekslerin küçülmesi, bakım işlemlerinin partisyon bazında koşması ve eski verinin partisyon düşürerek saniyeler içinde budanması demektir. Kritik kural, sorguların partisyon anahtarını içermesidir — anahtarsız sorgu tüm partisyonları tarar ve kazanımı geri verir. Saklama politikası (KVKK süreleri dahil) partisyon şemasıyla birlikte tasarlandığında, 'silme' bir gece işi olmaktan çıkıp anlık operasyona döner.

Sharding: gerektiğinde güçlü, erken alındığında pahalı

Sharding, veriyi anahtar bazında bağımsız veritabanlarına böler ve yazma ölçeğinin gerçek cevabıdır; bedeli ise mimariye kalıcı yerleşir: çapraz-shard sorgular uygulama katmanında birleştirilir, çapraz-shard işlem garantisi yoktur (saga/outbox devreye girer), ve shard sayısını değiştirmek (resharding) planlı bir taşıma operasyonudur. İki tasarım kararı acıyı belirler: anahtar seçimi — trafiği dengeli bölen ve iş sorgularının çoğunu tek shard'da tutan anahtar (çoğunlukla müşteri/kiracı) — ve yönlendirme katmanı — anahtardan shard'a eşlemenin merkezî, sürümlenebilir yönetimi. İlk günden sanal shard (çok sayıda mantıksal bölme, az sayıda fiziksel sunucu) kurgusu, resharding'i veri taşımadan eşleme değişikliğine indirger.

CQRS: modeli değil, okumayı ölçeklemek

CQRS'in yüksek trafikteki değeri dogma değil pragmatizmdir: yazma modeli normalidir ve iş kurallarını korur; okuma tarafında ise ekranların ihtiyacına göre şekillenmiş, önceden hesaplanmış görünümler (denormalize tablolar, arama indeksi, önbelleklenmiş projeksiyonlar) beslenir. Besleme, değişiklik olaylarıyla asenkron yapılır — bu da nihai tutarlılık penceresi demektir ve kullanıcı deneyimi bu pencereyle birlikte tasarlanır. Uyarı da nettir: her CRUD ekranına CQRS uygulamak karmaşıklık israfıdır; desen, okuma şeklinin yazma modelinden gerçekten ayrıştığı yerde (panolar, listeler, arama) değer üretir.

İş etkisi: veritabanı kararları geri alınması en pahalı kararlardır

Uygulama kodu yeniden yazılır; yanlış shard anahtarı ise canlı veriyle taşınır. Bu yüzden veri katmanı stratejisi, büyüme projeksiyonuyla birlikte ve ölçüm eşlikli ilerlemelidir: hangi metrik hangi eşiği aşınca hangi adım devreye giriyor — yazılı bir merdiven. Bu merdivenin ticari karşılığı öngörülebilirliktir: kapasite artışı kriz değil plan olur, altyapı bütçesi büyümeyle orantılı kalır ve teknik due diligence süreçlerinde 'ölçek planınız ne?' sorusunun belgeli cevabı hazırdır.

Sık sorulan sorular

Replikasyon gecikmesi kullanıcıya nasıl yansımaz?

Yazma sonrası kritik okumaların birincile sabitlenmesi, oturum bazlı 'en az şu sürüme kadar taze' kuralları ve gecikme büyüdüğünde kopyayı trafikten düşüren sağlık kontrolleriyle.

Partisyonlama ile sharding aynı şey mi?

Hayır: partisyonlama tek veritabanı içinde tabloyu böler; sharding veriyi ayrı veritabanlarına dağıtır. İlki bakım ve tablo boyutu, ikincisi yazma ölçeği ve toplam kapasite içindir.

NoSQL'e geçmek sharding ihtiyacını kaldırır mı?

Dağıtık NoSQL motorları bölümlemeyi yerleşik yönetir; ama anahtar tasarımı, sıcak partisyon ve çapraz-bölüm sorgu maliyeti aynen sizinle gelir. Problem motor değişimiyle değil, erişim deseni tasarımıyla çözülür.

Bağlantı havuzu ölçeklemede neden kritik?

Veritabanının eşzamanlı işlem kapasitesi sınırlıdır; kontrolsüz büyüyen uygulama havuzları bu kapasiteyi kilitlenmeye çevirir. Havuz boyutları toplamda DB kapasitesine göre bütçelenir; gerekirse ara havuzlayıcı katmanı kullanılır.

Veri katmanı ölçek kontrol listesi

1. Yavaş sorgu/indeks disiplini tükenmeden üst adıma geçilmiyor

2. Okuma yönlendirme kuralları iş semantiğiyle yazılı; gecikme panoda

3. Dev tablolar için partisyon şeması ve saklama politikası birlikte tasarlandı

4. Shard anahtarı adayı ve sanal shard planı belgelendi

5. Çapraz-shard işlemler için saga/outbox hazırlığı mevcut

6. CQRS yalnızca ayrışan okuma şekillerinde; tutarlılık penceresi UX ile hizalı

7. Ölçek merdiveni (metrik → eşik → adım) yazılı ve gözden geçiriliyor

SSH Yazılım, veri katmanı ölçek stratejinizi — replica kurulumundan shard tasarımına — ölçüme dayalı kurar. Büyüme merdiveninizi birlikte yazalım.