MongoDB ve NoSQL Veritabanı Geliştirme Rehberi [2026]

Veritabanı Seçimi Stratejik Bir Karardır

Her yazılım projesi bir veritabanı kararıyla başlar. Bu karar, uygulamanın performansını, ölçeklenebilirliğini ve bakım maliyetini doğrudan belirler. İlişkisel veritabanları onlarca yıldır standart olsa da, modern uygulama gereksinimleri NoSQL çözümlerini vazgeçilmez hale getirmiştir.

MongoDB, doküman tabanlı NoSQL veritabanları arasında en yaygın kullanılan çözümdür. 2026 itibarıyla Stack Overflow Developer Survey verilerine göre, profesyonel geliştiricilerin yüzde 28'i MongoDB'yi aktif olarak kullanmaktadır. E-ticaret, IoT, içerik yönetimi ve gerçek zamanlı analitik gibi alanlarda ilişkisel veritabanlarına güçlü bir alternatif sunmaktadır.

NoSQL Ne Zaman Dogru Secimdir

NoSQL veritabanları her proje için uygun değildir. Doğru seçimi yapabilmek için kullanım senaryosunu analiz etmek gerekir.

NoSQL tercih edilmeli:

• Veri yapısı sık değişiyor veya önceden tam olarak tanımlanamıyorsa
• Yatay ölçeklendirme (horizontal scaling) gereksinimi varsa
• Yüksek yazma hızı kritik öneme sahipse
• Hiyerarşik veya iç içe geçmiş (nested) veri yapıları kullanılıyorsa
• Coğrafi olarak dağıtık mimari planlanıyorsa

İlişkisel veritabanı tercih edilmeli:

• Veri bütünlüğü ve ACID uyumluluğu zorunluysa (finans, bankacılık)
• Karmaşık JOIN operasyonları sık kullanılıyorsa
• Veri yapısı katı ve önceden belirlenmiş ise
• Raporlama ve analitik sorguları ağırlıklıysa

MongoDB Veri Modelleme: Embedding ve Referencing

MongoDB'de veri modelleme, ilişkisel veritabanlarından temelden farklıdır. İki temel yaklaşım bulunur: embedding (gömme) ve referencing (referanslama).

Embedding (Gömme)

İlişkili veriler tek bir doküman içine yerleştirilir. Bu yaklaşım, birlikte okunan verilerde yüksek performans sağlar.

{
  "_id": ObjectId("..."),
  "ad": "Mehmet Yilmaz",
  "email": "[email protected]",
  "adresler": [
    { "tip": "ev", "sehir": "Ankara", "ilce": "Cankaya" },
    { "tip": "is", "sehir": "Ankara", "ilce": "Kizilay" }
  ]
}

Embedding, one-to-few ilişkilerde ve birlikte sorgulanan verilerde idealdir. Ancak doküman boyutu 16 MB sınırını aşmamalıdır.

Referencing (Referanslama)

İlişkili veriler ayrı koleksiyonlarda tutulur ve ObjectId ile bağlanır.

// Siparis koleksiyonu
{
  "_id": ObjectId("..."),
  "musteri_id": ObjectId("abc123"),
  "urunler": [ObjectId("prd001"), ObjectId("prd002")],
  "toplam": 1500.00
}

Referencing, one-to-many veya many-to-many ilişkilerde, bağımsız güncellenen verilerde ve büyük doküman boyutlarının söz konusu olduğu durumlarda tercih edilir.

Kriter	Embedding	Referencing
Okuma Performansı	Yüksek (tek sorgu)	Orta (birden fazla sorgu)
Yazma Performansı	Orta	Yüksek
Veri Tutarlılığı	Atomik güncelleme	Uygulama seviyesinde yönetim
Doküman Boyutu	Büyüyebilir	Sabit kalır
Kullanım Alanı	Alt dokümanlar, az değişen veri	Bağımsız varlıklar, sık güncelleme

Sema Tasarim Kaliplari

MongoDB, esnek şema yapısı sayesinde farklı tasarım kalıplarını destekler. Dogru kalıbın seçimi, sorgu performansını doğrudan etkiler.

Polymorphic Pattern (Polimorfik Kalıp)

