APACHE CASSANDRA: Nedir? Nasıl Kullanılır?
Bu yazımda veri kaybı önlem, yüksek erişilebilirlik ve yüksek performans gereksinimleri doğrultusunda günümüzde yaygın olarak tercih edilen bir veritabanı Apache Cassandra’dan bahsedeceğim.
Öncelikle Cassandra’nın ne olduğundan bahsedeceğim. Takiben örnek kullanım senaryolarına değineceğim. Yazının akışı aşağıdaki gibi olacaktır:
- Nedir?
- Avantajları Nelerdir?
- Dezavantajları Nelerdir?
- Nasıl Çalışır ve Mimarisi Nedir?
- Basit Ölçekte Örnek Cluster Kurulumu
Apache Cassandra Nedir?
Apache Cassandra en basit tanımıyla bir NoSQL veritabanıdır. İlişkisel veritabanlarına göre daha esnek bir yapıya / veri modeline sahiptir. Özellikle ilişkisel olmayan verilerin depolanması için uygundur. Apache Cassandra’nın çoğu avantajını sağlayan özelliği ise dağıtık yapıda olmasıdır. Bu yapıda veriler bir cluster içerisinde belirlenen kriterlere göre farklı bileşenlerde depolanmaktadır.
Cassandra’nın ilk çıkış noktası Facebook’un arama ve indeksleme işlemleri için yüksek performanslı bir veri kaynağı arayışıdır. Bu arayış doğrultusunda Facebook içerisinde bu işlemleri daha verimli hale getirmek için Java tabanlı tasarlanmaya başlanmış ve daha sonra 2008’de açık kaynaklı bir proje haline getirilmiştir. Mart 2009’a gelindiğinde ise Apache kuluçka merkezine geçmiş ve günümüze kadar bu bünyede gelmiştir.
Cassandra günümüzde farklı avantajlarını ön plana çıkaran birçok büyük firmada kullanılmaktadır. Sektöründe lider firmalardan birkaçı Apple, Netflix, CERN, Cisco şeklindedir.
Cassadra’nın Avantajları
Cassandra aynı özellikte birden fazla node’dan oluşan bir cluster üzerinde veriyi dağıtık (decentralised) bir yapıda depolamaktadır. Bu yapıda, cluster içerisinde bir Master/Slave kurgusu bulunmamaktadır. Böylece bir veya daha fazla node üzerinde bir hata meydana geldiğinde dahi veriye ulaşamadığımız bir zaman aralığından veya veri kaybından korunmuş oluyoruz. “Single Point of Failure” dediğimiz tüm sistemin tek bir noktada meydana gelen bir hatadan dolayı çalışamaz hale gelmesi engellenmektedir.
Master/Slave kurgusu olmadığı için eklenen her node yine diğerleriyle aynı yetkileri ve özellikleri taşımaktadır. Bir başka deyişle yeni eklenen node’lar da mevcut node’lar gibi okuma/yazma yetkilerine sahip olmaktadır. Böylece yeni eklenen bir node hem veri depolama kapasitesini arttırmakta hem de daha yüksek okuma performansı elde edilmesini sağlamaktadır. Bu noktada, donanım izin verdiği sürece ölçeklendirme yapmak mümkün hale gelmektedir. Özellikle büyük boyutta veriler üzerinde çalışılan senaryolarda fazla sayıda node ile çözümleme yapmak mantıklı hale gelmektedir.
Veriler tablolar halinde tutulmaya devam etse dahi bu tablolar sütunlara ayrılarak tutulmaktadır. Bu algoritma/yöntem tek node üzerinde dahi Cassandra’nın okuma/yazma sürelerinin çok daha hızlı olmasını sağlamaktadır.
Cassandra’yı benzerlerinden ayıran en önemli özelliklerinden biri ise kendi sorgu (query) dili olan Cassandra Query Language (CQL)’dir. Benzer ürünlerde veriye ulaşmak için JSON formatında sorgular yazmak gerekebilirken, Cassandra’da tek satırlık sorgularla veriye ulaşmak mümkündür. Buna ek olarak, farklı NoSql veritabanlarında sorguların dönüşünde hash table tarzı veri modellemeleri kullanılırken Cassandra direkt olarak sorguda aranan veriyi dönebilmektedir.
Cassandra’nın Dezavantajları
Elbette bu kadar avantajın yanında Cassandra’nın birkaç dezavantajı da bulunmaktadır. Cassandra’nın bir NoSQL veritabanı olması bu dezavantajların çoğunun temel sebebi olarak gösterilebilir.
Elbette bu kadar avantajın yanında Cassandra^nın birkaç dezavantajı da bulunuyor. Cassandra’nın bir NoSQL database olaması bu dezavantajların çoğunun temel sebebi olarak gösterilebilir.
Cassandra, ilişkisel veri tabanlarının aksine foreign key yapısına sahip değildir. Basitçe tanımlamak gerekirse bir objenin veya verinin bir diğer tablodaki primary key’ini gösteren foreign key yapısı Cassandra’da bulunmamaktadır. Bu kararın gerekçesi olarak foreign key yapısının sebep olabileceği potansiyel performans kaybı gösterilmektedir.
Foreign key yapısının olmaması Cassandra içerisinde tutulan bir objenin ikinci bir tabloda var olsa dahi aynı obje olduğunun kanıtlanamaması anlamına gelmektedir. Yani iki farklı tablodaki objeler aynı olsa dahi bu iki objeyi eşleştirmek mümkün değildir. Bu durum bize iki önemli kayıp getirmektedir:
- İlk olarak bir CQL sorgusunda aradığımız bir objenin bir field’ı farklı bir tablo içerisinde tutuluyorsa, değere ulaşamayacağımız anlamına gelmektedir. Yani yapacağımız CQL sorguları veriye hızlı ve kolay erişimi sağlayacak olsa bile sınırlı (tasarımımız doğrultusunda) bir veriye erişim imkânı tanımaktadır. 2.
- Tablolar aynı objeleri tutsa dahi veri eşleştirmesini yapmak için gerekli foreign key’ler olmadığı için tablolar arasında join işlemi yapmak mümkün değildir.
Üst kısımda değindiğimiz dezavantajlar nedeniyle Cassandra içerisinde saklanacak bilgiler için tablolar ve veri modellemeleri sistem ayağa kaldırılmadan önce planlanmalıdır. Aksi takdirde projelerin ilerleyen safhalarında bu planlamaları değiştirmek için hatırı sayılır bir ek efor harcamak gerekecektir.
Mimari Yapı ve Çalışma Prensipleri
İlk olarak Cassandra’nın 1 numaralı özelliği olan dağıtık yapısından bahsedelim. Cassandra günümüzde birçok araçta da gördüğümüz, farklı donanımlar/cihazlar üzerinde konumlandırılmış birçok node’dan meydana gelen cluster yapısı ile çalışmaktadır. Node sayısının yüksek miktarda olduğu durumlarda ise Cluster içerisinde daha küçük ve yerel Data Center gruplandırmalarından söz etmek mümkündür.
Cluster yapısını inceleyelim:
Yukarıdaki görselde 4 adet node’dan oluşan bir Cluster yapısı yer görülmektedir. Bu yapıya “Cassandra Ring” adı da verilir. Cluster’a yazılacak her bir yeni bilgi bir adet token’a sahiptir. Token burada bir ID gibi benzeri olmayan bir etiketleme için kullanılmaktadır. Toplam token sayısı ve node sayısı kullanılarak her node üzerinde saklanacak veriler için bir “Token Range” yani aralık belirlenir. Yeni bir veri geldiğinde, Cassandra içerisindeki bir hashing algoritması ile yeni veri için benzersiz bir hash (token)(emp_id) hesaplanır ve bu hash’in içerisinde bulunduğu token range hangi node üzerinde ise yeni veri bu node üzerinde saklanır.
Peki node’lar arası iletişim nasıl kurulmaktadır? Node’lar arası iletişim, sistem üzerinde bir işlem olmasa dahi periyodik olarak gerçekleşmektedir. Belirenmiş periyotlarda cluster içerisindeki her bir node, rastgele seçilmiş belli sayıda node (3 node’a kadar) ile peer-peer mantığında iletişim kurmaktadır. İletişim esnasında node’lar kendi durumlarını (active/failure/error gibi) ve bir önceki periyotta diğer node’lardan aldığı durum bilgilerini paylaşırlar. Kısacası node’lar kendi state’leri haricinde kendilerinde diğer node’lar hakkında bulunan en güncel bilgiyi de aktarırlar. Bu sebeple node’lar arası iletişim protokolüne “Gossip protocol” yani dedikodu adı verilmektedir.
Data Replication (veri kopyalama) Cassandra’nın asıl güçlü olduğu fault tolerance alanındaki temel bir özelliktir. Cluster içerisinde veriyi paylaşan node’lar aynı zamanda yapılandırmaya göre diğer node’lar üzerindeki verilerin kopyalarını (yedeklerini) da tutarlar. Veri kopyalama işlemleri kullanıcı (genelde sistem yöneticisi) tarafından yapılandırılabilir. Bu noktada bizim için en önemli yapılandırma değişkenleri “Replication Factor” ve “Replication Strategy” değişkenleridir.
- Replication Factor: Bir verinin kaç farklı kopyasının oluşturulacağını belirler.
- Replication Strategy: Veri kopyalama stratejisini belirler.
Verilerin kaybolmaması gibi kritik konulardan bir diğeri de verilerin tutarlı bir biçimde saklanmasıdır. Örnek verecek olursak herhangi bir objenin bir field’ı içerisinde bir değişiklik yapıldığında, ilk olarak işlem yapılan node üzerinde bu değer değiştirilmiş olur. Node’lar arası iletişim ne kadar hızlı olursa olsun iki node arasında verilerin farklı olduğu bir delta süresi mevcut olacaktır. Bu süre network sıkıntıları gibi senaryolarda uzayabilir veya en olumsuz şartlar altında değerler hiçbir zaman eşlenmeyebilir. Cassandra bu problemin çözümü için Consistency Level’ları kullanır. Cassandra içerisinde bir CRUD (Create, Read, Update, Delete) işlemi isteği geldiğinde farklı node’lar bu işlem talebinin alındığına dair birbirilerine onay verirler. Consistency Level’lar bir CRUD işleminin başarılı sayılması için işlemin onaylanması gereken node sayısını belirler. Consistency Level’ı sağlayamayacak sayıda onay döndüğünde işlem gerçekleşmez.
Cassandra Kurulumları ve Cluster Yapısı Oluşturma
Şimdi birlikte örnek bir cluster yapısı oluşturalım. Bunun için RedHat Centos7 kullanan, 3 node üzerinde farklı Apache Cassandra instance’ları ayağa kaldırıp ardından bu instance’ları bir cluster içerisinde birleştireceğiz. Bunun için öncelikle yapmamız gereken birkaç işlem var:
- Makinelerin birbiri ile konuşabilmesi için firewall üzerinden 9042, 9160, 7000, 7001 ve 7199 portlarını açmamız gerekli veya direkt firewall’u kapatabilirsiniz (güvenlik sebebiyle önerilmez).
- Makinelere Cassandra’yı yüklemek için ilgili package manager’a bir repository eklememiz gerekli:
“/etc/yum.repos.d” klasörü içerisine ismi farketmeksizin “.repo” uzantılı bir dosya ekleyeceğiz. Dosya içeriği aşağıdaki :
Bu adımın ardından, tek bir komut ile Cassandra’yı sistemimize yükleyip bir servis olarak ayağa kaldırabiliriz.
Cassandra’nın aktif olup olmadığını ve ilerleyen adımlarda cluster’ımızın durumunu kontrol etmek için “nodetool” isimli aracı kullanabiliriz.
Cassandra’yı aynı adımları kullanarak cluster içerisindeki tüm node’lar üzerinde kurup ayağa kaldırmamız gerekli. Kurulum işlemleri tamamlandıktan sonra tüm node’larımız tek başlarına çalışır ve bir cluster içerisine dahil edilmeye hazır durumda olacaklar. Cluster’ımızı oluşturmak için tüm makinelerdeki Cassandra servislerini kapatmamız gerekli.
Cassandra ilk kez ayağa kalktığında üzerindeki yapılandırma ayarlarını saklamak için bir veri (data) klasörü oluşturur. Henüz cluster ayarlarını yapmadığımız için bu klasör mevcutta cluster özelinde bir yapılandırma ayarı içermemektedir. Bu nedenle node’lardaki bu veri klasörünü temizlememiz gerekmektedir.
NOT: Sadece ilk kez ayağa kalktıktan sonra değil, yapılandırma dosyalarında her değişiklik yaptığımızda bu data klasörünü temizlememiz gerekmektedir.
Şimdi kendi cluster yapılandırmamızı yapabiliriz. Varsayılanda, Cassandra’nın config dosyası “/etc/cassandra/conf” klasörü içerisinde tutulan yine “cassandra” isimli bir yaml dosyasıdır. İçerisindeki birkaç ayarı değiştirerek cluster yapımızı kurabiliriz. Bu dosya içerisinde değiştirmemiz gereken değişkenler aşağıdaki gibidir:
Yaml dosyasındaki ayarları görseldeki gibi düzenledikten sonra makineler üzerine kurduğumuz node’ları ayrı ayrı servis olarak başlattığımızda bu instancelar birbiri ile bağlanıp cluster yapısını oluşturacaklardır. Tüm node’lar ayağa kalktıktan sonra herhangi bir node üzerinde “nodetool” aracı ile durum kontrolü yaptığımızda aşağıdaki gibi tüm node’ları görebilmemiz gerekir.
Komutlara ve dosyalara aşağıdaki repo üzerinden ulaşılabilir:
Sonuç olarak Cassandra’nın nasıl bir ürün olduğundan, nasıl doğduğundan, avantajlarından ve dezavantajlarından, kendi iç yapısından bahsettik. Birlikte bir Cassandra cluster’ı oluşturduk.
Okuduğunuz için teşekkür ederim, umarım yararlı bir kaynak olmuştur. Bir sonraki yazıda görüşmek üzere.
Kaynakça
Apache Cassandra Dokümanları- https://cassandra.apache.org/doc/latest/
Guru99- https://www.guru99.com/cassandra-tutorial.html
DigitalOcean- https://www.digitalocean.com/community/tutorials/how-to-run-a-multi-node-cluster-database-with-cassandra-on-ubuntu-14-04
