Veritabanları Bölüm 2

Merhaba;

https://www.linkedin.com/pulse/veritabanlar%C4%B1-yazacak-%C3%A7ok-%C5%9Fey-var-sarav-asiye-yigit/ yazıma gösterdiğiniz ilgi için çok teşekkür ederim. Makalenin pek çok kişi tarafından okunmuş olması ve elbette güzel yorumlarınız; ikinci bölümü, araya çok zaman vermeden yazmam gerektiğini bana anlatmaya yetti. İlk bölümde verinin tanımını yaptıktan sonra, veri türlerinden bahsettim. Ardından, verinin saklandığı veritabanlarını, düz dosya sistemi veritabanından başlayarak günümüzde popüler olanlara da değinerek bize ne yönden farklılıklar sunabileceklerini aktarmaya çalıştım. Değişen gereksinimleri, ihtiyaçları karşılamak ve farklı kullanım modellerini ele almak için yeni veritabanı türlerinin geliştirildiğini ve geliştirilmekte olduğunu belirttim. Veritabanı türü seçimimizin, elbette, uygulamamızın ne tür işlemleri kolayca gerçekleştirebileceği, verilerimizi nasıl kavramsallaştırdığımız ve veritabanı yönetim sistemimizin geliştirme (“development”) ve çalıştırma (“runtime”) sırasında bize sunduğu özellikler üzerinde önemli bir etkiye sahip olduğunu belirttik.

Bu yazımda öncelikle CAP teoreminden bahsedeceğim. Ama CAP teoremine geçmeden önce, veri tutarlılığı modelinin (“consistency models”) ne olduğundan kısaca bahsedelim. NoSQL veritabanları sözkonusu olduğunda, veri tutarlılığı modellerinin, ilişkisel veritabanları tarafından kullanılanlardan çarpıcı biçimde farklı olduğunu bilmemiz gerekiyor. İki farklı tutarlılık modeli olarak karşımıza ACID ve BASE çıkmaktadır.

ACID: Atomicity, Consistency, Isolation, Durability

BASE: Basically Available Soft-State Eventual consistency

ACID tasarım ilkelerini izleyen bir DBMS, en yüksek düzeyde güvenilirlik sağlar. BASE tasarım ilkelerini izleyen DBMS ise genellikle iyimser bir çoğaltma yaklaşımı (“optimistic replication approach”) olarak ifade edilir. Yani, okumalar nihayi olarak aynı değeri bize döndürür.

Dağıtık uygulamalarınızı tasarlarken ve uygulamalarınız için en uygun veritabanı türlerini belirlerken CAP teoreminini anlamış olmanız oldukça önemlidir. CAP teoremi, bir dağıtık yapının 3 karakteristiğinden faydalanarak bir sonuç üretir. Nedir bu üç özellik? Ama önce dağıtık sistem derken neyi ifade ettiğimizi anlayalım. “Sistem” kelimesini lütfen tek bir sunucu olarak sakın algılamayın. Altyapı tarafında sunucuyu sistem olarakta çağırıyorlar. Sistem ifadesi tüm dağıtık yapıyı ifade etmek için kullandığım bir kelime. İlerde göreceğiz aslında bir “cluster” yapısı sunuyor bize. Dağıtık yapılarda, fiziksel veya sanal sunucuyu ifade etmek için “node” kavramı kullanılıyor. Dağıtılmış bir sistem/yapı, verileri, aynı anda birden fazla “node” (fiziksel makineler ve/veya sanal makineler) üzerinde depolayan bir “network”tür. Dağıtılmış hesaplama olarak da bilinen dağıtılmış bir sistem, son kullanıcıya tutarlı tek bir sistem olarak görünmek için aksiyonları “node”lar arasında uygun şekilde iletebilmeli ve bu aksiyonları “node”lar arasında koordine edebilmelidir. 1995 yılında Tubitak’ta master tezimi hazırlamak için çalışırken ilk kez karşılaştığım “Sun” sistemleri üzerinde, “The Network Is The Computer” yazardı. Şirketin bu sloganının aslında ne kadar doğru bir söylem olduğunu sektörde tecrübesi arttıkça daha iyi anlıyor insan. Dağıtık bir yapının etkin bir şekilde çalışabilmesi için “network”ün ne kadar kritik olduğunu biliyoruz.

