Bu yazımda, NoSQL veritabanlarında uygulanan replication ve partitioning işlemlerinin ne olduğunu anlatmaya çalışacağım. Replication ile ilgili olarak maliyet ve avantajlarından bahsedeceğim. Neden replication yapmamız gerektiği sorusuna cevap vermeye çalışacağım.
Replication
NoSQL veritabanlarında kullanılan bir tekniktir. Elinizde veri var ve siz bu verinin birden fazla kopyasını alıp, birden fazla bilgisayarda saklıyorsunuz.
Örneğin, C1 clusterımız içerisinde 4 node’umuz olsun.
C1 = A, B, C, D
A node’unda tutulan tüm verilerin; B, C ve D node’larında full kopyası vardır. Bu şekilde verilerin kopyalarının farklı node’larda tutulması tekniğine replication denir.
Neden Replication?
Bunu yapmamız da birden çok sebep olabilir ancak, temelde 3 sebep vardır.
1. Performans
2. Fault Tolerance
3. High Availability
- Performans: Throughput’u arttırmak istiyor olabilirsiniz. Örneğin siz bir veriye çok fazla erişiyorsunuz. Bunu cluster içindeki farklı node’lara replicate edip, servis edebilirsiniz. 1 Node’dan okumak yerine 4 node’dan okuyup sistemin performansını arttırabilirsiniz.
- Fault Tolerance: Verimizin tek bir node üzerinde tutulduğunu düşünelim. Eğer ki o node herhangi bir sebepten ötürü veriyi kaybederse, veriyi tekrar elde etmek çok zor olacaktır. Belki de veri tam olarak kurtarılamayacaktır. Eğer ki replication yapmış olsaydık, çöken node yerine yeni bir node ekleyebilir ve cluster içindeki başka bir node’dan verileri replicate edebilirdik. Sistem normal bir şekilde çalışmaya devam edebilirdi.
- High Availability: Bir önceki senaryonun aynısının gerçekleştiğini varsayalım. Veriyi kaybettiğimiz yetmezmiş gibi, üstüne bir de servis veremez hâle geleceğiz. Çünkü verinin bulunduğu node ortada yok. Erişilebilirlik konusunda sınıfta kalmış olacağız. Replication yapmış olsaydık, gelen isteği başka bir node karşılar ve replicate ettiği veriyi geri dönebilirdi. Böylelikle sistem çalışmasına devam edebilirdi.
Partitioning
Partitioning replication yaparken kullandığımız bir yöntem. C1 clusterımızı düşünelim. A node’undaki veriyi B node’una replicate etmeye çalışalım. Ama verimizin boyutu çok büyük olmasın ve B node’unda yeterli alan olmasın.
Bu yüzden replication işlemini, partitioning yöntemi ile kullanacağız.
Data = P1 + P2
olarak ifade edelim. Yani verimizi 2 parçaya bölelim. P1 ve P2'ye partition, shard, bucket diyebiliriz. Ve her parçayı birden fazla yere replicate ediyoruz.
Örneğin; C1 clusterımızdaki data
verisini P1 ve P2 olmak üzere ayıralım.
A = P1 C = P2
B = P1 D = P2
olacak şekilde replicate edersek; hem sharding, hem de replication yapmış oluruz. Veriyi düşünecek olursak, hem birden fazla kopyasını saklamış oluyoruz, hem de veriyi küçük bloklara ayırmış oluyoruz.
Replication Maliyeti
Replication yapmanın da bir maliyeti var. Bu hayatta hiçbir şey free değil :)
Eğer ki replicate edeceğimiz veri üzerinde çok sık update işlemi yapılmıyorsa, yani read işlemi çok yüksek veya veri read-only ise replication yapmak çok kolay ve maliyeti düşük.
Replication işleminin maliyeti, sahip olduğumuz birden çok kopyası olan veri üzerinde update işlemi yapacağımız zaman başlıyor.
- Güncelleme yapmak.
- Güncelleme esnasındaki hataları ayıklamak.
Güncelleme yapma işlemi çok zor. Sahip olduğumuz tüm node’larda güncelleme işlemi başlatılacak ve bu esnada veri üzerinde conflict oluşacak.
Örneğin,
C1 clusterındaki A node’u üzerinde bir update işlemi yapalım. A node’unun replicası B olsun. A node yapılan update işlemini replicate etmek istediği anda çökmüş olsun. Daha sonra A node’u tekrar ayağa kalktığında, cevaplanması gereken bir soru var. A node’u üzerindeki veri geçerli mi değil mi? Buna karar vermek gerekiyor.
Hatta A node’u ayağa kalkana kadar, B node’u üzerinde başka bir update işlemi yapılmış olsun. A node’u geldiğinde, B node’unun replicate isteğine nasıl cevap verecek? Bunların hepsi belirlenmesi gereken kurallar ve ayrıca hepsi birer maliyet ve yük bizim için.
Read çok, Write az ise; Replication kolay, Maliyet düşük olacaktır.
Lost Update: Bir senaryo da şu. A node’unda update yaptık. A bu değişikliği B node’una bildirdi. B node’u successfull şeklinde cevap dönsün.
Daha sonra B, değişikliği C node’una söyleceği sırada çökmüş olsun. Yani update işleminden C node’u haberdar değil. Daha sonra biz C node’undan veriyi okumaya çalıştığımızda C bize böyle bir data olmadığını söyleyecek buna da lost update diyoruz ve oluşması bizim için çok kötü bir durum.