CAP Principle

2000 Yılında Eric Brewer tarafından öne sürülmüş, Gilbert ve Lynch tarafından 2002 yılında ispatlanmış ve kabul görmüştür. Teorem kısaca şunu söylemektedir; dağıtık bir data store’da 3 özelliğe aynı anda sahip olamayacağınızdan bahseder.

CAP teoremi bir üçgen gibi gösterilir.

      C            (CA) : Consistency – Availability
     / \           (CP) : Consistency – Partition Tolerance
    /   \          (AP) : Availability – Partition Tolerance
   A-----P

Bu teorem bize şunu söylüyor. Sisteminiz de sadece CA, CP, ve AP’yi aynı anda sağlayabilirsiniz. CAP’ye sahip olamazsınız. Acaba?

C, A ve P’nin ne olduğunu anlatabilmek için, bir data store cluster’a ihtiyacımız var ve clusterimiz 4 nodedan oluşşun.
C1 = A, B, C, D Nodes

Consistency — Tutarlılık

Consistency, 4 farklı node’dan veriyi okusam bile, her birinin bana aynı veriyi vermesi durumu. Veriyi replicate etmişiz ama okuma ve yazma yaparken sanki tek bir node’muş gibi işlem yapıyoruz böylece her zaman en güncel veriye erişiyoruz.

Örneğin C1 clusterındaki;
A node’una a=1 verisini koyalım. set a=1 --> A
Ardından B node’una a=3verisini koyalım. set a=3 --> B
C node’undan averisini okumaya çalışalım. get a <-- C
Aynı clusterdaki node’lar aynı değerleri veriyorsa sistem tutarlıdır.
Eğer 3 verisini elde ediyorsak sistemimiz tutarlıdır.

Availability — Erişilebilirlik

Erişilebilirlik; node’ların her an, her atılan isteğe cevap verebilme özelliğidir. Cluster’daki node’lar arasındaki network bağlantısı kopabilir. Bağlantı kopmasından kaynaklı olarak siz çalışma bakımından etkilenmiyorsanız high available bir sistem kurabilmişsinizdir. Ancak node’lardan aldığınız cevaplar, doğru ve güncel cevaplar olmayabilir. Availability çoğunlukla yüzdelik olarak ifade edilir ve bu değerler size süre cinsinden bilgi sağlar.

Downtime: Sistemin, erişilemez olduğu süre.
Uptime: Sistemin, erişilebilir olduğu süre.

+--------------+-------------------+--------------------+
| Availability | Downtime per year | Downtime per month |
+--------------+-------------------+--------------------+
|     %99      |     3.65 days     |     7.31 hours     |
|    %99.9     |     8.77 hours    |   43.83 minutes    |
|    %99.99    |   52.60 minutes   |    4.38 minutes    |
|   %99.999    |    5.26 minutes   |    4.38 minutes    |
|   %99.9999   |   31.56 seconds   |    2.63 seconds    |
+--------------+-------------------+--------------------+

Yukarıdaki tabloya bakarak, birisi size %99.99 uptime garantisi veriyorsa ve sizin aldığınız sistem aylık 5 dakika kapalı kaldıysa, gelsin paralar :)

Peki bu değerler nasıl hesaplanıyor? Çok basit, %99 uptime var ise, downtime %1 ihtimalledir. Yani;
(1 / 100) * 365 = 3.65 days.
((100–99.99)/100) * 365 * 24 = 8.77 hours.
Yaklaşık değerdir!

Örneğin C1 clusterındaki;
A node’una a=1 verisini koyalım. set a=1 --> A
Veriler replicate edilsin.
Yani B node’unda a=1 verisi var. repl a --> B
A node’nun replicası B node’u arasındaki network bağlantısı kopmuş olsun.
Şuan A ve B node’u arasında bir bağlantı yok. Yani A node’unda yapılan değişikliklerden B node’u haberdar olamayacak.