Tüm bulut uygulamaları da dağıtılmış sistemler olduğundan, bir bulut uygulamasını tasarlarken de CAP teoremini anlamak çok önemlidir. Böylece uygulamanızın en çok ihtiyaç duyduğu özellikleri sağlayan bir veri yönetimi sistemi (“Database Management System”) seçebilirsiniz. CAP teoremine Brewer’s Theorem de deniyor. Bu teorem, ilk olarak Profesör Eric A. Brewer tarafından 2000 yılında geliştirildi. İki yıl sonra, MIT profesörleri Seth Gilbert ve Nancy Lynch “Brewer’s Conjecture” adlı bir ispat yayınladılar.

CAP teoreminde bahsedilen dağıtık bir sisteme ait bu üç karakteristik nedir?

Tutarlılık (“Consistency”):

Tüm istemciler, dağıtık sistem içinde olan hangi “node”a bağlanırlarsa bağlansınlar aynı verileri aynı anda görmelidirler. Bu durumda; veri, bir “node”a yazıldığında, yazma işlemi başarılı olarak kabul edilmeden önce, dağıtılımış yapı içinde olan tüm “node”lara anında iletilmeli veya kopyalanmalıdır. Tutarlılık için öyle bir garanti gerekir ki dağıtık yapı içindeki her “node”, aynı, güncel ve başarılı yazma işlemini vermelidir. Her istemci, verilerin aynı görünüşüne sahip olmalıdır.

Kullanılabilirlik (“Availability”)

Kullanılabilirlik, veri talebinde bulunan herhangi birinin, bir veya daha fazla “node” çalışmıyor olsa bile yanıt alabileceği anlamına gelir. Bu durumu ifade etmenin başka bir yolu – dağıtılmış sistemdeki tüm çalışan düğümler, istisnasız herhangi bir istek için geçerli bir yanıt döndürmelidir. Şu şekilde de cümleyi oluşturabiliriz, başarısız olmayan her “node”, tüm okuma ve yazma istekleri için makul bir süre içinde bir yanıt döndürmelidir.

Bölme Toleransı (“Partition Tolerance”)

Bölüm dediğimiz kavram, dağıtılmış bir sistemdeki bir iletişim kesintisini ifade eder. Yani, iki “node” arasından kaybolan veya geçici olarak geciken bir bağlantıyı ifade eder. 2000’li yıllarda gerek Sun Cluster ve gerekse Veritas Cluster ile yoğun olarak çalışan biri olarak, “cluster” yapılarındaki en büyük kabusumuz “heartbeat”ler üzerinden “node”ların konuşamaması durumu olurdu. Bu durumda, “cluster” veri bütünlüğünü korumak için bir dizi aksiyon alırdı. Ardından, bağlantılar geri geldiğinde sistemleri normal işlevsel hallerine geri getirmek bizim en önemli işlerimizden biri olurdu. Dağıtık sistemin, ağ bölümlerine rağmen çalışmaya devam etmesi gerekir ve elbette en önemlisi tutarlılığı garantilemesi gerekir. Bölüm toleransını garanti eden dağıtılmış sistemler, bölümleme sorunu giderildikten sonra diğer bölümler sayesinde bölüm toleransı normal haline döner.

Bu açıklamalar sonrasında, CAP teorem der ki, dağıtık bir yapı/sistem, üç farklı kategoriye ayrılır.

CP (“Consistent & Partition Tolerance”) Veritabanları:

CP veritabanı, kullanılabilirlik pahasına tutarlılık ve bölüm toleransı sağlar. Herhangi iki “node” arasında bir ağ bölümü oluştuğunda, sistemin/yapının, ağ bölümü sorunu çözülene kadar tutarlı olmayan “node”u kapatması (yani kullanılamaz hale getirmesi) gerekir.

AP (“Availability & Partition Tolerance”) Veritabanları:

Bir AP veritabanı, tutarlılık pahasına kullanılabilirlik ve bölüm toleransı sağlar. Bir ağ bölümü oluştuğunda, tüm “node”lar kullanılabilir durumda kalır ancak bölümün yanlış tarafındaki “node”lar diğerlerinden daha eski bir veri döndürebilir. Ağ bölümü sorunu çözüldüğünde, AP veritabanları genellikle sistemdeki tüm tutarsızlıkları ortadan kaldırmak için “node”ları yeniden senkronize eder.

CA (“Consistent & Availability”) Veritabanları:

