NoSQL veritabanlarında kullanılan veri sıkıştırma yöntemlerinin performans analizi The performance analysis of data compression algorithms used in NoSQL databases Emir ÖZTÜRK 1, Altan MESUT 1, Banu DİRİ 2 1 Bilgisayar Mühendisliği Bölümü, Trakya Üniversitesi, Edirne, Türkiye {emirozturk, altanmesut@trakya.edu.tr 2 Bilgisayar Mühendisliği Bölümü, Yıldız Teknik Üniversitesi, İstanbul, Türkiye banu@ce.yildiz.edu.tr Özetçe Genellikle büyük boyutlu verileri saklamak için kullanılan NoSQL veritabanlarından bazıları verileri sıkıştırarak saklayabilmektedir. Bu sayede ihtiyaç duyulan saklama düğümlerinin sayısı azaltılabilmekte ve daha yüksek performans elde edilebilmektedir. Bu çalışmada MongoDB, Cassandra ve LevelDB veritabanları üzerinde kullanılan Snappy, LZ4 ve Zlib sıkıştırma algoritmaları sıkıştırma oranı ve sıkıştırma hızı bakımından karşılaştırılmıştır. Bu algoritmaların kullanılmasıyla veritabanına yazma hızlarının değişimi de incelenmiştir. En iyi sıkıştırma oranı MongoDb veritabanında kullanılan Zlib algoritması ile elde edilmiştir. En hızlı sıkıştırma sonuçlarını Snappy kullanıldığında LevelDB vermiştir. Anahtar Kelimeler Büyük veri; Veri Sıkıştırma; NoSQL Veritabanları. Abstract Some of the NoSQL databases which are generally used to store big data are able to store data by using a compression algorithm. Using data compression improves the performance by reducing the number of required storage nodes. In this paper, Snappy, LZ4 and Zlib which used on MongoDB, Cassandra and LevelDB is compared in terms of compression ratio and compression speed. Change of writing speed to the database with the use of these algorithms were also examined. Best compression ratios are obtained on MongoDB using Zlib algorithm. The fastest compression is seen on LevelDB with using Snappy. Keywords Big Data; Data Compression; NoSQL Databases. I. GİRİŞ Nesnelerin internetinin ve multimedya verilerinin paylaşımının yaygınlaşmasıyla yapısal veya yapısal olmayan bir veri akışı meydana gelmektedir. Literatürde teknolojinin saklama yönetme ve etkin işleme kapasitesini aşan bilgi miktarına eşdeğer olarak büyük veri terimi kullanılmaktadır. Büyük verinin temel olarak 3 özelliği sağladığı (Volume, Velocity, Variety) savunulmuş [1] ve daha sonra Value ve Veracity de dahil edilerek 5v elde edilmiştir. Volume verinin bir günde terabaytlarca üretiliyor olması, Velocity, verinin hızlı bir değişim içerisinde olması, Variety verinin yapısal veya yapısal olmayan durumda olmasıdır. Veriyi anlayarak ve yöneterek sonuç çıkarmak ile Value elde edilir [2]. Son olarak ayrık veri sistemleri ile Veracity, doğruluk ve kesinlik şartlarını sağlamalıdır [3][4]. Büyük veri videolardan, resimlerden veya sayısal sensör verilerinden oluşabildiği gibi metin verisinden de oluşabilmektedir. Büyük metin verisine örnek olarak, müşteri geri dönüş bildirimleri, yardım merkez kayıtları, sosyal medya girdileri verilebilir. Bu veri çoğunlukla yapısal olmamakta ve işlenmemiş halde elde edilmektedir. Büyük verinin saklanması dosyalar bazında yapılabilse de, veri saklama ve veriye erişim prosedürleri verimli olmayacaktır. Bunun yerine verilerin saklanması ve daha sonra erişilebilmesi için veritabanı yönetim sistemleri kullanılabilir. Veritabanı yönetim sistemlerinin kullandıkları veri modelleri aşağıdaki gibi sınıflandırılabilir. Sıradüzensel Veri Modeli Ağ Veri Modeli İlişkisel Veri Modeli Nesneye-Yönelik Veri Modeli Günümüzde ağırlıklı olarak ilişkisel veritabanı yönetim sistemleri kullanılmaktadır. Büyük veri için ise bu sistemlere alternatif olarak NoSQL veritabanları önerilmiştir. NoSQL veritabanları, açılımı Not Only SQL olan, ilişkisel olmayan, farklı tipteki verilerin hızlı organize edilmesini sağlayan dağıtık sistemlerdir. Hız, UBMK 2016 Proceedings 228
ölçeklenebilirlik ve erişilebilirlik konusunda ilişkisel veritabanlarına alternatif olarak ortaya çıkmıştır. Büyük veri kavramının yaygınlaşması ve veri miktarındaki artışın hızlanması ile NoSQL veritabanlarının kullanımı artmaktadır. NoSQL veritabanları genellikle önceden tanımlı şema içermezler ve bu sayede kayıtlar birbirinden farklı alanlara sahip olabilirler. İlişkisel veritabanı yönetim sistemleri milyonlarca aktif kullanıcının verilerinin yoğunluğa göre uygulama sunucularına bölünüp saklanması konusunda uygun değildir. NoSQL veritabanları büyük boyutlu işlemlerde, büyük veri setlerine düşük gecikme ile erişimde avantajlıdırlar. Performans sağlamak amacı ile ACID [5] prensibinin tümünü sağlamazlar fakat karşılığında milyonlarca kullanıcıya hizmet verebilirler. Buna örnek olarak Facebook ile kullanılan Cassandra örnek verilebilir [6]. NoSQL veritabanları CAP teoremindeki maddelere uyum sağlamalıdır. CAP teoremi (Brewer teoremi) dağıtık bilgisayar sistemlerinde aşağıda verilmiş 3 ana maddenin tümünün sağlanmasının mümkün olmadığını savunur [7]. Consistency (Veri Bütünlüğü) Availability (Erişilebilirlik) Partition tolerance (Bölüm Töleransı) Çoğu NoSQL veritabanı bu özelliklerin ikisini sağlamayı hedefler. NoSQL veritabanları 4 ana kategoride incelenebilir [8]. A. Anahtar-Değer Deposu (Key-Value Store) En basit NoSQL veritabanı türüdür. Bir anahtar ve anahtarın belirlediği veriden oluşur. Verinin içeriğinin herhangi bir önemi yoktur. Veri bir BLOB olarak kabul edilir ve anahtar ile ilişkilendirilerek veritabanında saklanır. İstendiğinde anahtar ile veri elde edilebilir veya silinebilir. Anahtar-değer depolarına örnek olarak LevelDB ve Oracle NoSQL Database verilebilir. B. Sütun Deposu (Column Store) Sütun bazlı veritabanları temelde her anahtarın birden fazla anahtar değer ikilisine sahip olduğu iki boyutlu dizilerdir. Her satır bir anahtara karşılık birden fazla sütun içerir ve sütunlar satır içerisinde sütun anahtarları ile sıralanırlar. Cassandra [9] ve BigTable [10] sütun depolarına örnek olarak verilebilir. C. Belge Veritabanı (Document Database) Belge Veritabanı XML, JSON gibi hiyerarşik ve tanımlı belgeleri saklar. Anahtar-değer depolarında olduğu gibi anahtara karşılık bir değer bulunur. Fakat buradaki değer bir belgedir ve anahtar-değer deposundan farklı olarak içeriği bilinebilir ve sorgulanabilir. En çok bilinen belge veritabanları MongoDB ve CouchDB [11] dir. D. Çizge Veritabanı (Graph Database) Çizge veritabanlarında varlıklar ve bu varlıkların arasındaki ilişkiler, düğümler ve bu düğümler arasındaki kenarlar biçiminde saklanır. Özellikle karmaşık hiyerarşik yapıların taranması ve bu yapılardan bilgi elde edilmesi için kullanılması uygundur. Neo4J ve OrientDB çizge veritabanlarına örnek olarak verilebilir. II. A. Cassandra KARŞILAŞTIRMA İÇİN KULLANILAN NOSQL VERİTABANLARI Apache tarafından Java ile geliştirilmiş NoSQL veritabanıdır. İlk olarak Amazon Dynamo ve Google BigTable temel alınarak Facebook tarafından geliştirilmiştir. Veriler JSON ya da XML formatında şema olmaksızın sütun bazlı saklanır. Birden fazla sunucu üzerinde dağıtık çalışabilir. Bu sayede yatay ölçeklemeye izin vermektedir. Bir küme ve kümeyi oluşturan düğümlerden oluşur. Ana düğüm (Master Node) konsepti bulunmaz. Bu sayede Master-Slave mimarisinde Master düğümde bir problem olduğunda çıkabilecek sorunların önüne geçilir. Peer-to-peer mimarisi ile tüm düğümler birbirleriyle iletişim halindedir ve iletişim için Gossip protokolü kullanılmaktadır. Verileri yerleştirmek için dağıtık hash tabloları kullanır. Cassandra nın asıl hedefi erişilebilirlik ve ölçeklenebilirliktir. Cassandra veri kopyalama desteği sunar ve kopyalama işlemleri düğümler arasında otomatik olarak gerçekleştirilir. Veritabanının oluşturulması esnasında kopya sayısının verilmesi yeterlidir. Ayrıca veri de düğümler arasında paylaştırılıp sıralı ya da varsayılan olarak rastgele dağıtılabilir. Cassandra nın yapısında ilişkisel VTYS lerdeki veritabanları yerine keyspace ler bulunur. Bu keyspace ler altında yer alan tablolar için bazen sütun aileleri (column families) terimi de kullanılmaktadır. Sütun aileleri sıralı bir şekilde satırları saklarlar. Satırlar ise sütun adları ve değerlerini istemci tarafından sağlanan bir timestamp ile saklarlar. Veri öncelikle bir commit log a yazılır ve bellekte bir Memtable içerisinde saklanır. Memtable dolduğunda veri diske SSTable (sorted strings table) veri yapısı kullanılarak yazılır. Veri okunmak istendiğinde bulunduğu düğümlerden toplanarak kullanıcıya iletilir. Eğer verinin bulunduğu düğüme ulaşılamıyorsa verinin yedeğinin bulunduğu düğümler veriyi kullanıcıya iletir. Cassandra da bir tablo oluşturmak için kullanılan ifade Şekil 1 de verilmiştir. Şekilde görüldüğü gibi sıkıştırma yöntemini belirlemek için bu tanımın sonundaki WITH compression satırında parametre olarak LZ4Compressor veya SnappyCompressor kullanılabilir. Bu satır yazılmazsa varsayılan olarak LZ4 yöntemi ile sıkıştırma UBMK 2016 Proceedings 229
yapılır. Sıkıştırmadan saklamak için ise yöntem isminin verildiği alan boş bırakılmalıdır. CREATE TABLE tr( block_id uuid, dosyaadi text, icerik text, dil text ) WITH compression = { 'sstable_compression' : 'LZ4Compressor' ; Şekil 1. Cassandra üzerinde tablo oluşturmak için gerekli ifade B. MongoDB C++ ile yazılmış belge tabanlı bir açık kaynak veritabanıdır. İlişkisel veritabanlarındaki tablolar yerine koleksiyonlar ve bu koleksiyonlar içerisinde kayıtlar yerine belgeler kullanılır. Belgeler için herhangi bir şemaya ihtiyaç duyulmaz. Her belge BSON (Binary JSON) formatında saklanır. BSON formatında bir belge içerisindeki elemanlar sırayla bir anahtar ve anahtara karşılık gelen değerden oluşur. Değerler kendi içerisinde başka belgeler veya belge dizileri olabilirler. MongoDB anahtara göre arama yapabildiği gibi herhangi bir alana göre de arama yapabilmektedir. Ayrıca indekslendiği takdirde metin alanların içerisinde regex ile arama (full text search) da yapılabilmektedir. Verinin doküman yapısında olması ve indekslenmesi sayesinde sorgulamanın hızlanması sağlanmaktadır. MongoDB ikincil indeksleri ve sharding i de destekler. MongoDB Master-Slave kopyalama (replication) kullanmaktadır. Veri asenkron bir şekilde sunucular arasında kopyalanır. Yazma işlevi bir sunucuya yüklenirken okuma işlevi ise slave sunucular ile karşılanmaktadır. Kopya kümeleri (replica set) kullanılarak sistemin erişilebilirliği arttırılabilmektedir. Kopya kümeleri kullanıldığında da bir adet master sunucu bulunmaktadır fakat bu sunucuda bir sıkıntı olduğu takdirde küme içerisinden yeni bir master seçilebilmektedir. MongoDB sıkıştırma seçeneklerini 3.0 versiyonu ile (Wiredtiger Storage Engine) sunmuştur. İndekslere ön ek sıkıştırma yapılabilirken, veri ise sıkıştırmadan saklanabildiği gibi Snappy veya Zlib kütüphanesi ile sıkıştırılarak da saklanabilir. MongoDB üzerinde koleksiyon oluşturmak için kullanılan sorgu Şekil 2 deki gibidir. db.createcollection( "tr", { storageengine: { wiredtiger: { configstring: 'block_compressor=zlib' ) Şekil 2. MongoDB üzerinde koleksiyon oluşturma ifadesi C. LevelDB Google tarafından geliştirilen anahtar-değer deposu türünde bir veritabanıdır. Anahtar ve değerler bayt dizileri şeklinde saklanır ve veriler anahtara göre sıralanarak saklanır. Veri üzerinde put, get ve delete işlemleri desteklenir. İstenildiği takdirde veriler üzerinde toplu değişiklik de yapılabilir. İleri ve geri iterasyon imkânı sağladığı için veriler üzerinde sıralı gezme gerçekleştirilebilir. LevelDB de saklanan tüm veriler varsayılan olarak Snappy yöntemi ile sıkıştırılır. Sıkıştırma istenmiyorsa veritabanı oluşturma seçeneklerinde knocompression bayrağı kullanılmalıdır. LevelDb ile bir veritabanı oluşturmak için kullanılan komut Şekil 3 te verilmiştir. leveldb::db* vt; leveldb::options ayarlar; ayarlar.compression= leveldb::knocompression; leveldb::db::open(ayarlar,"veritabanı Adı",&vt); Şekil 3. LevelDB veritabanı oluşturmak için yazılan kod bloğu III. NOSQL VERİTABANLARINDA KULLANILAN SIKIŞTIRMA YÖNTEMLERİ A. Zlib Zlib, Jean-loup Gailly ve Mark Adler tarafından geliştirilmiş Deflate tabanlı bir kütüphanedir. Snappy ye göre daha fazla kaynak tüketir ve daha fazla sıkıştırma sağlar. B. Snappy Snappy Google tarafından C++ kullanılarak geliştirilmiş açık kaynak kodlu bir sıkıştırma algoritmasıdır. Sıkıştırma oranını yüksek tutmak yerine yüksek hızda kabul edilebilir sıkıştırma oranları elde etmeyi amaçlayan sıkıştırma kütüphanesidir. Bit akışları yerine bayt akışları kullanır ve LZ77 tabanlıdır. C. LZ4 LZ4 Google tarafından hızlı sıkıştırma ve açma sağlamak amacıyla geliştirilmiş LZ77 tabanlı bayt akışı kullanan bir sıkıştırma algoritmasıdır. UBMK 2016 Proceedings 230
IV. PERFORMANS VE KARŞILAŞTIRMA SONUÇLARI Performans ve karşılaştırma sonuçlarının elde edilmesi amacıyla farklı mimarilere sahip birer adet NoSQL veritabanı farklı sıkıştırma seçenekleriyle kullanılmıştır. Bu veritabanlarına 8 farklı dilde toplanmış Wikipedia makaleleri eklenmiş, boyut ve yazma hızı bakımından sonuçlar elde edilmiştir. Kullanılan veritabanları ve bu veritabanlarının destekledikleri sıkıştırma yöntemleri Tablo 1 de, kullanılan Wikipedia makalelerinin dilleri ve boyutları ise Tablo 2 de verilmiştir. NoSQL Veritabanı Veritabanı Türü Sıkıştırma Seçenekleri Cassandra Column Based Snappy, LZ4 MongoDB Document Based Snappy, Zlib LevelDB Key-Value Snappy Tablo 1. NoSQL veritabanları ve desteklenen sıkıştırma seçenekleri Wikipedia Makaleleri Boyut (Byte) (Birleştirilmiş) de.txt 5.030.246.082 en.txt 11.838.929.073 es.txt 2.818.814.073 fr.txt 3.318.542.670 it.txt 2.367.208.876 nl.txt 1.447.569.624 pl.txt 1.376.809.649 tr.txt 378.471.567 Tablo 2. Wikipedia makalelerinin dil ve boyutları Tablo 3 te seçilen NoSQL veritabanlarının farklı sıkıştırma seçenekleri ile elde edilen sıkıştırma oranları bpc cinsinden verilmiştir. Veritabanına yazma işlemi gerçekleştirilmeden önce dosyalar belirli boyutta parçalara bölünmüş ve veritabanına ekleme işlemi bu işlemden sonra gerçekleştirilmiştir. Bunun sebebi MongoDB nin maksimum 16 MB belge boyutuna izin vermesidir. 10 MB lık yapılandırılmamış (raw) bir dosya veritabanına eklenmek istendiğinde yapı bilgileri ile birlikte 16 MB sınırına yakınlaşmaktadır. Bu sebeple parça boyutu 10 MB olarak seçilmiştir. Sıkıştırma kullanılmadığında bpc değerlerinin çoğunlukla 8 in üstünde çıkmasının sebebi de bu yapı bilgisinin veri boyutunu başlangıçta arttırmasıdır. Sıkıştırma Oranı (bpc) de en es fr it nl pl tr MongoDB NoComp 8,4 8,1 8,3 8,3 8,1 8,1 8,2 9,2 Snappy 5,0 4,8 4,9 4,9 4,9 4,2 5,1 4,9 Zlib 3,2 2,8 1,9 2,4 3,1 2,7 2,3 3,1 LevelDB NoComp 8,0 8,0 8,0 8,0 8,0 8,1 8,1 8,2 Cassandra Snappy 4,9 4,7 4,8 4,8 4,9 4,2 5,1 5,0 NoComp 9,7 12,7 8,2 11,7 7,9 7,7 8,0 8,7 Snappy 7,2 5,2 4,7 4,7 4,8 5,3 7,0 4,9 LZ4 4,9 5,8 5,2 4,8 6,6 4,1 7,4 4,9 Tablo 3. NoSQL veritabanlarının bpc cinsinden sıkıştırma oranları Tablo 4 te, NoSQL veritabanlarına farklı sıkıştırma seçenekleri ile eklenen dosyaların ne kadar sürede eklendiği sn cinsinden verilmiştir. Tablo 4 te de görüldüğü gibi LevelDB veri yazma konusunda en iyi süre değerlerini vermektedir. Bunun sebebi, LevelDB nin veride yapısal bir değişiklik yapmadan veriyi veritabanına yazmasıdır. MongoDB ve LevelDB üzerinde Snappy kullanıldığında veritabanına yazma hızı artarken Cassandra üzerinde bu değişiklik görülmemiştir. MongoDB üzerinde Zlib en iyi sıkıştırma sonuçlarını verse de birkaç dil dışında süre bakımından en yavaş algoritma olmuştur. Süreler MongoDB LevelDb CassandraDb (sn) NoComp Snappy Zlib NoComp Snappy NoComp Snappy LZ4 de 179,8 170,3 266,5 15,8 14,8 379,0 615,6 713,1 en 437,2 388,8 448,5 35,9 34,3 971,2 997,1 944,9 es 91,6 77,0 84,9 8,8 8,3 177,9 211,0 209,3 fr 127,3 110,2 145,6 10,4 9,9 262,7 281,1 290,4 it 68,8 69,0 149,8 7,3 7,1 146,5 189,2 184,6 nl 39,9 35,8 52,3 4,5 4,3 84,2 86,7 97,8 pl 43,4 39,2 42,0 4,2 3,9 79,2 89,6 91,5 tr 13,3 11,8 9,7 1,2 1,0 34,7 30,2 28,8 Tablo 4. NoSQL veritabanlarına veri yazma hızı sonuçları V. SONUÇLAR Veri boyutu ile veri yazma hızı arasında bir seçim yapmak amacıyla aynı NoSQL veritabanı üzerinde farklı sıkıştırma seçenekleri kullanılabilmektedir. NoSQL veritabanları verileri saklarken belirli yapı bilgileri de ekledikleri için sıkıştırma kullanmadıklarında veriyi genişletmektedirler. Bu genişleme en çok CassandraDB üzerinde gözlenmiştir. Sıkıştırma algoritmaları arasında en iyi sıkıştırma sonucunu veren algoritma Zlib olurken en hızlı algoritma Snappy olmuştur. Veri yazma hızı bakımından LevelDB diğer veritabanlarına göre daha iyi sonuçlar vermiştir. Sıkıştırma kullanıldığında LevelDB için yazma hızı daha da artmıştır. Bu çalışma farklı türlerde NoSQL veritabanlarının kendi bünyelerinde destekledikleri veri sıkıştırma yöntemlerinin sağladıkları kazanımları, farklı sıkıştırma yöntemlerinin avantaj ve dezavantajlarını da ortaya koyarak sekiz farklı dil üzerinde kıyaslaması ile akademik literatüre katkı sağlayacaktır. KAYNAKÇA [1] Laney, D., "3D Data Management: Controlling Data Volume, Velocity and Variety", Gartner, 2001. [2] De Mauro, A., Greco, M., Grimaldi, M., "A Formal definition of Big Data based on its essential Features", Library Review 65: 122 135. doi:10.1108/lr-06-2015-0061, 2016. [3] http://www.villanovau.com/resources/bi/what-is-big-data/ "What is Big Data?", Villanova University. UBMK 2016 Proceedings 231
[4] Grimes, S., "Big Data: Avoid 'Wanna V' Confusion", InformationWeek, 2016. [5] Haerder, T., Reuter, A., "Principles of transaction-oriented database recovery", ACM Computing Surveys 15 (4): 287, doi:10.1145/289.291, 1983. [6] Nance, C., Losse, T., Iype, R., Harmon, G., NoSQL vs Rdbms - Why There is Room For Both, Proceedings of the Southern Association for Information Systems Conference, Savannah, GA, USA, 8-9 Mart 2013. [7] Gilbert S., Lynch N., Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services, ACM SIGACT News, Volume 33 Issue 2, pg. 51-59, 2002. [8] Moniruzzaman, A.B.M., Hossain, S.A., NoSQL Database: New Era of Databases for Big data Analytics - Classification, Characteristics and Comparison, International Journal of Database Theory and Application Vol. 6, No. 4, 2013. [9] Lakshman, A., Malik, P., Cassandra: a decentralized structured storage system, ACM SIGOPS Operating Systems Review, 44(2), 35-40, 2010. [10] Chang, F., Dean, J., Ghemawat, S., Hsieh, W.C., Wallach, D.A., Burrows, M., Chandra, T., Fikes, A., Gruber, R.E., "Bigtable: A Distributed Storage System for Structured Data", OSDI'06: Seventh Symposium on Operating System Design and Implementation, Seattle, WA, 2006. [11] Leben, M., "CouchDB-relaxed web application development?, 2013. UBMK 2016 Proceedings 232