A node’undaki a verisini 4 olarak guncelleyelim. set a=4 --> A
Daha sonra B node’undan “a” verisini okumaya çalışalım. get a <-- B
Aldığımız cevap, 1 olacaktır. Ama bizim burada ilgilendiğimiz şey, sistemin en son koyulmuş veya doğru cevabı vermesi değil, bize cevap veriyor olmasıdır. High Availability bize şunu garantiler; sen bana istek attığında, her zaman bir cevap alırsın. Cevabın doğruluğu ve yanlışlığı ile ilgili bir şey söyleyemem. Low write, high read işlemlerinde çok iyi çalışır. Node’lar tekrar network bağlantısı kurduğunda veriler merge edilir. Merge işlemi esnasında conflictler oluşabilir. Bunun için merge functions tanımlaması yapılabilir. Rules yazılabilir. Bu sayede cluster’daki tüm node’lar aynı consistency seviyesine ulaşır.

Partial Tolerance — Bölünebilme Toleransı

Clusterımızda bulunan node’lar arasındaki network bağlantısı koptuğunda çalışmaya devam edebilme durumudur.

Replica: Başka bir node’a ait olan verinin kopyasını saklayan node’a verilen isim.
Replicate: Bir node’dan, başka bir node’a verilerin senkronize edilmesi işlemi.

Yani C1 clusterinda;
B, A’nın replicası. D, C’nin replicası.
Bu nodelar arasındaki bağlantı koparsa, sistem çalışabilecek mi? Doğru sonuçlar verecek mi?

CAP teoremine göre, aynı anda 3 duruma da sahip olamayız.

CA, Not P

Consistency ve availability istiyorsunuz. O zaman Partition Tolerance’dan feragat etmeniz gerekmektedir.
Nodelar arasındaki network bağlantınızın koptuğunu düşünelim.
A node’una a=1 verisini koydunuz. set a=1 --> A
Network bağlantınız koptuğu için, veriyi B node’una replicate edemediniz. Daha sonra, B node’una geldiniz ve “a” verisini istediniz. Cevap olarak, böyle bir verinin olmadığı cevabını alacaksınız. Bu da, sisteminizin P olmadığını gösteriyor. Veriniz parçalanmaya toleranslı değil.

AP, Not C

Availability ve Partition Tolerance istiyorsunuz. O halde, consistency’den feragat edeceksiniz.
A node’una a=1 değerini koydunuz. set a=1 --> A
B node’una bu değeri replicate edemediniz. Çünkü aranızdaki network bağlantısı bir şekilde koptu.
Daha sonra B node’una averisini sordunuz get a <-- B
Cevap olarak 0 veya boş bir string alırsınız. Error almazsınız.
B node’u şundan haberdar, bu veri bende yok ama diğer node’larda
mevcut olabilir. Ama size bir cevap dönmüş olur.

CP, Not A

Consistency ve Partition Tolerance istiyorsunuz. O halde, availability’den feragat edeceksiniz.
A node’una a=1 değerini koydunuz. set a=1 --> A
Eğer ki B node’u ile arasındaki network bağlantısı kopmuşsa, size write işlemini yapamayacağınıza dair cevap döner. Yani availability’i kaybettiniz. Sadece read yapabilirsiniz, çünkü network bağlantısı yokken veriyi güncellemek, tutarlılığı bozacaktır. Bu arada bu sistemle ilgili. Belki de size write izini verir, ama read izini vermez.

A node’una a=1 değerini koydunuz. set a=1 --> A
Network bağlantısı var ve bu değeri B node’una replicate edebildiniz.
Daha sonra B node’undan averisini okumaya çalıştınız. get a <-- B
Alacağınız cevap 1’dir.
Aralarındaki network bağlantısı koparsa, write işlemini yapamaz hale gelirsiniz. Bu durumda sadece read işlemini yapabilirsiniz. Veya tam zıttı şekilde, write yapabiliyorken read yapamazsınız. Bu durumda availability’den bir haber olmuş olursunuz.