SQL veritabanlarından Nosql veritabanlarına veri göçü aracı geliştirme

T.C.

DÜZCE

ÜNİVERSİTESİ

FEN BİLİMLERİ ENSTİTÜSÜ

SQL VERİTABANLARINDAN NOSQL VERİTABANLARINA

VERİ GÖÇÜ ARACI GELİŞTİRME

OKTAY YILDIRIM

YÜKSEK LİSANS TEZİ

ELEKTRİK ELEKRONİK VE BİLGİSAYAR MÜHENDİSLİĞİ

ANABİLİM DALI

DANIŞMAN

PROF. DR. RESUL KARA

T.C.

DÜZCE ÜNİVERSİTESİ

FEN BİLİMLERİ ENSTİTÜSÜ

SQL VERİTABANLARINDAN NOSQL VERİTABANLARINA

VERİ GÖÇÜ ARACI GELİŞTİRME

Oktay Yıldırım tarafından hazırlanan tez çalışması aşağıdaki jüri tarafından Düzce Üniversitesi Fen Bilimleri Enstitüsü Elektrik Elektronik ve Bilgisayar Mühendisliği Anabilim Dalı’nda YÜKSEK LİSANS TEZİ olarak kabul edilmiştir.

Tez Danışmanı

Prof. Dr. Resul KARA Düzce Üniversitesi

Jüri Üyeleri

Prof. Dr. Resul KARA

Düzce Üniversitesi _____________________ Dr. Öğr. Üyesi Şafak KAYIKÇI

Abant İzzet Baysal Üniversitesi _____________________

Dr. Öğr. Üyesi A. Talha KABAKUŞ

Düzce Üniversitesi _____________________

BEYAN

Bu tez çalışmasının kendi çalışmam olduğunu, tezin planlanmasından yazımına kadar bütün aşamalarda etik dışı davranışımın olmadığını, bu tezdeki bütün bilgileri akademik ve etik kurallar içinde elde ettiğimi, bu tez çalışmasıyla elde edilmeyen bütün bilgi ve yorumlara kaynak gösterdiğimi ve bu kaynakları da kaynaklar listesine aldığımı, yine bu tezin çalışılması ve yazımı sırasında patent ve telif haklarını ihlal edici bir davranışımın olmadığını beyan ederim.

28 Ağustos 2019

TEŞEKKÜR

Yüksek Lisans öğrenimimde ve bu tezin hazırlanmasında gösterdiği her türlü destek ve yardımdan dolayı çok değerli hocam Prof. Dr. Resul KARA’ya en içten dileklerimle teşekkür ederim.

Bu çalışma boyunca yardımlarını ve desteklerini esirgemeyen sevgili aileme ve çalışma arkadaşlarıma sonsuz teşekkürlerimi sunarım.

İÇİNDEKİLER

Sayfa No

ŞEKİL LİSTESİ ... vii

ÇİZELGE LİSTESİ ... viii

ÖZET ... ix

ABSTRACT ... x

1.

GİRİŞ ... 1

2.

VERİTABANI SİSTEMLERİ ... 10

2.2.4. Nosql Veritabanı Çeşitleri ... 17

2.2.4.1. Anahtar – Değer Depolama Yapan Nosql Veritabanı (Key – Value Store) ...17

2.2.4.2. Doküman Tabanlı Depolama Yapan Veritabanı (Document Store) ...19

2.2.4.3. Sütun Tabanlı (Wide Column Store) Depolama Yapan Veritabanları ...19

2.2.4.4. Grafik Tabanlı Depolama (Graph Store) Yapan Veritabanları ...20

3.

VERİ GÖÇÜ ARACI GELİŞTİRME ... 22

3.1. DENORMALİZASYONİŞLEMİ ... 22

3.2. KULLANILANYAZILIMLAR ... 23

3.2.1. Python ... 23

3.2.2. Microsoft Sql Server Veritabanı ... 24

3.2.3. Oracle Veritabanı ... 24

3.2.4. MongoDb Veritabanı ... 24

3.3. CSVUZANTILIDOSYALAR ... 25

3.4. VERİGÖÇÜARACIGELİŞTİRMEADIMLARI ... 26

3.4.1. 1. İhtimal ... 27

3.4.2. 2. İhtimal ... 28

3.4.3. 3. İhtimal ... 29

3.4.4. Özyineleme (Recursion) Kullanımı ... 30

3.5. VERİGÖÇÜARACISINIRLILIKLARI ... 30

4.1. MONGODB’YECSVTÜRÜNDEKİDOSYALARINMONGODB

COMPASSİLEEKLENMESİ ... 34

4.2. MONGODB’YECSVDOSYALARINKOMUTLARLAEKLENMESİ ... 36

4.3. MONGODBVESQLSERVERARASINDAVERİTABANIBOYUTU KIYASI ... 37

SONUÇLAR VE ÖNERİLER ... 39

KAYNAKLAR ... 40

ŞEKİL LİSTESİ

Sayfa No

Şekil 2.1. NOSQL veritabanlarının CAP teoremindeki yerleri. ... 14

Şekil 2.2. Dikey ve yatay ölçekleme. ... 15

Şekil 2.3. Yatay bölme (Horizontal sharding). ... 16

Şekil 2.4. Dikey bölme (Vertical sharding). ... 17

Şekil 2.5. Amazon DynamoDb yapısı. ... 18

Şekil 2.6. Doküman türünde Nosql veritabanı yapısı. ... 19

Şekil 2.7. Sütun tabanlı nosql veritabanı yapısı. ... 20

Şekil 3.1. MySql ve MongoDb kavramları. ... 24

Şekil 3.2. Örnek csv dosyası. ... 25

Şekil 3.3. Veri göçü aracı akış şeması. ... 26

Şekil 3.4. İhtimal-1 için örnek tablolar. ... 27

Şekil 3.5. İhtimal-2 için örnek tablolar. ... 29

Şekil 4.1. Northwind veritabanı diyagramı. ... 31

Şekil 4.2. Sql Server 2012’de Northwind veritabanı ekran görüntüsü. ... 32

Şekil 4.3. Tablolara ait şema bilgilerinin ekran görüntüsü. ... 33

Şekil 4.4. csv dosyalarının son görünümü. ... 33

Şekil 4.5. MongoDb Compass koleksiyonu oluşturma. ... 34

Şekil 4.6. MongoDb Compass Import Data. ... 35

Şekil 4.7. MongoDb Compass csv dosyası ekleme. ... 35

Şekil 4.8. MongoDb Compass verilerin eklenmiş hali. ... 36

Şekil 4.9. Northwind veritabanın sql server’da boyut görünümü. ... 37

ÇİZELGE LİSTESİ

Sayfa No Çizelge 2.1. Nosql veritabanlarından bazıları ... 12 Çizelge 3.1. Birinci ihtimal Csv dosya bilgileri. ... 28 Çizelge 3.2. İkinci ihtimal csv dosya bilgileri. ... 29

ÖZET

SQL VERİTABANLARINDAN NOSQL VERİTABANLARINA VERİ GÖÇÜ ARACI GELİŞTİRME

Oktay YILDIRIM Düzce Üniversitesi

Fen Bilimleri Enstitüsü, Elektrik Elektronik ve Bilgisayar Mühendisliği Anabilim Dalı Yüksek Lisans Tezi

Danışman: Prof. Dr. Resul KARA Ağustos 2019, 42 sayfa

Geleneksel veri tabanı yönetim sistemleri, verileri normalize ederek ilişkili tablolarda barındırırlar. Veriler disk sistemleri üzerinde depolanır ve işlenmek üzere belleğe transfer edilir. Günümüz teknolojik gelişmelerine bağlı olarak küçük boyutlarda milyarlarca verinin bir araya gelmesiyle oluşan ve adına “büyük veri” denilen veri yığını ilişkisel veri tabanlarıyla işlenmesi esnasında düşük başarımlara yol açarlar. Bu yüzden verileri bellekte işlenmek üzere organize eden NoSQL sistemlerin kullanımı kaçınılmaz olmuştur. Sosyal medya ve nesnelerin interneti uygulamalarından elde edilen veriler büyük veri olarak nitelendirilebilir. Günümüzde çok önem kazanan konulardan biri de verilerin analiz edilerek anlamlı bilgilerin çıkarımıdır. Özellikle veri analitiği çalışmaları için işlem zamanından kazanç sağlamak için ilişkisel veri tabanı sistemleri yerine NoSQL sistemlerin kullanımı kaçınılmaz olmaktadır. Mevcut verilerini ilişkisel veri tabanları üzerinde saklayan işletmelerin NoSQL’e geçişleri için verileri kayıpsız olarak taşımaları gereklidir. Bu çalışmada, ilişkisel veri tabanı sistemlerinden NoSQL sistemlere veri göçü için kullanılan yöntemler ele alınmış, veritabanı tablosundaki yabancı anahtar sayısına bağlı bir yöntem önerilmiştir. Python dili kullanılarak geliştirilen bir yazılımla, önerilen yöntemle kayıpsız veri göçü gerçekleştirilebildiği görülmüştür.

ABSTRACT

DEVELOPMENT OF A DATA MIGRATION TOOL FROM SQL DATABASES TO NOSQL DATABASES

Oktay YILDIRIM Düzce University

Graduate School of Natural and Applied Sciences, Department of Electrical - Electronic and Computer Engineering

Master’s Thesis

Supervisor: Prof. Dr. Resul KARA August 2019, 42 pages

