MongoDB Servisinin Yönetimi ve Ölçeklenmesi

Doküman temelli

Dinamik şemalı

Replikasyon ve yüksek bulunurluk

Otomatik shardlama ile yatay genişleme

Herhangi bir alanı indeksleyebilme

Map/Reduce

JSON ile sorgulama

BSON (Binary JSON) veri saklama

Dosya sistemi olarak kullanabilme (GridFS)

GNU AGPL lisanslı

Eski startuplarında sürekli ölçekleme sorunu yaşıyorlar.

2007’de 10Gen’i kurup, bir uygulama platformu üzerinde çalışıyorlar.

Kimse umursamıyor, kullanıcı yok, ilgilenen yok

2009’da uygulama kısmını çöpe atıp, veritabanını özgürleştiriyorlar.

Hızla popülerlik kazanıyor

2013’te 10gen → MongoDB Inc.

Mongo, İngilizce "humongous" sözcüğünden geliyor. humongous = çok geniş.

Document: Bir koleksiyonda yer alan bir kayıt. MongoDB’nin en temel birimi. (RDBMS: Satır)

Field: Bir belgedeki (document) isim/değer ikilisi (RDBMS : Kolon)

Collection: MongoDB dokümanlarının gruplanmış bir hali (RDBMS: Tablo)

Database: Koleksiyonlardan oluşan fiziksel bir alan (container).

Veri yazma/okuma isteklerini işler

Arkaplan operasyonlarını yapar

Port: 27017

Ayarlar: /etc/mongod.conf

Veriler: /var/lib/mongodb

Web arayüzü: 28017

En temel Mongo istemcisi

Konsol uygulaması

mongo komutu ile çalışır

Geçmiş kaydeden, kısayol kullanılabilen bir kabuk (shell) sunar

Mongo servisine istenilen komutu gönderebilir

Bir dosyadan bir seri komutu okuyup otomatik çalıştırabilir

C

C# + .NET

Java

Node.js

Perl

PHP

Python

Ruby

Scala

Action: Kullanıcının yapabileceği işlem (okuma, yazma, vs)

Resource: Veritabanı, koleksiyon, küme

Resource + Action → Privilege

n tane Privilege → Role

Hazır roller: dbAdmin, restore, userAdmin, Backup, …​

mongo: Konsol istemcisi

mongostat: Çalışan sürecin istatistikleri

mongotop: Çalışan sürecin kaynak tüketimi

mongosniff: Mongo’ya gelip-giden ağ trafiğini izleme

mongoimport, mongoexport: JSON, CSV, TSV ithalat-ihracat

mongodump, mongorestore: Yedek alma, yedekten geri dönme

Yazılımdan tetikleyerek silmek

TTL Collection: x günden daha eskileri otomatik sil

Capped Collection: Boyut sabit olsun, doldukça eskileri sil

Silinen dokümanlar disk alanı olarak geri gelmiyor

Mongo silinen yerlere yeni dokümanları yerleştiriyor

Yoğun silme/yazma işlemi → fragmantasyon ve performans düşüşü

Çözüm 1: db.repairDatabase() çağrılması (2x disk alanı)

Çözüm 2: Replika set ise, replikanın silinip baştan oluşturulması

MongoDB doküman boyut sınırı: 16 MB

GridFS katmanı: 255K’lık dokümanlara parçalıyor

İstemci alınan parçaları birleştiriyor

GridFS-Fuse → Dosya sistemi

GridFS-Nginx → Nginx’ten dosya sunumu

mod_gridfs → Apache’den dosya sunumu

Dosyaların da replikasyonu

Dosyalara kısmı erişim daha hızlı

Performans biraz daha düşük

Sorgulanacak doküman sayısı artıyor

Veri birden fazla sunucuya sürekli çoğaltılır

Tüm yazma işlemleri sadece Primary’e yapılır

Primary, oplog’una yazma işlemlerine kaydeder

Primary, (öntanımlı olarak) replikaya ulaşıp ulaşmadığını umursamaz

Replikalar oplog’daki veriyi alarak kendilerine uygular

Primary’de sorun olduğundan, diğerlerinden biri Primary olur

Süreksiz bağlantılarda da kullanılabilir

İkinci bir (boş) Mongo servisi kurulur

Tekil (standalone) servis replika seti üyesi yapılır ve replika başlatılır

İkinci sunucu aynı isimli replika setine üye haline getirilir

Boş sunucu diğerinden verileri çekerek eş hale gelir

