MongoDB Destek ve Danışmanlık

MongoDB projelerinde sorunların büyük bölümü yapılandırmadan değil tasarımdan doğar: yanlış seçilmiş bir parça anahtarı veya indeks stratejisi, donanım büyüterek çözülemez.

$ mongosh --eval 'rs.status().members.map(m => [m.name, m.stateStr])'
mongo-01:27017 PRIMARY
mongo-02:27017 SECONDARY
mongo-03:27017 SECONDARY ~8 dk geride
→ oplog penceresi ve indeks oluşturma yükü incelendi

MongoDB sistemlerinizi uçtan uca yönetiyoruz

Veritabanı sorunları tek başlıkta kalmaz. Şema tasarımı indeks boyutunu, indeks boyutu bellek kullanımını, bellek kullanımı da yanıt süresini belirler. Dört başlığı birbirinden ayırmadan yürütüyoruz.

Performans optimizasyonu

Yavaş işlemleri profiler ve db.currentOp() üzerinden tespit ediyor, explain() çıktısıyla indeks kullanımını doğruluyoruz. İndeks tasarımını eşitlik–sıralama–aralık (ESR) kuralına göre kuruyor, WiredTiger önbelleğini çalışma kümesine göre boyutlandırıyoruz. Bu sayfanın alt bölümleri indeks ve şema tasarımını ayrıntılı anlatır.

Yüksek erişilebilirlik

ReplicaSet kurulumlarını oy sayısı ve devralma davranışı hesaplanmış şekilde yapıyoruz. Yazma onayı (write concern) ve okuma tercihi (read preference) ayarlarını uygulamanın tutarlılık ihtiyacına göre belirliyor, sharding mimarisini parça anahtarı tasarımıyla birlikte kurguluyoruz.

Yedekleme ve kurtarma

Percona Backup for MongoDB ile ReplicaSet ve sharded cluster kurulumlarında tutarlı yedekleme kuruyoruz. Oplog arşivlemesiyle PITR (Point-in-Time Recovery) sağlıyor, geri yükleme (restore) testlerini otomatik çalıştırıyoruz.

Güvenlik ve KVKK teknik tedbirleri

Denetim kaydı (audit logging) ve disk üzerinde şifreleme, Percona Server for MongoDB dağıtımı üzerinden yapılandırılır. Rol tabanlı erişim denetimini en az yetki ilkesine göre kuruyor, düğümler arası ve istemci bağlantılarında TLS'i zorunlu hâle getiriyoruz.

ReplicaSet, MongoDB’de erişilebilirliğin temelidir

MongoDB’de yüksek erişilebilirlik ReplicaSet ile sağlanır. Küme içinde bir düğüm birincil (primary) olarak yazma trafiğini alır, diğerleri ikincil (secondary) olarak veriyi kopyalar. Birincil düğüm erişilemez duruma geldiğinde kalan düğümler oylama yaparak yeni birincili seçer. Oylamanın sonuçlanabilmesi için oy verebilen üye sayısının tek olması gerekir; üretim kurulumlarında karşılığı üç veri düğümüdür.

İki veri düğümü ve bir tanık (arbiter) kurulumu ilk bakışta aynı işi daha ucuza yapıyor görünür. Tanık düğüm oy verir, ancak veri tutmaz. Bir veri düğümü kaybedildiğinde geriye tek kopya kalır ve majority yazma onayı kullanan uygulamalar yazma yapamaz hâle gelebilir. Veri kaybı toleransı düşük sistemlerde tanık düğüm önermiyoruz.

Kurulumun asıl kararı düğüm sayısı değil, iki ayarın uygulamanın ihtiyacına göre belirlenmesidir:

  • Yazma onayı (write concern). majority değeri, yazmanın düğümlerin çoğunluğuna ulaştığı onaylanmadan başarı yanıtı dönmemesini sağlar; devralma anında veri kaybını önler ve karşılığında yazma gecikmesini artırır.
  • Okuma tercihi (read preference). Okuma trafiğinin ikincil düğümlere yönlendirilmesi birincil düğümü rahatlatır, ancak ikincil düğüm çoğaltmada geride kaldığı sürece eski veri döndürür. Yazma sonrası okuma tutarlılığı gerektiren akışlar birincil düğümde kalmalıdır.

Operasyonel tarafta düzenli izlediğimiz değer oplog penceresidir: ikincil bir düğümün ne kadar süre erişilemez kaldıktan sonra tam senkronizasyona zorlanacağını belirler. Pencere daraldığında bakım işlemleri için elde kalan süre de daralır.

Sharding kararı, parça anahtarıyla başlar ve orada biter

Sharding, verinin birden fazla ReplicaSet’e dağıtılmasıdır. Uygulama mongos yönlendiricisine bağlanır; hangi belgenin hangi parçada olduğu bilgisi ayrı bir ReplicaSet olarak çalışan yapılandırma sunucularında tutulur.

Mimarinin tamamını belirleyen tek karar parça anahtarıdır (shard key). Anahtar, belgelerin parçalara nasıl dağıtılacağını ve bir sorgunun tek parçaya mı yoksa tüm parçalara mı gideceğini tayin eder.

