Bilgi Bankası
MongoDBPerformans ve kapasite 15 dk 15.06.2026

MongoDB ölçeklenebilirlik: replica set, sharding ve shard key nasıl seçilir?

MongoDB yatay ölçeklenebilirlik denince sharding akla gelir; ama sharding yanlış shard key ile yapılırsa yükü dağıtmak yerine tek shardı yakar. Replica set erişilebilirlik sağlar, sharding kapasite dağıtır; ikisi aynı karar değildir.

Bu yazı sana şu durumda yardımcı olur
  • tek koleksiyon hızla büyüyor
  • bazı tenantlar tüm yükü taşıyor
  • sharding düşünülüyor ama shard key belirsiz
  • replica set var diye yatay ölçek tamam sanılıyor
  • bazı sorgular tek shard yerine tüm clusterı geziyor
Yazıyı bitirince

MongoDB’de replica set ve sharding farkını, shard key seçerken hangi soruları sormanız gerektiğini ve doküman modelinin ölçeği nasıl etkilediğini anlayacaksınız.

TürkDB açısından ürünleşme notu

Bu bölüm, TürkDB’nin ilgili problemi hangi ürün ilkeleri ve kontrol noktalarıyla ele alacağını anlatır. Kapsam, gerçek iş yükü ve ihtiyaçla birlikte netleşir.

TürkDB MongoDB tarafında cluster sağlığı, bağlantı, yedek ve kapasite görünürlüğünü sadeleştirmeyi hedefler. Shard key ve doküman modeli kararı ise ürünün okuma/yazma desenine göre verilmelidir; platform bu kararın etkisini izlenebilir hale getirmelidir.

Replica set ölçek değil, erişilebilirlik zemini sağlar

MongoDB replica set, primary ve secondary düğümlerle erişilebilirliği artırır. Primary düşerse yeni primary seçilir. Bu, yüksek erişilebilirlik için önemlidir; ama yazma kapasitesini otomatik olarak yatay büyütmez.

Secondary okuma bazı senaryolarda yardımcı olabilir; fakat stale read riski ve read preference davranışı ürün beklentisiyle birlikte düşünülmelidir.

Sharding kararı shard key kararıdır

Sharding, koleksiyon verisini birden fazla shard üzerine dağıtır. Bu dağılımın sağlığı shard key seçimine bağlıdır. Sürekli artan created_at gibi bir alan tek yöne yazma baskısı yaratabilir. Çok düşük kardinaliteli alanlar da dağılımı kötü yapar.

İyi shard key hem sorgularınızda kullanılır hem de veriyi dengeli dağıtır. Sadece benzersiz diye bir alanı shard key seçmek yeterli değildir.

  • Shard key yüksek kardinaliteye sahip olmalıdır.
  • Yazma yükünü tek shard üzerinde toplamamalıdır.
  • Sık sorgular shard key alanını kullanabiliyorsa hedefli sorgu artar.
  • Tenant bazlı sistemlerde büyük tenantlar ayrıca düşünülmelidir.

Hot shard büyümenin sessiz düşmanıdır

Sharded cluster var diye yük eşit dağılmaz. Eğer yazmaların çoğu aynı shard key aralığına gidiyorsa tek shard darboğaz olur. Sistem yatay görünür ama pratikte tek düğüm kadar davranır.

Bu yüzden chunk dağılımı, shard başına okuma/yazma, en büyük tenantlar ve sorgu hedefleme oranı izlenmelidir.

Shard key karar notu

mongodb-shard-key-decision.md
Koleksiyon:
En sık sorgular:
En sık yazma deseni:
Shard key adayı:
Kardinalite:
Tek yöne büyüme riski:
Büyük tenant etkisi:
Sorgular hedefli mi yoksa scatter-gather mı:

Kullanım örneği: çok tenantlı event koleksiyonu

Bir SaaS ürününde events koleksiyonu tenant_id ve created_at ile büyüyorsa yalnızca created_at shard key seçmek yazmaları yeni zaman aralığında yoğunlaştırabilir. Yalnızca tenant_id seçmek de büyük tenantları tek shardda toplayabilir.

Bu durumda bileşik shard key veya hashed yaklaşım değerlendirilebilir; ama karar gerçek sorgularla test edilmelidir. Panolar tenant ve zaman aralığıyla çalışıyorsa shard key bu okuma desenini de desteklemelidir.

Devam etmek istersen

Sorunu motor bazında derinleştirin

Benzer belirtiler farklı motorlarda farklı nedenlere dayanır; yayınlanan tüm rehberleri ana sayfadan takip edebilirsiniz.

Tüm makaleler