Bir CA veritabanı, tüm “node”larda tutarlılık ve kullanılabilirlik sağlar. Ancak dağıtık sistemdeki herhangi iki “node” arasında bir ağ bölümlemesi oluşursa maalesef bunu yapamaz. Bu nedenle hata toleransı sağlayamaz. https://codahale.com/you-cant-sacrifice-partition-tolerance/ makalesini incelerseniz, dağıtık bir yapıda CA veritabanı yapısının mümkün olmadığını göreceksiniz. Döküman şöyle bir örnek veriyor;

Bir veri parçasının üç “node” üzerinden takip edildiğini/yazıldığını düşünelim, A, B ve C “node”ları. Bir ağ bölümlemesi sorunu ile karşılaşıldığında bu üç “node”, tutarlılığı ve kullanılabilirliliği garanti ettiğini iddia etsin. Dağıtık yapının iki ağ bölümüne düştüğünü düşünelim: {A, B} ve {C}. C “node”una, bu tek parça veriyi güncelleyecek bir yazma isteği gelsin. C “node”un iki opsiyonu var:

Bölüm sorunu giderilene kadar, A ve B’nin her ikisinin de bu yeni veriyi bilmeyeceğini bilerek yazma işlemini kabul eder. Yani, tutarlılıktan bertaraf ediyor. Kullanılabilirliği seçmiş oluyor.

İstemcinin ağ bölümü sorunu çözülene kadar A veya B ile iletişim kuramayacağını bilir ve yazma isteğini reddeder. Bu durumda da kullanılabilirlik pahasına, tutarlılığı seçmiş olur.

Bu ne demek? Yani birinciyi tercih ederse, kullanılabilirliği seçmiş oluyor; ikinciyi tercih ederse tutarlılığı seçmiş oluyor. İkisini aynı anda yapamaz.

https://www.ibm.com/cloud/learn/cap-theorem dökümanında bu konuda önemli bir ayrıntı var. Bu tür, teorik olarak listelense de dağıtılmış bir sistemde ağ bölümlemelerinden kaçınmak nerdeyse imkansız olduğu için, CA türünde dağıtılmış bir veritabanı var olamaz. Ancak bu, ihtiyacınız varsa dağıtık uygulamanız için bir CA veritabanına sahip olamayacağınız anlamına gelmez. Oracle, PostgreSQL gibi birçok ilişkisel veritabanı tutarlılık ve kullanılabilirlik sağlar. https://blogs.oracle.com/maa/the-cap-theorem:-consistency-and-availability-except-when-partitioned makalesinden şu alıntıyı yapmak istiyorum: “In a distributed system, you can have both Consistency and Availability, except when there is a Partition.” Yani, dağıtılmış bir sistemde, bir ağ bölümü oluşmadığı takdirde hem tutarlılığa hem de kullanılabilirliğe sahip olabilirsiniz. Yine pek çok makalede, dağıtık sistemler için nihayi tutarlılığı (“eventual consistency”) bir alternatif olarak sunuluyor. Veritabanı sistemi yalnızca nihai tutarlılığı destekliyorsa, uygulamanın, eski (tutarsız) verileri okuma olasılığına karşı bir takım işlemler yapması gerekecektir. Yani, nihai tutarlılıkta ilişkili “eski verileri okuma” probleminden kaçınmak uygulama geliştiricisine bırakılmıştır.

https://www.oracle.com/technetwork/consistency-explained-1659908.pdf makalesini kesinlikle okumanızı öneriyorum. Bir yere paket ulaştırmak istediğinizde, paket gitsinde ne zaman giderse gitsin veya mutlaka şu saatte bu paket ilgili yerde olmalı analojisinden yola çıkarak, Oracle NoSQL veritabanında, uygulama tasarımcısının gerekli tutarlılık düzeyini işlem başına seçebildiğine dikkat çekiyor. İşlem başına tutarlılık seçimi opsiyonun en esnek ve en “uygulama dostu” olanı olduğu ifade ediliyor.

Ilk bölümde de belirttiğim gibi veritabanı konusu çok geniş. Uygulamanız ile ilgili en doğru kararı vermek için çok araştırmalı, okumalı, etkin ve gerekli testleri veritabanı ve uygulama ekipleriyle birlikte kontrollü yapmanız gerekir. Uygulama için yanlış bir veritabanı seçimi hiç iyi olmazdı.

