Database Sharding Nedir? Veritabanı Ölçeklendirme Rehberi
Veritabanınız milyarlarca satıra mı ulaştı? Tek sunucu artık yetmiyor mu? Sharding ile verinizi birden fazla veritabanına yatay olarak bölerek sınırsız ölçeklenebilirlik elde edin.
Sharding Tanımı
Sharding, büyük bir veritabanını birden fazla küçük, bağımsız parçaya (shard) bölme tekniğidir. Her shard, verinin bir alt kümesini tutar ve bağımsız bir veritabanı sunucusunda çalışır.
Tek DB: [10 milyar satır] → Yavaş, tek sunucu limiti
Sharding: Shard A [0-3.3M] → Sunucu 1
Shard B [3.3M-6.6M] → Sunucu 2
Shard C [6.6M-10M] → Sunucu 3
Vertical vs Horizontal Scaling
| Yaklaşım | Açıklama | Sınır | |-----------|----------|-------| | Vertical (Scale Up) | Daha güçlü sunucu | Donanım limiti | | Horizontal (Scale Out) | Daha fazla sunucu (Sharding) | Neredeyse sınırsız |
Sharding Stratejileri
1. Key-Based (Hash) Sharding
shard_number = hash(shard_key) % total_shards
user_id: 42 → hash(42) % 3 = 0 → Shard A
user_id: 123 → hash(123) % 3 = 1 → Shard B
user_id: 456 → hash(456) % 3 = 2 → Shard C
Avantaj: Eşit dağılım Dezavantaj: Yeni shard eklemek (resharding) zor
2. Range-Based Sharding
Shard A: user_id 1 - 1.000.000
Shard B: user_id 1.000.001 - 2.000.000
Shard C: user_id 2.000.001 - 3.000.000
Avantaj: Range sorguları kolay Dezavantaj: Hotspot riski (yeni kullanıcılar hep son shard'a gider)
3. Directory-Based Sharding
Lookup tablosuyla hangi verinin hangi shard'da olduğunu tutma:
user_id: 42 → Lookup → Shard B
user_id: 123 → Lookup → Shard A
Avantaj: Esnek, istediğiniz gibi dağıtın Dezavantaj: Lookup tablosu darboğaz olabilir
4. Geographic Sharding
Türkiye kullanıcıları → Shard EU (İstanbul)
ABD kullanıcıları → Shard US (Virginia)
Asya kullanıcıları → Shard APAC (Singapur)
Shard Key Seçimi
Doğru shard key seçimi en kritik karardır:
| Kriter | İyi Seçim | Kötü Seçim | |--------|-----------|------------| | Eşit dağılım | user_id | country (dengesiz) | | Sorgu yerelliği | tenant_id | created_at (range sorgusu gerekir) | | Kardinalite | UUID | boolean |
Consistent Hashing
Yeni shard eklerken tüm veriyi taşımamak için:
Normal hash: hash(key) % 3 → Shard eklediğinde TÜM veriler yeniden dağıtılır
Consistent: Hash ring → Shard eklediğinde sadece komşu shard'ın verisi taşınır
Sharding Zorlukları
1. Cross-Shard Queries
Birden fazla shard'ı kapsayan sorgular yavaştır:
-- Kolay: Tek shard'da (shard key ile)
SELECT * FROM orders WHERE user_id = 42;
-- Zor: Tüm shard'larda (scatter-gather)
SELECT * FROM orders WHERE total > 1000 ORDER BY created_at;
2. Transactions
Shard'lar arası transaction (2PC) karmaşık ve yavaştır.
3. JOIN'ler
Farklı shard'lardaki tablolar arasında JOIN yapamazsınız.
4. Resharding
Shard sayısını değiştirmek büyük veri göçü gerektirir.
Sharding Araçları
| Araç | Veritabanı | Yaklaşım | |------|-----------|----------| | Vitess | MySQL | Proxy-based, YouTube ölçeği | | Citus | PostgreSQL | Extension-based | | MongoDB | MongoDB | Native sharding | | CockroachDB | — | Auto-sharding | | PlanetScale | MySQL (Vitess) | Managed, branching |
Sharding Öncesi Alternatifler
Sharding karmaşıktır. Önce şunları deneyin:
- Read replicas — Okuma trafiğini dağıtın
- Caching — Redis ile sık verileri cache'leyin
- Indexing — Sorgu optimizasyonu
- Vertical partitioning — Tabloları bölün (sık/nadir erişilen kolonlar)
- Archiving — Eski verileri arşive taşıyın
Best Practices
- Mümkün olduğunca geciktirin — Sharding son çare olmalı
- Doğru shard key — En başta doğru seçim yapın, sonra değiştirmek çok zor
- Consistent hashing — Resharding'i kolaylaştırır
- Application-level routing — Uygulama hangi shard'a gideceğini bilmeli
- Monitoring — Shard başına boyut, sorgu süresi ve hotspot izleme
Sonuç
Database Sharding, devasa veri hacimlerinde yatay ölçeklenebilirlik sağlar. Ancak karmaşıklık maliyeti yüksektir — cross-shard sorgular, transaction'lar ve resharding ciddi zorluklar getirir. Önce daha basit optimizasyonları deneyin, sharding gerçekten gerekli olduğunda uygulayın.
Veritabanı ölçeklendirme ve sharding'i LabLudus platformunda öğrenin.