CAP teoremine fazla takılmayın

Mete Evrenol
hesapkurdu-development
4 min readFeb 25, 2018

Geçen hafta ofiste yapılan Redis odaklı NoSql eğitiminde ekip olarak CAP teoremini konuştuk ve aklımızdaki bazı soru işaretlerini net bir şekilde gideremedik. Bunun üzerine ben bu konu hakkında bir araştırma yapıp bir blog yazısı ile CAP teoremini özetlemeye karar verdim. Ancak konu hakkında biraz detaylı okuma yaptıktan sonra aslında CAP teoreminin kolaylıktan çok kafa karıştırıcı olduğunu ve gerçek hayat senaryolarında fazla işe yarayamayacak kadar basit/yetersiz tanımlar içerdiğini gördüm. Konuyla ilgili en iyi özeti Martin Kleppmann’ın sitesinde buldum.

Martin’in makalesinde söylediği gibi aslında CAP teorimine vakit ayırmanın gerçekten ciddi bir faydası yok. Hatta dağıtık veri tabanı çözümlerini sadece CAP toerimine göre düşünmenin doğrudan hatalı olacağını söyleyebilirim.

Neyse, bir kere bu konu hakkında yazmaya karar vermiş olduğum için en azından özet bir şekilde açıklamaya çalışayım.

“C, A ve P içerisinden 2 tanesi seç” karışıklığı

CAP teoerimi diyor ki: Dağıtık bir database sistemi aşağıda özetlenen 3 özellikten 3'ünü birden barındıramaz. Bir tanesinden feragat edip iki tanesini seçmek zorundasınız. (Pratikte durum daha farklı. Aşağıda açıklıyorum)

Öncelikle her türlü kafa karışıklığının sebebi olan tanımlardan başlamakta fayda var.

CAP-Consistency: Tutarlılığın bu bağlamdaki tanımı aslında linearizability denen tutarlılığın bir alt kavramı. Eğer X işlemi, Y işlemi başarılı bir şekilde bittikten sonra başlıyorsa sistemi Y işleminin bitişi anındaki durumda veya daha yeni bir durumda görmeli.

Örnek: X işlemi = “Maçın skorunu oku”, Y işlemi = “Skoru güncelle: 1–0”.

Bu durumda Y işlemi başarılı bir şekilde gerçekleştikten sonra X işlemi “0–0” şeklimde bir cevap alamamalı.

Not: CAP-Consistency ile ACID-consistency bir birinden farklı.

CAP-Partition Tolerance: Dağıtık sistemdeki nodelar arası iletişim kesildiğinde dahi sistem beklenen şekilde çalışmaya devam etmeli.

CAP-Availability: Hata durumunda olmayan tüm nodelar, gelen isteklere başarılı cevap verebilmeli (erişilebilir olmalı).

Not: CAP-Availability ile High-availablity (veya SLA ile garanti edilen availability) kavramları bir biriden farklı.

Her CAP teoremi makalesinde zorunlu olan küme görseli

Bir çok makale genel olarak şu kombinasyonları anlatıyor: Neden CA olan bir sistemde P olamaz? Neden CP olan bir sistemde A olamaz? Neden AP olan bir sistemde C olamaz?

“I really need to write a new CAP theorem” –Eric Brewer

Aslında tüm bunların üzerinden geçmeye gerek yok. Eric’in 2010’da tweetlediği üzere elimizdeki CAP teoremi yeterli değil çünkü gerçek hayatta partition tolerance ihtiyacınız olmadığı bir durum yok. Bu yüzden aslında seçim C ve A üzerine.

Olası network sorunlarında tutarlılık mı daha önemli yoksa erişilebilirlik mi?

Tutarlılık ve erişilebilirlik arasında yapılması gereken seçimi Yoav Francis oldukça net bir şeklide aşağıdaki görseller ile anlatmış.

İlk durumda dağıtık sisteminizdeki tüm nodelarda verinin ilk hali: V0 var.

Nodelardan birine veriyle ilgili bir güncelleme geliyor. Yeni değeri V1.

Bu güncelleme diğer nodelara da aktarılıyor. Artık tüm nodelarda verinin son hali var.

Yeni bir okuma isteği geldiğinde ilgili node başarılı bir şeklide yanıtı V1 olarak dönüyor.

Şimdi network’de bir sorun olduğu ve nodelardan bir tanesinin diğeleri ile iletişim kuramadığı bir duruma bakalım

Nodelardan birine veriyle ilgili bir güncelleme geliyor. Yeni değeri V1.

Senaryo 1: Eğer CAP-Availability (Erişilebilirlik) tercih edildiyse, sistem güncellemeyi yapıp başarılı bir yanıt dönmeli.

Ancak budurumda farklı partitiona gelen bir okuma isteği V0 dönecek ve CAP-Consistency (tutarlılık) ihlal edilmiş olacak.

Senaryo 2: Eğer CAP-Consistency (tutarlılık) tercih edildiyse, tüm nodelar güncellenemeyeceği için gelen isteğin başarısız yanıt alması gerekli.

Yani hata durumunda olmayan nodelar güncelleme isteğini reddetmiş olacaklar.

Bu durumda CAP-Availability (erişilebilirlik) durumu ihlal edilmiş olacak.

Buna karşılık bir sonra gelecek okuma isteği sistemdeki aynı veriyi döneceği için tutarlılık sağlanmış olacak.

--

--

Mete Evrenol
hesapkurdu-development

Ex-Microsoft PM, co-founder at Çözenadam, now CTO at Hesapkurdu