CAP teoreminin anlaşıldığını düşünüyorum Şekil 1’de CAP teoreminin özetini görebilirsiniz.

Şekil 1. CAP Teorem.

İkinci önemli kavramımız, “storage engine”dir. Bir depolama motoru (“storage engine”), bir veritabanı yönetim sisteminin (DBMS) verileri oluşturmak, okumak, güncellemek ve silmek (CRUD) için kullandığı temel yazılım bileşenidir. Şu “storage engine” en iyisidir diyebileceğimiz bir durum maalesef yok. Bir “storage engine”, belirli işlemlerde ve ortamlarda çok etkili olabilirken, diğer işlemler için doğru seçim olmayabilir. Bu nedenle, birçok modern DBMS, aynı veritabanı içinde birden çok depolama motorunu modüler bir bileşen olarak desteklemektedir. “Storage engine” aslında verilrin nasıl işlendiğini ve depolandığını tanımlar. Bir veritabanında kullanılan her “storage engine”in, uygulamanın tasarımına göre seçilmesi gereklidir.

Bilmemiz gereken diğer önemli bir konu, paylaşımlı disk kümeleri (“shared disk clusters”) ve hiçbir şeyin paylaşılmadığı kümelerin (“shared nothing clusters”) ne anlama geldiğidir. DBMS sistemlerinde iki farklı yaklaşım vardır: paylaşımlı disk (“shared disk”) ve hiçbir şey paylaşımlı değil (“shared nothing”). Paylaşımlı bir disk sisteminde, bir DBMS (“instance”) çalıştıran tüm sunucuların eşzamanlı olarak tüm verilere erişimi vardır. Hiçbir şeyin paylaşılmadığı bir sistemde ise veriler bölümlenir ve DBMS (“instance”) çalıştıran her bir sunucu, verilerin yalnızca bir alt kümesine erişir ve onu yönetir. Şekil 2 bize aradaki farkı göstermektedir.

Şekil 2. “Shared Disk Cluster” ve “Shared Nothing Cluster”.

“Shared nothing cluster” kavramından aslında “database sharding” kavramına gelmek istiyorum çünkü “database sharding”, hiçbir şey paylaşılmayan bir mimariye örnek teşkil etmektedir. “sharding”de yapılan şey, verinin benzersiz küçük parçalara ayrılmasıdır. Şekil 3.’de en basit haliyle “sharding” yapısını görebilirsiniz. “Sharding”i, yatay bölümleme (“horizontal partitioning”) olarakta düşünülebiliriz (Şekil 4).

Şekil 3. “Sharding” Yapısı.

Şekil 4. Dikey ve Yatay Bölümleme.

Bölüm 1’de pek çok farklı veritabanı türünden bahsettik: düz dosya veritabanları, hiyerarşik veritabanları, ağ (“network”) veritabanları, ilişkisel veritabanları, Anahtar-değer veritabanları (“key-value databases”), belge veritabanları (“document databases”), grafik veritabanları, sütun ailesi veritabanları (“column-family databases”), zaman serisi veritabanları, çok modelli veritabanları. Her biri içinde popüler veritabanı örnekleri verdik.

Yukarda aktardığımız kavramları, Bölüm 1’de isimlerini verdiğimiz popüler veritabanlarıyla eşleştirmeye çalışalım. Öncelikle CAP teoreminden başlayacağım.

MongoDB, verileri BSON (ikili JSON) belgeleri olarak depolayan popüler bir NoSQL veritabanı yönetim sistemidir. MongoDB, CAP teoremine göre bir CP veri deposudur. Tutarlılığı koruyarak ağ bölümlenmesi sorununu çözerken kullanılabilirlikten ödün verir.

Şekil 5. MongoDB “Single-Master System”.

