Önceki yazıya göz atmak isterseniz şu linki kullanabilirsiniz:
http://abdullahkise.blogspot.com.tr/2015/03/nosql-dunyas-1-veri-yonetiminin-evrimi.html
Geldiğimiz noktada temel olarak iki ayrı talep karşımıza çıkmakta;
- Ya verilerimiz son derece tutarlı olacak
- Ya da arıza bile olsa işlemlerimiz kesintiye uğramadan sistem son derece hızlı çalışacak.
Artan hız tutkusu, büyüyen ve çeşitlenen veri, kalabalıklaşan kullanıcı kitlesi gibi parametreler alt yapıya maliyetli yatırımlar yapmayı gerektirdi. Bu parametre değerlerinin dönem dönem farklılık göstermesi de alt yapı hazırlığındaki zorluğu bir kademe daha arttırdı.
Bir önceki yazımızda değindiğimiz gibi bu parametreler karşısında sisteminiz için iki tür ölçeklendirme yapabilirsiniz:
- Dikey Ölçeklendirme (Vertical Scaling - Scale Up) : Tek bir cihaza CPU, Memory gibi daha fazla kaynağın eklenmesi anlamına gelir. Sanallaştırma teknolojisi bu işlemlemi bir nepze olsun kolaylaşmıştır.
- Yatay Ölçeklendirme (Horizontal Scaling - Scale Out) : Sisteme görece daha ucuz bir çok cihazın bağlanması anlamına gelir.
Tek bir bilgisayarı güçlendirmek ve onunla çalışmaya devam etmek çok temiz görünüyor olabilir. Ancak bu şekilde güçücünüz bir yere kadar yetebilir. Tek bir süper bilgisayarın tüm dünya taleplerine cevap vermesi mümkün değildir (en azından şimdilik.). Dakikalar içerisinde terebaytlarca veri türetilebilen milyonlarca kullanıcının memnuniyetinin devam ettirildiği sosyal medya sistemlerinin arkasında tek bir makine olduğunu düşünebiliyor musunuz? Böyle bir süper bilgisayar çok pahalı olurdu. Ayrıca bu cihazın başına bir şey gelme ihtimali gücüne olan güveni yerle bir ediyor.
Bu durumda yatay ölçeklendirme daha mı mantıklı acaba? Yatay ölçeklendirme için bir araya getirdiğiniz cihazlar gelen talepleri güçlerini birleştirerek cevaplayabilirler. Harika! Peki bu cihazlar arasındaki iletişimde bir aksama olursa ne olur? Sistem durur mu? yoksa veri kaybına göz yumulur hayat devam mı eder? Cevapları yazının devamını okuyarak siz verebilirsiniz.
eTrade'in açıklamasına göre 1 saatlik kesintileri 8 milyon dolara tekabül ediyor. Dell 10 saatlik kesintisinin kendilerine 83 milyon dolara mal olduğunu ifade ediyor. Amozon'un 100 mili saniye daha hızlı çalışması karlarını %1 arttırabiliyor. Düşük performans, kesinti ve veri kaybı çoğu zaman kolayca tolere edilemeyecek sonuçlar doğurur.
En başta belirtiğimiz iki temel talep; tutarlılık ve erişilebilirlik, veri yönetim sistemlerinde iki farklı türde modelin doğmasına sebep olmuştur. Bunlar ACID ve BASE modelleridir.
ACID Modeli
Geleneksel veritabanı ile çalışmış olan hemen hemen herkesin aşina olduğu bir modeldir. Bu modelde çalışan sistemler tutarlılık konusunda son derece hassastır ve veri kaybına oldukça pesimist yaklaşır. ACID, yeteneklerini ortaya dökebilmek için kilit mekanizmalarını kullanır. Bu mekanizmalar verinin diskte ve memoryde tüm kullanıcılar tarafından aynı görünmesini, verinin güncellenmesi sırasında onay gelene kadar tüm istemcilerin bekletilmesini mümkün kılar. Gerekirse tüm veritabanı kilit altına alınır. Gerektiğinde çakışan işlemlerin en maliyetli olanı hariç hepsi iptal edilir. Tabi ki pesimistlik seviyesine müdehale edebilirsiniz. Ancak ACID pesimist olması için dizayn edilmiştir.
Bu yaklaşım, verileri denetim altında tutan lock ve latch mekanizlarını kullanarak veri bütünlüğünü son derece güvenli noktaya taşımıştır. Hızdan daha çok veri tutarlılığının ön planda olduğu, özellikle paraya dokunan işlemler için ACID vazgeçilmezdir.
Şu sözü her hatırladığımda hak veriyorum; Güçlü yanlar aynı zamanda zaafları doğurur. Çoğu zaman dikey ölçeklendirmede bazen de yatay ölçeklendirmede karşımıza çıkan bu modelin yetenekleri sistemleri hız konusunda adete boğazlamaktadır.
ACID, baş harflerini aldığı şu prensipleri garanti eder:
- Atomicity: Ya var ya yok prensibidir. Mesela bir banka havalesi yaptınız. Eğer havale işlemi gerçekleşmişse, sizden para eksilmiş, karşıya para eklenmiş demektir. Bunlardan biri hatalıysa havale işlemi geri alınır. Her şey havale öncesi haline döner. Paranız cebinizde kalır.
- Consistency: Yapılan işlemin mantıklı ve tutarlı olması prensibidir. İsteklerin veriyi bir tutarlı durumdan başka bir tutarlı duruma sokması gerekir. Ben 5 liralık havale yaptım, karşıya 2 lira gitti gibi bir şey söz konusu olamaz. Benden 5 lira eksildiyse karşıda da 5 lira artmalıdır. 2 lira görünüyorsa hesap özetine bakmakta fayda var. Bankanın o arada yaptığı başka bir hinlik olabilir.
- Isolation: İşlemin diğer işlemlerden izole olması prensibidir. Havale işlemi devam ederken veya henüz ben gönder onayını vermemişken kimse ne gönderiyor olduğumu bilemez. (Çeşitli Isolation Level'ler ile bu prensip esnetilebiliyor.)
- Durability: Yapılan işlemlerin kalıcı olduğunu ifade eden prensiptir. Verinin son halini sistem kayıt altına alır. Onay sonrasında bir sistem hatası bile olsa yeniden başlatıldığında verinin en son hali yerli yerindedir. Yani havale yaptınız karşıya para gitti ve yerine ulaştı. Sistem çökse bile paranız yerine ulaşmış demektir. Ancak verinin bulunduğu depolama alanı zarar görmüşse geçmiş olsun. Bu ACID'in garanti ettiği bir şey değildir. O sadece depolama aygıtınız sağlıklı çalıştığı sürece garanti verebilir. Bu aşamadan sonrası IT ekibinin Disaster Recovery yeteneklerine ve elindeki imkanlara kalmış demektir.
Hemen yeri gelmişken söyleyelim; SQL Server tarafında en azından bir kısım işlemler için bu zaaftan kurtulabilmek adına InMemory konsepti hayata geçirilmiştir. Hekaton adıyla duyurulan bu konseptte lock ve latch yer almamaktadır. Böylece 100 kata varan performans artışı elde edilebilmiştir.
Tutarlılığın ön planda olduğu özellikle paraya dokunan yerlerde ACID vazgeçilmezdir. Eğer benim için sosyal medya projelerinde olduğu gibi tutarlılıktan daha çok hız önemli diyorsanız, o zaman felsefenizi değiştirmeniz gerekir. Bu durumda BASE size ilaç gibi gelecektir.
BASE Modeli
Yatay ölçeklenmiş sistemlerde karşımıza çıkan bu modelde ACID'de olduğu gibi kilit mekanizmaları yer almaz. Tutarlılık konusunda son derece optimist bir yaklaşım söz konusudur. Bazı teknikler sayesinde tutarlı bir sistem kurulabilse de bu modelde asıl önemli olan taleplere hızla cevap verebilmektir. Sistemin büyüklüğüne ve sağlık durumuna bağlı olarak veri tutarlılığı yerlerde sürünebilir. Bir makinede arkadaşlık isteğini kabul ettiğiniz kişiye diğer makineden hemen baktığınızda isteğinin kabul edilmemiş olduğunu görmeniz muhtemel. Tabi ki kısa bir süre sonra onay tüm cihazlardan görünür hale gelir.
BASE, "Basically Available Soft-state services with Eventual-consistency" ibaresini ifade eder.
Yani, sürekli ayakta olan bu sistem kullanıcıların isteklerine hızla cevap verir. Veri tutarlılığını garanti etmez. Bir süre sonra veriler tüm sistemde tutarlı duruma gelir. Tutarlılık sağlanana kadar talebin yönlendiği cihazın elinde ne varsa istemciye o iletilir.
Yukarıdaki ibaredeyi ele alırsak;
- Basic Availability: Sistem CAP teoremine uygun olarak sürekli çalışır (CAP teoremine sonraki yazımızda odaklanacağız). Her bir talebe cevap verir. Fakat bu zorunluluk bir hata durumunda bile geçerli olduğu için veri tutarlılığını garanti etmez ve tüm veriye erişimi mümkün kılmaz. Yani bir nevi verinin bir kısmından feragat etmek suretiyle daha basit bir erişilebilirlik hizmeti almış olursunuz.
- Soft State: Verileri yazılır ancak tutarlı olmayabilir. Bu developerin görevi olarak görünür. Ayrıca veriler tüm cihazlarda aynı şekilde görünmesi garanti edilmez.
- Eventualy Consistency: İşlemlerin etkileri sistemin durumuna bağlı olarak ancak bir süre sonra diğer cihazlara yansır. Yani neredeyse tutarlı bir sistem.
Kim bu modelde çalışmak ister ki demeyin. Günlük hayatta her yanımızı saran sosyal medya bu model sayesinde milyonlara hizmet verebilmektedir. Birbirine bağlı binlerce cihazdan yüzlercesi gün içinde arızalanır. Fakat hizmet kesintisiz devam eder.
Yukarıda ACID ve BASE modellerinin varsayılan çalışma şekillerini anlattık. ACID modeli içerisinde "Isolation Level" tercihi çalışma şeklinizi BASE modeline benzetmenize olanak tanır. Benzer şekilde BASE modelindeki çalışma şekliniz de master kullanımı, kendi yazdığını okuma ve oy çokluğu gibi teknikler sayesinde ACID modeline benzetilebilir.
Yani bazı konfigrasyonlar sayesinde modeller birbirine yakınsayabilir. Ancak BASE yatay ölçeklenebilen NoSQL dünyasının, ACID ise dikey ölçeklenebilen geleneksel RDBMS dünyasının felsefesidir. Tabi istisnalar da mevcut. Mesela bazı NoSQL(NewSQL) veritabanları ACID'i destekler. Neo4J gibi.
Bu yazımızda veri tutarlarlılık modelleri olan ACID ve BASE'i ele aldık. Tutarlık (Consistency) ve erişebilirlik(Availability) ihtiyaçları göz önünde bulundurularak bu modeller arasında geçiş yapılabilir veya modeller bir yere kadar esnetilebilir. Tutarlılığın olduğu köşeyi ACID, erişebilirliğin olduğu köşeyi BASE almış durumda. Dikey ölçeklendirme dünyasında ACID, yatay ölçeklendirme dünyasında BASE hüküm sürmekte. Projelerinizi bu iki modelin karakterine bağlı olarak geliştirirsiniz. ACID tarafında kalmanız gerekiyorsa geleneksel RDBMS veya NewSQL teknolojilerine, BASE tarafında kalmanız gerekiyorsa NoSQL veya daha kapsamlı BigData teknolojilerine odaklanmanız gerekir.
Bir sonraki yazımızda BASE'in bu tembel tutarlılık yaklaşımının kaynağı olan ve birden fazla cihazın birlikte çalıştığı ekosistemde karşımıza çıkan CAP teoremini ele alacağız. Hem ACID hem BASE CAP teoremiyle ilişkilidir.
Serinin Devamı;
NoSQL Dünyası - 3 (CAP Teoremi)
http://www.abdullahkise.com/2017/01/nosql-dunyas-3-cap-teoremi.html
Peki, Ara Çözümler Var mı?
Yukarıda ACID ve BASE modellerinin varsayılan çalışma şekillerini anlattık. ACID modeli içerisinde "Isolation Level" tercihi çalışma şeklinizi BASE modeline benzetmenize olanak tanır. Benzer şekilde BASE modelindeki çalışma şekliniz de master kullanımı, kendi yazdığını okuma ve oy çokluğu gibi teknikler sayesinde ACID modeline benzetilebilir.
Yani bazı konfigrasyonlar sayesinde modeller birbirine yakınsayabilir. Ancak BASE yatay ölçeklenebilen NoSQL dünyasının, ACID ise dikey ölçeklenebilen geleneksel RDBMS dünyasının felsefesidir. Tabi istisnalar da mevcut. Mesela bazı NoSQL(NewSQL) veritabanları ACID'i destekler. Neo4J gibi.
Bu yazımızda veri tutarlarlılık modelleri olan ACID ve BASE'i ele aldık. Tutarlık (Consistency) ve erişebilirlik(Availability) ihtiyaçları göz önünde bulundurularak bu modeller arasında geçiş yapılabilir veya modeller bir yere kadar esnetilebilir. Tutarlılığın olduğu köşeyi ACID, erişebilirliğin olduğu köşeyi BASE almış durumda. Dikey ölçeklendirme dünyasında ACID, yatay ölçeklendirme dünyasında BASE hüküm sürmekte. Projelerinizi bu iki modelin karakterine bağlı olarak geliştirirsiniz. ACID tarafında kalmanız gerekiyorsa geleneksel RDBMS veya NewSQL teknolojilerine, BASE tarafında kalmanız gerekiyorsa NoSQL veya daha kapsamlı BigData teknolojilerine odaklanmanız gerekir.
Bir sonraki yazımızda BASE'in bu tembel tutarlılık yaklaşımının kaynağı olan ve birden fazla cihazın birlikte çalıştığı ekosistemde karşımıza çıkan CAP teoremini ele alacağız. Hem ACID hem BASE CAP teoremiyle ilişkilidir.
Serinin Devamı;
NoSQL Dünyası - 3 (CAP Teoremi)
http://www.abdullahkise.com/2017/01/nosql-dunyas-3-cap-teoremi.html
