şükela:  tümü | bugün soru sor
  • 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...
  • surada biraz aciklanmis, ama cok degil. http://robertgreiner.com/…06/cap-theorem-explained/
  • 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.
  • distributed bir sistemde, ayni anda consistency, availability ve partition tolerance'in saglanamayacagini soyler. mesela relational database'lerde consistency ve partition tolerance saglaniyorsa, bunun bedeli, availability'den feragat etmektir. nosql database'de ise availability ve partition tolerance saglanirken, bunun bedeli olarak consistency'den feragat edilir.

    daha da acmak gerekirse, soyle dusunelim;

    relational database icin;
    - consistency : tum node'lardaki veriler ayni
    - partition tolerance: node'larin birkaci uctu, buna karsin sistem ayakta ve diger node'lar uzerinden bilgi saglaniyor
    - availability: az once node'larin birkacinin ucmasindan bahsettik, node'larin da consistency'ye sahip oldugunu bildigimize gore, gocen node'lardan alinmasi gereken bilgi, diger database'lere query cekilerek alinacaktir, bu durumda da bunun bir zaman maliyeti vardir. availability de olculebilir goreceli bir kavram ayrica, attiginiz tweet'in 5 sn sonra gorunur olmasi bunun saglanamamasidir.

    nosql database icin;
    - consistency: data her an her node'da ayni olacak diye bir kaide yok, veri node'lara daginik bir sekilde yayilmis olabilir.
    - availability: hiz konusunda bir sorun yok, makul degerler icinde veri elde ediliyor (daginik node'lar icinde bir yerlerden)
    - partition tolerance: node'larin bir ya da birkacinin dusmesi, availability'yi dusurmuyor.

    ha simdi relational database'in availability'den feragat ederek nasil consistency ve partition tolerance ile distributed bir sistemde calistigini, kazanc ve kayiplarini anlatmama ragmen nosql database'de pek aciklayici olamadim. zira an itibariyle iddiasi consistency olmadan hizli ve partition tolerance'a sahip olunabilicegini iddia eden nosql kavramini ogreniyorum. velhasil neden nosql database kullanilir, ne icin tercih edilir sorusunun cevabidir, nasil'ini bilmem. adamlarin iddiasi bu sonucta, bunun uzerinde scalable web uygulamalari yapiliyor, nosql'in alip basini gitmesinin sebebi de dagitik sistemlerde yuksek performansla calismasidir.

    edit: ayrica bu biraz soyut ve teorik bir yaklasim sonucta;

    http://stackoverflow.com/a/12347673/3128926
  • 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/
  • 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.
  • 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.