Farklı yapıdaki dokümanlar aynı koleksiyonda tutulur. Örneğin bir e-ticaret sisteminde fiziksel ürün, dijital ürün ve abonelik farklı alanlara sahip olmasına rağmen tek bir "urunler" koleksiyonunda saklanabilir. Her doküman bir "tip" alanı taşır ve sorgulamada bu alana göre filtreleme yapılır.

Bucket Pattern (Kova Kalıbı)

Zaman serisi verileri gruplanarak tek bir dokümanda toplanır. IoT sensör verileri veya log kayıtları için idealdir. Örneğin, her saat için bir doküman oluşturulur ve o saate ait tüm ölçümler bir dizi içinde saklanır. Bu kalıp, indeks boyutunu ve doküman sayısını önemli ölçüde azaltır.

Outlier Pattern (Aykırı Değer Kalıbı)

Çoğu doküman küçük boyuttayken, az sayıda doküman aşırı büyüyorsa kullanılır. Örneğin bir sosyal medya uygulamasında çoğu kullanıcının 100-200 takipçisi varken bazı hesapların milyonlarca takipçisi olabilir. Bu durumda "has_overflow" bayrağı ile taşan veriler ayrı bir koleksiyona yönlendirilir.

Computed Pattern (Hesaplanmış Kalıp)

Sık hesaplanan değerler önceden hesaplanarak doküman içinde saklanır. Bir ürünün ortalama puanı, toplam sipariş sayısı gibi değerler her sorguda yeniden hesaplamak yerine güncelleme sırasında hesaplanarak kaydedilir. Bu, okuma ağırlıklı uygulamalarda ciddi performans kazanımı sağlar.

Indeks Turleri ve Performans Optimizasyonu

Doğru indeksleme, MongoDB performansının en kritik bileşenidir. İndeks olmadan MongoDB, sorguyu karşılamak için tüm koleksiyonu tarar (collection scan). Bu, büyük veri setlerinde kabul edilemez yanıt süreleri demektir.

Temel Indeks Turleri

Single Field Index: Tek bir alan üzerinde oluşturulur. En temel indeks türüdür. db.collection.createIndex({ email: 1 }) gibi tanımlanır.

Compound Index: Birden fazla alan üzerinde oluşturulur. Sorgu kalıplarıyla uyumlu olmalıdır. Alan sıralaması, ESR kuralına (Equality, Sort, Range) göre belirlenmelidir.

Text Index: Metin arama için kullanılır. Tam metin arama (full-text search) yapılabilir. Türkçe dahil birçok dili destekler.

Geospatial Index: Coğrafi konum verileri üzerinde 2dsphere veya 2d indeks oluşturulur. "Yakınımdaki restoranlar" gibi konum tabanlı sorgular için kullanılır.

Wildcard Index: Dinamik alan adlarına sahip dokümanlarda kullanılır. db.collection.createIndex({ "$**": 1 }) ile tüm alanlar indekslenir. Şema yapısı önceden bilinmeyen durumlarda faydalıdır.

Indeks Stratejisi

Etkili bir indeks stratejisi oluşturmak için explain() metodu ile sorgu planlarını analiz etmek gerekir. Her indeks yazma operasyonlarını yavaşlattığı için gereksiz indekslerden kaçınılmalıdır. Kullanılmayan indeksler db.collection.getIndexes() ve $indexStats ile tespit edilerek kaldırılmalıdır.

Aggregation Pipeline Tasarimi

Aggregation pipeline, MongoDB'nin en güçlü sorgu mekanizmasıdır. Verileri birden fazla aşamadan (stage) geçirerek dönüştürür, gruplar ve analiz eder.

db.siparisler.aggregate([
  { $match: { tarih: { $gte: ISODate("2026-01-01") } } },
  { $unwind: "$urunler" },
  { $group: {
      _id: "$urunler.kategori",
      toplam_satis: { $sum: "$urunler.fiyat" },
      siparis_sayisi: { $sum: 1 }
  }},
  { $sort: { toplam_satis: -1 } },
  { $limit: 10 }
])

Pipeline optimizasyon kuralları:

