MongoDB Sharding ile Yatay Ölçekleme

Tek bir MongoDB sunucusu disk kapasitesi, RAM ve CPU ile sınırlıdır. Veri seti büyüdükçe sorgular yavaşlar, yazma işlemleri darboğaz oluşturur ve yedekleme süreleri uzar. Sharding, veriyi birden fazla sunucuya (shard) dağıtarak bu sınırları ortadan kaldırır. Ancak yanlış shard key seçimi performansı iyileştirmek yerine daha da kötüleştirebilir. Bu rehberde MongoDB sharding mimarisini, doğru shard key stratejisini ve production ortamında dikkat edilmesi gereken noktaları somut örneklerle açıklıyoruz.

Sharding Mimarisi

MongoDB sharded cluster üç bileşenden oluşur:

Shard'lar

Verinin bir bölümünü tutan replica set'ler. Her shard bağımsız bir replica set olarak çalışır ve kendi verisinden sorumludur.

Config Server'lar

Cluster metadata'sını ve chunk dağılım haritasını tutan replica set. Hangi verinin hangi shard'da olduğunu bilir.

mongos Router'lar

Uygulama ile shard'lar arasında yönlendirme yapan query router. Sorguyu doğru shard'a yönlendirir.

Shard Key Seçimi

Shard key, verinin shard'lara nasıl dağıtılacağını belirler ve sharding'in en kritik kararıdır. Yanlış shard key seçimi tüm verinin tek bir shard'da toplanmasına (hotspot) veya her sorgunun tüm shard'lara gitmesine (scatter-gather) neden olur.

Shard Key Tipi	Avantaj	Dezavantaj	Kullanım Senaryosu
Ranged	Aralık sorguları hızlı	Monoton artan key'lerde hotspot	Tarih aralığı sorguları
Hashed	Eşit dağılım	Aralık sorguları scatter-gather	Yüksek yazma hacmi, eşit dağılım
Compound	Hem dağılım hem locality	Karmaşık planlama gerektirir	Multi-tenant, coğrafi dağılım

mongosh - sharding yapilandirmasi

// Sharding'i etkinlestir
sh.enableSharding("mydb")

// Hashed shard key - esit dagilim
sh.shardCollection("mydb.events", { _id: "hashed" })

// Compound shard key - tenant bazli izolasyon + tarih locality
sh.shardCollection("mydb.orders", { tenantId: 1, createdAt: 1 })

// Shard durumunu kontrol et
sh.status()

⚠️ Kritik: Shard key bir kez belirlendikten sonra değiştirilemez (MongoDB 5.0 öncesi). MongoDB 5.0+ ile reshardCollection komutu ile değiştirilebilir ancak bu işlem uzun sürer ve kaynak tüketir. Shard key seçimini production'a geçmeden önce test ortamında doğrulayın.

Chunk Balancer ve Veri Dağılımı

MongoDB veriyi chunk'lara böler (varsayılan 128 MB) ve balancer bu chunk'ları shard'lar arasında dengeli dağıtır. Dengesiz dağılım performans sorunlarına yol açar.

mongosh - balancer yonetimi

// Balancer durumunu kontrol et
sh.getBalancerState()
sh.isBalancerRunning()

// Balancer'i belirli saatlerde calistir (yogun olmayan saatler)
db.settings.updateOne(
  { _id: "balancer" },
  { $set: {
    activeWindow: { start: "02:00", stop: "06:00" }
  }}
)

// Chunk dagilimini kontrol et
db.orders.getShardDistribution()

Veritabanı karşılaştırması için MySQL vs PostgreSQL vs MongoDB rehberimizi, yedekleme stratejileri için Veritabanı Yedekleme Otomasyonu rehberimizi, veritabanı güvenliği için Veritabanı Güvenliği rehberimizi inceleyin. MongoDB Sharding Dokümantasyonu ve Shard Key Seçim Rehberi ek kaynak olarak faydalıdır.

Sıkça Sorulan Sorular

Sharding ne zaman gerekli olur?

Tek sunucunun disk kapasitesi, RAM veya yazma throughput'u yetersiz kaldığında sharding gerekir. Genel kural olarak veri seti 500 GB'ı aştığında veya saniyede 10.000+ yazma işlemi gerektiğinde sharding değerlendirilmelidir. Önce vertical scaling (daha güçlü sunucu) ve read replica'ları deneyin.

Minimum kaç shard ile başlamalıyım?

En az 2 shard ile başlayın. Her shard 3 üyeli replica set olmalıdır (1 primary + 2 secondary). Config server'lar için de 3 üyeli replica set gerekir. Toplam minimum: 6 shard node + 3 config node + 2 mongos = 11 process.

Sharding performansı her zaman artırır mı?

Hayır. Yanlış shard key seçimi scatter-gather sorgularına neden olur ve tek sunucudan daha yavaş olabilir. Shard key sorgu pattern'lerinize uygun olmalıdır. Sorgularınızın çoğu shard key'i içermiyorsa tüm shard'lara gider ve ağ overhead'i ekler.

ObjectId shard key olarak kullanılabilir mi?

Ranged shard key olarak ObjectId kullanmayın - monoton artan yapısı tüm yeni yazmaları son shard'a yönlendirir (hotspot). Hashed ObjectId kullanabilirsiniz ancak bu durumda tarih aralığı sorguları scatter-gather olur. İş yükünüze uygun compound key tercih edin.

Sonuç

MongoDB sharding büyük veri setlerinde yatay ölçekleme sağlar ancak operasyonel karmaşıklığı önemli ölçüde artırır. Shard key seçimini sorgu pattern'lerinize göre yapın, balancer'ı yoğun olmayan saatlere planlayın ve chunk dağılımını düzenli izleyin. Sharding'e geçmeden önce vertical scaling, read replica ve index optimizasyonu gibi daha basit çözümleri değerlendirin.

MongoDB Cluster İçin Yüksek Performanslı Sunucular

Hosted Cloud'un NVMe SSD sunucuları ile MongoDB sharded cluster performansınızı maksimize edin.

Bulut Sunucu Planlarını İncele →