Doküman Tabanlı NoSQL Veritabanları: MongoDB ve CouchDB yatay ölçeklenebilirlik karşılaştırması

Transkript

1 Doküman Tabanlı NoSQL Veritabanları: MongoDB ve CouchDB yatay ölçeklenebilirlik karşılaştırması Süleyman Eken, Fidan Kaya, Ahmet Sayar, Adnan Kavak Bilgisayar Mühendisliği Kocaeli Üniversitesi Umuttepe Kampüsü,41380, Kocaeli-Türkiye {suleyman.eken, fidan.kaya, ahmet.sayar, Öz MySQL, Oracle ve Microsoft SQL Server gibi klasik ilişkisel veritabanı yönetim sistemleri (VTYS) uzun zamandır birçok uygulamada veri depolamak ve işlemek için kullanılmaktadır. Bunlar ACID (Atomicity, Consistency, Isolation, Durability) garantisi vermesine rağmen yatay olarak ölçeklemek (çoklu sunucuya dağıtmak) çok zordur. Ayrıca internetin hızla büyümesiyle Facebook ve Twitter gibi içeriğini kullanıcıların oluşturduğu web sitelerinin büyük miktardaki verilerinin üstesinden de gelememektedirler. NoSQL (Not Only SQL) VTYS ise büyük verileri depolayabilmekte, yüksek trafiğe sahip sistemlerin ihtiyacını karşılayabilmekte ve yatay olarak ölçeklenebilmektedirler. Bu çalışmada, doküman tabanlı NoSQL veritabanlarından olan MongoDB ve CouchDB nin veri okuma ve yazma hızlarının yatay olarak ölçeklemeye karşı davranışları farklı miktardaki dokümanlar üzerinden karşılaştırılmaktadır. Anahtar Kelimeler NoSQL veritabanları, MongoDB, CouchDB, yatay ölçeklenebilirlik, dokuman tabanlı, JSON. I. GİRİŞ Verileri kalıcı olarak depolayan daha sonra gerektiğinde etkin bir biçimde geri getiren birçok VTYS mevcuttur. Bu sistemler sahip oldukları özellikler ve verileri depolamak için kullandıkları modeller sebebi ile birbirlerinden yarılabilmektedirler. Standart ilişkisel model, verileri tutmak için her satırı eşsiz olarak adreslenebilen tablolar kullanmaktadır. Bu sistemler verileri depolamak, değiştirmek ve geri döndürmek için yapısal sorgulama dilinden (SQL) yararlanmaktadır. Nesneye dayalı programlama paradigmasının yaygın olarak kullanılması ile ilişkisel veritabanlarının nesne tabanlı veritabanlarına transferi popüler hale gelmiştir. Ayrıca Web 2.0 ın gelişimi ile veritabanlarının ölçeklenebilme ihtiyacı ortaya çıkmıştır. Bu ölçekleme işlemi ise iki şekilde: (i) dikey ölçekleme denilen veritabanı içeren sunucunun donanımsal kaynaklarının artırılması ile ki bu çok maliyetlidir, (ii) yatay ölçeklenebilirlik denilen veritabanını birçok sunucuya dağıtmak yolu ile yapılabilmektedir. Yatay ölçeklenebilirliği gerçekleştirmek için ilişkisel olmayan veritabanları geliştiriliştir. Bunlar SQL i ve ilişkisel modeli kullanmayan NoSQL VTYS dir. Makalenin düzeni şu şekilde olacaktır: II. bölümde NoSQL veritabanlarının geleneksel olanlarla karşılaştırılması yapılacak ve NoSQL veritabanlarının çeşitleri üzerinde durulacaktır. III. bölümde önce ölçeklenebilirlik kavramından bahsedilecek daha sonra doküman tabanlı veritabanlarından MongoDB ve CouchDB nin yatay ölçeklemeyi nasıl gerçekleştirdiği anlatılacaktır. IV. bölümde ise tek sunucu kullanıldığında ve yatay ölçekleme yapıldığında veri okuma ve yazma hızlarının bu iki VTYS ye göre nasıl değiştiği irdelenmiştir. Son bölümde ise sonuçlar tartışılmıştır. II. NOSQL VERİTABANLARI NoSQL kavramı 2009 sonları 2010 başlarında ortaya çıkmıştır. Bu sistemler klasik veritabanlarından büyük verileri kontrol edebilme, ölçeklenebilme, veri formatları, yönetebilme, sorgulara daha hızlı cevap alabilme, eş zamanlı insert ve update işlemlerini gerçekleyebilme, açık kaynak kodlu geliştirme sağlayabilme gibi yönlerden farklılıklar arz etmektedir. Bu bölümde kısaca bu farklılıklar üzerinde durulacaktır. İlişkisel VTYS leri işlem (transaction) tabanlı çalışan sistemler olup bu işlemlerin düzgün çalışması ve veri bütünlüğü için ACID kurallarını garantilerler. NoSQL sistemleri bu kuralların tamamına uymaz. NoSQL sistemler ACID alternatifi olan BASE (Basically Available, Soft state, Eventually consistent) kurallarını garantiler. Yani dağıtık sistemin düğümlerinden birinde sorun olsa bile sistem çalışmaya devam eder. Sistemin durumu ve veri sürekli olarak değişebilir. Yeterli zaman olması durumunda dağıtık sistemin her düğümünde yer alan veri tutarlı olacaktır, her düğüm aynı veriyi görecektir. BASE in temelinde CAP Teoremi vardır. CAP teoremine göre herhangi dağıtık bir sistem aynı anda Tutarlılık (Consistency), Erişebilirlik (Availability) ve Parçalanma toleransı (Partition tolerance) kavramlarının hepsini aynı anda sağlayamaz [1]. Bunlardan mutlaka birinde problem çıkmaktadır. NoSQL sistemlerde ise bu kavramlar esnetilerek yatay ölçeklenebilirlik ile performans kazancı amaçlanmıştır. Örneğin veriyi bölerek belirli sayıdaki kopyalarını da dağıtık sistemin farklı parçalarına göndererek tutarlılık sağlanabilir. Bu sayede paket kaybı yaşansa da verinin tamamı kaybedilmez, aynı zamanda veri bölündüğü için her bir parçaya düşen yük dengelenmiş olur. İlişkisel VTYS lerinde veriler tablolarda bulunurken, NoSQL sistemler sabit tablo tanımlarına bağımlı değillerdir. İlişkisel VTYS lerde veriler ilişkilerine göre ayrı tablolara düzenli bir şekilde yerleştirilerek normalize edilirken verilere erişim için birleştirme (join) kullanılır. Birleştirilmek istenen veriler farklı parçalarda (partitions) bulunabildiğinden dağıtık sistemlerde birleştirme operasyonu sıkıntılara sebep olur. Bu birleştirme işlemi şu şekilde yapılmaktadır: örneğin a verisi bir parçadan çekilir, sonra bununla ilişkili bir başka parçada bulunan b verisi çekilip program düzeyinde birleştirme

2 yapılır. Normal sistemlerde bu işlem performans kaybına sebep olurken dağıtık sistemlerde bu kayıp sistemin genel performansı yanında önemsizdir. İşte bu sebeple dağıtık sistemlerde birleştirme operasyonu yapmak yerine veri denormalize tutularak verilere erişim kolaylaştırılır. NoSQL sistemler bu sebeple sabit tablo tanımı içermeyip verilerin denormalize tutulmasını kolaylaştırır. İlişkisel VTYS lerde verilerin tekil birer anahtar (primary key) ile birbirlerinden ayrılması zorunlu değildir. Ancak NoSQL sistemler temel olarak verilere tekil anahtarlar üzerinden erişir. Her NoSQL sisteminde ikincil indeks (secondary index) yeteneği de bulunmayabilir. Bu yüzden verilere erişim SQL sorguları ile yapıldığı gibi kolay yapılamaz. Uygulamanın özelliğine göre birincil anahtarlar belirli bir mantığa göre verilir ve bu sayede veriye erişmeden önce zaten bu anahtar biliniyor ya da oluşturulabiliyor olur. Örneğin zamana göre artan ön ek (prefix), kaydın anahtarı ile birleştirilerek tek seferde ilgili kaydın belirli bir zaman aralığındaki kayıtlarına erişmek mümkündür. Bu sayede herhangi bir sorguya gerek olmaksızın tamamen anahtarlar üzerinden verilere hızlıca erişim sağlanmış olur. NoSQL sistemlerin bazılarında map-reduce (büyük veri kümeleri üzerinde dağıtılmış programlamayı destekleyen bir yazılım kütüphanesi) yeteneği bulunmaktadır. Bu sayede RDBMS üzerinde SQL ile gerçekleştirilmesi çok karmaşık olan analizler map-reduce ile kolay bir şekilde gerçekleştirilebilir [2]. NoSQL veritabanlarının pek çok farklı çeşidi bulunmaktadır. Bunlardan en temel olanları: (i) sütunlar şeklinde tutulanlar, (ii) anahtar-değer şeklinde depolama yapanlar, (iii) doküman tabanlılar, (iv) graf tabanlılar. Verileri sütun şeklinde tutan sistemlerde her veri saklama bloğu bir kolona ait verileri içerir, bilinen SQL veritabanlarına çok benzemektedir; fakat onlar gibi istenilen sorgular yapılamıyor. Sütun tabanlı kayıt yapan sistemler genelde birçok farklı makine üzerine dağıtılmış oldukça büyük veriler için kullanılır. Böylelikle çok trafik gören sitelerde okuma/yazma işlemleri hızlandırılmış olur. Tablo 1, bu sistemleri özetlemektedir. Tablo 1. Verileri sütun şeklinde tutan sistemler Örnekleri Cassandra [3], HBase [4], BigTable [5], HyperTable [6] Dağıtık dosya sistemleri Sütunlar, sütun aileleri Hızlı arama, verinin dağıtık olarak depolanması iyi Çok düşük seviye API Anahtar-değer şeklinde depolama yapanlar sistemlerde ana mantık bir hash tablosu kullanarak her anahtar bir değer ile eşleştirilir. Böylece daha küçük verilere daha hızlı erişim sağlanır. Modeli gerçeklemek ve implemente etmek oldukça basittir. Tablo 2 bu sistemleri özetlemektedir. Tablo 2. Anahtar-değer şeklinde depolama yapanlar Örnekleri Riak [7], Tokyo Cabinet/Tyrant [8], Redis [9], Voldemort [10], [11] İçerik ön belleğe alma (özellikle büyük verileri idare etmek için), loglama, arşivleme, vb. Anahtar-değer çiftleri Hızlı arama, verinin dağıtık olarak depolanması iyi Veri karmaşıklığında problem çıkar Doküman tabanlı sistemler Lotus Notes tan esinlenmişler ve anahtar-değer depolamaya oldukça benzerlik göstermektedirler. Veri tutma modeli, anahtar-değer çiftlerinin toplanmasından oluşan versiyonlanmış haldeki dokümanlardır. Yarı yapılandırılmış dokümanlar JSON (JavaScript Object Notation) formatında tutulur. Sorgulama işlemini verimli bir şekilde sağlarlar. Bu kısımla ilgili detaylı bilgi bölüm 3 te verilecektir. Tablo 3 bu sistemleri özetlemektedir. Tablo 3. Doküman tabanlı sistemler Örnekleri CouchDB [12], [13], MongoDb[14], [15] Web ı (anahtar-değer benzeri ; fakat veritabanı değeri bilir) Anahtar-değer koleksiyonlarının koleksiyonu Tam olmayan verilere karşı dayanıklı Standart sorgulama sentaksının olmaması Graf tabanlı sistemler graf teorisini temel alıp düğümlerden oluşur. Düğümler arası ilişkiler saklanır. Graf algoritmaları kolaylıkla kullanılabilir. Tablo 4 bu sistemleri özetlemektedir. Tablo 4. Graf tabanlı sistemler Örnekleri Neo4J [16], InfoGrid [17], Infinite Graph [18] Forum veya bloglar yoluyla sosyal hesaplama, öneri içeren sistemler Düğümler Graf algoritmalarının kullanılabilmesi Bir sorgu için cevap araştırılırken tüm grafın taranması ve cluster yapısına uygun olmaması Sonuç olarak yukarıda da anlatıldığı gibi birçok NoSQL VTYS mevcuttur. Uygulamanın içeriğine, yapılması istenen işlere, hız, işlevsellik ve ölçeklemeye göre daha uygun olan VTYS seçilmelidir. Daha önceki çalışmamızda [19] Fatih projesi için geliştirilmekte olan yerel bulut sunucu tabanlı veri saklama ve içerik dağıtımı gerçeklemesinde verilerin senkronizasyonu için kullandığımız CouchDB yi bu makalede, yine doküman tabanlı olan MongoDB ile yatay ölçeklenebilirlik açısından karşılaştırmaktayız.

3 III. NOSQL VERİTABANLARINDA ÖLÇEKLENEBİRLİK Ölçeklenebilirlikle performans arasındaki farkı bilmek ölçeklenebilirliği daha iyi anlamamızı sağlar. Performans genel olarak bir sistemin yanıt süresi (reponse time) ve tamamlanan işlem sayısı (throughput) gibi özelliklerine refer eder. Dikey ölçekleme ise sistemdeki bir bileşene ekstra donanım ekleyerek hesaplama kapasitesinin artırılmasıdır. Bu işlem daha fazla bellek, daha hızlı CPU veya daha büyük sabit disk ekleme yolu ile yapılır. Yüksek kapasiteli bileşenler elde etmek maliyetli bir iştir. Aslında ölçekleme diye kastedilen şey genelde yatay ölçeklemedir. Yatay ölçekleme denilen şey ise bir sistemin hesaplama kapasitesinin yeni bileşenler devreye sokularak artırılmasıdır. Yatay ölçeklemede her bir bileşenin birbiri ile haberleşmesi sonucunda meydana gelen network aşırı yükü, sistemin toplam hesaplama kapasitesini azaltmaktadır. Ama bu yük ölçekleme yapıldıktan sonra kazanılan performans artışı yanında göz ardı edilebilir. Ölçeklenebilirlikle beraber çoğaltma (replication) ve bölümleme (sharding) işlemleri mümkün hale gelmiştir. Bu kavramları bazı senaryolar üzerinden açıklayabiliriz: İlk senaryo şöyle olsun. Bir kimsenin kitaplarını koyduğu bir kütüphanesi olsun. Bu kimse kitaplarını yok etmek isteyen bir düşmana sahip. Düşmanından kitaplarını korumak için bu kimse farklı lokasyonlarda yeni kütüphane kurar. Her ne zaman bir kitap alsa aynı kitabın bir kopyasını diğer kütüphanelere koyar. Böylelikle düşmanı kütüphanelerden birini yağmalasa diğerlerinde de aynı kitaplar olduğu için kitaplarını korumuş olur. Yani verinin kopyasını farklı sunucularda saklama işi çoğaltmayı ifade eder. Her bir sunucuya replika denir. Şimdi farklı bir senaryo düşünelim. Yine aynı kişi birçok kitaba sahip olsun; fakat düşmanı olmasın. Ama artık tek kütüphane yeterli olmamakta yeni kütüphanelere ihtiyacı vardır. Kitaplarını yazar isimlerine göre A-H ile başlayanları bir kütüphaneye, I-P arasını bir kütüphaneye, R-Z arasını bir kütüphaneye yerleştirmiştir. Yani verileri belirli bölümleme kuralına göre sunuculara dağıtma işi bölümlemeyi ifade eder. Bir başka senaryoda şöyle olsun. Son senaryoda ise aynı kişi hem düşmana sahip olsun hem de kitaplarını tek kütüphaneye sığdıramasın. Bu kimse hem düşmandan kitaplarını korumak hem de kitaplarını kütüphaneye yerleştirmek için artık ilk iki senaryodan çok kütüphaneye ihtiyacı vardır. Yine kitaplarını yazar adlarına göre üçe ayıracak ve düşmandan korumak için her kitaptan üç kopya yapacaksa dokuz sunucuya ihtiyaç vardır (çoğaltma ve bölümleme bir arada). Bu bölümde doküman tabanlı NoSQL VTYS lerden CouchDB ve MongoDB de ölçeklenebilirliğin nasıl yapıldığı anlatılmaktadır. A. CouchDB nin Ölçeklenmesi CouchDB yalnız başına ölçekleme işini destekleyemiyor. CouchDB düğümlerinden (sunucu vs.) bir küme oluşturabilmek için üçüncü parti araçlara ihtiyaç vardır. Bu araçlar BigCouch [20], Lounge [21] ve Pillow dur [22]. Bu çalışmada BigCouch tan yararlanılmıştır. BigCouch açık kaynak kodlu, hataya dayanıklı ve Apache CouchDB API ye uyumludur. BigCouch, Massachusetts merkezli bir şirket olan Cloudant şirketi tarafından piyasaya sürülmüştür. CouchDB yüklü bir sunucu ile nasıl irtibata geçiliyorsa aynı yolla BigCouch yüklü sunucu ile haberleşilir. BigCouch, CouchDB için otomatik olarak bölümleme işini yapmaktadır. Her BigCouch düğümü kümenin parçası olan düğümlerin bir listesini tutar. Her düğüm istekleri eşit olarak değerlendirir. Dokümanlar BigCouch tarafından sunucular (shards) arasında deterministik hash algoritması [23] kullanılarak dağıtılır. Okuma ve yazma işlemleri quorum protokolü [24] kullanılarak gerçeklenir. Bir BigCouch cluster ını kontrol etmek için dört parametre vardır. Bunlar Tablo 5 te özetlenmiştir [25]. Parametre Q N W R Tablo 5. BigCouch cluster parametreleri Tanımı Dokümanın kaç shard a bölüneceğini gösterir. Default olarak sekize setlenmiştir. Her shard ın kaç kez kopyalanacağını gösterir. Default olarak üçe setlenmiştir. Yazma (write) quorum sabiti. W, N ye eşit veya küçük olmalı. Default olarak ikiye setlenmiştir. Okuma (read) quorum sabiti. R, N ye eşit veya küçük olmalı. Default olarak ikiye setlenmiştir. B. MongoDB nin Ölçeklenmesi MongoDB ölçeklenebilir, doküman tabanlı, C++ ile geliştirilmiş açık kaynak kodlu NoSQL bir veritabanıdır. Özellikle hız gerektiren ve klasik VTYS nin çok yavaş kaldığı yerlerde kullanılmaktadır. Kullanım alanları arasında; yüksek hacim/içerikli problemler, analiz için veri saklanması, caching sistemleri, web içerik yönetim sistemleri, web yorum/etiket saklama ve yönetme yer almaktadır. 10gen şirketi (yeni adı ile MongoDB, Inc.), Google Uygulama Motoru na benzer bir servis oluşturduğu sırada, MongoDB geliştirmesi de 2007 yılında başlamıştı. Ocak 2014 itibari ile de en son versiyonu u yayınlamışlardır. Bir MongoDB temel olarak üç tip prosesten oluşmaktadır: (i) verileri depolamak için gerekli olan shard lar, (ii) doğru Configservers Data shards Mongos Clients Şekil 1. Bir cluster ın üç bileşeni veriye ulaşmak için yönlendirme yapan mongos birimi ve (iii) cluster ın durumunu takip etmek için config server lar (Şekil 1 e bakınız).

4 İstemciden gelen isteğin tipine göre mongos lar isteği ilgili shard lara gönderir ve onlardan gelen cevapları birleştirerek tekrar istemciye döner. MongoDB kümesinde dokümanlar kullanıcının belirlediği bölümleme anahtarına (shard key) göre bölümlenmektedir. Bu anahtar indeks yapısına benzemekte ve birden fazla veri alanı içerebilmektedir. Her shard bu bölümleme anahtarına göre dokümanları tutmaktadır. Shard içindeki dokümanlar yığınlar (chunks) şeklinde organize edilmektedir. Config sunucularda her yığının başlangıç ve bitiş anahtarı ve hangi shard ta tutulduğu bilgisi vardır. Bu bilgiler mongos lar tarafından istek olduğunda hangi shard a gidileceğini bulmak için kullanılır. MongoDB de iyi bir bölümleme anahtarı seçilmesi gerekmektedir. Üç türlü seçme yaklaşımı vardır: a- düşük eleman sayılı anahtar (low-cardinality shard key), b- artan sırada anahtar (ascending shard key) ve c- rasgele anahtar (random shard key). Kötü seçilen bölümleme anahtarı yoğun bir yüke veya uygulamanın beklenmeyen bir zamanda çalışmamasına neden olmaktadır. Bunu bir senaryo üzerinden şu şekilde anlatabiliriz. Kullanıcıların bilgilerini tutan bir uygulamamız var. Her doküman kullanıcının hangi kıtada bulunduğunu gösteren bir alana sahip olsun. Şekil 2 deki gibi bölümleme işlemi kullanıcıların bulundukları kıtalara göre yapılabilir. Bir kıtada veri arttığı zaman tek shard yeterli olmayacak ve yeni bir shard eklenmesi gerecek; ama tek anahtar olduğundan yeni shard a veri taşımak mümkün olmayacak. Bunun yerine tek anahtar yerine birden fazla anahtar kullanmak gerekiyor (ülke, kıta). Şekil 2. Kıta başına bir shard [26] RAM den veri okumak diskten veri okumaktan daha hızlıdır. Bundan dolayı veriye mümkün olduğunca RAM den erişmek isteriz. Aynı mantıkla sık kullanılan veriyi tutan zaman damgası (timestamp) gibi bir shard anahtarı tasarlanabilir. Örneğin Twitter benzeri bir servisin gönderilen bir mesajı, kimin gönderdiği, ne zaman gönderildiği gibi bilgileri içeren dokümanları tuttuğunu varsayalım. Bu belgeleri ne zaman gönderildi bilgisine göre (artan sıra shard anahtarı olarak) dağıttığımızı düşünelim. Bu zaman bilgisi sonsuza doğru gittikçe problem oluşturmaktadır. Bir diğer anahtar seçme yöntemi ise rastgele olandır. Bu ise sorgulama hızını düşürmektedir. Bütün anahtar seçimlerinin bir yerde tıkandığı görülmektedir. En iyi anahtar seçimi hibrit olanlardır (artan sıra shard anahtarı ve arama anahtarı). Örneğin kullanıcıların veriye erişim analitiğini tutan bir uygulama düşünelim. Burada yukarıda bahsedilen anahtarlara göre bölümleme yaptığımızda sıkıntılar meydana gelmektedir. Bunu önlemek için kullanıcıların veriye erişimlerini (ay, kullanıcı) anahtarına göre küme oluşturmak daha uygundur. Bu anahtar yapısı görüldüğü gibi ikilidir. İkinci kısmı (search key) sorgulama yapıldığı zaman yararlı olacak şekilde kullanıcı id, dosya adı gibi alanlar seçilmelidir. Uygun anahtar seçiminden sonra veri dağıtıma hazırdır. IV. COUCHDB-MONGODB ÖLÇEKLEME KARŞILAŞTIRMASI Henricsson lisans tezinde Phthon kütüphaneleri yardımıyla MongoDB ve CouchDB nin ekleme (insert) ve bazı sorgulamalara göre hangisinin daha hızlı olduğunu araştırmıştır. Ayrıca farklı boyutlardaki dokümanların tek bir sunucu kullanıldığında bu VYTS lerde ne kadar disk alanı kullandığını incelemiştir. Yaptıkları araştırma sonucunda CouchDB nin MongoDB den daha yavaş olduğu ve daha fazla disk alanı işgal ettiğini saptamışlardır [27]. Bu makalede ise veriler sunuculara dağıtıldığında MongoDB ve CouchDB nin farklı doküman boyutlarına göre okuma ve yazma hızları test edilmiştir. Test işlemi için gerekli olan dokümanların ne olduğundan önce bu iki veritabanının kullandığı veri modeli yapılarını bilmekte fayda vardır. CouchDB de dokümanlar JSON objeleri olarak tutulurlar. JSON [28]; JavaScript tarafından desteklenen sayı, katar, Boole değeri, dizi ve obje gibi veri türlerini desteklemektedir. Her doküman kendisine özgü tekil bir tanımlayıcıya ve revizyon numarasına sahiptir. Doküman revize edildikçe bu numara güncellenmektedir. Örnek bir okul verilerinin JSON formatında tutulması Şekil 3 te gösterilmiştir. { isim : İzmit Lisesi, şehir : Kocaeli, ilçe : İzmit, lokasyon (lat, long) : , , başarıları : [ { ÖSYM : Türkiye 2., yıl : 2012 }, { ÖSYM : Türkiye 3., yıl : 2013 }, ] } Şekil 3. Örnek bir JSON verisi MongoDB ise dokümanları ikili olarak kodlanmış BSON (Binary JSON) [29] objeleri olarak tutmaktadır. Kullanıcı veritabanına veri girişini JSON formatında yapar ve herhangi bir sorgusuna da JSON formatında cevap alır. Diğer bir deyişle kullanıcı hiçbir zaman BSON formatı ile ilgilenmez, ilgili dönüşümler veritabanının kendi içinde halledilir. Javascript sitilinde yazılmış bir dokümanın BSON karşılığı Tablo 6 da verilmiştir. Tablo 6. Javascript ve BSON gösterimi Javascript BSON gösterimi gösterimi { hello : World } \x16\x00\x00\x00\x02hello\x00 \x06\x00\x00\x00world\x00\x00 MongoDB ve CouchDB nin okuma ve yazma performansını test etmek için kişi bilgilerini temsil eden adedi 5-500,000 arasında değişen dokümanlar oluşturulmuştur. Bir

5 kişi Tablo 7 de verilen bilgilere sahiptir. Oluşturulan dokümanların örneği Şekil 4 te verilmiştir. Tablo 7. Test verisindeki anahtar-değerler Anahtar Değer Değerler aralığı İsim Katar 5-15 karakter Maaş Tam sayı Yaş Tam sayı Telefon numarası Katar 10 karakter Evcil hayvan Önceden tanımlanmış katarlar Kedi, köpek, kuş, hamster, balık Şekil 6 Ölçekleme yapılmadan CouchDB-MongoDB okuma performansları karşılaştırılması Şekil 4. Örnek veri seti Karşılaştırma yapılırken kullanılan yazılım ve donanımların özellikleri aşağıdaki gibidir: Centos GNU/Linux 6.4, kernel Apache CouchDB v1.0.4 MongoDB, Inc. MongoDB v2.4.9 Cloudant BigCouch 3 sunucu: Intel Celeron 1,8 GHz, 2 MB önbellek, 2 çekirdekli; 4 GB DDR3; 320 GB SATA (5400 Rpm) HDD Ölçekleme yapmadan (tek sunucu kullanıldığında) CouchDB ve MongoDB yazma (Şekil 5) ve okuma (Şekil 6) hızları farklı boyuttaki dokümanlar üzerinde karşılaştırılmıştır. BigCouch ile ölçekleme yapabilmek için bazı parametrelerin ayarlanması gerekmektedir. BigCouch sunuculara kurulabilmesi içinse bazı ön yüklemelerin (Erlang, OpenSSL, libcurl vb.) yapılmış olması gerekmektedir [30]. Bu yüklemelerden sonra kümedeki her bir düğüme BigCouch yüklenir ve birbirlerinden haberdar edilir. Bu ayarlamalardan sonra düğümlerin port ve admin portları Tablo 8 de verildiği gibi olmaktadır. Tablo 8. Cluster daki düğümlerin port ve admin port numaraları Düğüm Port Admin port Quorum protokolündeki parametrelerden Q (kaç shard) üçe, N (kaç kopya) bire, R (okuma) bire ve W (yazma) bire setlenmiştir. MongoDB de shard işlemi için bölümleme anahtarı olarak kişilere ait yaş değeri ele alınmıştır. Kümede toplamda üç düğüm olduğundan shard lar Şekil 5 te gösterildiği ayarlanmıştır. [18-52) [52, 76) [76-91) Şekil 7. MongoDB shard dizaynı Ölçeklemeden sonra (üç sunucu kullanıldığında) CouchDB ve MongoDB yazma (Şekil 8) ve okuma (Şekil 9) hızları farklı boyuttaki dokümanlar üzerinde karşılaştırılmıştır Şekil 5. Ölçekleme yapılmadan CouchDB-MongoDB yazma performansları karşılaştırılması

6 DrowsyDromedary REST arayüzüne sahiptir. Bunların birbirlerine karşı üstünlükleri araştırılabilir. Şekil 8. Yatay ölçeklemeden sonra CouchDB-MongoDB yazma performansları karşılaştırılması Şekil 9. Yatay ölçeklemeden sonra CouchDB-MongoDB yazma performansları karşılaştırılması V. SONUÇLAR Verilen şartlar altında tek sunucu üzerinde farklı boyuttaki dokümanları yazma/okuma hızı açısından MongoDB, CouchDB den daha hızlıdır. Aynı şekilde yatay olarak ölçekleme yapıldığında da MongoDB daha iyi sonuç vermektedir. Her iki durumda da dokümanların boyutlarının doğrusal bir şekilde artması ile okuma/yazma süreleri de artmaktadır. Yatay ölçekleme yapıldığındaki okuma/yazma performansı ise tek sunucu üzerindeki performanstan yaklaşık iki kat daha iyidir. MongoDB nin daha hızlı olmasının sebebi, veriyi önce RAM de gruplamakta sonra disk e topluca yazmaktadır (lazy writes). CouchDB ise her dokümanı tek tek diske yazmaktadır. CouchDB de dokümanlar her değişiklikte ayrıca versiyonlandığı için hataya dayanıklı ve güçlü için tercih edilebilir. MongoDB için bölümleme anahtarını hibrit oluşturarak ve CouchDB nin quorum parametrelerini daha verimli çalışmasını sağlayacak şekilde seçerek yeni karşılaştırmalar yapılabilir. CouchDB, HTTP REST üzerinden POST, GET, PUT ve DELETE metotlarını dört temel CRUD (create, read, update, delete) için kullanırlar. MongoDB ise Ruby tabanlı TEŞEKKÜR Bu çalışma, TÜBİTAK tarafından 1003 Fatih Projesi Çağrısı kapsamında EEEAG 113E033 nolu proje ile desteklenmektedir. Desteğinden dolayı TÜBİTAK a teşekkür ederiz. KAYNAKLAR [1] N. Lynch, S. Gilbert, Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services, ACM SIGACT News, vol. 33, no. 2, pp , [2] L. Yishan, S. Manoharan, A performance comparison of SQL and NoSQL databases, In: IEEE Pacific Rim Conference on Communications, Computers and Signal Processing (PACRIM), Aug. 2013, Victoria, BC, pp [3] A. Lakshman, M. Avinash, Cassandra: A Decentralized Structured Storage System, ACM SIGOPS Operating Systems Review, vol. 44, no. 2, pp , [4] Erişim Tarihi: 20 Şubat [5] F. Chang; J. Dean, S. Ghemawat, W.C. Hsieh, D.A. Wallach, M. Burrows, T. Chandra, A. Fikes, R.E. Gruber, Bigtable: A Distributed Storage System for Structured Data, ACM Transactions on Computer Systems (TOCS), vol. 26, no. 2, [6] [Erişim Tarihi: 20 Şubat 2014]. [7] [Erişim Tarihi: 20 Şubat 2014]. [8] [Erişim Tarihi: 20 Şubat 2014]. [9] J.L. Carlson, Redis in Action. Manning Publication, 1st edition, NY:U.S.A, [10] R. Sumbaly, J. Kreps, L. Gao, A. Feinberg, C. Soman, S. Shah, Serving Large-scale Batch Computed Data with Project Voldemort, Proceedings of the 10th USENIX conference on File and Storage Technologies, pp , [11] [Erişim Tarihi: 20 Şubat 2014]. [12] J. Lennon, Beginning CouchDB. Apress Publisher, 1st edition, NY:U.S.A., 2009, [13] S. Unge, Implementing a eventual consistency job distribution with CouchDB, Department of Information Technology, Uppsala University, [14] K. Chodorow, M. Dirolf, MongoDB: The Definitive Guide. O'Reilly Media Publisher; 1st edition, [15] K. Banker, MongoDB in Action. Manning Publication, 1st edition, NY: U.S.A, [16] H. Huang, Z. Dong, Research on architecture and query performance based on distributed graph database Neo4j, 3rd International Conference on Consumer Electronics, Communications and Networks (CECNet), Nov. 2013, Xianning, pp [17] [Erişim Tarihi: 22 Şubat 2014]. [18] [Erişim Tarihi: 22 Şubat 2014]. [19] S. Eken, F. Kaya, Z.İlhan, A. Sayar, A. Kavak, U. Kocasaraç, S. Şahin, Analyzing distributed file synchronization techniques for educational data, International Conference on Electronics, Computer and Computation (ICECCO), 7-9 Nov. 2013, Ankara, Turkey, pp [20] [Erişim Tarihi: 22 Şubat 2014]. [21] [Erişim Tarihi: 22 Şubat 2014]. [22] [Erişim Tarihi: 22 Şubat 2014]. [23] T. Icart. How to hash into elliptic curves, In Shai Halevi, editor, CRYPTO, vol. 5677, Lecture Notes in Computer Science, pp Springer, [24] D. Agrawal, A.J. Bernstein, A nonblocking quorum consensus protocol for replicated data, IEEE Transactions on Parallel and Distributed Systems, vol. 2, no. 2, pp , [25] B. Holt, Scaling CouchDB. O Reilly Publisher, 1st edition, 2011.

7 [26] K. Chodorow, Scaling MongoDB. O Reilly Media Publisher; 1st edition, [27] R. Henricsson, Document Oriented NoSQL Databases: A comparison of performance in MongoDB and CouchDB using a Python interface, Blekinge Institute of Technology, Bachelor thesis, computer science, [28] D. Crockford, RFC 4627-The application/json Media Type for JavaScript Object Notation (JSON) [Erişim Tarihi 5 Mart 2014]. [29] [Erişim Tarihi 5 Mart 2014]. [30] [Erişim Tarihi 7 Mart 2014].