MongoDb Read Preferences ve Write Concern Konseptleri

Modern veritabanı yönetim sistemleri, veri erişim ve yazma işlemlerinde yüksek esneklik ve güvenilirlik sağlamayı amaçlar. MongoDB, bu ihtiyaçlara cevap verebilmek için sunduğu gelişmiş özelliklerle öne çıkar. Özellikle read preferences ve write concernler, veritabanı işlemlerinde consistency, availability ve performans arasında dengeli bir yapı kurmayı mümkün kılar. Bu yazıda, MongoDB’nin read preferences ve write concerns kavramlarına bir bakış atacak, bu özelliklerin nasıl yapılandırıldığını ve uygulama senaryolarında nasıl kullanılabileceğini incelenecektir.

READ PREFERENCES

Replication genel olarak readleri scale etmek için kullanılır. Eğer ki tek node, uygulamanın read yükünü handle edemez ise, bu readleri birden fazla replicasyonu yayma seçeneği de mevcut. Bu read preference olarak adlandırılır ve driverinizi spesifik nodelardan read yapma imkanı sağlar. Read preferences MongoDB’deki bir sorgunun read işlemini yönlendiren bir ayarı ifade eder. Yani, bir sorgunun hangi MongoDB sunucusundan okunacağını belirlemek için kullanılır. genelde default primary readtir

Primary – Mongodb’de default read reference ayarıdır. Readlerin daima primary’e gideceği ve her daim consistent olacağını belirtir. Primary yoksa hata verir.

PrimaryPreferred – Bu readprefenrence de yine primaryden read yapar ancak primary bir sebepten unavailable olursa readler secondary’e gider. Bu da bazı durumlarda consistant olmama ihtimalini beraberinde getirir.

Secondary – Bu read preference da readlarin daima secondary node’a gideceğini garanti eder. Readlerin writelar üzerinde bir etkisi olmadığı durumlar için ideal olabilir. Eğer hiç bir secondary availlable değilse exception fırlatılır.

SecondaryPreferred – Sistemde secondary olduğu sürece secondarye eğer hiç secondary yoksa da primary’e yönllenir.

Nearest –  Bu config ile replika setteki network latency bazında yakın üyeden read yapar. Bu primary de olabilir secondary de.

Primary read preference, consistenyi garanti eden tek read preference’dir. Ayrıca neeratest kullanmasanız dahi mongodb size en hızlı cevap dönecek secondary’e yönlenme opsiyonu da sunar. Bunu da bir selection stratejisiyle yapar. Driver önce tüm nodeları network latecncyne göre sıralar. Sonra netwrok latensleri en düşük network latencyden 15ms at least büyük olanları exclude eder. Ve kalan nodelardan random bir tane seçer. 15 ms default bir ayardır deiştirebilir. Nearrest bu sürece primaryi de dahil eder ama aynı stratejiyle. En hızlısını seçemeyebilir belki ama aralarından hepsi birbirine yakındır zaten.

WRITE CONCERN

Verilerin yazılma işlemleri genellikle dağıtık bir ortamda gerçekleşir. “Write concern” kavramı da MongoDB’de bu dağıtık ortamda yazma işlemlerinin nasıl gerçekleştirileceğini kontrol etmeye yardımcı olan bir ayarı ifade eder. Write concern, bir yazma işlemi tamamlandığında acknowledge dönülebilmesi için clusterin ne kadarının onaylanması gerektiğini belirleyen bir konsepttir. Yani, bir veri yazıldığında, bu yazma işleminin kaç tane MongoDB sunucusu tarafından onaylanması gerektiğini kontrol etmek için kullanılır.

Write Concern Seviyeleri:

1. w: 0 (Standart):Bu durumda, yazma işlemi sadece MongoDB’deki bağlantı noktasına iletildiği anda onaylanır. Ancak, gerçekleşen bir hata durumunda bilgi alınamaz. w’i 0 set ettiğiniz takdirde write requestleri sonucu acknowledgment dönülmez. Bu seviye, yazma işlemlerinin hızlı bir şekilde gerçekleştirilmesi gereken durumlar için uygundur.
2. w: 1 (Default): Bu seviyede, yazma işlemi yazıldığı sunucu yani primary tarafından onaylandığında başarılı kabul edilir. Bu, standart güvenilirlik seviyesidir ve birçok uygulama için uygun olabilir.
3. w: majority (Çoğunluk): Yazma işlemi, veritabanındaki çoğunluk (majority) sunucuları tarafından onaylandığında başarılı kabul edilir. Bu seviye, yazma işlemlerinin genel güvenilirliği artırmak için kullanılır.
4. w: “tag”:1 (Özel Etiket): Belirli bir etiketle işaretlenmiş sunucuların yazma işlemini onayladığı durumu ifade eder. Özellikle özel bir konfigürasyona ihtiyaç duyan uygulamalarda kullanışlıdır.

