Veritabanı Parçalama (Sharding) ve Yeniden Dengeleme

Stack: SOFTWARE ARCHITECTURE STACK →Staff/Principal (L6+)architectural-primitive

ÖZET VE TEKNİK CEVAP

Yüksek kardinaliteli ve homojen dağılan bir parçalama anahtarı (örn. Tenant ID veya Customer ID) seçerek, satırları sanal düğümlü Tutarlı Özetleme (Consistent Hashing) ile fiziksel sunuculara yayarak ve veri denormalizasyonuyla parçalar arası join'leri engelleyerek.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Tek sunucu donanımı CPU, bellek veya yazma IOPS sınırlarına ulaştığında, sharding veriyi bağımsız veritabanı sunucularına yatay olarak böler. Parçalama stratejileri: 1) Özet (Hash) Tabanlı Parçalama: Homojen dağılım için `hash(anahtar) % parça_sayısı` veya sanal düğümlü Tutarlı Özetleme halkaları; 2) Aralık (Range) Tabanlı Parçalama: Bitişik değer aralıklarına göre bölme (örn. A-F, G-M veya tarih aralıkları); 3) Dizin Tabanlı Yönlendirme: Hangi verinin hangi parçada olduğunu tutan merkezi bir haritalama servisi. Yönlendirici katmanlar (Vitess, Citus) sorgudaki parçalama anahtarını yakalayıp doğrudan ilgili sunucuya iletir.

2. Doğru Kullanım Senaryosu

En büyük bulut sunucularının fiziksel donanım sınırlarını aşan devasa yazma ağırlıklı OLTP iş yükleri (onlarca terabayt aktif veri, >100.000 yazma/sn).

3. Prodüksiyon Arıza Modları

1) Sıcak Nokta (Hotspot) Doygunluğu: Tek bir dev kurumsal müşterinin bulunduğu parçayı kilitlemesi; 2) Dağıt-Topla (Scatter-Gather) Patlaması: Sorguyu parçalama anahtarı olmadan çalıştırıp yönlendiricinin tüm 64 parçayı aynı anda sorgulamak zorunda kalması ve en yavaş düğümü beklemesi; 3) Çapraz Parça İşlem Hataları: Birden çok parçayı kapsayan dağıtık 2PC işlemlerinin yarı yolda kilitlenmesi.

4. Teşhis ve Telemetri Sinyalleri

Parçalar arasında aşırı CPU/IOPS dengesizliği (bir sunucu %95'teyken diğerlerinin %10'da kalması), scatter-gather sorgularındaki P99 gecikme artışları ve çapraz parça 2PC kilit çekişme oranları.

5. Önleme ve Mimari Bariyerler

Kesintisiz parça bölme için sanal düğümlü (vnode) Tutarlı Özetleme kullanın; ilişkili varlıkları (Siparişler ve SiparişDetayları) aynı parçalama anahtarı altında aynı sunucuda depolayın ve mimari düzeyde çapraz parça SQL join'lerini kesinlikle yasaklayın.

6. Mimari Ödünleşimler (Trade-offs)

Neredeyse sınırsız yatay yazma ölçeklenebilirliği sağlar; buna karşılık muazzam operasyonel karmaşıklık, tablolar arası yabancı anahtar (FK) kısıtlarının kaybı ve zorlu şema geçişleri getirir.

Vaka İncelemesi (TinyCTO Örneği)

TinyCTO Bölüm 110: Çok kiracılı bir SaaS platformu veritabanını `TenantID % 8` ile parçaladı. Global trafiğin %40'ını üreten dev müşteri Parça 3'e düştüğünde, o sunucu mesai saatlerinde sürekli çöktü. Tutarlı özetleme ve büyük müşterilere özel dinamik parçalama mimarisine geçiş, küme dengesini sağladı ve gecikmeyi 10 ms altına düşürdü.

İnteraktif Konsept Alıştırmaları

3 Alıştırma

Aralık tabanlı parçalamada artan sıralı ID'yi (Auto-Increment ID) parçalama anahtarı seçmenin temel riski nedir?

Tüm yeni yazma trafiği yalnızca en son parçaya yönlendirilir; bu da tek bir sunucuda aşırı sıcak nokta (hotspot) yaratırken eski sunucuların atıl kalmasına neden olur.

'Dağıt-Topla' (Scatter-Gather) sorgusu nedir ve veritabanı performansına neden zararlıdır?

Parçalama anahtarı olmadan çalıştırılan, koordinatörün sorguyu kümedeki her parçaya ayrı ayrı gönderip sonuçları birleştirmesini gerektiren ve gecikmeyi en yavaş sunucunun hızına düşüren sorgudur.

'Tutarlı Özetleme' (Consistent Hashing), veritabanı büyütme sırasında devasa veri taşınmasını nasıl engeller?

Yeni bir parça eklendiğinde tutarlı özetleme yalnızca `K/N` kadar anahtarı taşır; basit `hash % N` yöntemi ise tüm anahtarların neredeyse %100'ünün yerini değiştirip sistemi kilitler.

Veritabanı Parçalama (Sharding) ve Yeniden Dengeleme — Sıkça Sorulan Sorular

Bir mühendislik ekibi veritabanını ne zaman parçalamalıdır (shard etmelidir)?

Yalnızca son çare olarak. Öncelikle dikey büyütme, okuma replikaları, önbellekleme ve eski veri arşivleme yollarını tüketin. Sharding çok büyük mimari ve operasyonel yük getirir.

SQL'de birden fazla parça (shard) arasında benzersizlik (unique) kısıtı zorunlu kılınabilir mi?

Veritabanının yerel benzersizlik kısıtı yalnızca tek bir sunucu içinde geçerlidir. Parçalar arası global benzersizlik için dağıtık Redis kilitleri veya merkezi kimlik üreticileri (Twitter Snowflake) gerekir.

CockroachDB ve YugabyteDB gibi modern Dağıtık SQL (NewSQL) veritabanları nedir?

Uygulama kodundan manuel parçalama mantığını çıkararak, motor seviyesinde otomatik şeffaf sharding, Raft tabanlı dağıtık mutabakat ve çoklu parça ACID işlemleri sunan yeni nesil sistemlerdir.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

▸Sharding, 2000'lerin başında Google, eBay ve Flickr gibi dev internet şirketleri tarafından ilişkisel veritabanlarını tek sunucu sınırlarının ötesine taşımak için popülerleştirilmiştir.
▸Parçalama Anahtarı (Shard Key), parçalı bir sistemdeki en kritik tek mimari karardır; sonradan değiştirmek tüm kümenin baştan yazılmasını ve göçünü gerektirir.

Yaygın Yanılgılar

✗Sharding'in yavaş sorgular için hızlı bir çözüm olduğunu sanmak; indeksi olmayan sorgular parçalı sistemde aynı anda birden fazla sunucuyu kilitleyecektir.

Karar Kılavuzu & Önceliklendirme

Daima değiştirilemez ve yüksek kardinaliteli bir kiracı (tenant) veya müşteri kimliğiyle parçalayın. Kritik OLTP yollarında asla parçalar arası işlemsel join yapmayın.

Doğrulanmış Kaynaklar & Referanslar

[PAPER]Spanner: Google's Globally-Distributed Database— ACM Transactions on Computer Systems (TOCS) (2013)
[PAPER]Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web— ACM STOC (1997)