• $match ve $project aşamalarını mümkün olduğunca erken yerleştirin. Bu, sonraki aşamalarda işlenecek veri miktarını azaltır.
• $match aşaması indeks kullanabilir, ancak yalnızca pipeline'ın ilk aşamasında ise.
• $lookup (JOIN benzeri) operasyonu maliyetlidir; mümkünse embedding ile ihtiyacı ortadan kaldırın.
• allowDiskUse: true parametresi, 100 MB bellek sınırını aşan pipeline'lar için disk kullanımını etkinleştirir.

MongoDB Atlas ve Self-Hosted Karsilastirmasi

Kriter	MongoDB Atlas	Self-Hosted
Kurulum	Dakikalar	Saatler/gunler
Yonetim	Tam yonetilen	Manuel yonetim
Olceklendirme	Otomatik	Manuel konfigürasyon
Maliyet (kucuk olcek)	Uygun (free tier var)	Sunucu maliyeti
Maliyet (buyuk olcek)	Yuksek olabilir	Daha uygun
Gizlilik	Bulut saglayici	Tam kontrol
Yedekleme	Otomatik	Manuel konfigürasyon
Izleme	Dahili araçlar	Prometheus/Grafana kurulumu

Startuplar ve orta ölçekli projeler için Atlas, hızlı başlangıç ve düşük operasyonel yük sunar. Büyük ölçekli kurumsal projeler veya veri egemenliği gereksinimleri olan kuruluşlar için self-hosted dağıtım daha uygun olabilir.

Sharding Stratejileri ve Shard Key Secimi

Sharding, MongoDB'nin yatay ölçeklendirme mekanizmasıdır. Veriler, shard key'e göre birden fazla sunucuya dağıtılır. Shard key seçimi geri dönüşü zor bir karardır ve dikkatli yapılmalıdır.

Iyi bir shard key özellikleri:

