Yazan: İsmet Bahadır – Ersin Aksoy 26 Mart 2012
Binlerce insanın internet üzerinden eriştiği web platformlarının temeldeki en büyük sıkıntısı, bu platformların kullandığı kaynakların (yazılım, donanım v.b.) yetersiz kalabilmesidir. Platforma erişen kullanıcı sayısı arttıkça, sistem kaynaklarını arttırmak gerekir. Bu işlem genelde veri tabanı için yeni sunucu sistemlerinin takviyesiyle veya mevcut sunucu sistemlerinin hafıza (RAM) alanlarının genişletilmesiyle gerçekleşir. Platformlara erişen kullanıcı sayısı genellikle gün geçtikçe arttığından, sistem kaynak kapasitesinin de arttırılması gerekmektedir (kaçınılmazdır). Alt yapı giderlerinin web girişimcileri açısından önemli bir rol oynadığını düşünürsek, her kaynak kapasite artırımı girişimci üzerine ek bir maliyet bindirecektir
Facebook ve Google gibi yüksek trafiğe sahip web platformlarının en büyük sıkıntısı, veri tabanları ile web sunucusu üzerinde çalışan programlar arasındaki veri trafiğinin zamanla dar boğaza dönüşmesi ve yetersiz kalmasıdır. Sisteme yeni veri tabanı sunucuları ekleyerek bu sorun çözülebilir ve veriler, kopyalama (replication) mekanizmalarıyla, sisteme ait tüm veri tabanı sunucularında eş zamanlı olarak tutulabilir. Ancak bu, sistemin bakımını ve geliştirilmesini zorlaştırabilecek bir gelişme olarak değerlendirilebilir. Ayrıca yeni sistemlerin maliyeti de girişimci üzerinde ekstra bir yük oluşturmaktadır.
Bu dokümanda caching (ön belleğe alma) mekanizmaları kullanılarak, dar boğaza dönen veri tabanlarının kapasite takviyesine gerek kalmadan nasıl yönetilebileceğini yakından inceleyeceğiz.
-
Caching Nedir?
Ön belleğe alma olarak Türkçeleştirebileceğimiz caching mekanizmalarıyla kullanılmak istenen veri, verinin kaynağına (disk v.b.) ulaşılmak zorunda kalmamak için, bilgisayar hafızasında (RAM) tutulur. RAM’e erişim süresi, verinin bulunduğu kaynağa erişim süresinden daha kısa olduğu için, veriye erişim ve verinin işlenme süresi kısaltılmış olur. Ayrıca verinin kaynağına erişim, veri transferi açısından bir dar boğaz olabileceği için, caching mekanizmaları ile bu dar boğazlılık sorunu da giderilir.
-
Neden Caching Mekanizmaları?
Ana işletim birimi (CPU) gerekli verileri elde ettikten sonra bu verileri kendi bünyesinde barındırdığı ön bellek alanlarında saklar. Bu, işletim biriminin çalışma hızını artırır. Diskler, caching mekanizmalarını kullanarak, kendi üzerinde bulunan verileri tekrar edinmek zorunda kalmadan kullanıcı sisteme aktarabilirler. Bu da performansı artırır. Veriler veri tabanından okunduktan sonra caching mekanizmaları kullanılarak hafızada tutulur. Bu, verileri kullanan programın performansını, sıkça veri tabanını kullanmak zorunda olmadığı için artırır.
-
Dikkat Edilmesi Gereken (Püf) Noktalar
Cache içinde tutulan veri, orijinal verinin bir kopyasıdır. Er ya da geç, veri, asıl kaynağı üzerinde (örneğin veri tabanı) değişikliğe uğrayacaktır. Bu durumda, cache içinde bulunan kopyanın durumu nedir?
Orijinali değişmediği sürece bir kopya veri orijinaliyle aynı değeri taşır. Ancak, orijinal veri değişikliğe uğradığı zaman, kopya veri için çanlar çalmaya başlar. Orijinal veri değişikliğe uğrarsa, cache içinde bulunan kopyanın da değişikliğe uğraması gerekir. Aksi takdirde; cache içinde bulunan veriyi kullanan program verinin en son haline sahip olmadığı için yanlış işlem yapabilir hale gelecektir. Bu durumda, şöyle bir sonuç çıkartılabilir:
Cache’te tutulan verinin belli bir zamandan sonra kendisini imha etmesi ve verinin asıl kaynağından tekrar edinmesi sağlanmalıdır.
Cache’te yedeklenen bir veri için bir “geçerlilik süresi” tespit edilmelidir. Aksi takdirde veri sonsuza dek (bilgisayar kapanana dek) cache içinde kalacak ve verinin tekrar asıl kaynağından kopyalanmasına mani olacaktır. Örnek olarak hastalık tanı kodlarını (ICD–10) içeren bir nesne cache’e kopyalanmadan önce, 24 saat geçerli olacak şekilde bir yapılandırma kullanılabilir. Böylece, her 24 saat bitiminde hastalık tanı kodları veri tabanından tekrar elde edilerek, cache’e kopyalanır. Sıkça değişikliğe uğrayan veriler için kısa süreler, değişikliğe sık uğramayan veriler için uzun süreler tercih edilmelidir. Bu durumda, şöyle bir sonuç çıkartılabilir:
Caching mekanizmasının sağlığı ve kullanıcının güncel verileri kullanabilmesi açısından, cache’te tutulan verilerin bir geçerlilik süresine (expiration time) sahip olmaları gerekmektedir. Bu süre, nesneyi cache’e kopyalayan program tarafından belirlenir ve bir zaman birimiyle (saniye, dakika, gün v.b.) ifade edilir.
Bir veriyi, caching sistemine kopyalamak ve geçerlilik süresini belirlemek yeterli olmayacaktır çünkü kopyalanan veriye tekrar erişmek gerekir. Bunun için bu veriyi “adresleyebilmek” gerekmektedir ve bir anahtar (key) kullanılarak bu adresleme yapılabilir. Ancak, kullanılan anahtarın tüm sistem içerisinde “eşsiz” (unique) olması gerekmektedir. Yalnızca bu sayede istenilen veriye ulaşılabilir ve aynı anahtara sahip iki verinin birbirlerini yok etmeleri engellenir. Bu durumda, şöyle bir sonuç çıkartılabilir:
Caching mekanizmasına kopyalanan verilere yeniden erişebilmek için eşsiz anahtarlar (unique key) kullanılarak adresleme yapılmalıdır. Bu sayede verilerin birbirini ezmesi engellenmiş olunur.
-
Caching Türleri
Caching mekanizmaları Lokal Caching Sistemleri ve Global Caching Sistemleri olmak üzere ikiye ayrılmaktadır:
-
Lokal Caching Sistemleri: Kullanıcı program ile caching sisteminin aynı hafıza alanında (in memory) faaliyette bulunduğu caching sistemidir. Caching sisteminin kullanıcı programa yakınlığından ötürü lokal caching sistemi olarak isimlendirilmiştir.
-
Global Caching Sistemleri: Birden fazla sunucu üzerine dağıtık olarak (distributed) kurulmuş ancak aynı hafıza alanındaymış gibi çalışan caching sistemidir. Bu sistemler kendi içinde iki gruba ayrılır:
-
Global Tek Hafıza Caching Sistemleri: Bu sistemlerde her uygulama sunucusu kendi hafıza alanında bir lokal caching sistemine sahiptir. Birden fazla uygulama sunucusu ve lokal caching sisteminin kullanılması bir global cache sistemi oluşturulduğu anlamına gelmez. Global bir caching sisteminin oluşabilmesi için, ağ içindeki lokal caching sistemlerinin birbirlerinden haberdar olmaları gerekmektedir. Kullanılan caching sistemleri ağ üzerinden birbirleriyle bağlantı kurarak, bünyelerinde meydana gelen değişiklikleri ağ içindeki diğer lokal cachelere bildirirler. Bu işlem için JGroups ya da JMS gibi iletişim (communication) teknolojileri kullanılır. EhCache bu tür faaliyet gösteren bir caching sistemidir.
-
Global Bölümsel (Partial) Hafıza Caching Sistemleri: Bu tür global caching sistemlerinde caching bileşenleri arasında veri kopyalaması (replikasyon) yapılmaz. Global caching sistemini kullanmak isteyen her uygulama, sistemdeki tüm caching sunucuları ile bağlantı kurarak, caching işlemlerini gerçekleştirir. Kullanılan özel bir caching API yardımıyla ile veriler değişik caching sunucularına dağıtılır. Bu yüzden bu tür faaliyet gösteren caching sistemlerine global bölümsel caching sistemleri adı verilmektedir. MemCached bu tür faaliyet gösteren bir caching sistemidir. [1]
Memcached
Memcached, Danga Interactive tarafından LiveJournal için geliştirilen ancak şu an başka birçok site tarafından da kullanılan, açık kaynak kodlu, yüksek performanslı, dağıtık bellekleme sistemidir (distributed memory caching system). Genellikle, verileri ve nesneleri RAM’e saklayıp bir dış veri kaynağının (mesela veri tabanı ve API) okunması gereken toplam sayıyı düşürerek, veri tabanı güdümlü web sitelerini hızlandırmak amaçlı kullanılır. Yani, yüksek trafik alan dinamik web uygulamalarının veri tabanına gitme sayısını azaltmayı, bu sayede de, performansı artırmayı hedefleyen bir uygulamadır.
Memecached Unix, Linux, Windows ve MacOSX üzerinde çalışabilmekte ve serbest yazılım lisansı altında dağıtılmaktadır (BSD).
Memcached’in API’ı birçok makinada dağıtık halde bulunan dev bir komut çizelgesi sağlar. Tablo dolduğu zaman, yeni eklenen kayıtlar eski kayıtları En Son Kullanılan (Least Recently Used – LRU) metoduna göre düşürür. [4]
API’lar
Memcached, diğer programlama dilleriyle beraber çalışmak için bazı API’lar sağlamaktadır. Bu programlama dilleri; C, C++, Java, PHP, Python, Ruby, Perl, Windows .Net, MySQL, PostgreSQL, Erlang, Lua, List Dialects, Cold Fusion, OCaml, Io ve CLI’dır. [5]
Veri Modelleri ve Mimari
Sistem bir sunucu-istemci mimarisi kullanmaktadır. Sunucular bir anahtar-değer ilişkisel dizisi (associative array) tutar; istemciler de bu diziyi doldurur ve sorgularlar. Anahtarlar en fazla 250 byte, değerler de en fazla 1 mega byte boyutunda olabilir.
Sunucular değerleri RAM’de tutarlar; eğer sunucu RAM’i dolarsa, sunucu en eski verileri atar. Dolayısıyla istemciler Memcached’i geçici bir ön bellek olarak düşünmek zorundadır; bir kez saklanan verinin ne zaman lazım olursa olsun sunucuda bulunacağını düşünmemelidir.
Kopyalama (Replication)
Memcached kopyalamayı desteklememektedir çünkü veriyi kopyalamak, sahip olunan alanın yarıya inmesi demektir. Veri kopyalanmaz ise kopyalanana göre 2 kat daha fazla alana sahip olunur. Bu durumda, yani 2 kat fazla alanda, daha fazla veri saklanabilir. Bunun dezavantajlı durumu düşünülürse, örneğin 10 sunucu varsa ve 1’i çökerse yüzde 10’luk bir kayıp oranı oluşur. Eğer kayıpsız bir ortam isteniyorsa, Membase veya diğer noSQL veri tabanları kullanılabilir.
Veri Kalıcılığı (Persistence)
Memcached veri kalıcılığını desteklememektedir ve yakın gelecekte de bu yönde bir çalışma planlanmamaktadır. Eğer kayıpsız ve kalıcı bir veri ortamı düşünülüyorsa, caching mekanizmaları değil veri tabanları kullanılmalıdır. Yine de, MemcachedDB olarak isimlendirilen ve Memcached ile uyumlu olan ürün ile veri kalıcılığı (persistence) sağlanabilir. [4]
Güvenlik
Memcached kimlik doğrulamayı desteklememektedir.. Network üzerinden erişimi olan bütün istemciler “atama” (set) ve “alma” (get) işlemlerini yapabilirler. Üzerinde memcached çalışan sunucuların güvenlik duvarı ayarlarının dikkatli yapılması gerekir. [6] Memcached, SASL (Simple Authentication and Security Layer) protokolünün kurulmasını desteklemektedir ve bu sayede güvensiz bir ortamda güvenlik sağlanabilir. [7]
Redis
Redis, açık kaynak kodlu olarak geliştirilmiş, kullanıcı program ile aynı hafıza alanında (in memory) faaliyette bulunan bir anahtar-değer (key-value) veri deposudur. ANSI C koduyla geliştirilen Redis, VMware tarafından desteklenmektedir.
API’lar
Redis, diğer programlama dilleriyle beraber çalışmak için bazı API’lar sağlamaktadır. Bu programlama dilleri; ActionScript, C, C++, C#, Clojure, Common Lisp, Erlang, Go, Haskell, haXe, Io, Java, server-side JavaScript (Node.js), Lua, Objective-C, Perl, PHP, Pure Data, Python, Ruby, Scala, Smalltalk ve Tcl’dir.
Veri Modelleri
Redis’in diğer NoSQL bilgi bankalarından en önemli farklarından birisi, yalnızca String’ler ile sınırlı olmamasıdır. String’lere ek olarak Redis, aşağıdaki veri tiplerini de desteklemektedir:
-
Setler (Sets)
-
Sıralı Setler (Sorted Sets)
-
Komut Çizelgeleri (Hash Tables)
-
Atomik İşlemler (Atomic Transactions)
Redis tek birim olarak maksimum 512 MB veriyi saklayabilmektedir.
Kopyalama (Replication)
Redis, yalnızca master-slave kopyalamasını desteklemektedir. Herhangi bir master Redis sunucusu, kendinde bulunan veri güncellendiği anda master sunucuya bağlı olan N kadar slave sunucuda da güncelleme yapar. Bir slave, diğer slave’ler için master durumunda olabilir. Böylece bir çizge (graph) yapısı oluşturulabilmektedir. Ancak, kopyalama yaparken gerekli RAM alanı yüzünden replikasyonla ilgili bazı tartışmalar vardır.
Redis aynı zamanda yayınla/abone ol (publish / subscribe) özelliğini de tam olarak desteklemektedir. Bu sayede bir slave’in istemcisi bir kanala abone olup, master’a yayınlanan tüm mesajları alabilir.
Veri Kalıcılığı (Persistence)
Bilgisayar bilimlerinde “veri kalıcılığı”; verinin, oluşturulduğu işlemden sonra da tutulması özelliğidir. Böyle bir özellik olmasaydı, veri sadece RAM’de bulunabilirdi ve bilgisayarın kapanması gibi RAM’in güç kaybına uğradığı durumlarda kaybolurdu.
Redis normalde tüm veri setlerini RAM’de tutmaktadır. Kalıcılığı sağlamak için ise 2 yöntem kullanılmaktadır. “Snapshotting” adı verilen birinci yöntemde, belirli zamanlarla snapshot’lar alınır ve bunlar diskte saklanır. Diğer yöntemde ise RAM’de tutulan veri setleri diskte de tutulur. İstenirse bu iki yöntem de devre dışı bırakılabilir. Bir başka seçenek de master yerine slave üzerinden kalıcılığı sağlayarak master üzerindeki yükü hafifletmektir. [2]
Güvenlik
Redis, güvenli istemcilerin güvenli ortamlarda Redis’e erişimi üzerinde tasarlanmıştır. Bu, Redis durumunun (instance) internete direkt olarak açılmasının veya bir başka deyişle güvenilmeyen istemcilerin direkt olarak Redis TCP portuna veya UNIX soketine erişmesinin iyi bir fikir olmayacağı anlamına gelmektedir.
Redis, erişim kontrolü (Access Control) protokolünü implemente etmezken, küçük bir kimlik doğrulama katmanı sağlamaktadır. Kimlik doğrulama katmanı aktif hale getirildiğinde Redis, kimlik doğrulamasından geçemeyen hiçbir istemciyi kabul etmez. İstemci “AUTH” komutunun arkasından sunduğu şifre ile kimlik doğrulama yapar. Şifre, sistem yöneticisi tarafından belirlenir ve “Redis.conf” dosyasında açık metin olarak tutulur. Şifrenin kaba kuvvet (brute force) saldırılarına karşı dayanabilecek kadar uzun ve karmaşık olması gerekmektedir. Bu koruma yöntemi, güvenlik duvarı gibi önlemler çökecek olursa, istemcilerin direkt olarak erişmesine mani olmak için kullanılır. Yani, birinci dereceden bir güvenlik önlemi değildir.
Redis, veri şifrelemesini desteklememektedir. Bu yüzden, sadece güvenli istemcilerin veya güvenilen tarafların Redis’e erişimini sağlamak için, SSL gibi ek güvenlik katmanları implemente edilmelidir.
Redis’te bazı spesifik komutlar devre dışı bırakılabilir veya bu komutların isimleri tahmin edilemeyecek şekilde değiştirilebilir.
Genel olarak denilebilir ki Redis, maksimum güvenlik için değil, maksimum performans ve basitlik üzerine tasarlanmıştır. [3]
Hazelcast
Hazelcast, Java ile geliştirilmiş olan açık kaynak kodlu kümeleme (clustering) ve veri dağıtımı (data distribution) çözümüdür. Hazelcast, verilerin küme içerisinde kolay bir şekilde paylaştırılmasına olanak sunar.
Hazelcast mimarisi P2P’dir, yani master-slave mimarisi yoktur. Dolayısıyla, tek kaynaklı çökme (single point of failure) yaşanmaz. Çok yöne yayını (multicast) veya TCP/IP protokolünü kullanarak dinamik keşfi (dynamic discovery) destekler. Keşiften sonra, düğüm iletişimleri JAVA NIO kullanılarak sadece TCP/IP ile sağlanır. [8]
Büyük sistemler geliştirilirken basitlik önemlidir. Uygulamalar dağıtıldığında ise basitlik çok daha fazla önem arz eder. Hazelcast de basittir! Hazelcast’i çalıştıran JVM’ler (Java Virtual Machine) dinamik olarak kümelenir.
Hazelcast, eğer
-
Veri birçok sunucu üzerinde dağıtılacaksa (örneğin web oturumu paylaşımı)
-
Veri ön belleğe alınacaksa (dağıtık ön bellek)
-
Uygulama kümelenecekse
-
Sunucular arasında güvenli iletişim sağlanacaksa
-
RAM’deki veri bölünecekse (partitioning)
-
İş yükü birçok sunucuya dağıtılacaksa
-
Paralel işlemenin avantajından faydalanılacaksa ve
-
Veri kaybı olmaksızın veri yönetimi uygulanacaksa
doğru seçim olacaktır.
API’lar
Hazelcast, diğer programlama dilleriyle beraber çalışmak için bazı API’lar sağlamaktadır. Bu programlama dilleri; Native C# (enterprise edition), Native Java Client, Memcache ve REST’tir.
Veri Modelleri
Hazelcast sadece String’ler ile sınırlı olmamakla beraber aşağıdaki veri yapılarını desteklemektedir:
-
Setler (Sets)
-
Sıralar (Queue)
-
Harita (Map)
Hazelcast için tutabileceği nesne boyutu sınırlaması yoktur; ancak, unutulmamalıdır ki boyu artıkça gecikme (latency) de artacaktır.
Kopyalama (Replication)
Hazelcast verileri her bir küme üyesine dağıtır. Bir küme üyesi çöktüğü zaman veri kaybı yaşamamk adına Hazelcast belli miktarda yedekleme yapılmasına izin verir. Bu sayede bir küme üyesi üzerinde bulunan veri bir başka üyeye kopyalanmış olur. Kopyalama işlemi asenkron olarak yapılmaktadır ve kaç adet kopyalama yapılacağı yönetici tarafından belirlenebilir. Varsayılan kopyala sayısı 1’dir. Eğer sayı 1’den fazla ise her bir küme üyesi hem kendi hem de bir başka üyenin verisini saklar.
Hazelcast aynı zamanda yayınla/abone ol (publish / subscribe) özelliğini de tam olarak ve küme çapında desteklemektedir. Bir üye bir konu için abone olduğunda, aslında kümedeki herhangi bir üyenin yayınladığı mesaja abone olmaktadır. Bunun içinde daha sonradan eklenen üyeler de vardır.
Veri Kalıcılığı (Persistence)
Hazelcast direkt olarak kalıcılık sağlamamaktadır. Ancak, bu işi uygulama tarafında sağlayan kodla uyumlu çalışarak, uygulama tarafında kalıcılığı sağlayabilmektedir.
Güvenlik
Hazelcast varsayılan olarak bir güvenlik paketi sunmamakla beraber Enterprise sürümünde JAAS ve SSL desteklerini sunmaktadır. JAAS sayesinde hem küme hem de istemciler kimlik doğrulamasından geçerler. Güvenlik ayarları, configuration XML’inden veya Config API’ından yapılabilmektedir.
Hazelcast ile tüm üyeler arasındaki soket seviyesi iletişim şifrelenebilir. Şifreleme Java Cryptography Architecture’a dayanmakta ve hem simetrik hem de asimetrik şifreleme desteklenmektedir. Simetrik şifrelemede her düğüm aynı anahtarı kullanmakta, yani anahtar paylaşılmaktadır. Asimetrik şifrelemede ise bir açık ve gizli anahtar çifti kullanılır. Veri bu anahtarlardan biriyle şifrelenir ve diğeriyle açılır. Bu metoda göre her düğümün bir gizli anahtarının ve diğer güveli üyelerin açık anahtarlarının olmasıdır.
Hazelcast’teki istemci yetkilendirmesi, istemci izin verme politikasıyla ayarlanmaktadır. Varsayılan olarak uygulanmış olan bir izin politikası Hazelcast güvenlik yapılandırma dosyasında yer almaktadır. [9]
Ehcache
Ehcache performansı arttırmak, veri tabanı yükünü azaltmak ve ölçeklenebilirliği basitleştirmek için kullanılan açık kaynak kodlu bir caching mekanizmasıdır. Ehcache ilk olarak Greg Luck tarafından 2003 yılında yazılmış ve 2009 yılında ücretli destek sağlayan Terracotta firması tarafından satın alınmıştır. Yazılım hala açık kaynak kodludur. 2011 yılında Wikimedia Foundation wiki projelerinde performansı arttırmak için Ehcache’i kullanacağını açıklamıştır. [10]
Ehcache güçlüdür ve kendini piyasada ispatlamıştır. Dağıtık ön bellekleme yapısını desteklemesi ve RAM’in yetersiz olduğu durumlarda diski kullanması (SWAP) gibi özellikleri sayesinde en çok kullanılan Java-tabanlı caching mekanizmalarından birisi olmayı başarmıştır. [11] Ehcache bir veya daha fazla düğümlü in-process’ten, karmaşık yapıdaki in-process/out-of-process yapılandırmaya kadar terabaytlar boyutunda ölçeklenebilir.
API’lar
Ehcache şu API’ları sağlamaktadır:
-
CacheSearch
-
Bulk Loading
-
Transactions (JTA)
-
Explicit Locking
-
CacheWriter
-
Unlocked Reads View
Veri Modelleri
Ehcache tüm standart veri tiplerini desteklemektedir. Bunlar arasında;
-
Setler (Sets)
-
Sıralar (Queue)
-
Harita (Map) v.b.
vardır.
Ehcache her boyuttan nesneyi tutabilmekte ancak boyut arttıkça performans da azalacaktır.
Kopyalama (Replication)
Yerleşik (built-in) dağıtık caching’e ek olarak Ehcache’in bir eklenebilir cache kopyalama düzeni vardır ve bu sayede cache kopyalama mekanizmalarının eklenmesini sağlar.
Şu ek kopyalanmış caching mekanizmaları vardır:
- RMI
- JGroups
- JMS
- Cache Server
Veri Kalıcılığı (Persistence)
Ehcache’te 3 tür depo vardır:
- MemoryStore
- OffHeapStore (BigMemory, Ehcache Enterprise)
- DiskStore (açık kaynak ve Ehcache Enterprise)
MemryStore her durumda vardır. Direkt olarak manipüle edilmez fakat her cache’in bir bileşenidir.
BigMemory, Terracotta firması tarafından sunulan ve cachelerin nesne yığını dışında ek bir hafıza tipi kullanmasına izin veren, tamamen Java ile yazılmış bir üründür. Ehcache Enterprise içerine paketlenmiştir.
Java GC’ye maruz kalmayan OffHeapStore, DiskStore’dan 100 kat daha hızlıdır ve çok büyük cache’lerin oluşturulmasına imkan sağlar (350 gb ve fazlası).
DiskStore disk biriktirme olanağı sağlar. DiskStore’ları opsiyoneldir.
Güvenlik
Terracotta’nın kurumsal versiyonu, Terracotta sunucularına girişleri kontrol etmek için, standart kimlik doğrulama metotları sunar.Bu metotlardan birini aktive ederek bir Terracotta sunucusunun, JMX öndermeden önce giriş bilgilerini istemesini sağlar.
Bir istemci tarafından doğru kimlik bilgileri sağlandıktan sonra, JMX mesajları şifrelenmediğinden ötürü, sunucu kimlik doğrulaması güvenli mesaj iletimini sağlamaz. Giriş bilgilerinin ötesinde bir güvenlik sağlamak için şu seçenekler düşünülebilir:
-
Terracotta sunucular gizli bir ağdaki güvenli bir yere konabilir
-
SSH veya tüneller gibi şifrelenmiş protokoller ile gelen istemler sınırlanabilir.
-
Eğer açık veya dış ağlar kullanılıyor ise kümedeki tüm iletişim VPN ile sağlanabilir [10]
Couchbase
Couchbase Server basit, hızlı, elastik ve açık kaynak kodlu bir NoSQL veri tabanıdır. Couchbase veriyi sunucular veya sanal makineler arasında otomatik olarak dağıtır. Yerleşik olarak kontrol edilen nesne ön belleklemesi sayesinde uygulamalar milisaniyelerin de altındaki bir gecikme ile veri okuyup yazabilmektedir. Yönetilecek bir şema olmadan, Couchbase herhangi bir çabaya gerek kalmadan değişen veri gereksinimlerini yönetir. Gelişmiş gözlem ve yönetici GUI’si sayesinde gerçek ortama kolaylıkla yüklenebilir ve yönetilebilir. [12]
Couchbase verileri ve veri işlem G/Ç’sini (I/O) sunucular veya sanal makinelerde dağıtabilir, yüksek-erişebilirlik için kopyalayabilir, veriyi transparan olarak ön belleğe alır ve çok katmanlı depolama modeli için kullanılan bir tasarımla veriyi kalıcı hale getirir. Veri işlemlerinin düşük gecikmeli ve yüksek verimli bir işlemcisidir.
Couchbase Server ile bir tuşa basarak kümenize yeni sunucular ekleyebilir veya çıkartabilirsiniz. Bu sayede kaynaklarınızın, uygulamanızın isteklerine ayak uydurmasını sağlar. Yeni sunucular ekleyerek sağlanan ek RAM ve I/O kapasitesi ile uygulamanızı yatay olarak ölçekleyebilirsiniz
API’lar
Couchbase’in diğer programlama dilleriyle beraber çalışmak için sağladığı API’ler Java, .NET, PHP, Ruby, C ve REST’tir
Veri Modelleri
Couchbase, memcached uyumlu olduğunda dolayı Memcached’in desteklediği veri tiplerini desteklemektedir. Sistemin sahip olduğu sunucu-istemci mimarisi dolayısıyla sunucular bir anahtar-değer ilişkisel dizisi tutar ve istemciler de bu diziye elemanlar doldurup bu elemanları sorgularlar.
Kopyalama (Replication)
Couchbase Server 3 kopya (veri setinin 4 kopyası) yapılandırılmasına izin vermektedir. Bir çökme olması durumunda, manüel veya otomatik olarak, sadece kopyalanan kadar düğüm kurtarabilir. Örneğin;
-
5 düğümlü ve 1 kopyalı bir kümede eğer 1 düğüm çökerse, o düğüm kurtarılabilir. Eğer ikinci bir düğüm çökerse, veriyi kurtaracak sayıda kopyaya sahip olunmadığından ötürü daha yavaş bir kurtarma sürecine girilir.
-
5 düğümlü ve 2 kopyalı bir kümede 1 düğüm çökerse, o düğüm kurtarılabilir. Eğer ikinci bir düğüm daha çökerse, o da kurtarılabilir. Ancak 3. düğümün çökmesi durumunda kurtarabilecek kopya olmadığından 3. düğüm kurtarılamaz.
Couchbase üzerinden kopyalama ile ilgili şu ayarlar yapılabilir:
-
Çoklu-model (multi-model) kopyalama desteği: Master-slave kopyalamasını destekleyen altyapı mimarisiyle birlikte P2P desteği
-
Yapılandırılabilir kopyalama sayısı: Kullanılabilirlik gereksinimleriyle kaynak kullanımını dengelemek
-
Yüksek hızlı kurtarma: isteğe bağlı olarak kopyalanmış verilerin hızlıca kurtarılması
Veri Kalıcılığı (Persistence)
Genel olarak konuşmak gerekirse, Couchbase Server bellek odaklıdır; yani, etkileşimi yüksek olan web uygulamalarında olduğu gibi bellekte çalışmakta olan uygulamaların etrafında olacak şekilde tasarlanmıştır. Ancak, bellekte bulunan veri seti herhangi bir zamanda “sıcak veridir”. Veri, Couchbase Server tarafından diske sistemde bulunan kurallar çerçevesinde asenkron olara yazılarak kalıcılığı sağlanır.
Couchbase kalıcılığı sağlanan veriyi “sqlite3” veri tabanında saklar. 1.7 ve sonraki versiyonlarında, veri birden fazla sunucuya senkron olarak dağıtılabilirken, diske yazmalar asenkron olarak devam etmektedir.
Güvenlik
Bir Couchbase uygulamasında uygun portlara hem “izin verilen” hem de “sınırlı” erişimin olmasına mutlaka dikkat edilmelidir. Düğümler çeşitli portlar üzerinden birbirleriyle iletişimde olabilmeli ve iç ve/veya dış erişimlerin sadece izin verilen tekiller tarafından gerçekleştirilmesine özen gösterilmelidir. Her şey güvenlik duvarıyla korunmalıdır ve sadece geçmesine izin verilen şeyler geçiş yapabilmelidir. Eğer uygulama yalnızca 1 sunucu üzerinde çalışıyorsa (yani Couchbase ve uygulama aynı makinedeyse), uygulama sunucuya bağlanabilir. Bu sayede güvenlik duvarı aşılsa bile herhangi bir sıkıntı teşkil etmeyecektir çünkü ön bellek ile bağlantı kurmak için o makinede olmak gerekir. [13]
Cache Ürünleri Karşılaştırma Tablosu
Redis |
Memcached |
Hazelcast |
Ehcache |
Couchbase |
|
İşletim Sistemi |
Windows (cygwin), Linux, Mac |
Cross Platform |
Cross Platform |
Cross Platform |
Linux, Windows Server (2008), MacOS |
Yazıldığı Dil |
C |
C |
Java |
Java |
C++, Erlang |
Java tarafından kullanılabilirliği |
Jedis |
spymemcached |
Hazelcast Native Java Client |
Ehcache Core 2.5.0 API |
Java Client Library (spymemcached) |
Varsa dunya çapında tanınan müşterileri |
flickr, blizzard, digg, youporn, sahibinden |
facebook, youtube, zynga, orange, twitter, wikipedia, digg |
crashplan, mozilla, atlassian, turkcell, avea, ericsson, sahibinden |
wikimedia, Party Gaming, Adobe, Electronic Arts, BBC, JP Morgan, John Wiley & Sons, Inc. |
Zynga, NHN, AOL Advertising, Adobe, BMW, AOL, Cisco, Honda, LG, Vodafone, Orange |
Dağıtıklılık |
Hayır |
Evet |
Evet |
Evet |
Evet |
Transaction Support |
Var |
Yok |
Var |
Var (v2.0 ve üstünde) |
Yok |
Yonetebildiği Obje Sayı |
RAM kadar |
over TBs |
~500milyon |
No limit |
no built in limit |
Yonetebildigi objenin birtanesinin maksimum buyuklugu |
512 MB |
1 MB |
Sınır yok. Sadece Latency artacak |
No limit |
Default: 20mb |
Lisanslama |
Açık Kaynak – BSD |
Açık Kaynak – BSD |
Açık Kaynak – Apache |
Açık Kaynak – Apache |
Açık Kaynak – Apache |
multi threading |
Yok |
Var |
Var |
Var |
Var |
Security |
Authentication var, Data encryption yok. Maks güvenlik değil maks performans hedefli |
Authentication yok, Data encryption yok. SASL uyumlu |
Full SSL ve JAAS desteği, soket seviyesi şifreleme desteği |
Authentication |
Cache Ürünleri Karşılaştırma Tablosu (Devam)
Cache lenmiş Objenin SQL benzeri dille sorgulanabilirliği |
Yok |
Yok |
Var |
Var |
Yok |
Lock (kilitleme) mekanizması |
Var (optimistik) |
Yok |
Var. Key ve map bazinda locking mevcut. |
Var |
Advisory Locking |
Replikasyon |
Var (only master-slave) |
Yok |
her map (node) icin ayri ayri backup count belirlenebilir. |
Var |
Var |
Destekledigi veri tipleri |
Lists |
Bytes (Lists) |
Queue |
Tüm standart veri tipleri |
Memcached ile aynı |
Dokuman bulunabilirliği |
IRC, FAQ, Mailing Lists, Manual, Forum |
IRC, FAQ, Mailing Lists, Manual, Forum |
FAQ, Mailing Lists, Manual, Forum |
FAQ, Mailing Lists, Manual, Forum |
IRC, FAQ, Mailing Lists, Manual, Forum |
Konsol Desteği |
CLI ile terminal üzerinden |
Yok |
Management Center |
ehcache-monitor |
Couchbase Web Console |
primitive tipler üzerinde işlem yapabilirliği ( artırma, eksiltme, concat, atama vs ) |
Var |
Var |
Var |
Var |
Var |
Diske veri yedekleme (persistence) |
Var |
Yok |
Yok |
Var |
Var |
CRUD Operations |
Var |
Var |
Var |
Var |
Var |
Desteklenen client dilleri |
ActionScript, C, C++, C#, Clojure, Common Lisp, Erlang, Haskell, Java, server-side JavaScript, Objective-C, PHP, Python, Ruby, Scala, Smalltalk, Tcl … |
C, C++, Java, PHP, Python, Ruby, Perl, Windows .Net, MySQL, PostgreSQL, Erlang, Lua, List Dialects, Cold Fusion, OCaml, Io , CLI |
Native Java Client, Native C#, Memcache, REST |
C, C++, Java, PHP, Python, Ruby, SOAP, REST, Scala |
Java, .NET, PHP, Ruby, C, REST, |
Kaynakça
[2] http://en.wikipedia.org/wiki/Redis
[3] http://redis.io/
[4] http://en.wikipedia.org/wiki/Memcache
[5] http://code.google.com/p/memcached/wiki/Clients
[6] http://ilkinbalkanay.blogspot.com/2008/02/memcached-datml-distributed-nbellek.html
[7] http://code.google.com/p/memcached/wiki/SASLHowto
[8] http://en.wikipedia.org/wiki/Hazelcast
[10] http://ehcache.org/
[11] http://www.hasanozgan.com/2010/08/bir-web-catisi-framework-anatomisi/
[12] http://en.wikipedia.org/wiki/Couchbase
[13] http://www.couchbase.com/couchbase-server/overview