MongoDB Temel Kavramları ve Uygulamaları

Günümüzde veri yönetimi, yazılım projelerinin en kritik bileşenlerinden biri. Geleneksel ilişkisel veritabanlarının sınırlamaları, modern uygulamaların ihtiyaçlarını karşılamakta yetersiz kalabiliyor. Bu noktada MongoDB, belge tabanlı yapısı ve esnek mimarisiyle öne çıkıyor. Özellikle e-ticaret, SaaS platformları ve cross-platform mobil uygulama geliştirme süreçlerinde, MongoDB'nin sunduğu hız ve ölçeklenebilirlik avantajları dikkat çekiyor. Noves Digital olarak, 150'den fazla projede edindiğimiz deneyimle hazırladığımız bu kapsamlı rehberde, MongoDB'nin temel kavramlarından gelişmiş uygulamalarına kadar her şeyi ele alacağız. Agile geliştirme süreçlerinde hızlı iterasyonlar ve kullanıcı deneyimi odaklı çözümler üreten profesyonel ekiplerde, doğru veritabanı seçimi projenin başarısını belirleyen kritik faktörlerden biridir.

Temel Kavramlar ve Avantajlar

MongoDB nedir; belge tabanlı veritabanı örnekleri

MongoDB, 2007 yılında piyasaya sürülen açık kaynaklı bir NoSQL veritabanıdır. Geleneksel tablo yapısına sahip ilişkisel veritabanlarının aksine, verileri BSON (Binary JSON) formatında koleksiyonlar içinde saklar. Bu yapı, karmaşık ilişkilerin ve hiyerarşik verilerin doğal bir şekilde temsil edilmesini sağlar. Örneğin, bir e-ticaret uygulamasında ürün bilgileri, varyasyonları, stok durumları ve yorumları tek bir belgede birleştirilebilir. Bu esneklik, API geliştirme süreçlerinde JSON formatıyla doğrudan çalışabilme avantajı sunar. Cross-platform projelerde, mobil uygulama ve web arayüzleri arasında veri tutarlılığını kolaylaştırır. Yapay zeka tabanlı öneri sistemleri gibi yapılandırılmamış veri yoğunluklu senaryolarda da tercih edilir.

// Basit bir ürün belgesi örneği
{
  "_id": ObjectId("..."),
  "name": "Akıllı Saat",
  "price": 1299.99,
  "category": "Elektronik",
  "variants": [
    { "color": "Siyah", "stock": 45 },
    { "color": "Beyaz", "stock": 12 }
  ]
}

Koleksiyon ve belge yapısı nasıl kullanılır; JSON/BSON farkları

MongoDB'de veriler koleksiyonlar içindeki belgelerde saklanır. Koleksiyon, ilişkisel veritabanlarındaki tablolara karşılık gelir ancak şema kısıtlaması içermez. Her belge, JSON benzeri BSON formatında tutulur. BSON, JSON'un binary uzantısıdır ve tarih, ObjectId, binary data gibi ek veri tiplerini destekler. JSON metin tabanlıyken BSON binary formattadır; bu sayede daha hızlı parse edilebilir ve daha az yer kaplar. Performans optimizasyonu açısından, BSON'un ek tipleri ve binary yapısı avantaj sağlar. Özellikle CI/CD pipeline'larında veri migrasyonu yapılırken, BSON formatı veri bütünlüğünü korur. Test edilebilirlik açısından, belge yapısı unit test yazımını kolaylaştırır çünkü beklenen çıktı doğrudan JSON olarak karşılaştırılabilir.

// Koleksiyona belge ekleme
db.products.insertOne({
  name: "Laptop",
  specs: { cpu: "M3", ram: "16GB" },
  createdAt: new Date()  // BSON Date tipi
});

Replikasyon ve yüksek erişilebilirlik avantajları

MongoDB'nin replikasyon özelliği, veri güvenliği ve yüksek erişilebilirlik sağlar. Replica set yapısı, birincil (primary) ve birden fazla ikincil (secondary) node'dan oluşur. Yazma işlemleri birincil node'a yapılırken, okuma işlemleri ikincil node'lara dağıtılabilir. Birincil node arızalandığında otomatik olarak bir ikincil node birincil rolü üstlenir. Bu mekanizma, SLA gereksinimleri yüksek SaaS ürünlerinde kesinti süresini minimuma indirir. E-ticaret platformlarında yoğun trafik dönemlerinde, okuma operasyonlarını ikincil node'lara yönlendirerek performans optimizasyonu sağlanabilir. Bulut tabanlı dağıtımlarda, farklı availability zone'lara yerleştirilen replica set'ler felaket kurtarma senaryolarında veri kaybını önler.

Veri Modelleme ve Sorgu Tasarımı

Şema tasarımı nedir; embed vs reference örnekleri

MongoDB'de şema tasarımı, uygulamanın veri erişim pattern'lerine göre yapılır. İki temel yaklaşım vardır: embedding (gömme) ve referencing (referans). Embedding, ilişkili verileri tek bir belgede saklamaktır; bu, okuma performansını artırır ancak belge boyutunu büyütür. Referencing ise ilişkili verileri ayrı koleksiyonlarda tutup ObjectId ile bağlamaktır; bu, veri tekrarını önler ancak join işlemi gerektirir. E-ticaret sepeti gibi sık birlikte erişilen veriler için embedding uygunken, kullanıcı profili ve sipariş geçmişi gibi bağımsız büyüyen veriler için referencing tercih edilir. Kullanıcı deneyimi açısından, sayfa yüklenme sürelerini minimize etmek için embedding stratejisi tercih edilebilir.

// Embedding örneği - sepet ve ürünler birlikte
{
  userId: ObjectId("..."),
  items: [
    { productId: "p1", name: "Kulaklık", qty: 2, price: 599 },
    { productId: "p2", name: "Mouse", qty: 1, price: 299 }
  ]
}