Sürecin hızlanması için veri dosyaları birebir diğerine kopyalanabilir

İstemci, birden fazla sunucudan sorgulama işlemini gerçekleştirir

Otomatik failover (bir sorun olduğunda diğerinin devam etmesi)

Okuma yükünü dağıtmak (öntanımlı değil)

Replikayı gerektiğinde kapatıp, yedek alabilmek ya da kopyalayabilmek

Farklı fiziksel yerlere canlı veri kopyası

Raporlamalar

Primary’de bir sorun olduğunda gerçekleşir

Oylama (quorum) yapılır

Oylamaya replika setinin çoğunluğunun katılması gerekir

Çoğunluk katılmazsa replika seti yazmayı durdurur (splitbrain)

Replikalar tek sayıda olduğunda en fazla hata toleransı elde edilir

Elinde en ileri tarihli veri olan Primary olur

Replikalar için öncelik belirtilerek, primary olma önceliği sağlanabilir

Primary’e ulaşılamayan bir failover sırasında, primary’nin oplog’unda secondary’e aktarılmamış veri varsa veri kaybı yaşanır.

Replikalardan en az birinin Primary’e eş donanımlı olması önerilir

Primary geri devreye girdiğinde, otomatik olarak Primary olmaz

1 sunucu, 0 sunucu toleransı

2 sunucu, 0 sunucu toleransı

3 sunucu, 1 sunucu toleransı

4 sunucu, 1 sunucu toleransı

5 sunucu, 2 sunucu toleransı

6 sunucu, 2 sunucu toleransı

7 sunucu, 3 sunucu toleransı

…​

Bir Mongod süreci

Tüm veriyi replike eder

Okuma sorgularına yanıt verir

İstemciler için görünmezdir

Primary olamaz

Oy verebilir

Taşınma işlemleri

Fiziken daha yakında canlı verisi olan bir test sunucusu

Bir Mongod süreci

Tüm veriyi replike eder ama x süre geriden gelir

İstemciler için görünmezdir

Primary olamaz

Oy verebilir

Olası hatalı sorgularda daha canlıya yakın bir servis

Daha hızlı devreye alınabilir (tamamen yedekten dönmeye göre)

Bir Mongod süreci

Tek görevi quorum’da oy vermek

Hiç veri içermez, almaz ve vermez

Çok az kaynak tüketir

Replika sayısını düşürmek

Daha az donanım kaynağı harcamak

Depolama kapasitesi tek sunucuyu aşmak üzere

Tek sunucu yazma işlemlerinin hepsine yetişemiyor

Yapılan sorguların boyutu RAM’i aşmak üzere

Tek sunucuya donanım eklemek (mümkünse bile), yeni sunucu almaktan daha pahalı

Shardlamak kaynak ihtiyacını ve karmaşıklığı arttırıyor

Gerek yoksa yapmayın

Yapacaksanız son dakikayı beklemeyin (shardlama zaman alır)

mongos = mongo shard

Gelen çağrıları karşılar

Shardlanmış kümede verinin nerede olduğunu bulur

İlgili kümeye yönlendirir (router)

Yanıtları alarak istemciye döndürür

İstemci açısından mongos süreci = mongod süreci

mongos durursa, tüm kümeye erişim durur

İstemci tarafından doğrudan sorgulanır

Az donanım kaynağı tüketir

Yüksek bulunurluk için en az iki tane

Özel Mongod süreci

Shardlanmış kümenin metadata’sını saklar

Metadata = Hangi chunk nerede, ne boyutta

Az donanım kaynağı tüketir

Yüksek bulunurluk için üç tane

Mongo, shard anahtarına (key) göre shard’lara verileri dağıtır

Anahtar birden fazla alanı içerebilir

Anahtarın olabildiğince farklı değerde veri içermesi gerekir

Mongo’nun kendi otomatik ürettiği bir ID’yi anahtar olarak kullanmak mümkün

Amaç 1: Verileri olabildiğince shard’lara dengeli dağıtmak

Amaç 2: Yapılan sorguların olabildiğince tek bir shard’dan karşılanması

MongoS ve Config Sunucular kurulur

Eldeki replika set, bir shard olarak MongoS’a eklenir

İkinci bir replika seti oluşturulur, ikinci shard olarak MongoS’a eklenir

İstenen koleksiyonlar shardlanacak biçimde ayarlanır

İlk shard’daki veri dağıtılmaya başlanır

Veri dağılımı shard’lar içinde dengesizleşebilir