Sahada en sık gördüğümüz hata, sürekli artan bir alanın — zaman damgası veya otomatik artan kimlik — anahtar olarak seçilmesidir. Yeni belgelerin tamamı aynı aralığa düştüğü için yazma trafiği tek bir parçaya yığılır; diğer parçalar boşta beklerken sistem tek düğümlü bir kurulum gibi davranır. Karşı uçta, tamamen rastgele dağıtan bir anahtar yazmaları eşitler ancak aralık sorgularını tüm parçalara yayar.

Doğru anahtar, uygulamanın sorgu desenine bakılarak seçilir. Bu nedenle sharding çalışmasını her zaman sorgu profilinin çıkarılmasıyla başlatıyoruz.

Güncel sürümlerde koleksiyonun yeniden parçalanması mümkündür, ancak işlem veri hacmiyle orantılı süre ve kaynak gerektirir. Baştan doğru seçilen bir anahtar, sonradan yapılacak her düzeltmeden ucuzdur.

Sharding’den önce sorulması gereken soru

Sharding’e geçiş talebiyle gelen sistemlerin önemli bölümünde asıl sorun ölçek değildir. Geçiş kararından önce üç ölçümü yapıyoruz:

  • Çalışma kümesi belleğe sığıyor mu? MongoDB, sık erişilen veriyi ve indeksleri WiredTiger önbelleğinde tutar. Çalışma kümesi belleği aştığında her sorgu diske iner ve yanıt süreleri birkaç kat artar. Tablo bu noktadayken sharding kurmak, sorunu daha fazla sunucuya kopyalamaktan ibarettir.
  • İndeks tasarımı doğru mu? Eksik bir indeks yüzünden koleksiyon taraması yapan bir sorgu, parça sayısı arttıkça daha fazla düğümü meşgul eder.
  • Yazma yükü gerçekten tek düğümü doyuruyor mu? Yazma gecikmesinin kaynağı çoğu zaman düğüm kapasitesi değil, disk eşzamanlılığı veya aşırı sayıda indeksin her yazmada güncellenmesidir.

Üç sorunun yanıtı sharding’i gerektiriyorsa mimariyi kuruyoruz. Gerektirmiyorsa, çok daha ucuz olan düzeltmeyi öneriyoruz.

İndeks ve şema tasarımı bir performans konusudur

MongoDB’de indeks tasarımının temel kuralı bileşik (compound) indekslerin önek davranışıdır: bir indeks yalnızca alanlarının baştan itibaren kesintisiz bir bölümü için kullanılabilir. Alan sırasını eşitlik–sıralama–aralık düzenine göre kuruyoruz; önce tam eşleşme aranan alanlar, sonra sıralama yapılan alan, en sonda aralık koşulu uygulanan alan. Sıralama yanlış kurulduğunda indeks var olduğu hâlde kullanılmaz ve explain() çıktısı bunu açıkça gösterir.

Şema tarafında belirleyici karar, ilişkili veriyi belgeye gömmek (embedding) ile ayrı koleksiyonda tutup referans vermek arasındaki tercihtir. Gömme, tek okumada tüm veriyi getirir ve birleştirme ihtiyacını ortadan kaldırır; buna karşılık belge her güncellemede bütün olarak yeniden yazılır ve sınırsız büyüyen bir dizi gömüldüğünde belge boyutu sınırına dayanılır. Ayrıştırma esneklik sağlar, karşılığında okuma sayısını artırır.

İkisi arasındaki tercih veri modeline değil erişim desenine göre yapılır. Uygulamanın hangi veriyi birlikte okuduğunu ölçmeden verilen şema kararı, sonradan veri göçü (migration) gerektiren türden bir karardır.

Dağıtım tercihi: Community ve Percona Server for MongoDB

MongoDB Community Edition çoğu kurulum için yeterlidir. Kurumsal denetimlerde istenen iki bileşen ise bu dağıtımda bulunmaz: denetim kaydı (audit logging) ve disk üzerinde şifreleme.

Bu ihtiyaç doğduğunda önerdiğimiz yol ticari lisans satın almak değil, aynı çekirdek üzerine kurulu Percona Server for MongoDB dağıtımına geçmektir. Denetim kaydı, şifreleme, sıcak yedekleme ve LDAP kimlik doğrulaması bu dağıtımda ek lisans maliyeti olmadan gelir. Geçiş uygulama tarafında değişiklik gerektirmez; sürücüler ve sorgular aynı kalır.

Percona ile ticari bir ilişkimiz bulunmuyor. Verdiğimiz hizmet dağıtımın kurulumu, yapılandırılması ve sonrasındaki operasyonel bakımıdır.

Yönetilen bulut servislerinde MongoDB desteği

MongoDB Atlas kullanan kurumlara destek veriyoruz. Yönetilen serviste altyapı, yedekleme ve sürüm yükseltmesi sağlayıcının sorumluluğundadır; şema tasarımı, indeks stratejisi, aggregation pipeline optimizasyonu ve parça anahtarı seçimi ise kurumda kalır. Destek ihtiyacının büyük bölümü zaten bu başlıklardadır.