MongoDB, tek yöneticili bir sistemdir (“single-master system”). Yani, sadece bir tane “primary” birincil “node” olabilir. Tüm yazma işlemlerini “primary” node alır. MongoDB’de “replica set” dediğimiz bir kavram vardır. Aynı veri setini koruyan bir grup “mongod” prosesidir. Yedeklilik ve yüksek kullanılabilirlik sağlar. Tüm üretim dağıtımlarının temelini oluşturur. Aynı “replica set” içindeki diğer “node”lar, ikincil yani “secondary” node’lardır. İkincil “node”lar, “primary” node’un operasyon logunun replikasyonunu yapar ve kendi veri setlerine uygularlar. Varsayılan olarak, istemciler, “primary” node’dan da okuma yapar. Diğer taraftan, istenirse, ikincil düğümlerden okumalarına izin veren bir okuma tercihi de belirtebilirler. “Primary” node, kullanılamaz olduğunda, en güncel operasyon loguna sahip olan “secondary” node, yeni “primary” node olarak seçilir. Diğer “secondary” node’lar yeni master node’u yakaladığında, “cluster” tekrar kullanılabilir olur. İstemciler bu zaman aralığında herhangi bir yazma isteğinde bulunamayacağından, veriler tüm ağda tutarlı kalır.

“Storage engine” kavramından bahsetmiştik. Tekrar ifade etmek gerekirse, depolama motoru, verilerin hem bellekte hem de diskte nasıl saklandığını yönetmekten sorumlu olan veritabanı bileşenidir. MongoDB, farklı motorlar belirli iş yükleri için daha iyi performans gösterdiğinden, birden çok depolama motorunu destekler. Kullanım durumunuza uygun depolama motorunu seçmek, uygulamalarınızın performansını önemli ölçüde etkileyecektir. WiredTiger, MongoDB 3.2 sürümü ile başlayan varsayılan depolama motorudur. Çoğu iş yükü için çok uygundur ve yeni dağıtımlar için önerilmektedir. WiredTiger, diğer özelliklerin yanı sıra belge düzeyinde eşzamanlılık modeli (“document-level concurrency model”), denetim noktası belirleme (“checkpoint”) ve sıkıştırma (“compression”) gibi özellikler sağlar.

(“In-Memory Storage Engine”), bellek içi depolama motoru, MongoDB Enterprise’da mevcuttur. Belgeleri diskte depolamak yerine, daha öngörülebilir veri gecikmeleri için onları bellekte tutmaktadır.

MongoDB’de “sharding” yapısı nasıl olmaktadır? “Sharding”in verileri birden çok makineye dağıtmak için kullanılan bir yöntem olduğunu belirtmiştik. MongoDB, çok büyük veri kümeleri ve yüksek verimli işlemler gerektiren dağıtımları desteklemek için “sharding” yapısını kullanır. Büyük veri kümelerine veya yüksek verimli uygulamalara sahip veritabanı sistemleri, tek bir sunucunun kapasitesini zorlayabilir. Örneğin, yüksek sorgu oranları sunucunun CPU kapasitesini tüketebilir. Sunucunun RAM’inden daha büyük çalışma seti boyutları, disklerin I/O kapasitesini zorlar.

Sistemdeki büyüme kapasitesini adreslemek için dikey (“vertical”) ve yatay (“horizontal”) ölçekleme kavramları vardır. Dikey ölçeklendirme, daha güçlü bir CPU kullanmak, daha fazla RAM eklemek veya depolama alanı miktarını artırmak gibi tek bir sunucunun kapasitesini artırmayı içermektedir. Mevcut teknolojilerdeki sınırlamalar, tek bir makinenin belirli bir iş yükü için yeterince güçlü olmasını bu nedenle kısıtlayabilir. Sonuç olarak dikey ölçekleme için pratikte bir maksimum sınır vardır diyebiliriz.

Diğer taraftan yatay ölçeklendirme ise veri kümesini bölmeyi, birden çok sunucuya yüklemeyi ve kapasiteyi ihtiyaca göre artırmak için ek sunucular eklemeyi içerir. Tek bir makinenin hızı veya kapasitesi yüksek olmayabilir. Ancak bu mimaride her makine genel iş yükünün bir alt kümesini yönetir. Bu mimari (Şekil 6) potansiyel olarak tek bir yüksek hızlı, yüksek kapasiteli sunucudan çok daha iyi verimlilik sağlar. Dağıtım kapasitesini genişletmek için, yalnızca gerektiğinde ek sunucuların eklenmesi yeterlidir.

MongoDB, “sharding” yapısını kullanarak yatay ölçeklendirme sağlar. “Sharding” mimarisinde üç bileşen vardır:

“Shard”: Her “shard”, parçalanan verinin bir alt kümesini içerir. Her “shard” bir “replica set” olarak dağıtılabilir.

