cap theorem

• eric brewer tarafından 2000 yılında ortaya atılan ve epey doğrulanmış bir kuram. der ki:
  
  distributed sistemler aynı anda su 3 özelliğin hepsine sahip olamazlar: (en fazla ikisi olur yani)
  
  - consistency: butun nodelarda aynı anda aynı data vardır, commit edilen data her node'da commitlenmistir.
  - availability: sisteme yapılan butun requestlere cevap alınır.
  - partition tolerance: sistemdeki nodelardan bazıları bir sekilde kendi aralarındaki iletişimi kaybederse (crash olur, network outage olur) sistem calismaya devam eder.
  
  cloud computing sistemlerinden tutun nosql veritabanlarının tasarımında cok ciddi payı vardır bu bulgunun. ama gelin görün ki bugün p (partition tolerance) kısmı oldukca nadir lazım oldugundan genelde c&a bolca kullanılır.
  
  can sıkıntısından kendi uktemi doldurmasaydım iyiydi...
  
  (bkz: flp theorem)
• bunun klasik ispatini yapmak icin birbiri arasinda iletisim olan iki node alirlar ve bu iki node'dan birine yazip digerinden okurlar. normalde eger hersey yolunda giderse yazdigim degerden daha eski bir deger okumamam lazim. eger birisi benden sonra birseyler yazdiysa daha yenisini okuyabilirim o sorun degil. bu guzel durumda goruluyor ki consistency saglaniyor cunku okudugum deger guncel. availability saglaniyor cunku okumaya calisinca okudum. bana hele bi dur diyen olmadi. ama hani partition tolerance? olur da bu iki node arasindaki iletisim kesilirse^* ve ben bir node'a yazip nodelar arasi iletisimin kesildigi diger nodedan okumaya calisirsam, benim yazdigim node gidip digerine "bak beni guncellediler yeni degerimiz su" diyememis oldugundan eski bir sey okurum. ne oldu simdi? availability saglandi cunku okumak istedigimde bana bir deger soyledi ama hani consistency? alternatif olarak ben okumaya calistigimda "bi saniye guncel degilim" diye dusunerek bekletebilirdi beni ama ne kadar beklerdim? nodelar arasindaki iletisim tekrar kurulana kadar. o arada ne olurdu? availability yalan olurdu...
• zaman zaman kafada canlandırması zor olan bir teorem. şu linkteki hikaye oldukça yardımcı.
  
  özet ve kişisel yorumlarımla çevirisi şu şekilde yapılabilir.
  
  maaşlı işinizi bırakıp, hatırlatma hizmeti veren bir şirket kurmaya karar veriyorsunuz(ne kadar da girişimci biri). gazateye, internete, tv' ye her yere ilan verip "unutulmaması gereken günlerinizi 118-80'i arayıp söyleyin, biz sizin yerinize hatırlayalım" diyorsunuz.(alttan hızlı bir altyazıyla , 40 kuruş hizmet bedeli hattınızdan düşecektir yazmayı da atlamıyorsunuz) tipik bir konuşma şu şekilde geçiyor:
  
  müşteri: bizim kayınpederin doğum gününü kaydebilir misiniz?
  siz: tabi, ne zaman?
  müşteri: 12 ocak
  siz: (defterinizde müşteriye ait sayfaya not alıp) kaydedildi. kayınpederinizin doğum gününü hatırlamak için bizi istediğinizde arayabilirsiniz.
  müşteri: sağol yeğenim.
  siz: rica ederim, yine bekleriz.
  
  bir defter ve bir telefondan oluşan bu sistem oldukça başarılı oluyor ve her gün yüzlerce kişi aramaya başlıyor. problem burda ortaya çıkıyor, çünkü müşteriler sizle konuşmak için beklemek zorunda kalıyor.bazıları beklemeyip telefonu kapatıyor. işe gelmediğiniz gün ne kayıt alınabiliyor, ne de hatırlatma hizmeti verilebiliyor. işleri büyütmenin zamanı geliyor ve bir yastığa baş koyduğunuz eşinizden yardım istiyorsunuz.
  
  plan şu şekilde:
  
  - aynı numara - iki telefon (pbx)
  - pbx boş olan kişiye müşteriyi aktaracak.
  
  her şey iyi giderken daimi müşterilerinizden taylan'la aranızda şu görüşme geçiyor:
  
  taylan:kıbrısa uçuşum ne zamandı, hatırlayamıyorum mınskim?
  siz: tabi bir saniye taylan bey.
  siz: üzgünüm taylan bey, bize böyle bir bilgi vermemişsiniz, bir hata olmalı.
  taylan:ne! sizi daha dün aramıştım. böyle hizmetin amksdjskdaldajh...
  
  deyip kapatır. siz ne olduğunu anlamaya çalışırken jeton düşer. eşinizin kayıt aldığı deftere baktığınızda taylan'ın uçuş tarihi oradadır. consistency problemi dedikleri nana demekki buymuş dersiniz. bir müşteri kayıt ettirdiği kişiye hatırlatması için aradığında denk gelmezse o bilgiye ulaşamayacak yani.
  
  ama bunun da bir çözümü var, ve yine siz zehir gibi zekanızla yine işin içinden çıkıyorsunuz. yeni planı yine eşinize açıklıyorsunuz:
  
  -birimiz yeni hatırlatma kaydı(update) aldığımızda işlemi tamamlamadan önce diğerine haber verecek.
  -bu sayede ikimizde de en güncel kayıt tutulacak.
  -müşteri hatırlatılması için aradığında(search) diğerimizle konuşmaya gerek olmayacak. önümüzdeki defterden direkt söyleyebileceğiz.
  
  bu metodun tek olumsuz yani, yeni kayıt yaparken parallel çalışamamanız. ikinizde aynı bilgiyi yazmak zorundasınız.örneğin siz kayıt alırken, aynı anda eşiniz başka kayıt alamıyor. yine de bunu çok sorun etmiyorsunuz, çünkü bir müşteri kayıt için bir kez ararken, hatırlamak için 100 kez aramakta.
  
  tam bu sisteme geçecekken eşiniz sistemin zayıf noktasını tespit ediyor. " ya ikimizden biri işe gelmezse? o zaman diğer deftere kayıt yapılamayacağı için yapılan arama sonlandırılamayacak." evet, bu durumda o gün yeni bir kayıt alınamayacaktı. availability problemi ile de tanışmış olduk deyip yine düşüncelere daldınız.
  
  ama sizde çareler tükenmiyordu. yeni plan şuydu:
  
  -birimiz yine yeni hatırlatma kaydı(update) aldığımızda işlemi tamamlamadan önce diğerine haber verecek.
  -ancak karşı taraf işe gelmemişse, kayıtla ilgili e-mail atıp aramayı sonlandıracağız.
  -bir sonraki gün, işi asan kişi işe başlamadan önce maillere göre deftere güncelleyip çalışmaya başlayacak.
  
  evet, şimdi sistem size göre son derece consistent ve available.
  
  ta ki siz bayramda kaynananıza ikinci gün gidip eşinizi kızdırana kadar. işe gelmediğiniz gün, kızgın eşiniz gerekli güncellemeleri size email atmayıp bir sonraki gün çuvallamanıza neden oluyor. yani sisteminiz partition tolerant değil. siz de bu durum devam ederken, partition tolerant olmak için yeni bir kayıt almayı durduruyorsunuz. ama bu durumda availability kayboluyor.