// Referencing örneği - siparişler ayrı koleksiyonda
// orders koleksiyonu
{ _id: ObjectId("..."), userId: ObjectId("..."), total: 1497 }

İndeksleme nasıl yapılır; performans etkileri

İndeksleme, sorgu performansını artıran kritik bir optimizasyon tekniğidir. MongoDB'de createIndex() komutuyla tek alanlı, bileşik, text, geospatial ve hash indeksleri oluşturulabilir. Doğru indeksleme, sorgu sürelerini milisaniyelerden mikrosaniyelere düşürebilir. Ancak her indeks yazma işlemlerini yavaşlatır ve disk alanı tüketir. E-ticaret ürün aramalarında, kategori ve fiyat alanlarına bileşik indeks eklemek performansı dramatik şekilde iyileştirir. API endpoint'lerinde response time SLA'ları karşılanmak isteniyorsa, sık kullanılan sorgu pattern'leri analiz edilerek stratejik indeksleme yapılmalıdır. Agile geliştirme süreçlerinde, yeni özellikler eklendikçe indeks stratejisi de gözden geçirilmelidir.

// Bileşik indeks oluşturma
db.products.createIndex({ category: 1, price: -1 });

// Text indeksi ile arama
db.products.createIndex({ name: "text", description: "text" });
db.products.find({ $text: { $search: "akıllı saat" } });

Aggregation framework kullanımı ve örnekleri

Aggregation framework, MongoDB'nin veri işleme ve analiz motorudur. Pipeline yapısı sayesinde verileri filtreleme, gruplama, sıralama ve dönüştürme işlemlerinden geçirebilirsiniz. $match, $group, $sort, $lookup gibi stage'ler bir araya getirilerek karmaşık analizler yapılır. E-ticaret platformlarında satış raporları, kullanıcı davranış analizleri ve envanter özetleri için idealdir. SaaS ürünlerinde müşteri segmentasyonu ve kullanım metrikleri hesaplamak için kullanılır. Yapay zeka pipeline'larında veri ön işleme adımı olarak da tercih edilebilir. Aggregation pipeline'ları, veritabanı seviyesinde çalıştığı için ağ trafiğini minimize eder ve uygulama katmanındaki işlem yükünü azaltır.

// Aylık satış raporu
db.orders.aggregate([
  { $match: { status: "completed" } },
  { $group: {
      _id: { $month: "$createdAt" },
      totalRevenue: { $sum: "$amount" },
      orderCount: { $sum: 1 }
  }},
  { $sort: { _id: 1 } }
]);

Pipeline optimizasyonu ve stage bazlı iyileştirmeler

Aggregation pipeline'ların verimliliği, stage sıralamasına bağlıdır. $match ve $project gibi veri miktarını azaltan stage'ler mümkün olan en başta yer almalıdır. $lookup (join) operasyonları maliyetli olduğundan, önce filtreleme yapılarak join edilecek veri seti küçültülmelidir. Index kullanımı için $match stage'inin sorgu pattern'leri indekslerle uyumlu olmalıdır. E-ticaret analitiklerinde, milyonlarca sipariş üzerinde çalışan pipeline'ların optimizasyonu kritiktir. Performans optimizasyonu için explain("executionStats") çıktısı analiz edilerek stage bazlı iyileştirmeler yapılmalıdır. Büyük veri setlerinde $limit ve $skip kombinasyonları yerine cursor-based pagination tercih edilmelidir.

// Optimize edilmiş pipeline
db.orders.aggregate([
  { $match: { status: "completed", createdAt: { $gte: startDate } } },
  { $sort: { createdAt: -1 } },
  { $limit: 1000 },
  { $lookup: { from: "users", localField: "userId", foreignField: "_id", as: "user" } }
], { allowDiskUse: true });

Görselleştirme ve İzlenebilirlik

Monitoring nedir; Ops Manager ve Cloud Monitoring örnekleri

Monitoring, MongoDB cluster'ının sağlığını ve performansını sürekli izleme pratiğidir. MongoDB Ops Manager, on-premise deployment'lar için kapsamlı monitoring, backup ve automation çözümü sunar. Atlas Cloud Monitoring ise bulut tabanlı deployment'larda real-time metrikler, özel alert'ler ve performans analizleri sağlar. CPU kullanımı, memory tüketimi, disk I/O, connection sayısı ve replication lag gibi metrikler izlenir. E-ticaret platformlarında Black Friday gibi yoğun dönemlerde, connection pool limitlerinin aşılmaması için proaktif monitoring şarttır. SaaS ürünlerinde multi-tenant yapılarda, tenant bazlı kaynak tüketimini izlemek için özel dashboard'lar oluşturulabilir. Profesyonel ekiplerde, monitoring stratejisi uygulama yaşam döngüsünün ayrılmaz bir parçasıdır.

// Atlas Monitoring API ile metrik çekme
const atlas = require('mongodb-atlas-api-client');
const metrics = await atlas.monitoring.getMeasurements({
  groupId: "proj-id",
  hostName: "cluster0-shard-00-00",
  granularity: "PT1M",
  metrics: ["QUERY_EXECUTION_TIME", "OPCOUNTER_QUERY"]
});

Loglama ve performans metrikleri nasıl yorumlanır

MongoDB logları, slow query'ler, connection hataları ve replication olaylarını kaydeder. db.setProfilingLevel(2) ile tüm operasyonlar loglanabilir; seviye 1 ile yalnızca yavaş sorgular yakalanır. Slow query log'larında millis alanı, sorgunun kaç milisaniyede tamamlandığını gösterir. 100ms üzerindeki sorgular optimize edilmelidir. db.currentOp() komutu, o anda çalışan operasyonları listeler ve uzun süren işlemleri tespit eder. E-ticaret sepet işlemlerinde yavaş sorgular, kullanıcı deneyimini doğrudan etkiler ve dönüşüm kaybına neden olabilir. Performans optimizasyonu için log analizi düzenli olarak yapılmalı ve trend'ler izlenmelidir. CI/CD süreçlerinde, deployment sonrası log pattern'leri otomatik olarak kontrol edilebilir.