“Mongos”: Sorgu yönlendiricisi olarak görev yapar. Istemci uygulamalarla, “sharded” yapıdaki “cluster” arasında bir arabirim sağlar.

“Config Servers”: Bu sunucular, meta veri ve yapılandırma ayarlarını depolar.

Şekil 6. MongoDB Sharding Yapısı

MongoDB ile ilgili son olarak, “Ops Manager”dan bahsedeceğim (Şekil 7). “Ops Manager” MongoDB node’larını ve kümelerini (“cluster”) yapılandırmanızı ve korumanızı sağlar. “Ops Manager”, önemli veritabanı ve donanım göstergeleri hakkında gerçek zamanlı raporlama, görselleştirme ve uyarı mekanizması sağlar. Elbette, “replica set” ve “cluster”ların, planlanan zamanlar için anlık görüntüsünü alabilme, “point-in-time” kurtarılabilme özellikleriyle bir yedekleme çözümü olarakta fayda sağlar.

Şekil 7. MongoDB “Ops Manager”.

Cassandra ve CAP teoremini analiz edelim. Apache Cassandra, Apache Software Foundation tarafından sağlanan açık kaynaklı bir NoSQL veritabanıdır. Verileri dağıtılmış bir ağda depolamanıza izin veren geniş sütunlu (“wide-column database) bir veritabanıdır. Bununla birlikte, MongoDB’den farklı olarak, Cassandra, bir “master” node’a sahip değildir. CAP teoremine göre Cassandra bir AP veritabanıdır. Yani kullanılabilirlik ve bölüm toleransı sağlar ancak her zaman tutarlılık sağlayamaz. Cassandra’nın “master node”u olmadığı için, tüm “node”lar sürekli olarak kullanılabilir olmalıdır. Ancak Cassandra, istemcilerin herhangi bir zamanda herhangi bir “node”a yazmasına izin vererek ve tutarsızlıkları mümkün olan en kısa sürede gidererek nihai tutarlılık sağlamayı hedefler. Veriler, yalnızca bir ağ bölünmesi durumunda tutarsız hale geldiğinden ve tutarsızlıklar hızla çözüldüğünden, Cassandra “node”ların eşlerini yakalamalarına yardımcı olmak için (“repair”) onarım işlevi sunar. Bununla birlikte, sürekli kullanılabilirlik, uygulamanıza bağlı olarak ödünleşmeye değer olabilecek yüksek performanslı bir sistem sağlar.

Cassandra’da, bir kümedeki (“cluster”) bir veya daha fazla “node”, belirli bir veri parçası için kopya (“replica”) görevi görür. Bazı “node”ların güncel olmayan bir değerle yanıt verdiği tespit edilirse, Cassandra en güncel değeri istemciye döndürecektir. Cassandra, en son değeri döndürdükten sonra eski değerleri güncellemek için arka planda bir okuma onarımı gerçekleştirir. Şekil 8, Cassandra’nın tek bir hata noktasına sahip olmamasını sağlamak için bir kümedeki “node”lar arasında veri çoğaltmayı (“data replication”) nasıl kullandığını göstermektedir.

Şekil 8. Cassandra Veri Replikasyonu.

Cassandra, birden fazla veri Merkezi konfigürasyonu doğuştan destekler. Cassandra mimarisinde bazı temel bileşenler mevcut (Şekil 9).

Şekil 9. Cassandra Mimarisi.

Node: Veriyi depoladığımız alanlar.

Rack: Bir veya birden fazla “node”un mantıksal koleksiyonu.

Data Center: Bir veya birden fazla “rack”ın mantıksal seti. Replikasyon, veri merkezi tarafından yönetilir.

Cluster: Bir veya birkaç veri merkezinden oluşan mantıksal bir set.

Cassandra için “vnode” ve “token” kavramlarından bahsetmemiz gerekiyor.

Cassandra, büyük miktarlarda veriyi depolamak ve veri büyüdükçe yeterince esnek olabilmek adına oldukça başarılı bir veritabanıdır. Diğer taraftan, küme (“cluster”) içindeki verinin dengesiz bir şekilde dağıtılmasının önüne geçilmesi gerekiyor.

