NoSQL veritabanlarında kullanılan veri sıkıştırma yöntemlerinin

International Conference on Computer Science and Engineering
Tekirdağ, Turkey, 20-23 October 2016
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ÜRK1, Altan MESUT1, Banu DİRİ2
Bilgisayar Mühendisliği Bölümü, Trakya Üniversitesi, Edirne, Türkiye
1
{emirozturk, altanmesut}@trakya.edu.tr
Bilgisayar Mühendisliği Bölümü, Yıldız Teknik Üniversitesi, İstanbul, Türkiye
2
[email protected]
Ö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
UBMK 2016 Proceedings
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,
228
International Conference on Computer Science and Engineering
ö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.
UBMK 2016 Proceedings
Tekirdağ, Turkey, 20-23 October 2016
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.
KARŞILAŞTIRMA İÇİN KULLANILAN NOSQL
VERİTABANLARI
A. Cassandra
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
229
International Conference on Computer Science and Engineering
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.
UBMK 2016 Proceedings
Tekirdağ, Turkey, 20-23 October 2016
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.
230
International Conference on Computer Science and Engineering
IV.
Tekirdağ, Turkey, 20-23 October 2016
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
(Birleştirilmiş)
de.txt
en.txt
es.txt
fr.txt
it.txt
nl.txt
pl.txt
tr.txt
Boyut (Byte)
5.030.246.082
11.838.929.073
2.818.814.073
3.318.542.670
2.367.208.876
1.447.569.624
1.376.809.649
378.471.567
V.
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
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
LevelDB
Cassandra
Zlib
3,2
2,8
1,9
2,4
3,1
2,7
2,3
3,1
NoComp
8,0
8,0
8,0
8,0
8,0
8,1
8,1
8,2
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ı
UBMK 2016 Proceedings
Süreler
MongoDB
LevelDb
CassandraDb
(sn) NoComp Snappy Zlib NoComp Snappy NoComp Snappy LZ4
179,8
170,3 266,5
15,8
379,0 615,6 713,1
de
14,8
437,2
388,8 448,5
35,9
971,2 997,1 944,9
en
34,3
91,6
77,0 84,9
8,8
177,9 211,0 209,3
es
8,3
127,3
110,2 145,6
10,4
262,7 281,1 290,4
fr
9,9
68,8
69,0 149,8
7,3
146,5 189,2 184,6
it
7,1
39,9
35,8 52,3
4,5
84,2
86,7 97,8
nl
4,3
43,4
39,2 42,0
4,2
79,2
89,6 91,5
pl
3,9
13,3
11,8 9,7
1,2
34,7
30,2 28,8
tr
1,0
Tablo 4. NoSQL veritabanlarına veri yazma hızı sonuçları
Tablo 2. Wikipedia makalelerinin dil ve boyutları
MongoDB
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.
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]
[2]
[3]
Laney, D., "3D Data Management: Controlling Data Volume,
Velocity and Variety", Gartner, 2001.
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.
http://www.villanovau.com/resources/bi/what-is-big-data/ "What is
Big Data?", Villanova University.
231
International Conference on Computer Science and Engineering
Tekirdağ, Turkey, 20-23 October 2016
[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