Balancer süreci "chunk"ları tekrar dağıtır

Sadece göç eşiği (migration threshold) geçildiği balancer çalışır

Bir MongoS tarafından dengeleme işlemi başlatılabilir

En çok chunk’ı olan shard’dan en az chunk’ı olana doğru yapılır

Sistemde yük oluşmaması için aynı anda tek bir chunk taşınır

Balancer geçici olarak kapatılabilir (çalışıyorsa önce yarım işlemi tamamlar)

Balancer’ın çalışma saatleri ayarlanabilir

Bir shard’a belirli bir boyut sınırı getirmek mümkün

Elle chunk taşıyarak, daha da ince ayar yapmak mümkün

O shard’da shardlanmamış veritabanı varsa, onun başka bir shard’a taşınması

Shardlanmış verinin boşaltılması (drain) ve diğerlerine aktarılması gerekir

Mongo’ya "shard’ı çıkar" dendiğinde shardlanmış veri taşınmaya başlanır

Verinin boşaltılması işlemi veri miktarına ve sisteme göre uzun sürebilir

Veri boşaltıldıktan sonra, tekrar "shard’ı çıkar" komutu gönderilir

Otomatik bir yöntemi yok

Yeni koleksiyon oluşturulur

Yeni bir shard anahtarı oluşturulur

Birindeki veri alınarak diğerine basılır

Veri girişi durdurulup, fark alınıp, tekrar aktarım yapılır

Veri girişleri yeni koleksiyona yapılmaya başlanır

Eski koleksiyon çöpe atılır

Alternatif 1: Tüm shard’ları teker teker çıkarıp, tekrar shard’lamak

Alternatif 2: Tüm verinin dump’ını alıp, key’i değiştirip veriyi geri basmak

Replika ile birebir canlı sistem oluşturma

Delayed Member ile x zaman geriden gelen canlı sistem

Oplog ile yapılan tüm işlemlerin tek tek kaydı

Doğrudan veritabanı dosyalarının kopyalanması

mongodump ile dokümanların yedeğini alma

Point-in-Time Recovery

Tutulan binary log kayıtları sayesinde veritabanının istenilen bir ana döndürmek mümkündür.

Oplog miktarı kadar geriye gidilebilir

Bir Delayed Member süreci hızlandırır (yoksa yedekten oluşturulur)

Delayed member’ın üzerinde oplog uygulanarak istenilen noktaya gelinir

mongooplog, mongorestore ile yapılır

MongoDB’nin kendi araçları canlı bilgi veriyor (mongostat, mongotop, vs)

MongoDB servisinden istatistiki bilgiler alınabiliyor (dbStats, serverStatus, vs)

MongoDB’nin Profiler özelliği (performans düşürür)

İç ağa kurulan bir gözetleme yazılımı kullanımı (Nagios, Zabbix, Ganglia, vs)

SaaS olarak (ücretli?) bir servis, dışarıdan erişim verilmesi gerekir (ör: MMS)

Ne kullanırsanız kullanın, hatalı uyarı vermemesi için, yazılımınıza göre ayarlamalısınız

MongoDB ayakta mı? :)

Boştaki bağlantı sayısı

Lock miktarı

Bellek kullanımı

Page faultlar

Eklenen veri miktarı

Silinen veri miktarı

Primary değişimleri

Replikasyon gecikmesi

Index ıskalama oranı

…​

RAID 10

SSD

RAM arttırımı

ulimit değerlerinin düzenlenmesi

Indeksler okumaya yararlı, yazmaya zararlı

vm.swappiness değerini düzenleme

Okuma için daha çok replika, yazma için daha çok shard

Sunucu zamanlarının NTP ile senkronize olması önemlidir

Kümeyi kapalı bir ağda çalıştırmak

İsim/parola doğrulaması kullanmak

Rol bazlı erişim kontrolü

--noscripting: mapReduce, group, eval ve $where

Web sunucu arayüzünü açmamak

Input validation kullanmak

Açık ağda Mongo’lar arası SSL kullanmak

Mongo araçları (mongodump, mongooplog, vb) multi-threaded

Farklı depolama motorları: MMAPv1, WiredTiger, TokuMX

Depolama alanının sıkıştırılması

Daha detaylı audit ve loglama

Daha fazla sorgunun explain() ile detaylı incelenebilmesi

Ayrı bir enterprise sürüm

Ops Manager ile grafik arayüz ile küme yönetimi

LDAP ya da Kerberos ile doğrulama

Destek hizmeti

?