# Slow query log analizi
grep "command.*ms" /var/log/mongodb/mongod.log | awk '{print $NF}' | sort -n | tail -20

# Profiling aktif etme
db.setProfilingLevel(1, { slowms: 50 })

Veri görselleştirme araçları ile dashboard örnekleri

MongoDB verilerini görselleştirmek için MongoDB Charts, Grafana, Kibana ve Tableau gibi araçlar kullanılabilir. MongoDB Charts, Atlas üzerinde doğrudan çalışan native bir çözümdür ve aggregation pipeline'ları görsel olarak oluşturmanıza olanak tanır. Grafana, Prometheus exporter ile MongoDB metriklerini görselleştirir ve özel alert'ler kurulabilir. E-ticaret yönetim panellerinde, günlük satış grafikleri, stok seviyeleri ve kullanıcı aktivite heatmap'leri oluşturulabilir. SaaS analitiklerinde, MRR (Monthly Recurring Revenue), churn rate ve activation funnel'ları izlenir. Kullanıcı deneyimi tasarımı açısından, dashboard'ların responsive tasarım prensiplerine uygun olması ve mobil cihazlarda da okunabilir olması gerekir.

// Atlas Charts için aggregation pipeline
[
  { $match: { createdAt: { $gte: new Date(Date.now() - 30*24*60*60*1000) } } },
  { $group: {
      _id: { $dateToString: { format: "%Y-%m-%d", date: "$createdAt" } },
      revenue: { $sum: "$total" }
  }},
  { $sort: { _id: 1 } }
]

Yerleşim, Dağıtım ve Mimari

Replica set ve sharding nedir; ne zaman kullanılır

Replica set, verinin birden fazla kopyasını farklı node'larda saklayarak yüksek erişilebilirlik sağlar. Sharding ise veriyi yatay olarak bölerek yazma ve okuma kapasitesini artırır. Sharding, tek bir server'ın RAM ve disk kapasitesini aştığında gereklidir. Genellikle veri boyutu 2TB'ı aştığında veya saniyede 50.000'den fazla okuma/yazma işlemi gerektiğinde sharding düşünülmelidir. E-ticaret platformlarında, milyonlarca ürün ve kullanıcı verisi sharding ile yönetilebilir. SaaS ürünlerinde multi-tenant mimaride, tenant ID shard key olarak seçilerek veri izolasyonu sağlanabilir. Replica set'ler felaket kurtarma için kritikken, sharding ölçeklenebilirlik için kullanılır.

// Sharding aktif etme
sh.enableSharding("ecommerceDB");
sh.shardCollection("ecommerceDB.orders", { customerId: "hashed" });

// Shard durumunu kontrol etme
sh.status();

Bulut vs on-premise dağıtım karar kriterleri

Bulut dağıtımı (Atlas), otomatik yedekleme, monitoring ve ölçeklendirme avantajları sunar. Operasyonel yükü azaltır ancak uzun vadede maliyetli olabilir. On-premise dağıtım ise tam kontrol ve veri lokasyonu esnekliği sağlar; ancak donanım, bakım ve uzman personel maliyetleri vardır. Regülasyon gereksinimleri (GDPR, KVKK) verinin fiziksel lokasyonunu belirleyebilir. Finans sektöründe hassas veriler on-premise tercih edilebilirken, startup'lar ve hızlı büyüyen e-ticaret siteleri bulut çözümlerini tercih eder. Maliyet analizinde, TCO (Total Cost of Ownership) hesaplanmalı ve 3-5 yıllık projeksiyon yapılmalıdır. Hybrid çözümler, kritik verileri on-premise'da tutup analitik iş yükünü buluta taşıyarak iki dünyanın avantajlarını birleştirir.

Çok bölgeli dağıtım ve veri tutarlılığı stratejileri

Çok bölgeli dağıtım, kullanıcıların coğrafi olarak en yakın veri merkezine erişmesini sağlayarak latency'yi düşürür. MongoDB Atlas Global Clusters, veriyi farklı bölgelerde otomatik olarak replike eder. Veri tutarlılığı, CAP teoremi bağlamında değerlendirilir: tutarlılık (consistency) ve erişilebilirlik (availability) arasında denge kurulmalıdır. E-ticaret ödeme işlemlerinde güçlü tutarlılık gerekirken, ürün önerilerinde eventual consistency kabul edilebilir. Cross-platform mobil uygulamalarda, kullanıcıların farklı bölgelerden erişimi göz önünde bulundurulmalıdır. Veri yerleşim stratejisi, kullanıcı dağılımına ve regülasyonlara göre belirlenmelidir.

Read preference ve write concern ayarlarının etkileri