Write concern, yazma işlemlerinin ne kadar güvenilir olduğunu belirler. Daha yüksek write concern seviyeleri, yazma işlemlerinin daha fazla sunucu tarafından onaylanması anlamına gelir, bu da veri bütünlüğünü ve güvenilirliği artırabilir. Ancak, daha yüksek write concern seviyeleri, yazma işlemlerini biraz daha yavaşlatabilir.

Bu ayar genel getLastError command’inin içerisinde w ve wtimeout olmak üzere iki ayar ile yönetilir. w writein toplam kaç servera replika edilmesi gerektiği, wtimeout ise write replike olamazsa ne kadar süre sonra bunun hatasının dönülmesi gerektiğidir ve milisaniyeler bazında olmalıdır.

Örneğin, writeınızın en az 1 servera replike olduğundan emin olmak istiyorsunuz. w’yi 2 set etmeniz gerekir. Bu server writeı alamazsa 500ms içinde, timeout dönsün istiyorsanız da wtimeout’u 500 set etmeniz gerekir. Eğer wtmeout tanımlanmazsa, operasyon süresiz olarak bloklanabilir.

Bir örnek üzerinden gidecek olursak 1 primary ve 2 secondary olacak şekilde 3 üyeli bir replika setiniz olduğunu varsayalım. w:2 oldugu durumda bir primary ve secondarylerden birinden ack dönüşüne ihtiyaç duyulur. w:3 set edildiği takdirde de primary ve iki secondaryden acknowledge ihtiyacı vardır.

Mongo db’de default write concern uygulamalar için 1 dir. çünkü uygulamaların çoğu primary servera write’ın hatasız bir şekilde ulaştığını bilmek ister. Ancak rollback ihtimalini elimine etmek isterseniz daha yüksek write concern kullanmanız gerekebilir. Bu noktada write concern developera bir write ack almadan önce repliklara yayılma ayarlamasını yapma imkanı sağlar. 

Write concern hem replica sets’te hem de master-slave replikasyonunda çalışabilir. Ancak 1’den büyük write concernlerin sisteme extra latency katacagını bilmekte de fayda var. Configure edilebilir write concern size speed ve durability arasında bir trade-off sunar. Eğer ki journaling ile çalışıyorsanız w’nin 1 olması çoğu uygulama için yeterlidir. Öte yandan, loglama ve analitik gibi konularda hem journalingi hem de write concerni devre dışı bırakmayı seçebilir ve durability için yalnızca replikasyonun kendisine güvenebiliriz. Bu durumda bazı senaryolarda writeları kaybetme ihtimalini göze alabiliriz.

Write concern seviyeleri, uygulamanızın ihtiyaçlarına bağlı olarak seçilmelidir. Örneğin, kritik verilerle çalışan bir uygulama için daha yüksek bir write concern seviyesi seçmek önemli olabilir, ancak daha hızlı yanıt sürelerine ihtiyaç duyan bir uygulama için standart seviye yeterli olabilir.

Tagging

Eğer write concern’leri ya da read ölçeklendirmesini kullanıyorsanız, write’ları ya da read’leri hangi ikincil node’ların alacağını daha ayrıntılı bir şekilde kontrol etmek isteyebilirsiniz. Örneğin, beş node’dan oluşan bir replika clusterını iki coğrafi olarak ayrılmış merkezde, NY ve FR’de dağıtmış olabilirsiniz. Ana veri merkezi, NY, üç node içerirken ikincil veri merkezi, FR, kalan iki node’ı içermektedir. Diyelim ki belirli bir write’ın FR veri merkezindeki en az bir node’a replike edilene kadar bloke etmek istiyorsunuz. Şu anda write concern’ler hakkında bildiklerinizle, bunu yapmanın iyi bir yol olmadığını göreceksiniz. Çoğu node’un (3) bir çoğunluğu ile bir w değeri kullanamazsınız çünkü en olası senaryo, NY’deki üç node’ın önce onay vereceğidir. 4 değerini kullanabilirsiniz, ancak diyelim ki her bir veri merkezinden bir node kaybederseniz, bu durum iyi bir şekilde sürdürülemez.

Replika kümesi tagging, bu sorunu çözer. Belirli tag’lere sahip replika kümesi üyelerini hedefleyen özel write concern modlarını tanımlamanıza izin vererek bu sorunu çözer.