Conventional database management systems normalize the data and host it in the associated tables. Data is stored on disk systems and transferred to memory for processing. Due to today's technological developments, the data stack formed by gathering billions of data in small dimensions is called big data. Processing large stacks in relational databases reduces performance. Therefore, the use of NoSQL systems organizing data for processing in memory has become inevitable. Data obtained from social media and internet of things can be considered as big data. One of the most important issues today is the analysis of data and the extraction of meaningful information. It is inevitable to use NoSQL systems instead of relational database systems in order to save processing time especially for data analytic studies. Businesses that store existing data on relational databases are required to migrate data to NoSQL without loss. In this study, the methods used for data migration from relational database systems to NoSQL systems are discussed, and a method based on the number of foreign keys in the database table is proposed. It has been found that with the software developed using Python language, the proposed method can perform lossless data migration.

Keywords: Data migration, Denormalization, Nosql, Rdbms, Relational database

1.

GİRİŞ

1.1. TEZİN KAPSAMI

Gelişen teknoloji ile birlikte bilişim sektörünün her alanında olduğu gibi veritabanı sistemlerinde de ihtiyaçlar değişmiştir. Gelişen mobil teknolojiler her yaş grubundan insanın internet kullanmasını elverişli kılmıştır. Dünya nüfusunun % 56,8’inin internet (https://www.internetworldstats.com/stats.htm) kullandığı düşünüldüğünde ihtiyaçların da değişmesi kaçınılmaz olmuştur. İlişkisel veritabanlarında saklanan veriler yapısal formatta verilerdir. Fakat internet üzerinden sürekli akan veriler yapısallığı bozmaktadır. Örneğin sosyal medya üzerinden sürekli olarak gelen veriler düzenli bir yapıda değildir. Bundan dolayı da ilişkisel veritabanlarının işleyiş yapısına uygun olmamaktadır.

İlişkisel veritabanlarında veriler satır ve sütunlar halinde tablolarda saklanmaktadır. ACID özelliği tek başına dahi bu yapıyı halen birçok işlem için vazgeçilmez tutmaktadır. Örneğin bankacılık işlemleri gibi en küçük hataya yer olmayan sistemlerde ilişkisel veritabanlarının alternatifi yoktur. Fakat bazı uygulamalarda ilişkisel veritabanlarının avantaj olarak değerlendirilen bazı özellikleri dezavantaj halini almıştır. Örneğin sensörlerden gelen verilerin anlık işlenme ihtiyacı veya sosyal medyadan sürekli olarak milyonlarca kullanıcıdan gelen veriler klasik ilişkisel veritabanlarını maliyetli ya da yetersiz duruma düşürmüştür. Dünyanın önde gelen firmaları kendi ihtiyaçlarını giderecek veritabanı sistemleri geliştirme yoluna gitmişlerdir. Ölçeklenebilme maliyetinin yüksek olması ve veri yazma hızlarının yavaş olması nedeniyle, büyük verileri işleme ihtiyacı olan Google, eBay ve Amazon gibi şirketler tarafından son yıllarda NoSQL veritabanları tercih edilmiştir [1].

Yakın geçmiş itibarıyla birçok NoSql veritabanı ortaya çıkmıştır. Bunların değişik özelliklerinin yanında değişik artıları ve eksilerinin olması işletmelerin veri tabanı yöneticilerinin geliştirilen ya da geliştirilecek uygulamalarda hangi veritabanını seçecekleri problemini doğurmuştur [2]. Veritabanı yöneticileri dört ana kategoriye ayrılmış olan NoSql yapılarından tercihlerini yapmaktadırlar.

İlişkisel veritabanı kullanan işletmelerin verilerinin tamamını ya da bir kısmını NoSql veritabanlarına aktarmak istemeleri veri göçü sorununu ortaya çıkarmaktadır. İlişkisel veritabanlarında normalizasyon işlemi yapılarak veri küçük parçalara ayrılmaktadır. Ayrılan parçalar birincil anahtarlar ve yabancı anahtarlar yardımı ile gerektiğinde birleştirilerek sorgulanabilmektedir. Nosql veritabanlarında normalizasyon işlemi tercih edilmediğinden ilişkisel veritabanlarındaki gibi parçalanmış veriler söz konusu değildir. Mimari olarak tamamen farklı yapılarda olan ilişkisel veritabanları ve NoSql veritabanları arasındaki veri göçü işlemi birçok yabancı çalışmanın konusu olmuştur. Bunlara literatür araştırması kısmında yer verilmiştir.

Bu tez kapsamında ilişkisel veritabanlarından NoSql veritabanlarına veri göçü işlemi üzerinde çalışılmış ve bu işlem için bir uygulama geliştirilmiştir. Uygulama Python programlama dili ile geliştirilmiştir. Sql server 2012 ve Oracle 11g ilişkisel veritabanlarından alınan veriler csv formatında olan dosyaya denormalizasyon işleminin ardından kaydedilmektedir. Denormalizasyon işleminde tablolarda kullanılan yabancı anahtar sayılarına dayalı bir algoritma geliştirilmiştir. Algoritmaya ait detaylar tezin üçüncü kısmında detaylı olarak anlatılmıştır.

Csv formatındaki dosyaya denormalizasyon işlemi uygulanarak kaydedilen veriler MongoDb ve Apache Cassandra Nosql veritabanlarına eklenmiştir.

1.2. LİTERATÜR ARAŞTIRMASI

Bu kısımda iki ayrı başlık halinde literatür araştırması yapılmıştır. Öncelikle Nosql veritabanları üzerine ülkemizde yapılan çalışmalara yer verilmiştir. Ülkemizde yapılan nosql veritabanı çalışmalarında ilişkisel veritabanlarından nosql veritabanlarına veri göçü ile alakalı çalışmaya rastlanmamıştır. İlişkisel veritabanlarından nosql veritabanlarına veri göçü ile alakalı yabancı çalışmalar ayrı başlık halinde verilmiştir.

Ülkemizde Yapılmış Olan Nosql Veritabanı Çalışmaları

Kabakus ve Kara [3] farklı özellik ve karakteristikte 255’in üzerinde NoSql veritabanı olduğunu, bunlardan hangisinin hangi veri işlemlerinde nasıl sonuç vereceğinin bilinmesinin gerekliliğini ifade etmişlerdir. Çalışmalarında Nosql veritabanlarından en bilinen birkaçını test işlemine tabi tutmuşlardır. Sonuç olarak belirledikleri kriterlerin hepsinde en yüksek performansı sağlayan Nosql veritabanı olmamıştır.

Aladily, [4]’te yer alan çalışmada çok kullanılan nosql veritabanlarını kıyaslamıştır. Nosql veritabanlarından MongoDb, CouchDb, Cassandra ve Hbase mimarilerini ele almış ve bu veritabanlarının performans kıyaslamasını yapmıştır.

Oyucu, [5]’te yer alan çalışmasında Makineler Arası Haberleşme (M2M) cihazlarıyla geliştirilen M2M sistemleri için bir web tabanlı uygulama geliştirmiştir. Bu uygulamada veriler Nosql veritabanında saklanarak hem maliyetten tasarruf hem de ölçeklenebilirlik sağlanmıştır.

[6]’da MongoDB, Cassandra ve LevelDB veritabanları üzerinde kullanılan Snappy, LZ4 ve Zlib sıkıştırma algoritmalarını sıkıştırma oranı ve sıkıştırma hızı bakımından karşılaştırmışlardı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.

Uzunbayır, [7]’de büyük veri tasarım zorlukları üzerine bir sosyal alışveriş uygulaması kullanarak ilişkisel veritabanları ve nosql veritabanları arasında bir karşılaştırma yapmıştır. Bu iki veritabanı teknolojisini kıyaslamak için sosyal ağ ile çevrimiçi alışveriş uygulaması olan TrendPin kullanılmıştır. TrendPin üzerinden yapılan veri tasarım modelleri ve farklı sorgular tezde gösterilmiştir. Ek olarak bilgi çıkarımı konusu açıklanmış ve grafik modeli tasarımında karşılaşılan zorlukların üstesinden gelmek için bir bilgi bankası oluşturulmuştur. Yapılan uygulama da ilişkisel veritabanı olarak Microsoft SQL Server 2012, nosql veritabanı olarak Neo4j 2.1.7 Community Edition kullanılmıştır.

Karataş [8]’de yer alan tez çalışmasında yazılım mühendisliği kapsamında önemli bir konu olan yazılım testlerinin, kullanımı artan dağıtık sistemlere uygulanması alanını ele almıştır. Bir dağıtık veritabanı uygulaması olan MongoDB üzerinde farklı sınamaların gerçeklendiği test uygulaması geliştirilmiş olup, bu uygulamaya “MongoDB Tester” ismi verilmiştir. Bu uygulama kullanılarak Dağıtık Veritabanları üzerinde yapılan iyileştirmelere ait sonuçlar paylaşılmıştır. MongoDB Tester uygulamasının önerisi ile yapılan iyileştirmelerle elde edilen sonuçlarda sistemde iyileştirmeler olduğu görülmüştür.

Cihan, [9]’daki tez çalışması kapsamında Java programlama dili ile Jdbc, Hibernate, NoSql geliştirmeleri yaparken karşılaşılan farklılıkları ve benzerlikleri uygulamalar ile

inceler ve bunların yazılım geliştiriciler açısından avantaj ve dezavantajlarını ortaya çıkarır. Tez kapsamında ele alınan performans çalışmaları NoSql’in performans açısından diğer kullanımlara göre çok daha hızlı olduğunu göstermiştir.

Benzer, [10]’daki tez çalışmasında ontoloji geliştiriminin aşamalarından biri olan “var olan ontolojilerin yeniden kullanımı” adımının nasıl gerçekleştirilebileceği konusunda bir yöntem önerisi yapmıştır. Ontolojilerin bütün olarak yeniden kullanımının yanı sıra, varlıkların da bağımsız olarak yeniden kullanılabileceği tartışılmıştır. Oluşturulan yöntem, Ontology Development 101 yönteminin yeniden kullanım adımına uygulanmıştır. Geliştirilen yöntemin ontologlar tarafından kolaylıkla uygulanabilmesi için bu yöntemi destekleyen bir araç geliştirilmiştir. Bu aracın geliştirilmesinde Scala, Play Framework 2, MongoDB ve Angular.js teknolojileri kullanılmıştır. Araç, tüm platformlarda çalışması ve rahatlıkla kullanabilmesi için, bir web uygulaması olarak geliştirilmiştir. Çok sayıda kullanıcının aynı anda kullanabilmesini sağlamak amacıyla ölçeklenebilir bir mimari kullanılmıştır.

Hammood, [11]’de MongoDb, Apache Hbase ve Apache Cassandra NoSQL veritabanı sistemlerinin yeteneklerini ve farklı operasyonlarda nasıl tepki verdiklerini ortaya çıkarmak için detaylı testler yapmıştır. Bu çalışmanın sonuçları çalışmada kullanılan her bir veritabanı sisteminin zayıf ve güçlü yönlerini ortaya koymaktadır. Çalışmada, veritabanı performansını test etmek için Yahoo tarafından tasarlanan bir kıyaslama çerçeve uygulaması olan Yahoo Cloud (YCSB) kullanılmıştır. Elde edilen sonuçlara göre, MongoDB düşük yükler ile çok iyi performans göstermiştir. Ancak, Cassandra ve HBase optimize tasarımları sayesinde ağır yükler altında çok iyi performans göstermiştir. Okuma işleminde ise, HBase test edilen diğer sistemlere kıyasla düşük bir performansa sahiptir.

Eren, [12]’de yer alan tez çalışmasında bulut bilişim teknolojilerini ve NoSQL veritabanlarını kullanarak Türkiye’de ki terör olaylarını incelemiştir. İnceleme için bu teknolojileri kullanan bir uygulama hazırlamıştır. Bu uygulama bu teknolojilerin ne kadar efektif olduğunu araştırmaya yöneliktir. Uygulamada terör olaylarının görsel olarak incelenebilmesi ve yorumlanarak önlemlerin alınabilmesi için bir model önerilmiştir. Nosql veritabanı olarak Neo4j kullanılmıştır. Modellenen örnek uygulama Türkiye’de gerçekleşmiş terör olaylarına odaklanmıştır.

uygulamasını kullanarak; veri ekleme, okuma, güncelleştirme ve silme gibi temel işlemler bakımından ilişkisel veri tabanı sistemleri (MySQL (RDBM)) ve ilişkisel olmayan veri tabanı sistemlerinin (Mongo DB ve Apache Cassandra) performanslarının detaylı karşılaştırılmasını sunmaktadır. Bu amaçla, temel veri tabanı işlemlerini içeren farklı iş yükleri tasarlanmış ve her bir iş yükü için bir test ortamı oluşturulmuştur. Bu çalışmada kullanılan her bir veri tabanı yönetim sistemi için her bir iş yükü test edilmiş ve sonuçlar raporlanmıştır. Bu çalışmanın sonuçları, her bir sistemin performansının kendi veri depolama mekanizmalarındaki farklılıktan dolayı değişiklik gösterdiğini ortaya koymaktadır. Bunun yanında, bu çalışmanın sonuçları bu çalışmada kullanılan her bir veri tabanı sisteminin zayıf ve güçlü yanlarını sunmaktadır.

[14]’de, SQL ve NoSQL veritabanlarının karşılaştırması ve avantajları ile dezavantajlarının belirlenmesine yönelik bir araştırma yer almaktadır. Karşılaştırmalar her iki veritabanı türünü ölçekleme (ACID ve CAP) kuramı, esneklik, başarım, şema, sorgulama dili, maliyet, hız ve veri açısından değerlendirmektedir. Çalışmada, MySQL, MS-SQL Server Express Edition, Oracle 11g Express Edition gibi SQL veritabanlarına örnekler verilmiştir. Ayrıca, çalışmada NoSQL veritabnalarına örnek olarak, Anahtar-Değer Depo veritabanları, Kolon-Yönelimli Veritabanları, Doküman Depol Veritabanları ve Dizge Veritabanları kısaca örneklerle anlatılmıştır. Çalışmanın sonuçları ve karşılaştırmalar SQL vertiabanlarının tablo tabanlı sistemler olduğunu, esnekliği, düşey ölçeklemeyi ve yapısal sorgulama dili SQL’i desteklediğini ortaya koymuştur. Diğer taraftan, bu çalışma, SQL sıra düzensel veri yapıları için uygun olmadığını, ve NoSQL veritabanlarının daha az esnek olmasına ragmen, yatay ölçeklenebilir, yapısal olmayan sorgulama dili özellikleri ile, sıra düzensel veritabanı yapıları için daha uygun olduğu ortaya çıkartmıştır.

Öztürk, [2]’deki tez çalışmasında ilişkisel ve ilişkisel olmayan (nosql) veri tabanı yönetim sistemlerinin mimari performansını yönetim bilişim sistemleri kapsamında incelemiştir. Yapılan çalışmada işletmeler tarafından kullanılan veri tabanı yönetim sistemlerinin seçimi problemi üzerinde durulmuştur. Firmaların yönetim bilgi sistemlerinde çok sık kullanılan uygulamalar baz alınarak seçilen bir uygulama ile, ilişkisel ve NoSQL veri tabanlarının farklı veri tabanı sorgu türleri karşısında gösterdikleri performans karşılaştırılmıştır. İşletmelere hangi durumda nasıl bir veri tabanı yönetim sistemi kullanmaları konusunda önerilerde bulunulmuştur. Yapılan çalışma ile elde edilen sonuçlardan hareketle, artan veri tabanı yönetim sistemi

alternatiflerinin, hazırlanan uygulamaların özelliklerine göre seçimlerini kolaylaştıracak bir çalışma yapılabileceği değerlendirilmektedir. Piyasada yaygın olarak kullanılan bütün veri tabanı yönetim sistemlerinin tek tek değerlendirilerek geliştirilecek bir metot ile hazırlanan uygulama kapsamında veri tabanına kaydedilecek tahmini kayıt sayısı, transactional özellikte işlem yapılması gerekip gerekmediği, kullanılacak veri tabanı sorgulamalarında tablo birleştirmenin gerektiği karmaşık sorguların kullanılıp kullanılmayacağı, zamanla yatay olarak ölçeklenebilirliğe ihtiyaç duyulup duyulmaması olasılığı gibi verileri kullanıcılardan alarak veri tabanı yöneticilerine kullanabilecekleri uygun veri tabanı yönetim sistemleri alternatiflerinin sunulacağı bir uygulama geliştirilebileceği öngörülmektedir.

Shwaysh, [15]’teki tez çalışmasında nosql veri tabanı sistemlerinin güvenlik ve performans karşılaştırmasını yapmıştır. Bu çalışmada iki aşamalı bir araştırma yapılmıştır: Birinci aşamada, iki farklı NoSQL veri tabanının, MongoDB (3.6.3) ve Cassandra'nın (3.11.1), Yahoo Cloud Hizmet Ölçümü (YCSB-0.12.0 sürümü) kullanarak performansını tek bir düğümde ve çok düğümlü (küme) konfigürasyonlarda inceleyerek karşılaştırılmıştır. Bu aşamada, farklı iş yükleri için bir test ortamı kurulmuş ve çalışmada kullanılan her bir veri tabanı yönetim sisteminin yanıtları her iş yükü için incelenmiştir. Bu çalışma, özellikle karar vericilerin, hangi veri tabanının gereksinimlerine göre daha iyi olduğunu belirlemesine yardımcı olacaktır. Bu çalışmanın ikinci katmanı, her iki veri tabanının güvenliğini araştırmaktır. İlk adım, her iki veri tabanının literatürdeki on seçilmiş özelliğe göre güvenlik özelliklerinin karşılaştırmalı bir çalışmasıdır. Güvenlik incelemesinin ikinci adımı, veri şifreleme yükünün karşılaştırılmasıdır. Veri şifreleme yükü, veri tabanı motorunun tüm gelen veri akışlarını şifrelemek için harcadığı süreyi ve sorguları yanıtlamak için verilerin şifresini çözmek için harcanan toplam süredir. Bu çalışmanın sonuçları, her bir sistemin performansının, veri saklama mekanizmalarındaki farklılıklar nedeniyle farklı olduğunu göstermiştir.

Erden, [16]’daki tez çalışmasında nosql veritabanları için ortak sorgu işletim katmanı geliştirmiştir. Bu tezde, farklı NoSQL veritabanları üzerinde saklanan verilerin bütünleştirilmesi problemine odaklanılmıştır. Probleme çözüm olarak kullanılan yaklaşımlar literatürde çoklu depolama sistemleri adıyla anılmaktadır. Tezde bu veri yönetim sistemlerinden örnek alınarak bir prototip gerçekleştirmi yapılmıştır. Prototip tasarlanırken, veri kaynağı dağılımı, heterojenliği ve özerkliği problemine çözüm

oluşturabilmek için arabulucu-sarmalayıcı mimariden yararlanılmıştır. Prototip bu mimariye referansla tartışılmaktadır. Ayrıca veri depoları üzerinde sorguların çalıştırılabilmesi için PQL (Polystore Query Language) adında temel operasyonları içeren bir sorgulama dili gerçekleştirimi yapılmıştır. Sonuç olarak dağıtık olmayan yerel depolar üzerinde sorgu işletimi gerçekleştirilmiştir. Sorgu sonucu farklı depolardan dönen sonuçlar, sonuç bütünleştirme işlemi ile bellek üzerinde ortak bir anahtar-değer veri yapısı gerçekleştirimi ile tutulmuştur. Yapılan gerçekleştirim MovieLens veri seti üzerinde yaratılan bir kullanım durumu ile denenmiş ve sonuçlar listelenmiştir.

Dumanlı, [17]’deki tez çalışmasında en çok kullanılan ilişkisel ve nosql veritabanı yönetim sistemlerinin performans karşılaştırmasını yapmıştır. En çok kullanılan NoSQL veritabanı sistemlerinden üç tane ve en çok kullanılan ilişkisel veritabanlarından üç tane seçilerek sistemlerin yeteneklerini ve farklı işlemlerde nasıl tepkiler verdiklerini ortaya çıkarmak için testler yapılmıştır. Bu amaçla, birçok iş yükü yüklenmiş ve iki adet test ortamı hazırlanmıştır. Bu çalışmanın sonuçları kullanılan her bir sistemin zayıf ve güçlü yanlarını ortaya koymaktadır. Test edilen her bir veritabanı farklı mimari ve özelliklere sahip olduğu için farklı sonuçlar ortaya çıkarmıştır.

İlişkisel veritabanlarından Nosql veritabanlarına veri göçü çalışmaları

Lee ve Zheng, [18]’de ilişkisel veritabanları ile hazırlanmış olan içerik yönetim sistemlerinin (wordpress, joomla vb.) veritabanlarını nosql ile hazırlama ve veri göçü gerçekleştirme üzerine çalışmışlardır. Öncelikle ilişkisel veritabanının şema denormalizasyonu yapılmakta olup akabinde veri göçü gerçekleştirilmektedir.

Scavuzzo, Di Nitto ve Ceri, [19]’da, sütun bazlı nosql veritabanları (column based) için ortak çalışabilir bir yaklaşım ortaya koymuşlardır.

Bansel ve Gonzalez Velez, [20]’de, bulut tabanlı nosql veri göçü aracı geliştirmişlerdir. Bu çalışmada hem kaynak veritabanı hem de hedef veritabanı nosql veritabanlarıdır. Yani veri göçü nosql veritabanları arasında gerçekleşmektedir.

Stanescu, Brezovan ve Burdescu, [21]’deki çalışmalarında ilişkisel veritabanı olan MySql’den MongoDb’ye veri göçü gerçekleştirmişlerdir. Öncelikle MySql veritabanının yapısının bir haritalamasını yapmışlar ardından MongoDb’ye verileri aktarmak için bir algoritma geliştirmişlerdir.

Yoo, Lee ve Jeon [22]’de ilişkisel veritabanlarından nosql veritabanlarına sütun bazlı bir denormalizasyon yaparak veri göçü gerçekleştirmişlerdir. Aynı zamanda çalışmaları ilişkisel veritabanlarında kullanılan atomik yapıyı da desteklemektedir.

Hanine, Bendarag ve Boutkhoum [23]’de, ilişkisel veritabanı olan MySql veritabanından NoSql veritabanı olan MongoDb’ye veri göçü aracı geliştirmişlerdir. Geliştirdikleri araç mysql veritabanının şemasına bakarak otomatik olarak MongoDb veritabanını oluşturarak veri göçü işlemini gerçekleştirmektedir.

[24]’de yazılım geliştiriciler için MySql veritabanından MongoDb veritabanına veri göçü sağlayan arayüz geliştirmişlerdir.

Rith, Lehmayr ve Meyer – Wegener [25]’de genişletilebilir bir ara katman geliştirmişlerdir. Bu katman sql sorgularını nosql veritabanının sorgularına çevirmektedir.

Zhao ve diğerleri [23]’de, ilişkisel veritabanlarından NoSql veritabanlarına şema dönüşümü çalışması yapmışlardır. Hazırladıkları programla MySql’den MongoDb’ye veri göçü uygulaması yapmışlardır.

Rafique ve dig. [24]’de, nosql veritabanları arasında taşınabilirliği, birlikte çalışılabilirliği ve veri göçünü sağlayan ara katmanların kıyasını yapmışlardır. Testlerinde kullandıkları ara katmanlar Impetus Kundera, Playorm ve Spring Data platformlarıdır. Bu platformlarda yaptıkları testlerde kriterleri performans ve veri göçü maliyetidir.

Klettke ve dig. [25], çalışmalarında nosql veritabanlarındaki ölçeklenebilir uygulama yöntemlerini tembel şema dönüşümünü gerçekleştirmek maksadıyla araştırmaktadırlar. Simülasyon tabanlı analizlerinde Google Cloud Datastore ve MongoDb kullanmışlardır. Kuderu ve Kumari [26]’daki çalışmalarında ilişkisel veritabanlarından nosql veritabanlarına veri göçü için şema göçü (schema migration) ve eşleşme (mapping) arayüzü geliştirmişlerdir.

Karnitis ve Arnicans [28]’de, çalışmalarında ilişkisel veritabanlarından doküman tipindeki NoSql veritabanına hızlı bir veri göçü yöntemi önermektedirler. Fiziksel veriler üzerinde yarı otomatik bir araç oluşturmuşlardır.

El Alami ve Bahaj [29]’da veri göçü yöntemlerinden, tersine veritabanı mühendisliğinden bahsetmektedirler. Veri göçü için önerdikleri bir yöntemi doküman

tipinde bir NoSql veritabanı olan MongoDb üzerinde denemişlerdir. İlişkisel veritabanının meta verilerine göre şema çıkarılmış ve MongoDb ye veri göçü sağlanmıştır. Bu işlem esnasında veri fazlalığı ve join işlemlerini çözümlemeye odaklanılmıştır.

2.

VERİTABANI SİSTEMLERİ

Literatürde veritabanı sistemleri dendiğinde akla öncelikle ilişkisel veritabanı sistemleri gelmektedir. Nosql kavramı da hızlı bir şekilde literatürde ki yerini almaktadır. Bu bölümde ilişkisel veritabanlarının ve nosql veritabanlarının genel tanıtımı yapılacaktır. Veritabanı çeşitliliği Nosql kavramıyla çok fazla artmıştır. Örnek teşkil etmesi için Amazon firmasının müşterilerine sunduğu veritabanları incelenmiştir. Amazon web servisleri (AWS) web sayfası incelendiğinde Amazon’un müşterilerine geniş bir veritabanı ürün yelpazesi sunduğu görülmektedir. Bunlar [26];

 Transaction uygulamaları için ilişkisel veritabanları,

 İnternet ölçekleme uygulamaları için ilişkisel olmayan veritabanları,  Analiz için veri ambarı (data warehouse),

 Önbelleğe alma ve gerçek zamanlı iş yükleri için bellek içi veri deposu,  Birbiriyle ilişkisi çok olan verilere uygulamalar oluşturmak için grafik

veritabanı,

 Zaman içindeki değişiklikleri ölçmek için bir zaman serisi veritabanı,  İşlemlerin eksiksiz ve doğrulanabilir kaydının tutulması için defter (ledger

database) veritabanından oluşur.

Bu ürünler veritabanı sistemlerinin ne kadar çeşitlendiğini göstermektedir. Farklı firmaların benzer ya da daha farklı yapılarda ürün yelpazeleri bulunmaktadır.

Bu bölümün devam eden kısımlarında Nosql ve Sql veritabanlarının farkının anlaşılması için ilişkisel veritabanlarının ve nosql veritabanlarının bazı özellikleri ele alınmıştır.

2.1. İLİŞKİSEL VERİTABANLARI

İlişkisel veritabanları, verileri önceden tanımlı bir şema çerçevesinde kaydeder. Bu işlem veritabanında bulunan tabloların ve tablolara ait özelliklerin (alan adları vb.) önceden belirlenmesi ve bu şema üzerine verilerin kaydedilmesi şeklinde ifade edilebilir. İlişkisel veritabanlarında tablolar arasındaki ilişkilerin iyi tasarlanmış olması depolamanın düzenli olmasında hayati öneme sahiptir. İlişkilerin doğru belirlenmesi sorunsuz bir veri yönetimini sağlayacaktır.

2.1.1. ACID

Klasik ilişkisel veri tabanlarında olması beklenen temel özellikler (ACID) [27]:  Bölünmezlik (Atomicity); veritabanında başlayan bir işlemin bölünmez

olmasıdır. Başlamış olan bir işlem ya tamamen bitmeli ya da iptal olmalıdır.  Tutarlılık (Consistency); veritabanında yapılan bir işlemin tutarlı bir durumdan

yine tutarlı bir duruma sebep olması gerekir. Örneğin gönderen hesaptan 100 eksilmiş ise gönderilen hesap 100 artmalıdır.

 Yalıtım (Isolation); aynı veri üzerinde yapılan farklı işlemler birbirlerinden yalıtılmış olarak çalışmalıdır. Eşzamanlı olarak yapılan işlemlerin herbiri tek işlemmiş gibi davranmalıdır

 Dayanıklılık (Durability); yapılan işlem bittikten sonra sistem hatası olsa bile veri yerli yerinde olmalıdır. Örneğin yaptığınız havale işlemi onaylandıktan sonra sistem çökse bile paranız karşı tarafa ulaşmıştır.

ACID özellikleri sistemin tutarlılığı, güvenliği gibi konularda çok etkilidir. Fakat avantajlarının yanında işlemleri yavaşlatması gibi dezavantajları da vardır.

2.2. NOSQL VERİTABANLARI

Nosql ile ilgili birçok tanım yapılmıştır. Genellikle “Not Only Sql (Sadece Sql Değil)” tabiri akıllarda kalmaktadır. Bu ifade dahi klasik veritabanlarında farklı bir yapı ile karşı karşıya olunduğunu göstermektedir. Teknolojinin gelişiminde ihtiyaçlar önemli yer tutmaktadır. NoSql yapılara da bazı ihtiyaçlar neticesinde yönelim olmuştur. Çok fazla artan veri miktarı bu ihtiyaçların başında gelmektedir. NoSQL’in SQL’i reddetmediği,

yanı sıra ilişkisel veritabanlarının eksikliklerini kapattığı görülmektedir. Dumanlı’ya göre NoSQL [17], ilişkisel veritabanı sistemlerine alternatif bir çözüm olarak ortaya çıkan, değişken şema yapısına sahip verilerin saklanabilmesini ve büyük verilerin yüksek performansla sorgulanabilmesini sağlayan, yatay ölçeklendirilmesi kolay olan bir veri depolama sistemidir. NoSQL çözüm sağlayıcılarının genel olarak üzerinde birleştiği görüş; NoSQL’in mükemmel değil, cazip olduğu yönündedir [1]. Çizelge 2.1’de [28] nosql veritabanlarından bir kısmı hakkında bilgiler bulunmaktadır.

Çizelge 2.1. Nosql veritabanlarından bazıları.

Nosql

Veritabanı Adı Üretici Dil Platform Lisans

Şema Tanımı

Yok Sütun tabanlı depolama

Hbase Hadoop Java Java Apache 2.0 Y

Azure Tables Microsoft .Net Azure Saas Y

Cassandra Apache Java Java Apache 2.0 Y

Hypertable Açık kaynak C++ Linux/Mac GPLv2 Y

SimpleDB Amazon Erlang EC2 SaaS Y

Doküman tabanlı veri depolama sistemi

MongoDB Açık kaynak C++ Linux/Mac/Windows Friendly AGPL Y CouchDB Açık kaynak Erlang Linux Apache 2.0 Y Terrastore Açık kaynak Java Java Apache 2.0 Y

Anahtar/Değer Depolama

Redis Açık kaynak C Linux BSD Y

LevelDB Açık kaynak C Linux BSD Y

Tokyo

Cabinet/Tyrant Açık kaynak C Linux/Windows LGPL Y Berkeley DB Açık kaynak C Linux/Mac/Windows Sleepycat Licence Y Memcached DB Açık kaynak C Linux/Mac/Windows BSD Y

Grafik veri yönetim sistemi

Neo4j Neo

Techonologies Java Java AGPL/Commercial Y InfoGrid NetMesh Inc Java Java AGPL/Commercial N HyperGraphDB Kobrix Java Java AGPL/Commercial N

2.2.1. BASE Teoremi

İlişkisel veritabanlarının kullandığı ACID özelliklerine karşın NoSQL’de BASE (Basically Available, Soft state, Eventually consistent) özellikleri kullanılmaktadır. BASE özellikleri [1];

 Kolay Ulaşılabilirlik (Basically Available): Veri erişim sorunlarını ortadan kaldırmak için kopyaları kullanır ve arta kalan herhangi bir paylaşılmış ya da bölümlenmiş veriyi birçok sunucudan alır.

 Esnek Durum (Soft state): ACID mantığında veri tutarlılığının olmazsa olmaz bir gereklilik olduğu savunulur fakat NoSQL sistemler tutarsız ve süreksiz verilerin barınmasına da izin verir.

 Eninde sonunda Tutarlı (Eventually consistent): Uygulamalar anlık tutarlılıkla ilgili olmasına rağmen, NoSQL sistemlerin gelecekte bir zamanda tutarlı olacağı farz edilir. ACID’te zorunlu tutulan tutarlılığın, NoSQL’de tanımlanmayan bir zamanda oluşacağı garanti edilir.

Yazılımcılar bazen ilişkisel veri yapıları ile bellek veri yapıları arasındaki uyuşmazlıklardan dolayı sorunlar yaşamaktadırlar. NoSQL [12] yazılımcılara hafıza veri yapılarını ilişkisel veri yapılarına dönüştürmeden geliştirme yapmalarını sağlamaktadır. NoSql, ilişkisel veritabanlarında olduğu gibi önceden belirlenmiş kurallardan oluşan tablolardan oluşmamaktadır. İlişkisel veritabanlarında önceden belirlenmiş olan tablo şemasında bir değişiklik yapıldığında bu değişiklik milyonlarca kaydı etkileyebilmektedir. NoSql’de önceden tanımlanmış bir şema dâhilinde kayıt gerçekleşmediğinden böyle bir sorunla karşılaşılmamaktadır.

2.2.2. CAP Teoremi

CAP teoremi [29], tutarlılık (consistency), ulaşılabilirlik (availability) ve bölünmüş ağ toleransı (partition tolerance) ifadelerinin kısaltmasıdır ve ilk kez literatüre kazandıran Eric Brewer’dır. CAP ifadesi consistency, avaibility ve partition tolerance ifadelerinin ilk harfleri alınarak kısaltmasıdır. Veritabanı sistemlerini geliştirenler kendi teknolojilerinin sağlamasını istedikleri özelliklere göre bu teoremden yararlanırlar. Örneğin Apache Cassandra, mimarisi itibariyle bölünmüş ağ toleransına ve ulaşılabilirliğe öncelik verir, fakat tutarlılığı önemsemez. Yani ağda sorun olması ve dağıtım yapılan veri kaynaklarının birbiri ile senkronizasyon yapamaması durumunda, sistem durma yoluna gitmez birbirinden bağımsız şekilde veri kaynaklarında işlemler devam eder. Böyle bir durumda sistem ulaşılabilirdir. İki veri kaynağında farklı işlemler yapılmış olduğundan tutarlılık feda edilmiş olur. İlişkisel veritabanlarında tutarlılık ön plandadır. Gerekirse veritabanı hizmet vermeyi durdurur tutarlılıktan vazgeçmez.

Şekil 2.1’de [30] CAP teoremine göre hangi veritabanı hangi kenarda yer almakta görülmektedir. Nosql veritabanlarının farklı özelliklerde olması hangi veritabanının kullanılacağı konusunda doğru karar vermeyi zorlaştırmaktadır. CAP üçgeni bu işi

kolaylaştırmaktadır. Şekil 2.1 incelendiğinde tutarlılık ve ulaşılabilirlik kenarında (CA) ilişkisel veritabanlarının olduğu görülmektedir. Yani ilişkisel veritabanlarında öncelik tutarlılık ve ulaşılabilirliktedir. AP kenarında ise Nosql veritabanlarından Cassandra ve Dynamo görülmektedir. Bu iki veritabanı için ulaşılabilirlik ve bölünmüş ağ dayanıklılığı öne çıkmış gerektiğinde tutarlılık feda edilmiştir. Son zamanlarda literatürde eninde sonunda tutarlılık kavramına da rastlanmaktadır. Yani sistem kendi içinde tutarlılığını daha sonra sağlayabilmektedir.

Şekil 2.1. NOSQL veritabanlarının CAP teoremindeki yerleri.

2.2.3. Ölçekleme

Dikey ölçekleme artan veri miktarına karşı mevcut sistemin kapasite artımını ifade etmektedir. Bu kapasite artımı donanımsal olacağı gibi yazılımsal da olabilir. Donanımsal kısımda işlemcide hızlandırma, bellek ve sabit disk kapasitesinde artıma gitme ilk akla gelenler olmaktadır. Yazılım kısmında ise sunucu yazılımlarında üst özellikler eklemek söylenebilir. Şekil 2.2’de görüldüğü gibi dikey (vertical) ölçeklemede mevcut sunucunun özellikleri veri büyüdükçe büyütülmektedir [31].

Şekil 2.2. Dikey ve yatay ölçekleme [31].

Yatay ölçekleme ise [32] sistemin kapasitesinin yeni bileşenlerle artırılmasıdır. Yatay ölçeklemede her bir sistem bileşeni birbiriyle haberleşmektedir. Sistemin toplam kapasitesi haberleşmekte olan bileşenlerin toplamıdır. Şekil 2.2’de görüldüğü gibi yatay (horizontal) ölçekleme düşük kapasiteli bir çok sunucunun kullanılması olarak ifade edilebilir. Yatay ölçekleme aslında nosql veritabanlarında doğrudan ölçekleme olarak adlandırılır.

Yatay ölçekleme daha ucuz olabilir fakat mimari olarak iyi tasarlanmalıdır. İyi ölçeklenmiş bir sistemde gerektiğinde büyütme küçültme işlemleri rahat yapılabileceğinden maliyetten tasarruf sağlanmış olur. Yatay ölçekleme de arızalanan bir sunucu olduğunda sistem yine çalışmaya devam eder [33].

2.2.3.1. Bölümleme (Sharding)

Verileri ölçeklerken verilerin farklı sunucularda olacak şekilde ayrılmasına bölümleme (sharding) denir. Her bölüm (shard) kendi içerisinde farklı bir veritabanıdır.

Bölümleme işlemi de yatay ve dikey olarak ayrılmaktadır. Yatay bölme Şekil 2.3’te görüldüğü gibi her bir kaydın bölümleme kurallarına göre ayrı sunuculara kaydedilmesi şeklindedir. Şekildeki örnekte key alanına göre A-G aralığındaki harflerle başlayan kayıtlar bir sunucuya diğerleri ayrı bir sunucuya kaydedilmiştir [34].

Şekil 2.3. Yatay bölme (Horizontal sharding) [34].

Dikey bölme (vertical sharding) ise Şekil 2.4’te görüldüğü gibi bir kaydın belirlenen kural kapsamında bölümlenerek farklı sunuculara kaydedilmesi şeklindedir. Cassandra ve Hbase gibi sütun tabanlı nosql veritabanlarında daha uygundur [34].

Şekil 2.4. Dikey bölme (Vertical sharding) [34]. 2.2.3.2. Çoğaltma (Replication)

En basit haliyle verilerin birden fazla makina üzerinde saklanarak veri kaybının önlenmesidir. Veri replikasyonu [35], verilerdeki büyümeyi etkili bir biçimde yönetmenizi sağlayan güvenli veri bütünleştirmesi ve eşitlemesi sağlayan bir çözümdür. Gerçek zamanlı bilgilerin kullanımıyla büyük veri sistemlerini ve mobil uygulamaları zenginleştirerek, sürekli değişen verileri dahi yakalar ve olay odaklı işinizi güçlendirir.

2.2.4. Nosql Veritabanı Çeşitleri

İnternet kaynakları incelendiğinde nosql veritabanlarının birçok çeşidinin olduğu görülmektedir. Fakat literatürde kabul görmüş dört farklı nosql veritabanı çeşidi bulunmaktadır. Bunlar;

2.2.4.1. Anahtar – Değer Depolama Yapan Nosql Veritabanı (Key – Value Store) Veri bloklarında anahtar – değer ilişkisi bulunmaktadır. Anahtara göre sorgulama yapılıp değer istenir. Veritabanı için değerin ne olduğu önemli değildir. API’lerle kullanmak için en basit NoSql veritabanıdır.

Eren’e [16] göre istemci anahtar ile değeri alabilir, değeri ekleyebilir veya anahtarı veritabanından silebilir. Eş zamanlı çalışmada yüksek performans, hızlı arama ve büyük

veri tutma anahtar – değer veri depolarının avantajlarındandır. Bu türdeki veri tabanları geçici veritabanı olarak kullanılabilir yani veriyi diske yazmaz. Diske yazılmayıp RAM üzerinden işlemler yapıldığından okuma ve yazma işlemleri çok hızlı olmaktadır. Geçici veritabanlarında ki risk ise sistemdeki sıkıntı veri kaybına sebep olabilir. Anahtar – değer türündeki veritabanları kalıcı türde de veri kaydedebilir. Diske kayıt yapıldığında okuma yazma hızı RAM’den çalışan sisteme göre düşmektedir. Fakat verinin tutarlılığı artmış olur. Bu türdeki veritabanları hibrit olarak ta kullanılabilir. Geçici ve kalıcı türdeki veritabanlarının avantajlarını alarak işleyen bir sistemdir. Şekil 2.5’te [36] anahtar - değer veritabanı olan Amazon DynamoDb yapısı görülmektedir. Anahtar – değer veritabanlarında bazıları [37];

DynamoDb

Azure Table Storage Redis Aerospike LevelDb Voldemort Scalaris GenieDb BoltDb Serenety InfinityDb Iovow DBreeze

2.2.4.2. Doküman Tabanlı Depolama Yapan Veritabanı (Document Store)

Doküman tabanlı veritabanları anahtar – değer veritabanlarına benzerlik göstermektedir. Her bir kaydın anahtarıyla beraber farklı türlerdeki değerleri vardır. Bu türdeki veritabanlarında değer kısmından veritabanı haberdardır. Bu değerlere göre sorgulama vb. işlemler yapılabilmektedir. Dokümanların içeriği birçok türdeki değerleri alabilmektedir. Her dokümanın kendine ait değişken şeması vardır. Dokümanlar birbirinden farklı türdeki verileri alabilir. Yazılım geliştiricilerin uygulama geliştirdiği programlama dillerine uyum sağlayabilecek birçok veri türünü desteklemektedir. Veriler genelde JSON formatında tutulmaktadır. Şekil 2.6’da [38] görüldüğü gibi doküman

veritabanları collection’lardan oluşmaktadır. Collection içeresinde document ismi verilen kayıtlar bulunmaktadır.

Doküman veritabanlarından bazıları [37]; MongoDb Cloud Datastore Azure DocumentDb CouchDb MarkLogic IBM Cloudant BaseX OrientDb

Şekil 2.6. Doküman türünde Nosql veritabanı yapısı. 2.2.4.3. Sütun Tabanlı (Wide Column Store) Depolama Yapan Veritabanları

Koçer’e göre [39] ilişkisel veritabanı mantığıyla key – value (anahtar – değer) veritabanlarının mantığının birleşmesiyle tasarlanmıştır. Mümkün olduğunca bu iki veritabanının avantajları alınmıştır.

Dumanlı [17] sütun tabanlı veritabanlarının yüksek yazma ve okuma performansının olduğunu aynı zamanda yüksek erişilebilirlik için tasarlandıklarını söylemektedir. Dağıtık olarak çalışan veritabanlarıdır. Atomik yapıya sahip olduğundan hızlı bir biçimde güncelleme, silme, ekleme işlemleri yapmaktadır. Ölçeklenme konusunda o kadar iyidir ki sütunların artması ve verinin çok büyümesi neredeyse hızda bir düşüşe sebep olmamaktadır [28]. Şekil 2.7’de [40] sütun tabanlı veritabanı yapısı görülmektedir. Bu türde en bilinen veritabanı Apache Cassandra’dır.

Şekil 2.7. Sütun tabanlı nosql veritabanı yapısı [40]. Sütun tabanlı depolama yapan veritabanlarından bazıları [37];

HyperTable Hadoop/Hbase Apache Cassandra Scylla Amazon SimpleDb Clouddata Ibm Informix

eXtremeDb Financial Edition Druid

2.2.4.4. Grafik Tabanlı Depolama (Graph Store) Yapan Veritabanları

Grafik tabanlı depolama yapan veritabanları düğümleri, kenarları ve özellikleri depolar ve bunlar arasındaki ilişkiyi kurar [28]. Ölçeklenebilirliği ve performansı yüksek bir

veritabanıdır. Kayıt ekleme ve güncelleme işlemlerinde diğer nosql veritabanı türlerine göre yavaş kalmaktadır. Tasarım amacı veriler arasındaki ilişkiyi kurup göstermek olduğundan performansı bu yöne doğru yöneltilmiştir.

Grafik tabanlı depolama yapan veritabanlarından bazıları [37]; Neo4j Infinite Graph FlockDb InfoGrid Titan Trinity VertexDb HyperGraphDb

3.

VERİ GÖÇÜ ARACI GELİŞTİRME

Bu kısımda tezin konusu gereği kullanılan yazılım teknolojilerinden ve veri göçü işleminin detaylarından bahsedilmiştir.

3.1. DENORMALİZASYON İŞLEMİ

Denormalizasyon işlemi bilgi çıkarımını daha hızlı şekilde yapmak için veritabanı tasarımına ek özellikler ekleme veya veritabanı tasarımındaki mevcut özellikleri birleştirme olarak tanımlanabilir [41]. Denormalizasyon işlemini yapan birinin öncelikle normalizasyon konusunda uzman birisi olması gerekir. En basit haliyle denormalizasyon işleminde normalizasyon ile parçalanıp ilişkilendirilmiş olan tablolar belirlenen kurallara göre birleştirme işlemine tâbi tutulmaktadır. Denormalizasyon işlemi, veri büyüklüğünün artması sonucu sorgu sürelerinin yavaşlamaya başlamasına karşı üretilen çözümler olarakta tanımlanabilir [42]. Bu çözümlerden bazıları [41];

 Birden fazla tablodan veri çekme sorgu sürelerinin yavaşlaması durumunda alt tablolardaki verinin üst tablolara taşınması işlemi, kısacası JOIN işlemini azaltma işlemi

 SQL fonksiyonları (SUM, AVG, COUNT, MIN, MAX vs) oluşturulmuş sorguların yavaş kalması durumunda hesaplama sonuçlarının ayrı bir özellik olarak bir tabloya yazılması işlemi

 Birden fazla satırı ve/veya sütunu birleştirip tek sütunluk özelliğe çevirme işlemi şeklinde sayılabilir.

Büyük veri çalışmalarında veritabanının dikey ölçeklenmesi değil de yatay ölçeklenmesi tercih edildiğinden normalizasyon işlemlerine gerek duyulmamaktadır. Zaten ilişkisel veritabanlarında saklı verileri NoSql veritabanlarına göç ettirmek gerektiğinde denormalizasyon işlemi ilk akla gelen olmaktadır. Sql join komutları ile sorguda istenen performans sağlanamazsa da denormalizasyon işlemine başvurulmaktadır. Bu tez çalışmasında veri göçünü sağlamak için bir araç olarak denormalizasyon işlemi kullanılmıştır. Literatür araştırması kısmında denormalizasyon

işlemi ile nosql veritabanlarına veri göçü çalışmaları belirtilmiştir.

Bu tezde uygulanan denormalizasyon işleminin amacı ilişkisel veritabanındaki herbir tablonun ilişkiye gerek kalmaksızın tüm bilgileri içermesidir. Yani her bir tablo amacına ait tüm bilgileri içermelidir. Tablo içerisindeki bilgilerin detayı için farklı bir tabloya erişme zorunluluğunun bulunmamasıdır.

3.2. KULLANILAN YAZILIMLAR

Tezde geliştirilmiş olan veri göçü aracı için aşağıdaki yazılımlardan yararlanılmıştır.

3.2.1. Python

Python [43] öğrenilmesi kolay, güçlü bir programlama dilidir. Zarif sözdizimi, dinamik yazımı ve yorumlayıcı (interpreter) yapıda olması ile ideal bir script ve uygulama geliştirme dilidir. Python kurumsal web sayfasında (www.python.org) çok geniş standart kütüphaneye sahiptir ve bu kütüphaneye ücretsiz olarak erişilip kullanılabilmektedir.

Python açık kaynak platform bağımsız bir programlama dilidir. Yani yazılan bir script ya da uygulama (application) Linux, Windows, Mac OS X, Android ve diğer işletim sistemlerinin çoğunda çalışmaktadır.

Python sözlükler, listeler, demetler, kümeler gibi üst düzey veri yapılarına sahiptir. Bunlar yazılım geliştiricilere büyük kolaylık sağlamaktadır. Diğer programlama dillerinde bu yapılar için üçüncü parti yazılımcıların yazmış olduğu eklentiler kullanılmak zorunda kalınabilmektedir.

Python birçok modülü bünyesinde barındırmaktadır. Modüller kullanıcılar için ihtiyacı giderici nitelikte geliştirilmiş kütüphanelerdir. Çizim modülleri, oyun geliştirme modülleri, analiz modülleri python modüllerinin sadece birkaç türüdür. Analiz konusunda; uzay, biyoloji, matematik gibi birçok bilim dalında python adından söz ettirmektedir.

Python genellikle açık kaynak yazılımlar geliştirmek için kullanılır fakat ücretli yazılımlar için dahi özgürce kullanılabilmektedir [44].

3.2.2. Microsoft Sql Server Veritabanı

Microsoft firması tarafından geliştirilen Sql Server sunucu istemci yapısıyla çalışan ilişkisel veritabanlarından biridir. Veritabanı sunucusu olarak uzaktan ya da yerel olarak kullanılmaktadır. Sorgulama dili T-Sql (Transact SQL) olarak adlandırılmaktadır. T-Sql standart sql üzerine eklemeler yapılarak geliştirilmiş bir sorgulama dilidir. Böylelikle standart sql’in yetersiz kaldığı durumların üstesinden gelinmiştir.

3.2.3. Oracle Veritabanı

Oracle adlı firmanın geliştirmiş olduğu sunucu istemci yapısıyla çalışan ilişkisel veritabanlarından biridir. Her ne kadar ilişkisel veritabanı olarak adından söz ettirse de nosql alanında da ürünleri bulunmaktadır.

Oracle tarafından geliştirilmiş olan PL/Sql sorgulama dili standart sql’in eksikliklerini gidermektedir. Sql’in eksiklikleri yapısal programlama dillerindeki özelliklerin sql’e eklenmesiyle giderilmiştir. Oracle’ın güçlü yapısında PL/Sql sorgulama dilinin etkisi büyüktür.

3.2.4. MongoDb Veritabanı

MongoDB ölçeklenebilir ve esnek, gerektiğinde sorgulama ve indexleme yapılabilen doküman tipinde NoSql veritabanıdır [45].

İlişkisel veritabanlarından olan MySql veritabanındaki bazı kavramların MongoDb’deki karşılıkları Şekil 3.1’de listelenmiştir.

MySQL MongoDB

tablo koleksiyon

satır Doküman

Sütun Alan

İkinci Index İkinci Index

JOINs Embedded documents, $lookup & $graphLookup GROUP_BY Aggregation Pipeline

Şekil 3.1. MySql ve MongoDb kavramları.

MongoDB JSON benzeri dokümanlarda esnek yapıda veri depolar. Bunun anlamı alanların dokümandan dokümana değişebilir olması ve zamanla veri yapısının değişebilir olmasıdır. Doküman modeli geliştirdiğiniz uygulamadaki nesnelerle eşleşir

böylelikle veriyle çalışmak kolaylaşmış olur. MongoDB yüksek ulaşılabilirliğe sahip yatay ölçeklenebilen dağıtık bir veritabanıdır.

3.3. CSV UZANTILI DOSYALAR

Virgülle ayrılmış değer (Comma Separated Value) ifadesinin İngilizce halinin ilk harfleri alınarak adlandırılmış bir dosya türüdür. Bu dosya türü çok büyük boyutta veri barındırabilir ve bunu diğer dosya türlerinden çok daha düşük kapasitede depolama yaparak yapar. Ayraç olarak (delimeter) genelde virgül (,) kullanılır fakat başka karakterler de kullanılabilmektedir. Genellikle farklı uygulamalar arasında veri geçişi yapmak için kullanılan bir dosya formatıdır.

Veritabanı kullanan uygulamalarda csv dosyalarla veri import veya export etme işlemine sıklıkla rastlanır. Bu tez çalışmasında da denormalize edilen veriler csv türündeki dosyalara kaydedilmektedir. Bu dosya türünün seçilmesinde tüm veritabanlarının bir şekilde csv dosyaları okuma yazma desteği vermesi etkili olmuştur. Ayrıca internet üzerinde csv dosyaların içeriğini farklı türde ki nosql veritabanlarına import etme işlemini anlatan bol miktarda kaynak bulunmaktadır.

Csv dosyalarının yapısı arasında virgüllerin bulunduğu bir veri listesi şeklindedir. Her satır ayrı kaydı ifade etmektedir. Şekil 3.2’de görülmekte olan csv dosyası virgüllerle ayrılmış verilerden oluşmaktadır. İlk satır veritabanında üzerinde işlem yapılan tablonun alanlarını ifade etmekte ikinci satırdan itibaren bu alanlara ait kayıtlar görülmektedir.

3.4. VERİ GÖÇÜ ARACI GELİŞTİRME ADIMLARI

Sql’den Nosql’e veri göçü aracının Şekil 3.3’de akış şeması görülmektedir. Bu akış şemasında basit olarak veri göçü aracının mantığı verilmiştir.

Şekil 3.3. Veri göçü aracı akış şeması.

Öncelikle veritabanı yönetim sisteminin (Oracle veya Sql Server) üzerinde çalışılan veritabanının şema (schema) bilgilerine erişilmiştir. Veritabanının şemasından tablolar, tablolara ait birincil anahtar ve yabancı anahtar bilgileri, yabancı anahtarın referans gösterdiği tablo vb. bilgilere erişim sağlanmıştır.

Biraz daha detaya inilirse geliştirilen uygulama adımları şu şekildedir; I. Tabloların hepsi tek tek ele alınmıştır.

II. Aktif olarak çalışılan tabloya ait yabancı anahtar sayısına şema bilgilerinden ulaşılmıştır.

III. Yabancı anahtar sayısına göre üç ihtimal belirlenmiştir. Bu ihtimallerin detayları sonraki başlıklarda verilmiştir.

IV. Her üç ihtimalde de csv türünde dosya öncelikle oluşturulmaktadır. Kullanılan ihtimale göre dosya adı belirlenmektedir.

V. İhtimal 1 ve ihtimal 2’de yabancı anahtar bulunduğundan denormalizasyon işlemi yapılmıştır. Ardından veriler daha önce oluşturulan csv türünde ki dosyalara kaydedilmiştir.

VI. İhtimal 3’te yabancı anahtar olmadığından tabloda ki veriler olduğu gibi csv türündeki dosyaya kaydedilmiştir.

Yukarıda ki adımlar neticesinde oluşan veri ile dolu csv türündeki dosyalar veri göçü istenen Nosql veritabanına eklenmektedir. Ekleme işlemi nosql veritabanının çeşidine göre değişmektedir. Örnek olarak MongoDb’ye eklemek için MongoDb Compass adındaki grafik arayüzü kullanılabilmektedir.

3.4.1. 1. İhtimal

Tablonun yabancı anahtar sayısı iki ve üstünde ise 1. İhtimale ait komutlar çalışmaktadır. Şekil 3.4’te görülen üç tablo 1. İhtimalde uygulanan yöntemin anlaşılması için verilmiştir.

Şekil 3.4. İhtimal-1 için örnek tablolar.

Y tablosu iki yabancı anahtara sahiptir. Y tablosu 1. İhtimaldeki komutlar çalıştığında denormalize edilerek Çizelge 3.1’de bulunan alanlara sahip bir csv dosyası oluşturulacak ve veriler bu sıra ile kaydedilecektir.

Çizelge 3.1. Birinci ihtimal Csv dosya bilgileri.

Y Tablosuna ait

alanlar X tablosuna ait alanlar Z tablosuna ait alanlar CSV dosyasını ilk

satırı Y_PK,Y1,Y2,Y4, X_PK,X1,X2,X3,X4, Z_PK,Z1,Z2,Z3,Z4

Csv dosya adı Y_ X_ Z

Çizelge 3.1 yardımıyla veri göçü aracının ürettiği csv dosyasının anlaşılabilmesi için bilinmesi gerekenler;

 Csv dosyasının ilk satırında tabloların alan adlarına ait bilgiler bulunmaktadır. Şekil 3.4’te gösterilen üç tablo için öncelikle Y tablosunun alanları gelmektedir. Bu üzerinde çalışılan tablo olduğundan ilk onun alanları getirilmiştir. Alan adı tekrarı olmaması için yabancı anahtar olan alanlar çıkartılmıştır. Bu alanlar aynı zamanda X ve Z tablolarının birincil anahtarlarıdır. Diğer tabloların sırası önemsenmemiştir. X ve Z tablolarından hangisinin önce geldiği önemli değildir.  Csv dosyası veri göçü aracı tarafından oluşturulmaktadır. Adını da veri göçü

aracı belirlemektedir. Dosya adında öncelikle üzerinde çalışılan tablo adı gelmektedir. Örneğimizde Y tablosu üzerinde çalışıldığı için dosya adı Y ile başlamaktadır. Ardından gelen her tablo adından önce alt tire ( _ ) konmaktadır.

3.4.2. 2. İhtimal

Tablonun yabancı anahtar sayısı bir ise 2. İhtimale ait komutlar çalışmaktadır.

Şekil 3.5’te görülen iki tablo 2. İhtimalde uygulanan yöntemin anlaşılması için verilmiştir. Y tablosu bir tane yabancı anahtara sahiptir. Y tablosu 2. İhtimaldeki komutlar çalıştığında denormalize edilerek aşağıdaki alanlara sahip bir csv dosyası oluşturulacak ve veriler bu sıra ile kaydedilecektir

Şekil 3.5. İhtimal 2 için örnek tablolar.

1. İhtimalde anlatıldığı gibi alan adları csv dosyasına sırasıyla kaydedilmiştir. Üzerinde aktif olarak çalışılan tablo Y tablosu olduğu için alan adlarının csv dosyaya yazımında öncelik Y tablosunun alan adlarının olmuştur. Dosya adı belirlenirken de öncelikle Y tablosunun adı ardından X tablosunun adı gelerek dosya adı Y_X olarak belirlenmiştir. Çizelge 3.2’de 2. İhtimal Csv dosya bilgileri görülmektedir.

Çizelge 3.2. İkinci ihtimal csv dosya bilgileri.

Y Tablosuna ait alanlar X tablosuna ait alanlar CSV dosyasını

ilk satırı Y_PK,Y1,Y2,Y4,Y5, X_PK,X1,X2,X3,X4, Csv dosya

adı Y_ X

3.4.3. 3. İhtimal

Tablonun yabancı anahtarı yok ise 3. İhtimale ait komutlar çalışmaktadır.

Şekil 3.5’te görülen iki tablodan X Tablosu üzerinde çalışırken 3. İhtimale ait komutlar çalışır. X tablosu için denormalizasyon yapacak yabancı anahtar olmadığından böyle bir işlem uygulanmaz. Tablo alan adları ve veriler aynen tablonun aslında olduğu gibi csv türündeki dosyaya kaydedilir. Csv dosya X olarak adlandırılır.

3.4.4. Özyineleme (Recursion) Kullanımı

1 ve 2. İhtimallerde yabancı anahtar bulunan tabloların referans gösterdiği tablolarda da yabancı anahtarlar bulunursa özyinelemeli olarak yazılmış fonksiyonlar devreye girmektedir. Veri göçü aracı hiçbir yabancı anahtar kalmayana kadar devam etmektedir.

3.5. VERİ GÖÇÜ ARACI SINIRLILIKLARI

Veri göçü aracının çalışması esnasında SQL tablolarında bulunan binary resim dosyalarının kaydedildiği alanlar da Python tarafından csv dosyaya aktarılmıştır. Fakat bunların MongoDb veritabanına eklenmesinde sorun oluşmuştur. Bundan dolayı test veritabanından bu alanlar silinmiştir. Veri göçü aracında kaynak SQL veritabanlarında bulunan tablolarda binary olarak depolanmış resim dosyası tutan alanların olmadığı kabul edilmiştir.

4.

TEST İŞLEMİ

Veri Göçü Aracı test işlemi için Microsoft tarafından sağlanan Northwind veritabanı kullanılmıştır. Şekil 4.1’de Northwind veritabanı görülmektedir.

Northwind veritabanı ücretsiz, içerisi veri ile dolu veritabanıdır. Birçok tablo ilişkisine sahip olduğundan veri göçü aracı için iyi bir test veritabanı olmuştur.

3. Bölümde detayları anlatılan veri göçü aracı Northwind veritabanı kaynak gösterilerek çalıştırılmıştır. Sonuç olarak csv uzantılı dosyalar elde edilmiştir.

Test esnasında Northwind veritabanı Microsoft Sql Server 2012 içerisine eklenmiştir. Default olarak Sql Server 2012 içerisinde bulunmamaktadır. Şekil 4.2’de Sql Server 2012 içerisinde Northwind veritabanı tablolarla beraber görülmektedir.

Şekil 4.2. Sql Server 2012’de Northwind veritabanı ekran görüntüsü.

Python programlama dili ile kodlamada IDE olarak Jet Brains firmasına ait PyCharm Community Edition kullanılmıştır. Şekil 4.3’te verilen ekran görüntüleri bu IDE’ye aittir.

Veri göçü aracı geliştirilirken kritik öneme sahip bazı hususlar;

i. Veri göçü aracının geliştirilmesi esnasında Şekil 4.3’te verilmiş olan tablo bilgileri sürekli olarak kullanılmıştır. Yazılımın çekirdeği niteliğinde bilgileri içermektedir. Sırasıyla kısıtlama türü (constraint type), kısıtlamanın ana tablosu (parent table name), kısıtlamanın uygulandığı alan (parent column name), kısıtlamanın uygulandığı alanın veri tipi (parent column name data type), ilişkilendirildiği referans tablonun adı (reference table name), ilişkilendirilen referans tablodaki referans alan adı (reference column name) bulunmaktadır.

Şekil 4.3. Tablolara ait şema bilgilerinin ekran görüntüsü.

ii. Northwind veritabanında bazı tablolarda binary olarak resim dosyaları bulunmaktadır. Bu dosyaların bulunduğu alanlar tablolardan silinerek resim dosyalarının olmadığı bir veritabanı üzerinde test işlemi yapılmıştır. Binary haldeki resim dosyaları csv dosyaya dönüştürülüp nosql veritabanına eklendiğinde istenen sonucu vermediğinden yok kabul edilmiştir.

iii. csv dosyalarda aynı verilerin tekrarı söz konusu olabilir. Örneğin Şekil 4.4’te görüldüğü gibi Categories tablosu yabancı anahtara sahip olmadığından tek başına Categories adında bir csv dosyaya verileriyle kaydedilmiştir. Aynı zamanda Products tablosundan referans olarak gösterildiğinden Categories tablosundaki Products tablosuyla ilişkili satırlar aynen Products tablosunda da yer alacaktır. Veri göçü esnasında ve Nosql veritabanlarında veri tekrarı göz ardı edilebilir bir durumdur.

4.1. MONGODB’YE CSV TÜRÜNDEKİ DOSYALARIN MONGODB COMPASS İLE EKLENMESİ

MongoDb’ye csv ve json türündeki dosyaların eklenmesi oldukça kolaydır. MongoDb’ye ait MongoDb Compass adındaki grafik arayüzü bu işi son derece kolay hale getirmiştir.

Adım adım csv dosyaları MongoDb’ye ekleme şöyle gerçekleştirilmiştir:

 MongoDb Compass bağlantı adımlarından sonra CREATE DATABASE tıklanarak bir veritabanı oluşturulur. Test için Northwind adında veritabanı oluşturulmuştur.

 Oluşturulan veritabanı içerisine girilerek ilişkisel veritabanlarında ki tabloların MongoDb’deki karşılığı olan COLLECTION’lar oluşturulur. Örneğin Şekil 4.5’te görüldüğü gibi Categories csv dosyası için Categories collection’u oluşturulmuştur.

Şekil 4.5. MongoDb Compass koleksiyonu oluşturma.

 Oluşturulan Categories collection’u içerisine girilip Şekil 4.6’da görüldüğü gibi Collection menüsünden Import Data komutu verilir.

Şekil 4.6. MongoDb Compass Import Data.

 Gelen ekrandan CSV seçilerek eklenecek dosyanın yolu seçilir. Son durumda Şekil 4.7’teki ekran elde edilir.

Şekil 4.7. MongoDb Compass csv dosyası ekleme.

Şekil 4.8. MongoDb Compass verilerin eklenmiş hali.

Bu adımlar csv dosyalarının hepsi ya da ihtiyaç duyulan kadarı için tekrar edilir. Veri göçü aracı tüm tabloları csv dosyalara dönüştürmektedir. Hangilerinin Nosql veritabanlarına eklenip kullanılacağına veritabanı yönetimi işini yapan kişi ya da kişiler karar verecektir.

4.2. MONGODB’YE CSV DOSYALARIN KOMUTLARLA EKLENMESİ

Linux işletim sistemleri için aşağıdaki adımlar takip edilerek mongodb’ye csv dosyalar import edilebilir. MongoDB örneğinin (MongoDB Instance) localhost, veritabanının users, port numarasının 27017, eklenecek csv dosya adının contacts olduğu kabul edilen import işlemi komutları:

mongoimport --db users --collection contacts --type csv --headerline --file /opt/backups/contacts.csv

Burada headerline ilk satırda alan adlarının kullanıldığını göstermektedir.

4.3. MONGODB VE SQL SERVER ARASINDA VERİTABANI BOYUTU

KIYASI

Nortwind veritabanının dosya boyutu görüntülendiğinde Şekil 4.9’da 6,06 MB olduğu görülmektedir.

Şekil 4.9. Northwind veritabanın sql server’da boyut görünümü.

Mongodb Northwind veritabanı dosya boyutu ise MongoDB Atlas üzerinden görüntülenmiştir. Şekil 4.10’da görüldüğü gibi toplam boyut 5,22 MB’dır.

Şekil 4.10 MongoDB veritabanında Northwind dosya boyutu ekranı.

Northwind veritabanının her iki veritabanında ki boyutları birbirine yakın gibi görülebilir. Fakat şunu unutmamak gerektir ki mongoDB üzerindeki Northwind veritabanında tablolara denormalizasyon işlemi uygulanmıştır. Denormalizasyon işlemi sonucu birçok veri tekrarı oluşmuş, alan sayıları çok fazlalaşmıştır. Buna rağmen mongoDB dosya boyutu Sql Server dosya boyutundan düşüktür. MongoDB’nin barındırdığı sıkıştırma algoritmalarının artısı bu testte görülmektedir.