Read preference, okuma işlemlerinin hangi node'dan yapılacağını belirler: primary (sadece birincil), secondary (sadece ikincil), nearest (en yakın) gibi seçenekler vardır. Write concern ise yazma işleminin kaç node'a onaylatılacağını belirler: w: 1 (birincil), w: majority (çoğunluk) veya w: "majority", j: true (journal'a yazılması). Daha yüksek write concern, daha güçlü dayanıklılık sağlar ancak yazma latency'sini artırır. E-ticaret sepet güncellemelerinde w: majority tercih edilirken, ürün görüntülenme sayaçlarında w: 1 yeterli olabilir. API tasarımında, endpoint bazında farklı consistency gereksinimleri için farklı ayarlar kullanılabilir. Performans optimizasyonu açısından, her operasyonun kritikliğine göre bu ayarlar dinamik olarak yapılandırılmalıdır.

// Write concern ile güvenli yazma
db.orders.insertOne(
  { userId: "u123", total: 599, items: [...] },
  { writeConcern: { w: "majority", j: true, wtimeout: 5000 } }
);

// Secondary'den okuma
db.getMongo().setReadPref("secondaryPreferred");
db.products.find({ category: "Elektronik" });

Gelişmiş Özellikler ve Entegrasyon

Change Streams nasıl kullanılır; gerçek zamanlı senaryolar

Change Streams, MongoDB'deki veri değişikliklerini real-time olarak dinlemenizi sağlayan özelliktir. 3.6 sürümünden itibaren kullanılabilir ve replica set veya sharded cluster gerektirir. Insert, update, delete operasyonlarını yakalayarak olay bazlı mimariler kurulabilir. E-ticaret sepetinde stok değişikliklerini anında diğer kullanıcılara yansıtmak, fiyat güncellemelerini real-time bildirmek veya sipariş durumu değişikliklerini push notification olarak göndermek için kullanılır. SaaS platformlarında, kullanıcı davranışlarını anlık analiz etmek ve yapay zeka modellerini tetiklemek için change streams idealdir. Cross-platform uygulamalarda, mobil ve web client'ların senkronizasyonu sağlanabilir.

// Change Stream dinleme
const changeStream = db.orders.watch([
  { $match: { "fullDocument.status": "shipped" } }
]);

changeStream.on("change", next => {
  console.log("Sipariş durumu değişti:", next.fullDocument);
  // Push notification gönder veya cache invalidate et
});

Transactions nedir; ACID garantileri ve örnekleri

MongoDB 4.0'dan itibaren multi-document ACID transactions desteği sunar. Bu, birden fazla belge üzerinde atomik işlemler yapılmasını sağlar. session.startTransaction(), işlemlerin commit veya abort edilmesini kontrol eder. ACID özellikleri (Atomicity, Consistency, Isolation, Durability) finansal işlemler ve envanter yönetimi gibi kritik senaryolarda güvenilirlik sağlar. E-ticaret sipariş işlemlerinde, ödeme kaydı oluşturma, stok düşürme ve sipariş durumu güncelleme tek bir transaction içinde yapılmalıdır. Ancak transactions performans maliyeti vardır ve gereksiz yere kullanılmamalıdır. Test edilebilirlik açısından, transaction'ların hata senaryoları ve rollback davranışları unit testlerle doğrulanmalıdır.

// Transaction örneği - sipariş ve stok güncelleme
const session = client.startSession();
session.startTransaction();

try {
  await ordersCollection.insertOne(orderDoc, { session });
  await productsCollection.updateOne(
    { _id: productId },
    { $inc: { stock: -quantity } },
    { session }
  );
  await session.commitTransaction();
} catch (error) {
  await session.abortTransaction();
  throw error;
} finally {
  session.endSession();
}

Full-text search ve Atlas Search entegrasyonu nasıl yapılır

Atlas Search, MongoDB Atlas üzerinde entegre full-text search çözümüdür. Lucene tabanlıdır ve fuzzy matching, autocomplete, faceted search gibi gelişmiş özellikler sunar. Index tanımlaması JSON formatında yapılır ve analizörler (Turkish, standard, whitespace vb.) seçilebilir. E-ticaret ürün aramalarında, yazım hatalarına toleranslı arama ve filtreleme kombinasyonları kullanıcı deneyimini iyileştirir. SaaS dokümantasyonlarında, içerik tabanlı arama ve öneriler sunulabilir. Atlas Search, ayrı bir Elasticsearch cluster'ı yönetme ihtiyacını ortadan kaldırarak operasyonel yükü azaltır. Performans optimizasyonu için, search index'leri düzenli olarak optimize edilmeli ve query pattern'leri analiz edilmelidir.

// Atlas Search index tanımı
{
  "mappings": {
    "dynamic": false,
    "fields": {
      "name": { "type": "string", "analyzer": "turkish" },
      "description": { "type": "string", "analyzer": "turkish" },
      "price": { "type": "number" }
    }
  }
}

// Search sorgusu
db.products.aggregate([
  { $search: {
      index: "default",
      text: { query: "akıllı saat", path: ["name", "description"] }
  }}
]);

Performans, Ölçeklenebilirlik ve Optimizasyon

Sorgu optimizasyonu nasıl yapılır; explain plan örnekleri

Sorgu optimizasyonu, explain("executionStats") çıktısını analiz ederek yapılır. Bu çıktıda executionTimeMillis, totalDocsExamined, totalKeysExamined ve stage bilgileri incelenir. İdeal bir sorguda totalDocsExamined ile nReturned yakın değerlerde olmalıdır; büyük farklar indeks kullanılmadığını gösterir. COLLSCAN stage'i tam koleksiyon taraması yapıldığını, IXSCAN indeks kullanıldığını belirtir. E-ticaret platformlarında, ürün listeleme sorgularının IXSCAN kullanması kritiktir. Compound indekslerde ESR (Equality, Sort, Range) kuralına uyulmalıdır. Performans optimizasyonu sürekli bir süreçtir; yeni özellikler eklendikçe sorgular yeniden değerlendirilmelidir.

// Explain plan analizi
db.orders.find({ status: "completed", createdAt: { $gte: date } })
  .explain("executionStats")

// İdeal çıktıda:
// executionStages.stage: "IXSCAN"
// totalDocsExamined ≈ nReturned

Cache stratejileri ve bellek yönetimi uygulamaları

MongoDB, WiredTiger storage engine ile bellek tabanlı cache kullanır. cache_size ayarı, RAM'in %50-60'ı olarak önerilir. Sık erişilen veriler ve indeksler otomatik olarak belleğe alınır. Uygulama katmanında Redis veya Memcached ile ek cache katmanı eklenebilir. E-ticaret ürün detay sayfaları, cache'lenerek veritabanı yükü azaltılır. SaaS platformlarında, kullanıcı yetkilendirme bilgileri ve konfigürasyon verileri cache'lenir. Cache invalidation stratejisi kritiktir; TTL (Time To Live), event-based invalidation veya write-through pattern'leri kullanılabilir. Cross-platform uygulamalarda, client-side cache ile server-side cache kombinasyonu kullanıcı deneyimini optimize eder.

// Redis cache pattern örneği
const cacheKey = `product:${productId}`;
let product = await redis.get(cacheKey);

if (!product) {
  product = await db.products.findOne({ _id: ObjectId(productId) });
  await redis.setex(cacheKey, 3600, JSON.stringify(product));
}

Shard anahtar seçimi ve yeniden dengeleme etkileri

Shard key, verinin hangi shard'a yerleştirileceğini belirleyen alan veya alan kombinasyonudur. İdeal shard key: yüksek kardinalite (çok benzersiz değer), uniform dağılım ve sorgu pattern'leriyle uyumluluk göstermelidir. Monoton artan değerler (timestamp, ObjectId) tek bir shard'a yoğunlaşmaya neden olur; bu durum "hot shard" problemi yaratır. Hashed shard key, uniform dağılım sağlar ancak range query'leri desteklemez. E-ticaret siparişlerinde customerId (hashed) veya orderDate + region (compound) gibi seçenekler değerlendirilebilir. Yeniden dengeleme (rebalancing), veri shard'lar arasında taşınırken performans etkisi yaratır; bu nedenle yoğun saatlerde yapılmamalıdır. Shard key seçimi geri dönüşü olmayan bir karardır; bu yüzden dikkatli analiz yapılmalıdır.

// Hashed shard key - uniform dağılım
sh.shardCollection("ecommerce.orders", { customerId: "hashed" });

// Compound shard key - range query desteği
sh.shardCollection("ecommerce.events", { region: 1, timestamp: 1 });

Uyumluluk, Güvenlik ve Operasyon

Kimlik doğrulama ve yetkilendirme nasıl uygulanır

MongoDB, SCRAM, x.509 sertifikaları, LDAP ve Kerberos gibi kimlik doğrulama mekanizmaları destekler. Role-based access control (RBAC) ile kullanıcılara ve rollerine göre yetkilendirme yapılır. Yerleşik roller (read, readWrite, dbAdmin, userAdmin) ve özel roller tanımlanabilir. E-ticaret platformlarında, uygulama kullanıcısı yalnızca gerekli koleksiyonlara erişmelidir. SaaS multi-tenant yapısında, tenant izolasyonu hem uygulama katmanında hem de veritabanı seviyesinde sağlanmalıdır. Audit logging, kim hangi veriye ne zaman eriştiğini kaydeder ve uyumluluk için gereklidir. CI/CD pipeline'larında, veritabanı credential'ları environment variable'lar veya secret manager'lar (HashiCorp Vault, AWS Secrets Manager) ile yönetilmelidir.

// Kullanıcı oluşturma ve yetkilendirme
db.createUser({
  user: "app_user",
  pwd: "secure_password",
  roles: [
    { role: "readWrite", db: "ecommerce" },
    { role: "read", db: "analytics" }
  ]
});

// Özel rol tanımlama
db.createRole({
  role: "orderProcessor",
  privileges: [
    { resource: { db: "ecommerce", collection: "orders" }, 
      actions: ["find", "update"] }
  ],
  roles: []
});

Veri şifreleme ve GDPR benzeri uyumluluk örnekleri

MongoDB, transit şifreleme (TLS/SSL) ve rest şifreleme (AES-256) desteği sunar. Atlas'ta encryption-at-rest varsayılan olarak etkindir; on-premise'da Key Management Interoperability Protocol (KMIP) ile harici anahtar yönetimi yapılabilir. Client-side field level encryption (CSFLE), hassas alanların (kredi kartı, TCKN) uygulama tarafından şifrelenerek veritabanına yazılmasını sağlar. GDPR ve KVKK kapsamında, veri minimizasyonu, saklama süreleri ve unutulma hakkı (right to be forgotten) teknik olarak uygulanmalıdır. E-ticaret müşteri verilerinde, kişisel bilgilerin şifrelenmesi ve erişim loglarının tutulması zorunludur. SaaS platformlarında, tenant bazlı veri izolasyonu ve şifreleme anahtarları yönetimi kritiktir. Profesyonel ekiplerde, güvenlik ve uyumluluk projenin ilk gününden itibaren göz önünde bulundurulmalıdır.

// Client-side field level encryption
const keyVaultNamespace = "encryption.__keyVault";
const kmsProviders = { local: { key: Buffer.from(process.env.MASTER_KEY, "base64") } };

const encryptedClient = new MongoClient(uri, {
  autoEncryption: {
    keyVaultNamespace,
    kmsProviders,
    schemaMap: {
      "ecommerce.customers": {
        bsonType: "object",
        properties: {
          creditCard: { encrypt: { bsonType: "string", algorithm: "AEAD_AES_256_CBC_HMAC_SHA_512-Random" } }
        }
      }
    }
  }
});

Yedekleme, felaket kurtarma ve operasyonel prosedürler

Yedekleme stratejisi, point-in-time recovery (PITR) ve snapshot'ları içermelidir. Atlas'ta otomatik yedekleme ve PITR varsayılan olarak sunulur. On-premise'da mongodump/mongorestore veya filesystem snapshot'ları kullanılabilir. Felaket kurtarma planı, RTO (Recovery Time Objective) ve RPO (Recovery Point Objective) hedeflerini belirlemelidir. E-ticaret platformlarında, 4 saatten fazla veri kaybı kabul edilemez; bu nedenle sürekli yedekleme ve hızlı restore prosedürleri şarttır. SaaS ürünlerinde, multi-region failover testleri düzenli olarak yapılmalıdır. Operasyonel prosedürler dokümante edilmeli ve runbook'lar hazırlanmalıdır. CI/CD süreçlerinde, yedekleme kontrolleri otomatikleştirilebilir ve alert'ler kurulabilir.

# Otomatik yedekleme scripti
#!/bin/bash
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
mongodump --uri="mongodb://..." --out="/backups/$TIMESTAMP"
aws s3 sync "/backups/$TIMESTAMP" "s3://mongo-backups/$TIMESTAMP"

Uygulama Senaryoları ve Sektörel Kullanım

Web geliştirme ve responsive tasarım ile entegrasyon örnekleri

MongoDB, modern web geliştirme stack'lerinin vazgeçilmez bir parçasıdır. Next.js ve Node.js ile birlikte kullanıldığında, JSON tabanlı veri yapısı frontend-backend iletişimini kolaylaştırır. Headless CMS mimarilerinde, içerik belgeleri MongoDB'de saklanır ve API üzerinden frontend'e sunulur. Responsive tasarım prensipleri, veri yapısının da esnek olmasını gerektirir; MongoDB'nin şemasız yapısı bu esnekliği doğal olarak sağlar. E-ticaret admin panellerinde, dinamik form alanları ve özelleştirilebilir ürün özellikleri MongoDB ile kolayca yönetilir. Cross-platform projelerde, aynı veri yapısı web ve mobil uygulamalarda ortak olarak kullanılabilir. Kullanıcı deneyimi açısından, hızlı veri erişimi sayfaların anında yüklenmesini sağlar.

// Next.js API route ile MongoDB entegrasyonu
import clientPromise from "@/lib/mongodb";

export default async function handler(req, res) {
  const client = await clientPromise;
  const db = client.db("cms");
  const posts = await db.collection("posts").find({ published: true }).toArray();
  res.status(200).json(posts);
}

E-ticaret için katalog ve sepet yönetimi nasıl kurulur

E-ticaret katalog yönetiminde, ürünlerin kategorileri, varyasyonları, özellikleri ve medya dosyaları karmaşık hiyerarşiler oluşturur. MongoDB'nin belge yapısı, bu karmaşıklığı doğal olarak yönetir. Ürün belgeleri, varyasyonları array olarak içerebilir ve farklı kategoriler farklı özellik setlerine sahip olabilir. Sepet yönetiminde, kullanıcı sepeti bir belge olarak tutulur ve ürünler embedding ile saklanır. Stok kontrolü, sepete ekleme anında atomic update ile yapılır. Fiyatlandırma kuralları, kampanyalar ve indirimler belge içinde dinamik olarak hesaplanabilir. Performans optimizasyonu için, ürün listeleme sayfalarında projection kullanılarak sadece gerekli alanlar çekilir. API tasarımında, sepet endpoint'leri idempotent olmalı ve aynı ürünün tekrar eklenmesi durumunda quantity artırılmalıdır.

// E-ticaret ürün belgesi
{
  _id: ObjectId("..."),
  sku: "SHOE-001",
  name: "Koşu Ayakkabısı",
  basePrice: 899.99,
  categories: ["Spor", "Ayakkabı"],
  variants: [
    { size: 42, color: "Siyah", stock: 15, priceModifier: 0 },
    { size: 43, color: "Beyaz", stock: 8, priceModifier: 50 }
  ],
  attributes: { material: "Mesh", weight: "280g" }
}

SaaS ürünlerinde çok kiracılı veri modelleme örnekleri

Multi-tenant SaaS mimarisinde, veri izolasyonu üç yaklaşımla sağlanır: database-per-tenant (her kiracıya ayrı veritabanı), collection-per-tenant (her kiracıya ayrı koleksiyon) ve shared database (tek veritabanında tenant ID ile izolasyon). Database-per-tenant en yüksek izolasyonu sağlar ancak operasyonel maliyeti yüksektir. Collection-per-tenant orta yoldur. Shared database en ölçeklenebilir yaklaşımdır; tenant ID her belgede bulunur ve sorgularda filtrelenir. E-ticaret SaaS'larında, shared database + tenant ID pattern'i tercih edilir. Kullanıcı deneyimi açısından, her tenant'ın kendi konfigürasyonu ve özelleştirmeleri belge içinde saklanabilir. Performans optimizasyonu için, tenant ID + kullanıcı ID bileşik indeksi oluşturulmalıdır. Veri güvenliği açısından, aggregation pipeline'larında tenant ID filtrelemesi zorunlu olmalıdır.

// Multi-tenant shared database pattern
{
  tenantId: "tenant_abc",
  userId: "user_123",
  settings: { theme: "dark", currency: "TRY" },
  data: { ... }
}

// Güvenli sorgu - tenant izolasyonu
db.records.find({ tenantId: currentTenantId, userId: currentUserId });

UI/UX odaklı kişiselleştirme ve gerçek zamanlı içerik örnekleri

MongoDB, kişiselleştirilmiş kullanıcı deneyimleri için real-time veri altyapısı sağlar. Kullanıcı davranışları, tercihleri ve geçmiş etkileşimleri belgelerde saklanır; bu veriler aggregation pipeline'larıyla işlenerek kişiselleştirilmiş içerik üretilir. E-ticaret ana sayfalarında, kullanıcının geçmiş aramalarına ve satın almalarına göre ürün önerileri sunulabilir. SaaS dashboard'larında, kullanıcının rolüne ve kullanım pattern'ine göre widget'lar dinamik olarak düzenlenir. Change streams ile, kullanıcı A bir ürünü sepete eklediğinde kullanıcı B'ye "son 5 kişi bu ürünü inceledi" bildirimi anında gösterilebilir. Yapay zeka entegrasyonu ile, kullanıcı segmentasyonu ve tahmine dayalı kişiselleştirme yapılabilir. Responsive tasarım prensipleri, kişiselleştirilmiş içeriğin tüm cihazlarda tutarlı görünmesini sağlar.

// Kişiselleştirilmiş ürün önerisi
db.userBehaviors.aggregate([
  { $match: { userId: "currentUser", tenantId: "tenant_abc" } },
  { $unwind: "$interactions" },
  { $group: { _id: "$interactions.category", score: { $sum: "$interactions.weight" } } },
  { $sort: { score: -1 } },
  { $limit: 3 },
  { $lookup: { from: "products", localField: "_id", foreignField: "category", as: "recommended" } }
]);

Araçlar, Kütüphaneler ve Mühendislik Pratikleri

Resmi sürücüler ve ODM/ORM entegrasyon örnekleri

MongoDB'nin Node.js, Python, Java, Go ve diğer diller için resmi sürücüleri bulunur. ODM (Object Document Mapping) kütüphaneleri olarak Mongoose (Node.js), MongoEngine (Python) ve Morphia (Java) popülerdir. Mongoose, şema tanımlama, middleware, validation ve query building özellikleri sunar. E-ticaret projelerinde, ürün ve sipariş modelleri Mongoose şemalarıyla tanımlanır; bu sayede tip güvenliği ve validation sağlanır. SaaS platformlarında, tenant bazlı model davranışları plugin'lerle yönetilebilir. Cross-platform geliştirmede, aynı model tanımlamaları farklı platformlarda kullanılabilir. Test edilebilirlik açısından, Mongoose modelleri mock'lanarak unit test yazımı kolaylaştırılır. TypeScript ile kullanıldığında, interface tanımlamaları ile tam tip güvenliği sağlanır.

// Mongoose şema tanımı
const orderSchema = new mongoose.Schema({
  userId: { type: mongoose.Schema.Types.ObjectId, required: true, ref: 'User' },
  items: [{
    productId: { type: String, required: true },
    name: String,
    quantity: { type: Number, min: 1 },
    price: { type: Number, min: 0 }
  }],
  status: { type: String, enum: ['pending', 'paid', 'shipped', 'delivered'], default: 'pending' },
  createdAt: { type: Date, default: Date.now }
});

orderSchema.index({ userId: 1, createdAt: -1 });
const Order = mongoose.model('Order', orderSchema);

CI/CD boru hatları ile veritabanı migrasyonları nasıl yönetilir

Veritabanı migrasyonları, CI/CD süreçlerinin en hassas noktalarından biridir. MongoDB'de şema esnekliği olduğundan, migrasyonlar genellikle indeks oluşturma, veri dönüştürme veya koleksiyon yeniden yapılandırma işlemlerini içerir. migrate-mongo veya umzug gibi araçlarla versiyonlanmış migrasyon script'leri yönetilir. Her migrasyon, up (uygula) ve down (geri al) fonksiyonları içerir. Deployment pipeline'ında, migrasyonlar uygulama kodundan önce çalıştırılır. E-ticaret platformlarında, sıfır kesinti ile migrasyon yapmak için blue-green deployment veya rolling update stratejileri kullanılır. SaaS ürünlerinde, tenant bazlı migrasyonlar sıralı veya paralel olarak yürütülebilir. Test edilebilirlik açısından, migrasyon script'leri staging ortamında test edilmeli ve rollback prosedürleri hazır olmalıdır. Agile süreçlerde, her sprint sonunda veritabanı değişiklikleri dokümante edilmelidir.

// migrate-mongo konfigürasyonu
module.exports = {
  migrationFileExtension: ".js",
  changelogCollectionName: "changelog",
  useFileHash: false,
  moduleSystem: 'commonjs',
};

// Örnek migrasyon
module.exports = {
  async up(db) {
    await db.collection('products').createIndex({ category: 1, price: -1 });
    await db.collection('products').updateMany(
      {}, 
      [{ $set: { slug: { $toLower: { $replaceAll: { input: "$name", find: " ", replacement: "-" } } } } }]
    );
  },
  async down(db) {
    await db.collection('products').dropIndex("category_1_price_-1");
    await db.collection('products').updateMany({}, { $unset: { slug: "" } });
  }
};

Observability, MLOps ve veri boru hattı entegrasyonları

Observability, sistemlerin iç durumunu dış çıktılarından anlama yeteneğidir. MongoDB için Prometheus exporter, Grafana dashboard'ları ve distributed tracing (OpenTelemetry) entegrasyonları kullanılır. MLOps süreçlerinde, MongoDB feature store olarak kullanılabilir; eğitim verileri, model metrikleri ve tahmin sonuçları belgelerde saklanır. Veri boru hatlarında (data pipelines), MongoDB Change Streams ile CDC (Change Data Capture) yapılır ve veri ambarına (Snowflake, BigQuery) aktarılır. E-ticaret platformlarında, kullanıcı davranış verileri MongoDB'den Kafka'ya akatarılarak real-time analitik yapılır. Yapay zeka modellerinin eğitim verileri, MongoDB'den Python pipeline'larıyla çekilir. Test edilebilirlik açısından, veri pipeline'ları idempotent olmalı ve duplicate handling mekanizmaları içermelidir. Profesyonel ekiplerde, observability ve MLOps stratejileri projenin ilk gününden planlanmalıdır.

// Change Stream ile Kafka entegrasyonu
const changeStream = db.orders.watch();
const producer = kafka.producer();

changeStream.on("change", async (change) => {
  await producer.send({
    topic: "orders.events",
    messages: [{ key: change.documentKey._id.toString(), value: JSON.stringify(change) }]
  });
});

Sonuçlar, Ölçümleme ve Geçiş Stratejileri

Başarı metrikleri nedir; performans ve iş KPI örnekleri

MongoDB tabanlı projelerin başarısı, teknik ve iş metrikleriyle ölçülür. Teknik KPI'lar: sorgu yanıt süresi (p95 < 100ms), uptime (%99.9+), replication lag (< 10sn), cache hit ratio (%80+) ve storage efficiency'dir. İş KPI'ları: dönüşüm oranı, sayfa yükleme süresi, kullanıcı memnuniyeti ve operasyonel verimlilik artışıdır. E-ticaret platformlarında, MongoDB optimizasyonu sonrası sepet terk oranının %15 düşmesi, sayfa yükleme süresinin 2 saniyenin altına inmesi hedeflenir. SaaS ürünlerinde, API response time'ının iyileşmesi kullanıcı aktivasyonunu artırır. Agile süreçlerde, her sprint sonunda bu metrikler gözden geçirilir ve iyileştirme hedefleri belirlenir. Performans optimizasyonu, sürekli bir döngüdür; metrikler düzenli olarak izlenmeli ve eşik değerler güncellenmelidir.

// Performans metrikleri toplama
db.orders.find().explain("executionStats").then(stats => {
  metrics.histogram('query.executionTime', stats.executionStats.executionTimeMillis);
  metrics.gauge('query.docsExamined', stats.executionStats.totalDocsExamined);
});

Monolitten MongoDB tabanlı mimariye geçiş adımları ve risk yönetimi

Monolitik bir uygulamadan MongoDB tabanlı modern mimariye geçiş, stratejik planlama gerektirir. Strangler Fig pattern'i kullanılarak, monolitik uygulama parça parça değiştirilir. İlk adım, veri modelini analiz etmek ve MongoDB'ye uygun şekilde yeniden tasarlamaktır. İkinci adım, read replica'lar kurarak monolitik veritabanından MongoDB'ye veri senkronizasyonu başlatmaktır. Üçüncü adım, okuma operasyonlarını yavaş yavaş MongoDB'ye yönlendirmektir. Dördüncü adım, yazma operasyonlarını taşımaktır. Risk yönetimi açısından, her aşamada rollback planı hazır olmalı ve veri tutarlılığı sürekli doğrulanmalıdır. E-ticaret platformlarında, ödeme ve stok işlemleri en son taşınmalıdır. SaaS ürünlerinde, tenant bazlı geçiş stratejisi izlenebilir. Test edilebilirlik açısından, her aşama sonunda kapsamlı regression testleri yapılmalıdır. CI/CD pipeline'larında, dual-write period'ları otomatik olarak yönetilmelidir.

// Dual-write pattern örneği
async function createOrder(orderData) {
  // Monolitik DB'ye yaz
  await legacyDb.query('INSERT INTO orders ...', orderData);
  
  // MongoDB'ye de yaz
  await mongoDb.collection('orders').insertOne(orderData);
  
  // Tutarlılık kontrolü
  await consistencyChecker.validate(orderData.id);
}

Proje yol haritası: prototipten üretime geçiş planı

MongoDB tabanlı bir projenin prototipten üretime geçişi, aşamalı bir yaklaşım gerektirir. Faz 1 (0-2 ay): Teknik spike, POC geliştirme ve veri modeli tasarımı. Faz 2 (2-4 ay): MVP geliştirme, temel CRUD operasyonları, basit aggregation'lar ve temel monitoring. Faz 3 (4-6 ay): Performans optimizasyonu, indeksleme, caching katmanı ve güvenlik hardening. Faz 4 (6-8 ay): Ölçeklendirme, sharding, multi-region deployment ve felaket kurtarma testleri. Faz 5 (8-12 ay): Gelişmiş özellikler (full-text search, change streams, transactions), MLOps entegrasyonu ve advanced monitoring. Her fazda, kullanıcı deneyimi metrikleri ve teknik KPI'lar ölçülür. E-ticaret platformlarında, Faz 2'de temel katalog ve sepet yönetimi, Faz 4'te yüksek trafik optimizasyonları yapılır. SaaS ürünlerinde, Faz 3'te multi-tenant optimizasyonları, Faz 5'te AI entegrasyonları eklenir. Agile metodoloji ile 2 haftalık sprint'lerle iteratif geliştirme yapılır ve her sprint sonunda demo ve geri bildirim toplanır. Profesyonel ekiplerde, bu yol haritası proje başlangıcında tüm paydaşlarla paylaşılır ve düzenli olarak güncellenir.

// Prototip aşaması basit bağlantı
const { MongoClient } = require('mongodb');
const client = new MongoClient(process.env.MONGODB_URI);
await client.connect();
const db = client.db('prototype');

// Üretim aşaması connection pool yapılandırması
const client = new MongoClient(uri, {
  maxPoolSize: 100,
  minPoolSize: 10,
  maxIdleTimeMS: 30000,
  serverSelectionTimeoutMS: 5000,
  retryWrites: true,
  w: 'majority'
});

---

MongoDB, modern uygulama geliştirme dünyasında esnekliği, ölçeklenebilirliği ve performansı bir arada sunan güçlü bir veritabanı çözümüdür. Temel kavramlardan gelişmiş özelliklere kadar kapsadığımız bu rehberde, e-ticaret, SaaS ve cross-platform projelerde nasıl etkili bir şekilde kullanılacağını detaylandırdık. Doğru veri modelleme, stratejik indeksleme ve proaktif monitoring ile MongoDB tabanlı sistemler yüksek performans ve güvenilirlik sunar. Noves Digital olarak, 150'den fazla projede edindiğimiz deneyimle, işletmelerin dijital altyapılarını modern ve ölçeklenebilir çözümlerle güçlendirmeye devam ediyoruz. Eğer siz de MongoDB tabanlı bir proje başlatmayı düşünüyorsanız, doğru planlama ve teknik uzmanlık ile hedeflerinize ulaşmanız mümkün. Unutmayın, veritabanı seçimi sadece teknik bir karar değil, aynı zamanda iş stratejinizin bir parçasıdır.