• su sekilde de aciklanabilir:
  
  consistency : yapilan her read islemi, en son yazilan write datasini veya hata alir. belirsiz veri gelmez.
  availability : yapilan her isleme bir cevap gelir ancak bu cevabin dogru olup olmadigi garanti edilmez.
  partition tolerance : sistem network veya node errordan bagimsiz calisir.
  
  tasarlayacaginiz distributed sistemin ihtiyaclarina gore bunlardan sadece ikisini kullanabilirsiniz . ornekle anlatmak gerekirse :
  
  ornegin business sensitive bir cozum gelistirecekseniz, yanlis data uretmek istemezsiniz. bu yuzden hem gelen verinin guvenilir olmasi, hem de upgrade vs yaparken veri kaybina ugramamak icin cp - consistency ve partition tolerance - tercih edebilirsiniz. simdi buraya neden availability sokamiyoruz, mesela ?
  
  bu noktada tum nodelarin available olmasini istediginiz durumda, nodelar active-stand by calisacak, stand by olan node a data replication real time olmayacak ( yok oyle bir dunya :) ). active node'un kaybedildigi durumda, stand by node devreye mecburen eksik data ile girecek ( real time replication yapamiyoruz, hatirlayin ) ve cekilen veri guncel olmayacak, yani consistency kaybolacak. bu aslinda basit bir software trade off, ancak sistem tasarimina da cok kolaylikla uygulanabiliyor.
