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, akavak}@kocaeli.edu.tr
Ö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
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]
Kullanıldığı
uygulamalar
Dağıtık dosya sistemleri
Veri modeli
Sütunlar, sütun aileleri
Artıları
Hızlı arama, verinin dağıtık olarak depolanması
iyi
Eksileri
Ç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]
Kullanıldığı
uygulamalar
İçerik ön belleğe alma (özellikle büyük verileri
idare etmek için), loglama, arşivleme, vb.
Veri modeli
Anahtar-değer çiftleri
Artıları
Hızlı arama, verinin dağıtık olarak depolanması
iyi
Eksileri
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]
Kullanıldığı
uygulamalar
Web uygulamaları (anahtar-değer benzeri
uygulamalar; fakat veritabanı değeri bilir)
Veri modeli
Anahtar-değer koleksiyonlarının koleksiyonu
Artıları
Tam olmayan verilere karşı dayanıklı
Eksileri
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]
Kullanıldığı
uygulamalar
Forum veya bloglar yoluyla sosyal hesaplama,
öneri içeren sistemler
Veri modeli
Düğümler
Artıları
Graf algoritmalarının kullanılabilmesi
Eksileri
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.
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].
Tablo 5. BigCouch cluster parametreleri
Parametre
Q
N
W
R
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
2.4.9’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
Data
shards
Configservers
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).
İ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).
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)”: “40.7669, 29.9169”,
“başarıları”: [
{“ÖSYM”: “Türkiye 2.”, “yıl”: “2012”},
{“ÖSYM”: “Türkiye 3.”, “yıl”: “2013”},
]
Ş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
}
Ş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
gösterimi
{“hello”:”World”}
BSON gösterimi
“\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
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
Maaş
Yaş
Telefon numarası
Evcil hayvan
Katar
Tam sayı
Tam sayı
Katar
Önceden
tanımlanmış katarlar
5-15 karakter
9000-400000
18-90
10 karakter
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
donanımların özellikleri aşağıdaki gibidir:
yazılım
ve
Centos GNU/Linux 6.4, kernel 2.6.32-358
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
1
2
3
Port
15984
25984
35984
Admin port
15986
25986
35986
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ı
DrowsyDromedary REST arayüzüne sahiptir.
birbirlerine karşı üstünlükleri araştırılabilir.
Bunların
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
Ş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ü
uygulamalar 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ı
[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. 51-59 , 2002.
[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), 27-29
Aug. 2013, Victoria, BC, pp. 15-19.
[3] A. Lakshman, M. Avinash, “Cassandra: A Decentralized Structured
Storage System”, ACM SIGOPS Operating Systems Review, vol. 44, no.
2, pp. 35-40, 2010.
[4] http://wiki.apache.org/hadoop/Hbase, Erişim Tarihi: 20 Şubat 2014.
[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, 2008.
[6] http://hypertable.org/, [Erişim Tarihi: 20 Şubat 2014].
[7] http://docs.basho.com/riak/latest/, [Erişim Tarihi: 20 Şubat 2014].
[8] http://fallabs.com/tokyocabinet/, [Erişim Tarihi: 20 Şubat 2014].
[9] J.L. Carlson, Redis in Action. Manning Publication, 1st edition,
NY:U.S.A, 2013.
[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. 18-18, 2012.
[11] http://www.project-voldemort.com/voldemort/, [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, 2011.
[14] K. Chodorow, M. Dirolf, MongoDB: The Definitive Guide. O'Reilly
Media Publisher; 1st edition, 2010.
[15] K. Banker, MongoDB in Action. Manning Publication, 1st edition, NY:
U.S.A, 2011.
[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), 20-22 Nov. 2013, Xianning, pp. 533 – 536.
[17] http://infogrid.org/trac/, [Erişim Tarihi: 22 Şubat 2014].
[18] http://www.objectivity.com/infinitegraph#.Uxxq6vl_tCY,
[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. 318-321.
[20] http://bigcouch.cloudant.com/, [Erişim Tarihi: 22 Şubat 2014].
[21] http://tilgovi.github.io/couchdb-lounge/, [Erişim Tarihi: 22 Şubat 2014].
[22] https://github.com/khellan/Pillow, [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. 303-316.
Springer, 2009.
[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. 171 – 179, 1991.
[25] B. Holt, Scaling CouchDB. O’Reilly Publisher, 1st edition, 2011.
[26] K. Chodorow, Scaling MongoDB. O’Reilly Media Publisher; 1st
edition, 2011.
[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,
2011.
[28] D. Crockford, RFC 4627-The application/json Media Type for
JavaScript Object Notation (JSON). http://tools.ietf.org/html/rfc4627,
2006. [Erişim Tarihi 5 Mart 2014].
[29] http://docs.mongodb.org/meta-driver/latest/legacy/bson/, [Erişim Tarihi
5 Mart 2014].
[30] http://bigcouch.cloudant.com/develop, [Erişim Tarihi 7 Mart 2014].
© Copyright 2024 Paperzz