Amazon DocumentDB ayrı bir üründür ve bu ayrımın bilinmesi gerekir. MongoDB API’siyle uyumlu çalışır, ancak MongoDB’nin kendisi değildir; desteklediği özellik kümesi ve davranışı farklıdır. DocumentDB üzerinde çalışan sistemlerde önce hangi özelliklerin gerçekten kullanılabildiğini ölçüyor, uyumsuzlukları raporluyoruz.

Çalışma biçimimiz

Sistemlerinize gizlilik sözleşmesi (NDA) kapsamında uzaktan bağlanıyoruz. Veritabanı kullanıcısına yalnızca yapılacak iş için gereken yetkileri tanımlıyor, uyguladığımız her değişikliği kayıt altına alıyoruz.

Bir sistemi ilk devraldığımızda önce mevcut durumu çıkarırız: sürüm ve yapılandırma envanteri, ReplicaSet topolojisi ve oplog penceresi, indeks envanteri ve kullanım oranları, çalışma kümesi ile bellek ilişkisi, yedekleme ve geri yükleme durumu. Öneriler bu ölçümün üzerine kurulur.

İlgili hizmetler

Aynı çalışmaları MySQL, PostgreSQL ve MariaDB için de yürütüyoruz: MySQL Destek · PostgreSQL Destek · MariaDB Destek

Sık sorulan sorular

Otomatik devralmanın çalışması için oy verebilen üye sayısının tek olması gerekir; üretim kurulumlarında karşılığı üç veri düğümüdür. İki veri düğümü ve bir tanık (arbiter) kurulumu maliyeti düşürür, ancak iki önemli sonucu vardır: tanık düğüm veri tutmadığı için bir veri düğümü kaybedildiğinde geriye tek kopya kalır ve majority yazma onayı kullanan uygulamalar bu durumda yazma yapamaz hâle gelebilir. Veri kaybı toleransı düşük sistemlerde tanık düğüm önermiyoruz.

Sharding, tek bir ReplicaSet'in veri hacmini veya yazma yükünü karşılayamadığı noktada gündeme gelir; erken uygulandığında yalnızca operasyonel karmaşıklık ekler. Geçiş kararından önce çalışma kümesinin belleğe sığıp sığmadığını, indeks tasarımının doğru olup olmadığını ve yazma yükünün gerçekten tek düğümü doyurup doyurmadığını ölçüyoruz. Sahada gördüğümüz durumların önemli bölümünde sorun ölçek değil, indeks veya şema tasarımıdır.

Güncel MongoDB sürümlerinde koleksiyonun yeniden parçalanması mümkündür, ancak işlem veri hacmiyle orantılı süre ve kaynak gerektirir; üretim sisteminde planlanması gereken bir bakım penceresidir. Bu nedenle parça anahtarını baştan doğru seçmek, sharding çalışmasının en kritik adımıdır. Sürekli artan bir alan — zaman damgası veya otomatik artan kimlik — anahtar olarak seçildiğinde tüm yazma trafiği tek bir parçaya yığılır ve sharding'in amacı ortadan kalkar.

Evet. Yönetilen serviste altyapı ve yedekleme sağlayıcının sorumluluğundadır; buna karşılık şema tasarımı, indeks stratejisi, sorgu ve aggregation pipeline optimizasyonu ile parça anahtarı seçimi aynı şekilde kurumun sorumluluğunda kalır ve destek ihtiyacının büyük bölümü zaten buradadır. Amazon DocumentDB ise ayrı bir üründür: MongoDB API'siyle uyumlu çalışır, ancak MongoDB'nin kendisi değildir ve desteklediği özellik kümesi farklıdır. DocumentDB üzerinde çalışan sistemlerde bu farkı önce ölçüyoruz.

Denetim kaydı ve disk üzerinde şifreleme gibi kurumsal denetimlerde istenen bileşenler Community Edition'da bulunmaz. Bu ihtiyaç doğduğunda önerdiğimiz yol ticari lisans satın almak değil, aynı çekirdek üzerine kurulu Percona Server for MongoDB dağıtımına geçmektir; denetim kaydı, şifreleme, sıcak yedekleme ve LDAP kimlik doğrulaması ek lisans maliyeti olmadan gelir. Geçişi biz yürütüyoruz. Hiçbir üretici ile ticari bir ilişkimiz bulunmuyor; lisans satışı yapmıyoruz.

Evet, üç veritabanına da aynı ekip bakıyor. Kurumların çoğunda ilişkisel veritabanı ve MongoDB bir arada bulunur; yedekleme, izleme ve KVKK teknik tedbirlerinin ayrı ekiplerce yürütülmesi aynı işin iki kez yapılmasına ve süreçler arasında boşluk kalmasına yol açar. Üç sistem için tek bir izleme altyapısı ve tek bir yedekleme disiplini kuruyoruz.

MongoDB destek talebinizi iletin