COLLSCAN neden bir uyarı işaretidir?
Koleksiyon küçükken COLLSCAN can yakmaz; hatta ekip “çalışıyor işte” diye düşünür. Veri büyüdüğünde aynı sorgu CPU, disk ve bellek baskısı üretir. Özellikle tenant_id, status, created_at gibi alanlarla filtrelenen çok kiracılı uygulamalarda compound index erken tasarlanmalıdır.
Explain çıktısında totalDocsExamined değeri nReturned değerinden çok büyükse, sorgu gereğinden fazla doküman geziyor demektir.
executionStats ile plan okuma
db.orders.find(
{ tenant_id: "acme", status: "paid" },
{ _id: 1, status: 1, created_at: 1 }
).sort({ created_at: -1 }).limit(50).explain("executionStats")Compound index sırasını doğru seçin
MongoDB compound index tasarımında önce eşitlik filtreleri, sonra sıralama ve range alanları düşünülür. Sorgu tenant_id ve status ile filtreleyip created_at ile sıralıyorsa index sırası bu erişim biçimini yansıtmalıdır.
Çok kiracılı sorgu için indeks
db.orders.createIndex(
{ tenant_id: 1, status: 1, created_at: -1 },
{ name: "idx_orders_tenant_status_created" }
)
db.orders.getIndexes()İndeks eklemeden önce sorgu desenini sabitleyin
MongoDB’de her yavaş sorguya indeks eklemek kısa vadede rahatlatır ama yazma maliyetini ve disk kullanımını artırır. Önce hangi sorgunun ürün açısından kritik olduğunu, hangi alanlarla filtrelediğini ve hangi sıralamayı istediğini netleştirmek gerekir.
Aynı koleksiyonda hem katalog listeleme hem admin araması hem raporlama yapılıyorsa tek indeks seti hepsini çözmez. Kritik kullanıcı akışları için indeks, raporlama için ayrı okuma modeli veya aggregation çıktısı gerekebilir.
- Equality alanlarını compound index başına koyun.
- Sort alanını sorgunun kullandığı yönde ekleyin.
- Düşük seçiciliğe sahip boolean alanları tek başına indekslemeyin.
- Projection kullanarak büyük dokümanların gereksiz alanlarını taşımayın.
Replica set ve yönetilen operasyon
Yavaş sorgu bazen yalnızca sorgudan değil, replica lag veya disk baskısından da kaynaklanır. Uygulama secondary okumaya yönleniyorsa gecikme kullanıcıya eski veri veya dengesiz gecikme olarak dönebilir.
TürkDB’de MongoDB cluster oluşturma, bağlantı bilgisini alma ve yedek akışları tek arayüzdedir. Özellikle içerik ve katalog sistemlerinde geri yükleme edilebilirlik indeks değişiklikleri kadar önemlidir.
TürkDB MongoDB kullanım akışı
turkdb cluster create --name catalog-mongo \ --type mongodb \ --version 7.0 \ --plan standard \ --replicas 3 \ --wait turkdb connect catalog-mongo --no-tunnel turkdb backup create catalog-mongo turkdb backup list catalog-mongo
Düzeltmenin işe yaradığını nasıl anlarsınız?
İndeks ekledikten sonra explain çıktısında winningPlan tarafında IXSCAN görmeyi, totalDocsExamined değerinin nReturned değerine yaklaşmasını ve executionTimeMillis değerinin düşmesini beklersiniz.
Eğer IXSCAN var ama hâlâ çok doküman inceleniyorsa indeks sırası yanlış olabilir veya filtre alanları yeterince seçici değildir. Bu durumda sorgu tasarımı ve veri modeli tekrar ele alınmalıdır.
İndeks sonrası doğrulama
const plan = db.orders.find(
{ tenant_id: "acme", status: "paid" },
{ _id: 1, status: 1, created_at: 1 }
).sort({ created_at: -1 }).limit(50).explain("executionStats")
printjson({
nReturned: plan.executionStats.nReturned,
totalDocsExamined: plan.executionStats.totalDocsExamined,
executionTimeMillis: plan.executionStats.executionTimeMillis
})