• Yüksek kardinalite (çok sayıda benzersiz değer)
• Düşük frekans (değerlerin eşit dağılımı)
• Monoton olmayan artış (zaman damgası tek başına kötü bir seçimdir)
• Sorgu kalıplarıyla uyumluluk (sorgular tek shard'a yönlendirilebilmeli)

Shard key örnekleri:

• E-ticaret: { musteri_id: 1, siparis_tarihi: 1 } (hashed + ranged)
• IoT: { cihaz_id: "hashed" } (eşit dağılım)
• Çok kiracılı SaaS: { tenant_id: 1 } (kiracı izolasyonu)

Yanlış shard key seçimi, "jumbo chunk" sorununa ve dengesiz veri dağılımına yol açar. Üretim ortamına geçmeden önce gerçekçi veri hacmiyle test yapılmalıdır.

Replikasyon ve Yuksek Erisilebilirlik

MongoDB replica set, verinin birden fazla sunucuda kopyalanmasını sağlar. Bir replica set, bir primary ve en az iki secondary düğümden oluşur.

Replica set avantajları:

• Otomatik failover: Primary düğüm çökerse, secondary düğümlerden biri saniyeler içinde primary olarak seçilir.
• Okuma ölçeklendirme: Secondary düğümlerden okuma yapılarak (read preference) okuma yükü dağıtılabilir.
• Veri dayanıklılığı: Veriler birden fazla sunucuda tutularak veri kaybı riski minimize edilir.

Write concern ayarları:

• w: 1 - Yalnızca primary'ye yazıldığında onay (hızlı, daha az güvenli)
• w: "majority" - Çoğunluk onayı (dengeli)
• w: 3 - Üç düğüme yazıldığında onay (yavaş, en güvenli)

Üretim ortamlarında w: "majority" önerilir. Finansal işlemler gibi kritik verilerde w: 3 veya üzeri kullanılabilir.

MongoDB ile Uygulama Gelistirme

Node.js Driver Best Practices

// Baglanti havuzu (connection pool) konfigürasyonu
const client = new MongoClient(uri, {
  maxPoolSize: 50,
  minPoolSize: 5,
  maxIdleTimeMS: 30000,
  connectTimeoutMS: 10000,
  retryWrites: true,
  retryReads: true
});

// Uygulama yasam dongusu boyunca tek bir client kullanin
// Her istek icin yeni baglanti ACMAYIN

Python Driver (PyMongo) Best Practices

from pymongo import MongoClient

client = MongoClient(
    uri,
    maxPoolSize=50,
    minPoolSize=5,
    retryWrites=True,
    w="majority"
)

# Bulk operasyonlar icin insert_many veya bulk_write kullanin
# Tek tek insert yapmak yerine toplu islem tercih edin
koleksiyon.insert_many(dokuman_listesi, ordered=False)

Ortak kurallar:

• Bağlantı havuzunu uygulama başlangıcında oluşturun ve paylaşın.
• Hata yönetiminde retry mekanizması kullanın; geçici ağ hataları yaygındır.
• Büyük sonuç setlerinde cursor kullanın; tüm veriyi belleğe yüklemeyin.
• Projection ile yalnızca ihtiyaç duyulan alanları çekin.

Change Streams ve Real-Time Uygulamalar

Change streams, MongoDB koleksiyonlarındaki değişiklikleri gerçek zamanlı olarak dinlemeyi sağlar. Bu özellik, event-driven mimarilerde ve gerçek zamanlı uygulamalarda kritik bir bileşendir.

const degisiklikAkisi = koleksiyon.watch([
  { $match: { operationType: { $in: ["insert", "update"] } } }
]);

degisiklikAkisi.on("change", (degisiklik) => {
  // Bildirim gonder, cache guncelle, arama indeksini senkronize et
  console.log("Degisiklik algilandi:", degisiklik.documentKey);
});

Kullanım senaryoları:

• Gerçek zamanlı bildirimler (sipariş durumu güncellemeleri)
• Cache invalidation (önbellek güncellemesi)
• Elasticsearch veya Algolia ile arama indeksi senkronizasyonu
• Mikroservisler arası veri senkronizasyonu
• Audit log (denetim kaydı) oluşturma

Change streams, replica set veya sharded cluster gerektirir. Standalone MongoDB sunucusunda çalışmaz.

MongoDB ve PostgreSQL: Ne Zaman Hangisi

Bu iki veritabanı birbirinin rakibi değil, tamamlayıcısıdır. Proje gereksinimlerine göre doğru aracı seçmek önemlidir.

Kriter	MongoDB	PostgreSQL
Veri Modeli	Doküman (JSON/BSON)	İlişkisel (tablolar)
Sema Esnekligi	Esnek, dinamik	Katı, tanımlı
ACID Desteği	Multi-document (4.0+)	Tam destek
Olceklendirme	Yatay (sharding)	Dikey (öncelikli)
JOIN Performansi	Sınırlı ($lookup)	Güçlü, optimize
Tam Metin Arama	Atlas Search	tsvector/tsquery
JSON Desteği	Native (BSON)	JSONB (güçlü)
Coğrafi Sorgular	Dahili destek	PostGIS eklentisi

MongoDB tercih edin: Hızlı prototipleme, değişken veri yapıları, yüksek yazma hacmi, gerçek zamanlı analitik, içerik yönetim sistemleri.

PostgreSQL tercih edin: Finansal işlemler, karmaşık raporlama, güçlü veri bütünlüğü gereksinimleri, çoklu tablo ilişkileri.

Polyglot persistence yaklaşımıyla her iki veritabanı aynı projede farklı ihtiyaçlar için birlikte kullanılabilir. Örneğin ürün kataloğu MongoDB'de, ödeme işlemleri PostgreSQL'de tutulabilir.

Sonuc

MongoDB ve NoSQL veritabanları, doğru senaryolarda kullanıldığında geliştirme hızını, uygulama performansını ve ölçeklenebilirliği önemli ölçüde artırır. Ancak başarılı bir MongoDB projesi, iyi bir veri modelleme stratejisi, doğru indeksleme, uygun şema tasarım kalıpları ve replica set konfigürasyonu gerektirir.

Smart Maple olarak, Ankara merkezli yazılım geliştirme projelerimizde MongoDB ve NoSQL veritabanlarını etkin biçimde kullanmaktayız. Veri modelleme, performans optimizasyonu ve ölçeklendirme konularında deneyimli ekibimiz, projenizin gereksinimlerine en uygun veritabanı mimarisini tasarlamak için hazırdır. Veritabanı stratejinizi belirlemek veya mevcut sisteminizi optimize etmek için bizimle iletisime gecin.