Database sharding kararını ne zaman ve nasıl ver

Database sharding başlı başına bir sanat. Tek bir veritabanı’ın kaldıramadığı yükte, veriyi birden fazla node’a bölmek. Kulağa basit geliyor. Pratikte en karmaşık database migration’lardan biri.

Onlarca projede sharding tartışması yaptım. Bazılarında uyguladık, bazılarında alternatif buluyorduk. Bu yazıda karar kriterlerini ve gerçek uygulama notlarını anlatacağım.

Sharding nedir, tekrar bakalım

Sharding verinin büyüklüğü tek bir DB server’ın kaldıramadığı noktada başlıyor. 2TB data, 50K QPS, tek PostgreSQL instance’ı yetmiyor.

Çözüm: veriyi “shard” dediğimiz parçalara böl. Her shard ayrı bir DB instance’ında. Uygulama shard key’e göre doğru instance’a query atıyor.

shard_0: user_id 0-999999
shard_1: user_id 1000000-1999999
shard_2: user_id 2000000-2999999

Ya da hash-based sharding:

shard = hash(user_id) % 4

Ne zaman sharding gerekli?

Çoğu proje sharding’e ihtiyaç duymadan tamamlanır. Gerekli olduğunu düşünmeden önce:

1. Vertical scaling’i tükettin mi?

Database server RAM 512GB+, CPU 64+ core, NVMe SSD. Bu seviyede vertical yeter. AWS RDS x1e.32xlarge 4TB RAM’li bile var.

2. Read replica yeter mi?

Read-heavy workload ise replica yeter. Master tek, replicas çok. Read load’u dağıtıyor.

3. Arşivleme yaptın mı?

Eski data (1+ yıl önce) hot table’dan ayrı bir arşive. Hot data 100GB’a düşerse tek server yeter.

Bu 3’ü denendikten sonra hâlâ yetersizlik varsa sharding gündeme gelebilir.

Sharding’in maliyetleri

Sharding’e geçmeden önce gerçekten ne maliyete geldiğini bilmek lazım:

1. Cross-shard query yok. JOIN across shards yok. Application layer’da aggregation gerekiyor. Birkaç saat süren iş birkaç haftaya çıkıyor.

2. Transactional guarantees azalıyor. Multiple shard’a yazma atomic değil. Distributed transaction pattern’ları (saga, 2PC) gerekiyor.

3. Rebalancing zor. Shard büyürse node ekle, veriyi redistribute et. Live system’de bu saatler/günler alabilir.

4. Failover complex. Bir shard down olursa? App partial down? Shard replica’ları da kurmak şart.

5. Backup/restore karmaşık. Her shard’ın ayrı backup’ı. Cross-shard consistency backup’ta zor.

6. Schema migration 4x zor. N shard varsa N kere migrate. Her shard’ın versiyonunu track etmek gerekiyor.

Operational overhead 2-3x artıyor. Küçük ekipler bunu taşıyamıyor.

Shard key seçimi

Sharding yapılacaksa en kritik karar: shard key ne olacak?

User-based sharding (en yaygın): Shard key user_id. Tek kullanıcı’nın tüm verisi tek shard’da. Kullanıcı bazlı query’ler tek shard’a gidiyor. Basic SaaS’lar için ideal.

Tenant-based sharding: Multi-tenant SaaS için. Her tenant ayrı shard. Enterprise müşterilerine “kendi shard’ınız” pazarlanabiliyor.

Geographic sharding: Avrupa kullanıcıları EU shard’da, US kullanıcıları US shard’da. Latency faydası, compliance (GDPR).

Time-based sharding: Eski data bir shard’da, yeni data başka. Logging/analytics için iyi.

Yanlış seçim geri dönülmez bir şey. 6 ay sonra fark etsen de, re-sharding 3-6 aylık proje.

Hot shard problemi

Sharding’in en kötü kabusu: hot shard. Tüm load bir shard’a gidiyor.

Örnek: e-ticaret sharded by customer_id. Bir mega customer binlerce order veriyor. O customer’ın shard’ı 5x daha yoğun. Diğer shard’lar boşta.

Fix’ler:

1. Re-sharding: Hot customer’ı kendi shard’ına taşı. Manuel karar.
2. Sub-sharding: Büyük customer’ı multiple shard’a böl (composite key).
3. Dynamic shard allocation: Shard yöneticisi sürekli load’u izliyor, rebalance ediyor.

Bu hepsi ek infrastructure. Shard yöneticisi custom-built veya Vitess gibi third-party.

Alternatif: Managed solutions

Kendi sharding’i kurmak yerine managed solutions düşün:

CockroachDB: SQL-compatible distributed database. Transparent sharding, no app changes. Automated rebalancing.

YugabyteDB: PostgreSQL-compatible distributed. Similar to CockroachDB.

Vitess: MySQL’in üzerine kurulu sharding layer. YouTube geliştirdi, open source.

AWS Aurora: Vertical olarak çok büyük (128TB storage, 64 core). Çoğu proje için sharding gerek kalmıyor.

Bu seçenekler operational complexity’yi azaltıyor. Ama cost ve lock-in trade-off’ları var.

Gerçek migration hikayesi

Bir SaaS projesinde kararımız: sharding yerine arşivleme + vertical scale.

Durum: PostgreSQL instance 500GB, 30K QPS. CPU %70, IOPS %80.

Sharding öncesi denediklerimiz:

1. Query optimization: Top 10 slow query’yi optimize ettik. IOPS %30 azaldı.
2. Partitioning: PostgreSQL native partitioning ile eski data’yı ayırdık. Hot table 80GB’a düştü.
3. Read replica: 2 replica ekledik, analytics query’ler replica’ya. Primary %50 rahatladı.
4. Vertical upgrade: db.r5.24xlarge’a (768GB RAM) yükselttik.

Toplam değişiklik: 3 hafta iş. 18 ay daha sharding gerekmedi. Sharding ise 3-6 aylık bir projeydi.

Lesson: sharding son çare. Önce diğer seçenekler.

Sharding yapacaksan checklist

Gerçekten sharding gerekliyse:

1. Shard key’i 2 kere düşün. Yanlış seçim 6 ay sonra geri dönülmez.
2. Cross-shard query’lere hazır ol. Application code’da aggregate layer.
3. Transaction pattern’ını belirle. Saga veya eventual consistency.
4. Monitoring per-shard. Hot shard detection erken.
5. Backup/restore automation. Manuel olmaz.
6. Replica’lar her shard için. Failover planı.
7. Schema migration tool’u. Ortalama 30 shard için migrate tool şart.
8. Load test with production data volume.

Bu 8 madde hazır değilse sharding’e girme. Yarım kurulmuş sharding ölüm.

Sonuç

Sharding son çare bir scaling tool. Vertical scaling + replica + partitioning + archiving çoğu proje için yetiyor. Gerçekten gerektiğinde ise managed solutions (CockroachDB, Vitess) kendi rolling-your-own’a göre daha güvenli.

Kararı veri volume + QPS + tolerans kombinasyonuyla ver. “Galiba scale lazım” ile değil. Monitoring kur, trend’e bak, 12-18 ay plan yap.