Her “node” için casandra.yaml dosyasındaki initial_token ayarını kullanarak “token”ları belirtebilir ve veri modelinizin verileri kümeye (“cluster”)a eşit olarak dağıtmasını sağlayabilirsiniz. Diğer bir deyişle Cassandra, veriyi “token”lara göre dağıtır. “Token”, “primary key”in “hashed” değeridir. Cassandra’ya bir “node” eklendiği zaman, her “node”a “token” aralığı atanır. Bu sayede, Cassandra’ya bir veri eklendiğinde, “token” hesaplanır ve verinin hangi “node”da tutulacağı belirlenir. “Vnodes”, cassandra.yaml dosyasındaki “num_tokens” ayarı ile tanımlanan mevcut “token” aralığını daha küçük aralıklara böler. “Vnodes”un faydasını görmek için, “vnode”ları küme içinde rastgele dağıtmamız gerekir. Bu amaç ile Cassandra, “Cassandra-Shuffle” algoritmasını kullanır. Şekil 10’da “vnode”ların olduğu ve olmadığı yapıyı görebilirsiniz.

Şekil 10. Vnodes

Şekil 11 ise “shuffling” algoritması sonrası “vnodes”ların ne şekilde rastgele dağıldığını göstermektedir. Cassandra, “Log Structured Merge (LSM) storage engine” kullanır. LSM ağacı, uzun bir süre boyunca yüksek yazma hacmine sahip dosyalara erişim için en uygun performans özelliklerine sahip bir veri yapısıdır.

Şekil 11. “Shuffling”

Cassandra’nın depolama motoru yani “storage engine” yapısına bakalım. Cassandra, B-Ağacı (“B-tree”) kullanan tipik bir ilişkisel veritabanının aksine, “Log-Structured Merge Tree”ye benzer bir depolama yapısı kullanmaktadır. Cassandra, yazmadan önce okumaktan (“read-before-write”) kaçınır. Yazmadan önce okuma, özellikle büyük dağıtılmış bir sistemde, okuma performansında büyük gecikmelere ve diğer başka sorunlara neden olabilmektedir. Örneğin, iki istemcinin aynı anda okuma yaptığı bir durumu düşünelim; birinci istemci A güncellemesini yapmak için satırın üzerine yazar ve diğer istemci ise B güncellemesini yapmak için satırın üzerine yazar, yani A güncellemesini kaldırır. Maalesef, bu yarış durumu belirsiz sorgu sonuçlarına neden olur: hangi güncelleme doğru?

Cassandrai çoğu yazma işleminde yazmadan önce okumayı kullanmaktan kaçınmak için, depolama moturu, “insert” ve “update” işlemlerini bellekte gruplamaktadır. Verileri ekleme (“append”) modunda sıralı olarak disker yazar. Veriler diske yazıldıktan sonra, değişmezdir ve asla üzerine yazılmaz. Verilerin Cassandra’dan okunması, sıralı olarak yazılmış bu değişmez verilerin doğru sorgu sonuçlarını keşfetmek için birleştirilmesi anlamına gelir.

Cassandra’nın sıralı olarak değişmez dosyalar yazdığını söylemiştik. Aslına bu yazma modelinden dolayı yazma yükseltmesinden (“write amplification”) ve disk arızalarından kaçınıldığından, veritabanı ucuz, tüketici SSD’lerle etkin bir şekilde kullanılabilir.

Yazımın 2. bölümünü burda tamamlamak istiyorum. Bu bölümde, CAP teoreminden ve depolama motorlarından bahsettim. MongoDB ve Cassandra’nın CAP teoreminde hangi tür veritabanlarına karşılık geldiğini belirtti. Bu iki veritabanının depolama motorlarıyla ilgili genel bilgilendirme yaptım. Yazımın 3. bölümünde Couchbase anlatıyor olacağım.

Sarav Asiye Yiğit – 28 Kasım 2020 – Cumartesi

Kaynakça:

https://www.service-architecture.com/articles/database/index.html

https://towardsdatascience.com/cap-theorem-and-distributed-database-management-systems-5c2be977950e

https://www.ibm.com/cloud/learn/cap-theorem

https://blog.stackpath.com/distributed-system/

https://tr.wikipedia.org/wiki/Sun_Microsystems

https://dzone.com/articles/understanding-the-cap-theorem

https://codahale.com/you-cant-sacrifice-partition-tolerance/

https://blogs.oracle.com/maa/the-cap-theorem:-consistency-and-availability-except-when-partitioned

https://www.ibm.com/cloud/learn/relational-databases

https://www.oracle.com/technetwork/consistency-explained-1659908.pdf