MongoDB Kurulum Tipleri

Uygulamanızın altında MongoDB’yi kullanmak oldukça kolaydır. Bir connection string ile database’e bağlanıp işleminizi yaparsınız. Ancak bağlandığınız ortamın neresi olduğunu, size nasıl bir high availability sağladığını veya sorun anında altyapının nasıl davrandığını pek bilmezsiniz. Bu makalede MongoDB kurulumlarından bahsedeceğim. Herhangi bir kurulum yapmayacağız sadece altyapısal olarak MongoDB bize neler sağlayabiliyor onlara göz atacağız. MongoDB’yi 3 farklı altyapısal şekilde kurabilirsiniz;

1. Standalone (Tek Sunucu)

Standalone kurulum aslında oldukça basittir. MongoDB’yi sunucuya yükler, servisi çalıştırır ve bağlanırsınız. Ancak standalone kullandığınız zaman altyapıda yaşanabilecek sorunlara karşı herhangi bir yedekliliğiniz yok demektir. Database sunucusu kapandığı zaman uygulamanız çalışamaz hale gelir. Ayrıca sunucunuzun gücü ne kadar ise o kadar performans alabilirsiniz. Eğer kritik bir uygulamanız yok ve kesinti toleransınız çok yüksek ise rahatlıkla kullanabilirsiniz.

2. Replica-Set

Replica Set kurulumu için birden fazla (en az 3) sunucuya ihtiyacınız vardır. Tüm sunucular tek bir replica set içerisine dahil edilir ve bu sunuculardan bir tanesi primary ilan edilir. Bu primary tüm read/write yükünü karşılarken diğer node’lar (secondary node’lar) read veya backup işleri için kullanılabilir. Ayrıca primary node’unuzda bir sıkıntı olduğu zaman diğer secondary node’lardan bir tanesi primary rolünü üstlenir ve minimum kesinti ile uygulamanız çalışmaya devam eder. High Availability anlamında oldukça sağlam bir altyapı sağlanmış olur. Ancak tabi ki handikapları yok diyemeyiz. Öncelikle write yapabildiğiniz sadece 1 node olduğundan (isterseniz replica-set’iniz 50 node’lu olsun) o sunucunun performansı kadar write yapabilirsiniz. Eğer uygulamanız çoğunlukla write yapıyor ise bu sizin için bir bottleneck oluşturabilir.

3. Sharded Cluster

Bu konfigürasyon aslında MongoDB’nin ve daha geniş bir perspektiften bakarsak database teknolojilerinin en üst konfigürasyonu diyebiliriz. Sharded Cluster aslında karmaşık gibi gözükse de komponentleri teker teker incelediğimiz zaman pek de karışık olmadığını göreceğiz. Kabaca tarif etmek gerekirse birden fazla replica-set bir araya geliyor ve Sharded Cluster’ı oluşturuyor. Bu sayede birden fazla write node’umuz oluyor. Ayrıca data istenilen şekilde replica-set’lere shard edilebiliyor. Örneğin bir e ticaret sitesi düşünelim. Otomobil kategorisine ait dokümanları A shard’ında, elektronik kategorisine ait dokümanları B shard’ında tutabiliyoruz. Bu sayede aslında iki kategorinin MongoDB’deki kaynağını ayrıştırmış oluyoruz. Bu sayede t anında otomobil kategorisine gelen read/write yükü artar ise bundan elektronik kategorisindeki ürünlerimiz etkilenmemiş oluyor.

Sharded cluster’ın client’ı karşılayan ilk komponent’i ise Mongos. Mongos’i bir proxy olarak düşünebiliriz. Uygulama connection string’ine mongos’i yazıyor ve mongos üzerinden database’e bağlanıyor. Peki istenilen verinin hangi replica-set’te olduğunu mongos nerden biliyor? Sonuçta otomobil kategorisindeki bir ürün için A shard’ına, elektronik kategorisindeki bir ürün için ise B shard’ına gitmemiz gerekiyor.

Aslında mongos herhangi bir metadata tutmuyor. Tüm replica-set metadatası Config Server dediğimiz komponent üzerinde tutuluyor. Yani client mongos’e gidiyor, mongos ilgili datanın nerede olduğunu öğrenmek için config server’a gidiyor, shard (replica-set) bilgisini alıp client’a veriyor. Aslında tüm sharded cluster komponentlerini listelersek;

• Mongos
• Config server
• Shard

MongoDB bakım ve desteği almak için bizimle iletişime geçebilirsiniz. Faydalı olması dileğiyle.