• bana siyaset felsefesinde meritokrasi sorununu çağrıştıran teoridir. yazılımcılıktaki bazı bilgilerin, siyaset felsefesindeki rejim biçimlerinde çeşitli şekillerde ortaya çıkan, özellikle oy verme ve yönetim hiyerarşisiyle ilgili bazı sorunların çözümünde kullanılabileceğini düşünüyorum.
• surada biraz aciklanmis, ama cok degil. http://robertgreiner.com/…06/cap-theorem-explained/
• consistency : nodelardaki verilerin senkronize oldugunu garanti eder.
  availability : clientlerin her zaman okuma ve yazma yapabilmesi anlamına gelir.
  partition tolerance: sistemindeki bazı nodeların aktif olmamısına ragmen sitemin calısma durumu.
  
  cap theorem aynı anda bunlardan sadece ikisine sahip olabilecegimizi soylüyor.
  
  https://phaven-prod.s3.amazonaws.com/…tic_mevik.png
• distributed sistemler soz konusu oldugunda 'c ve a'yi birlikte secemezsiniz. bu, cap teoreminin en cok yanlis anlasilan konularindan bir tanesidir.
  
  konuyu, bilal'e anlatir gibi anlatan linkler icin:
  
  https://henryr.github.io/cap-faq/
  https://codahale.com/…acrifice-partition-tolerance/
• cap, aşağıdaki üç özellik için bir kısaltmadır:
  
  consistency (tutarlılık) : bu özellik, bir cluster'da tüm node larin aynı verileri aynı anda görüp görmediğini belirtir.
  
  availability (kullanılabilirlik) : bu özellik, her istek için bir cevap alacağınızdan emin olup olmadığını gösterir. bir kullanıcı bir clusterdaki tüm nodelari kullanılabilir olduğunu düşünebilir mi? iki makine arasında bölünmüş veri veya durum bilgisini düşünün. bir istek yapılır ve makine 1'in bazı verileri vardır ve makine 2, verilerin geri kalanına sahiptir. her iki makine de azalırsa, tüm istekler yerine getirilemez, çünkü tüm veri veya durum bilgisi tamamen makinede mevcut değildir.
  
  partition tolerance (bolum toleransı) : bu özellik, sistemde rastgele mesajların kaybolması durumunda çalışmaya devam edip etmeyeceğini gösterir. bir sistem artık erişilebilir olmadığında bir ağ bölümü olayı oluşur (ağ bağlantısının başarısız olduğunu düşünün). bölme toleransını dikkate almanın farklı bir yolu, mesajın iletilmesi olarak düşünmektir. bireysel sistem artık başka sistemlere / sistemden mesaj alamıyor / alamıyorsa, şebekeden etkin bir şekilde ayrıştırılmıştır.
  
  kötü haber, çoğaltılan (veya dağıtılmış) bir sistemin aynı anda bu üç özellikten sadece ikisini sağlayabilmesidir.
  
  tutarlılık, kullanılabilirlik ve bölme toleransını aynı anda sunmak teorik olarak imkansızdır. büyük ölçekli bir sistem planlıyorsanız, gereksinimlerinize özel gereksinimlere bağlı olarak farklı konseptler bulmak zorunda kalabilirsiniz.
  
  mesela :
  postgresql, oracle, db2, vb., cap nin ca sini size sunarken, mongodb veya cassandra gibi nosql sistemleri size cap nin ap sini sağlayacaktır. bu yüzden nosql genellikle nihayetinde tutarlı olarak ifade edilir.