=Paper=
{{Paper
|id=Vol-1483/72_Bildiri
|storemode=property
|title=İlişkisel Veri Tabanı Sistemlerinde İşlem Yönetimi ve Büyük Verinin Saklanması
|pdfUrl=https://ceur-ws.org/Vol-1483/72_Bildiri.pdf
|volume=Vol-1483
|dblpUrl=https://dblp.org/rec/conf/uyms/AydoganDKAHK15
}}
==İlişkisel Veri Tabanı Sistemlerinde İşlem Yönetimi ve Büyük Verinin Saklanması==
https://ceur-ws.org/Vol-1483/72_Bildiri.pdf
li³kisel Veri Taban Sistemlerinde Çoklu Oturum
ve ³lem Yönetimi
NoSQL Veri Taban Sistemlerinde Büyük Verinin
Saklanmas
12 12 2
S. Said Aydo§an , Esat E. Demirel , Utku Ketenci , Mehmet S.
1 2 1
Aktas ,Ihsan Helvacioglu , Oya Kalipsiz
1
Bilgisayar Mühendisli§i Bölümü, Elektrik-Elektronik Fakültesi Yldz Teknik
Üniversitesi, stanbul
2
Ar-Ge Merkezi, Cybersoft, stanbul ?
utku.ketenci@cs.com.tr
Kurumlar tarafndan barndrlan veri ve bu verilere eri³im skl§ gittikçe art-
maktadr. Artan veri boyutuyla analiz i³lemleri de karma³k hale gelmektedir.
Günümüzde birden çok veri taban ayn amaca yönelik i³lemlerde beraber kul-
lanlabilmektedir. Veri tabanlarnn ortak kullanmlarnda ba§lant problemleri,
hangi tablonun hangi veri tabanndan geldi§inin bilinememesi, i³leme (commit)
ve geri alma (rollback) mekanizmalarnn yeterli düzeyde sa§lanamamas gibi
sorunlar meydana çkabilmektedir. Bu çal³ma, birden çok veri tabannn bulun-
du§u sistemlerde bahsedilen problemlere bir çözüm sunmaktadr. Bu çözümle
birlikte geni³ ölçekte kullanlan Oracle, MySQL, MSSQL, DB2 ve Sybase gibi
veri tabanlar için ortak bir eri³im katman olu³turulmaktadr. Bununla birlikte,
birden çok veri tabanndan elde edilen büyük hacimli verinin muhafaza edil-
mesi ve analiz i³lemlerinde kullanlabilmesi için kolon tabanl büyük veri i³leme
platformlar da kullanlmaktadr. Bu platformlardan yaygn olarak kullanlan,
açk-kaynakl, HBase ve Hadoop mimarileri, büyük verinin muhafazas ve is-
tenildi§inde eri³ilmesi amaçlaryla kullanlm³tr. Gerçekle³tirilen araçla farkl
ili³kisel veri taban sistemleri ile i³lemlerin (transaction) sorunsuz bir ³ekilde
yönetilebilmesi ve bu veri tabanlarndan alnan verinin büyük veri i³leme plat-
formuna ta³nmas sa§lanabilmi³tir. Geli³tirilen çözümün kullanlabilirli§ini ve
performansn ortaya koymak adna, i³levsel ve ba³arm testleri gerçekle³tirilmi³
ve olumlu sonuçlar elde edilmi³tir.
Anahtar Kelimeler: Veri Taban Sistemleri, ³lem Yönetimi, Büyük Veri Plat-
formlar, Da§tk Sistemler
?
Bu çal³ma Yldz Teknik Üniversitesi Yazlm Kalite Ara³trma Grubu ve Cybersoft
rmas Ar-Ge birimlerinin i³birli§i çerçevesinde gerçekle³tirilmi³tir. Yazarlar, Cyber-
soft rmasna sa§lanan çal³ma ortam için; Cybersoft Ar-Ge Müdürü Umut Orçun
Turgut'a ve Cybersoft çal³anlarndan e k Temel'e de katklar için te³ekkür etmek-
tedir. Bu çal³ma ayn zamanda, Yldz Teknik Üniversitesi BAP Projesi (Proje No:
2013-04-01-KAP03) kapsamnda gerçekle³tirilmi³tir.
691
1 Giri³
Gün içinde insanlar tarafndan gerçekle³tirilen pek çok i³lem, çe³itli veri taban
sistemleri aracl§yla, farkl tipteki veri kaynaklarna kaydedilmektedir. Bu du-
rum, sürekli artan ve farkl tipteki veri taban sistemlerinde bulunan verinin
yönetimi ve birle³tirilmesi için, bir ihtiyaç olarak ortaya çkmaktadr. Kayde-
dilen bu veriler ile yaplacak raporlama ve analiz çal³malarnda kullanlmak
üzere, bütün bu veritaban sistemleri ile tek bir noktadan ileti³ime geçebilecek
bir altyap kurulabilmektedir. Bu noktadaki zorluklar her sistemin kendine has
bir altyapya sahip olmas ve bu sistemler ile ileti³im kurma metotlarnn farkl
olmasdr. Veri tabanlarnn ortak kullanmlarnda ba§lant problemleri, hangi
tablonun hangi veri tabanndan geldi§inin bilinememesi, i³leme (commit) ve geri
alma (rollback) mekanizmalarnn yeterli düzeyde sa§lanamamas gibi sorunlar
meydana çkabilmektedir. Bu çal³mann amaçlarndan biri, birden çok veri ta-
bannn bulundu§u sistemlerde bahsedilen problemlere bir çözüm sunmaktadr.
Bu çözümle birlikte geni³ ölçekte kullanlan Oracle, MySQL, MSSQL, DB2 ve
Sybase gibi veri tabanlar için ortak bir eri³im katman olu³turulmaktadr.
Birden çok veri kayna§na sahip bu sistemlerde, veri kayna§ndan gelen ve-
rilerin i³lenerek kullan³l bilgiye çevrilmesi gerekmektedir. Yüksek hacimli bu
veriler i³lenmek istendi§inde da§tk çal³abilen NoSQL veri tabanlarnda mu-
hafaza edilebilirler. Google, ili³kisel veri taban yönetim sistemlerinin büyük
verileri mevcut dosya sisteminde kontrol etme ve verileri efektif kullanma ko-
nusundaki sorunuyla yüzle³mi³tir. Bunun neticesinde geli³tirdikleri Google File
System (GFS) [6], BigTable, Map/Reduce paralel i³leme platformu ile sorunlara
en efektif çözümleri bulurken Apache Hadoop ve Apache HBase projelerine ilham
kayna§ olmu³lardr. Hadoop, Map/Reduce i³lem özelli§i olan Hadoop Distribu-
ted File System (HDFS) üzerine kurulmu³ paralel programlama platformudur
[9]. HBase ise HDFS üzerinde çal³an bir veri yönetim sistemidir [5]. Çal³mann
bir di§er amac da, HBase NoSQL veri taban kullanlarak, farkl ili³kisel veri
tabanlarnda bulunan bilgilerin tek bir kaynakta depolanmasn sa§lamaktr.
Bu bildiride; birden çok veri taban i³letim sistemi aracl§ ile kayt edilmi³
verilerin okunarak i³lenmeye hazr hale getirilmesi, farkl veri taban sistemlerin-
den gelebilecek i³lemsel istisnalarn (transactional exception) Spring Framework
kullanlarak gerçekle³tirilen i³lem yöneticisi (transaction manager) aracl§ ile
yönetiminin yaplmas ve analizi yaplan verinin da§tk olarak çal³an sunucu-
larda bulunan Hadoop da§tk dosyalama sistemine ve HBase veri taban siste-
mine ta³nmasnn deneyimlerinin sonuçlar payla³lmaktadr. Bu bildirinin geri
kalannda srasyla; testlerde kullanlan ili³kisel ve ili³kisel olmayan veri tabanlar
ve NoSQL hakknda genel bilgiler verilecektir; bir sonraki a³amada, genel sistem
mimarisi anlatlacaktr; en son bölümde de testler ve sonuçlar payla³lacaktr.
2 li³kisel ve NoSQL Veri Tabanlar
li³kisel veri taban sistemleri 1960'l yllarda General Electric laboratuvarlarnda
ortaya çkm³tr [1]. Bu tarihten önce veriler dosya yaps içerisinde saklanrken,
692
ortaya çkan bu yeni yap ile dosyalar yerlerini ili³kisel veri taban tablolarna
brakm³lardr. Artan veri büyüklü§ü ile ili³kisel veri tabanlar ile çal³mann zor-
luklarnn belirgin bir ³ekilde ortaya çkmaya ba³lad§ 2010 ba³larnda NoSQL
veri tabanlar popülerlik kazanmaya ba³lam³tr. li³kisel veri taban sistemlerine
göre yüksek ölçeklenebilirlik, kümeleme, veri e³leyebilme, veri modelinin sabit ol-
mamas ve karma³k sorgulara kar³t olma gibi özellikleri ile [7][8] NoSQL veri
taban sistemleri farkllk yaratmaktadr.
li³kisel veri tabanlar ACID (Atomik Atomicity, Tutarllk Consistency,
Yaltm Isolation, Süreklilik - Durability) ³artlarnn hepsini sa§larken, No-
SQL veri tabanlar bu ³artlar tamamen sa§lamamaktadr. Bunun yerine da§tk
sistemdeki herhangi bir küme elemannda sorun oldu§unda çal³maya devam
edebilmesi ve verinin bütünlü§ünü koruyabilmesi ³artlarn en ön srada tutmak-
tadrlar. li³kisel veri tabanlarnn aksine NoSQL veri tabanlarnda, verilere tekil
anahtar üzerinden eri³ilmekte, fakat verilere eri³im SQL yapsndaki kadar ko-
lay olmamaktadr. Bu bildiri hazrlanrken popüler olarak kullanlan ili³kisel veri
taban sistemleri ve HBase NoSQL veri taban sistemi incelenmi³tir.
li³kisel veritabanlar arasnda, Oracle, yaygn kullanlan, popüler bir veri ta-
ban yönetim sistemidir [2][4]. Birden çok programlama dili deste§i mevcuttur
[3]. MySQL ise dünya çapnda en çok kullanlan açk kaynak kodlu veri taban yö-
netim sistemidir. MySQL ile kurumsal ve kurumsal olmayan binlerce uygulama
geli³tirilmi³tir. Ayrca Windows ve Unix/Linux i³letim sistemlerini desteklemek-
tedir [3]. Microsoft SQL Server, Windows i³letim sistemine sahip bilgisayarlar
üzerinde çal³abilen modern ve popüler veri taban sistemlerindendir. Yaygn
kullanm özellikle .NET uygulamalar ile olmaktadr. DB2, IBM tarafndan;
Sybase, SAP tarafndan geli³tirilen popüler veri taban sistemlerindendir.
HBase, kolon temelli NoSQL veri taban olarak sn andrlr. Kolon ailesi
(column family) yaps ile ayn satra (row) ait farkl kolon aileleri olu³turularak
verilere eri³imin hzlandrlmas mümkündür. Bir kolon ailesindeki veriye eri³im,
ba³ka bir kolon ailesindeki veriye eri³imi performans anlamnda etkilememek-
tedir. Ba³ka bir deyi³le kolon temelli yap veri aktarm esnasnda satrn ta-
mamen kilitlenmesine sebep olmamaktadr. Kolon temelli veri tabanlar d³nda
Anahtar-De§er (Key-Value), doküman temelli ve çizge temelli gibi NoSQL veri
taban tipleri de bulunmaktadr. HBase di§er NoSQL veri taban sistemlerinden,
HDFS alt yapsn kullanmas ile fark yaratmaktadr. Kendine ait ve tam perfor-
mansla çal³abilece§i da§tk bir dosyalama sisteminin varl§ HBase'i elastik ve
ölçeklenebilir klmaktadr. Bununla birlikte, rastlantsal okuma ve yazma konu-
sunda etkili olmas HBase'in di§er NoSQL veri taban sistemlerine göre avantaj
sa§lad§ ba³ka bir noktadr. Facebook Messages'n da tercih etti§i ve yaptklar
testlerde en iyi sonuçlar veren veri taban sistemi NoSQL olmu³tur [8].
3 Sistem Mimarisi
Gerçekle³tirilen çal³ma esnasnda, farkl veri tabanlarna ba§lanmak için Sp-
ring Çats (Framework) ve MyBatis Sürerlik Çats (Persistence Framework)
kullanlm³tr. Genel sistem mimarisi ekil 1'de gösterilmektedir.
693
Spring, bir uygulamann gerçekle³tirilmesi esnasnda gerekecek birçok mo-
dülü içinde barndran bir uygulama çatsdr. Bu çal³mada Spring'in i³lem yö-
neticisi (Transaction Manager) modülüne yer verilmi³tir.
ekil 1: Genel Sistem Tasarm .
MyBatis Sürerlik Çats, ili³ki nesne modellerinden (ORM) farkl olarak sakl
yordamlarn (stored procedure) nesne olarak Java ortamnda tutulmasna veya
SQL cümlelerinin birer Java metotu olarak kullanlmasna olanak vermektedir.
MyBatis, kullanld§ projelerde, genel olarak, tek bir veri taban kaynak olarak
kullanlmaktadr.
Spring Application-Context modülü i³lem yöneticisini barndrmaktadr. My-
Batis modülü, e³leyicileri (mapper) tutmaktadr ve SQL ifadeleri aracl§ ile
veri tabanndaki verinin çekilmesini sa§lamaktadr. ³lem yöneticisi SQL cümle-
ciklerinin çal³trlmas esnasnda do§abilecek istisnalar do§rultusunda i³lemleri
(Commit ve Rollback) yönetmektedir
Çal³ma prensibi a³a§da maddeler halinde verilmektedir:
1. Kullanlacak veri taban sisteminin bilgileri (ör: Veri taban tipi, IP de§eri ,
port, uid, parola, vb.) ile SqlSessionFactory (MyBatis snf) olu³turulmak-
tadr.
2. MyBatis'te veri taban i³lemleri (ör: create, update, insert, vb.) servisler
aracl§ ile gerçekle³tirilmektedir. Bu servisler veri taban yapsndaki tablo
modellerine uygun ³ekilde çal³maktadrlar. Servislerle modeller arasndaki
etkile³im e³leyiciler (mapper) aracl§ ile sa§lanmaktadr. Servislerin çal³a-
bilmesi için bir önceki a³amada yaratlan SqlSessionFactory kullanlarak veri
taban oturumu olu³turulmaktadr.
694
3. Bu a³amada istemci, e³leyicilerde tanmlanan fonksiyonlar aracl§yla veri
tabanndaki modele eri³imini sa§layabilmektedir.
4. Veri tabannda istenilen de§i³iklik veya görüntüleme yapldktan sonra, is-
temci tarafndaki veri taban oturumu yine istemci tarafndan kapatlmak-
tadr.
Bu çal³mann hede edi§i gereksinimlerinden biri olan farkl veri tabanlarna
ba§lanma ve i³lem yönetimi Bölüm 3.1'de, verilerin HBase'e aktarm ve eri³imi
Bölüm 3.2'de anlatlmaktadr.
3.1 Farkl li³kisel Veri Taban Sistemlerine Ba§lanabilme ve
³lemlerin Yönetilmesi
Bu projede Oracle, MSSQL, MySQL, Sybase ve DB2 veri taban sistemlerinin
hepsi birden veri kayna§ olarak kullanmak istenmektedir. Bunun bir sonucu ola-
rak yukarda anlatlan MyBatis çal³ma prensibi Spring'in özellikleri kullanlarak
geli³tirilmi³tir. MyBatis-Spring Kütüphanesi aracl§ ile Spring'in MyBatis ile
entegrasyonu gerçekle³tirilmi³tir (Bknz. ekil 2). Entegrasyonun sonucunda or-
taya çkan yap ³u ³ekilde çal³maktadr:
1. Spring, Application-Context Container modülü içinde servis yönetimini ger-
çekle³tirir. Bu modül içerisindeki i³levsel nesnelerden biri olan Datasource
Bean, proje kapsamnda kullanlacak farkl veri taban sistemlerine ait bil-
gilere eri³imi sa§lamaktadr (XML, Veri taban, Metin Belgesi veya Hard
coded ³ekilde verilmi³ olan). Datasource Bean, bu bilgileri kullanarak, i³-
lem yaplacak veri taban sisteminde ba§lant (connection) açmaktadr.
2. Bir di§er i³levsel nesne olan SqlSession Bean, Datasource Bean 'in olu³-
turdu§u ba§lanty kullanarak veri taban oturumunu açmaktadr.
3. Veri taban üzerindeki i³lemleri gerçekle³tirmek amacyla kullanlan MyBatis
servisleri birer Bean nesnesi olarak Container içerisinde yazlmc tarafn-
dan tanmlanmaktadr. Bu servisler olu³turulurken bir önceki admda yara-
tlan SqlSession enjekte edilmektedir. Ba§mllk enjeksiyonu (Dependency
Injection) diye de adlandrlan bu yap sayesinde enjekte edilen oturum bil-
gisine göre servis, farkl veri taban sistemi ile etkile³ebilmektedir.
4. Aktif olan veri tabannda i³lem yaptktan sonra ba³ka bir veri tabanyla etki-
le³ime geçilmek istenebilir. Bu durumda, Datasource Bean 'inin kulland§
aktif veri taban bilgileri bu veri tabannn bilgileri ile de§i³tirilir. Bu de§i-
³im bir metot ya da arayüzden gelen bir istek ile gerçekle³tirilebilir. De§i³im
tamamlandktan sonra Container yenilenir. Servisler yeni oturum bilgileri ile
güncellenir ve etkile³ime hazr hale getirilir.
Farkl veri tabanlarna ba§lant ve sorgulama amac ile kurulan sistem a³a-
§daki srada i³lemleri gerçekle³tirmektedir.
1. Veri taban de§i³ikli§i istemi gönderilir.
2. Ba§lanlacak veri tabanna ait bilgiler Spring ApplicationContext Conta-
iner'a iletilir.
695
3. Ba§lant Açlr.
4. SqlSession Bean ba§lanty sa§lar.
5. Veri tabannda oturum açlr.
6. Oturum Service Bean 'e enjekte edilir.
7. Veri tabanndaki i³lemi gerçekle³tirilecek servis ça§rlr.
8. Servis, Mapper'n gerekli metodunu ça§rr.
9. Mapper ça§rlan metota uygun SQL cümleci§ini bulur.
10. Ba³langçta karar verilmi³ olan veri taban ile etkile³ime geçerek SQL cüm-
leci§i ko³turulur.
11. Sorgu sonucu Service Bean 'e ula³trlr.
12. Kullanc tarafna servis ça§rsnn cevab ula³trlr.
ekil 2: Çoklu Veri taban Eri³imi
Farkl veri tabanlar ile çal³rken kar³la³lan bir sknt da istisnalarn (excep-
tion) yönetimidir. Bu noktada da Spring Framework'ün sa§lad§ i³lem yönetimi
(Transaction Management) modülü kullanlmaktadr. Servislerin içerisindeki me-
totlardan i³lemsel olanlar (Transactional notasyonuna sahip olanlar) istisna ile
kar³la³lan durumlarda geri alma (Rollback) yapabilme özelli§ine sahip olurlar.
Detayl anlatm örnek üzerinde Bölüm 4.1.'de yaplacaktr.
Veri tabanlar üzerinde kullanc tarafndan yaratlacak olan sorgular için ilgili
³emada hangi tablolarn bulundu§u bilgisine ihtiyaç duyulmaktadr. Her veri
696
tabannn farkl bir yapya sahip olmasndan dolay bu tablolar listeleyebilmek
probleme neden olmaktadr. Projede bu probleme çözüm için Java'nn veri taban
tablo isim listesi, view isim listesi gibi meta data bilgilerini getiren java.sql paketi
içindeki DatabaseMetaData snf kullanlmaktadr. Bu snf birçok veri taban
tasarmcs kurulu³ ile ortak olu³turulmu³tur ve veri taban ile ilgili yapsal bütün
bilgileri bize sunabilmektedir.
3.2 Büyük Veri Taban Sistemlerine Veri Aktarm
HBase, Hadoop ile en verimli ³ekilde çal³maktadr. Hadoop'un da§tk mima-
risi HBase'in performans ve sa§lamlk açsndan optimum düzeyde çal³masn
sa§lamaktadr. Bu sebepten çal³mamzda ilk a³ama olarak Hadoop kurulumu
gerçekle³mi³tir.
Bu a³amada Hadoop'un kurulacak olan versiyonunu seçerken, çal³lmaya
karar verilmi³ olan HBase versiyonu ile uyumlulu§una dikkat edilmi³tir. Ger-
çekle³tirilen çal³mada HBase 0.98.9-Hadoop2 versiyonu ve buna uyumlu olan
Hadoop 2.5.2 kurulmu³tur. Kurulumumuzda 3 tane i³çi (slave) ve 1 tane üstat
(master) dü§ümleri bulunmaktadr. Kurulum srasnda, makinalar Centos 6.5
i³letim sistemine sahiptir.
Bu makinalar hepsinin üstüne Hadoop kurulumu gerçekle³tirilirken i³letim
sistemine ve Hadoop'a ait hosts, core-site.xml ve hdfs-site.xml dosyalar üze-
rinde ayarlarn yaplmas gerekmektedir. Bu dosyalar Hadoop'un temel 3 süreci
(process) olan Namenode (veri a§ac yapsn saklar cluster içinde hangi verinin
nerede tutuldu§unun kaydn barndrr), Datanode (verileri saklar) ve Secon-
daryNamenode'un (Namenode'un yede§idir) çal³masnda temel olmaktadr. Bir
master makinada Namenode tutulurken i³çi makinalarda Datanode çal³makta-
dr.
SecondaryNamenode, Namenode'dan ba³ka bir makinada tutulmaktadr. Bu
sayede Namenode'un çökmesi durumunda SecondaryNamenode'daki bilgiler kul-
lanlarak sistem aya§a kaldrlabilir. Hosts, core-site.xml ve hdfs-site.xml
dosyalar master ve slave makinalarn her biri için ayarlanmaldr.
Hadoop kurulumu ve kon gürasyonu tamamlandktan sonra HBase kurulumu
gerçekle³tirilir. HBase'in temel süreçleri HMaster (Namenode'un ko³turuldu§u
makinada ko³turulur metadatalar saklar.), HRegionServer (Datanode'larn ça-
l³trld§ makinalarda çal³trlr, verilerin tablo yaps altnda saklanmasn sa§-
lar.) ve HQuorumPeer (Hmaster ve Hregionserverlar arasnda bilgi al³veri³inin
yaplmasn sa§lar. stemci tarafndan gelen istekleri yönetir.)'dir.
HBase kurulurken hbase-site.xml kon güre edilmektedir. HDFS'nin yor-
dam (HDFS Path) burada belirtilmektedir. Yaplan kon gürasyon HBase'in
tablolarn HDFS yaps altnda tutmasn sa§lamaktadr. Ayrca, Hadoop'un ça-
l³ma moduna göre (Fully Distributed, Pseudo Distributed, Single Node) HBase'in
çal³ma modu bu dosyada belirlenmektedir. Bu çal³mada single node (tek ma-
kina) ve fully distributed (tamamen da§tk) modlar testlerde kullanlmaktadr.
HBase'in tablo yaps kolon aileleri (Column Family) içermektedir. Ayrca,
veriyi baytlar halinde tuttu§undan dolay kayt edilen verinin baytlara çeviri-
lerek kayt edilmesi gerekmektedir. JSON kaydedilecek verinin snf yapsnda
697
baytlara çevrilerek kaydedilmesini sa§lamaktadr. Yaplacak testlerde kolon aile-
leri kullanlarak veri kayt edilmesi ve verinin JSON objesine çevrilerek kayt
edilmesi ayr ayr incelenmektedir. Bir sonraki bölümde gerçekle³tirilen testler
incelenecek ve sonuçlar payla³lacaktr.
4 Gerçekle³tirilen Testler ve Sonuçlar
Sistem gereksinimleri dahilinde 5 farkl veri taban i³letim sistemine eri³im per-
formans testleri ve i³lem yöneticisi fonksiyonalite testleri gerçekle³tirilmi³tir.
Bunlarla birlikte HBase veri taban üzerinde büyük veri yazma ve okuma testleri
yaplm³tr. Bölüm 4.1'de ili³kisel veri tabanlar üzerinde yaplan testler, Bölüm
4.2'de HBase üzerinde gerçekle³tirilen testler detaylandrlacaktr.
4.1 Çoklu ili³kisel veri taban sistemlerine eri³im testleri
li³kisel veri taban sistemlerine eri³im testleri 3.4 GHz i7 i³lemciye, 8Gb RAM'e
sahip bir makina üzerinde gerçekle³tirilmi³tir. li³kisel veri tabanna yönelik
fonksiyonel testler olarak, ba§lant kontrolü ve i³lem yönetimi testleri gerçek-
le³tirilmi³tir. Ba§lant kontrolünde (ekil 2'de detaylandrlan), veri tabanlarna
ba§lant ve oturum açma kontrolü bahsi geçen tüm veri tabanlar için gerçek-
le³tirilmi³tir. Bu test srasnda veri tabanlarndan sadece veri getirme amacyla
kullanlan (select sorgular içeren) servisler ça§rlm³tr. Servis ça§rlarnn so-
nucunda her veri tabannn kendisine ait olan veriyi eksiksiz bir ³ekilde getirdi§i
görülmü³tür.
Farkl veri taban i³letim sistemlerinde bulunan, index içermeyen ve 8 ko-
lonluk varchar bilgi saklayan tablolardan 5000 satrn getirilmesi (select) ile
gerçekle³tirilen testlerin sonuçlar Tablo 1'de gösterilmektedir. MyBatis-Spring
kütüphanesi ile geli³tirilen ili³kisel veri taban eri³imi testlerinin sonuçlar Tablo
1'in ilk satrnda, JDBC ile gerçekle³tirilen testlerin sonuçlar tablonun ikinci sa-
trnda gösterilmektedir. Test sonuçlarna göre MyBatis-Spring kütüphanesi ile
olu³turulan sistemin sonuçlar JDBC ba§lantsna göre her veri taban için daha
iyi sonuçlar vermektedir.
Tablo 1: 5000 satrn okunmas (Saniye)
MySQL MSSQL ORACLE SYBASE DB2
JDBC 2,01 2,06 2,14 2,32 2,45
MyBatis-Spring 0,55 1,19 2,12 1,50 2,36
³lem yönetimi testinde, Cybersoft tarafndan kullanlan hatasz çal³mas
beklenen servisler kullanlmaktadr. Örne§in baz durumlarda, kullancnn web
uygulamas üzerinde oturum açp, i³ledi§i veriyi kaydetmek için ilgili servisi ça-
§rmas gerekmektedir. ekil 1'de gösterildi§i üzere Application Context içeri-
sinde bulunan ilgili servis, aktif olan veri taban oturumu kullanlarak çal³trlr.
698
Böylelikle, kayt i³lemlerini kendisine enjekte edilmi³ oturum üzerinden gerçek-
le³tirebilmektedir.
E§er metot i³lemselse yani @transactional notasyonuna sahip ise; Applica-
tion Context içerisinde yer alan i³lem yönetimi (transaction manager) aracl§yla
istisnalar yönetebilmektedir. Metot içerisinde istisna (exception) ortaya çkarsa
yaplan i³lemin geri alnmasn (rollback) ya da istisna olu³mam³sa metottan
dönüldü§ü srada i³lemin onaylanmasnn (commit) sa§lamas gerçekle³mekte-
dir. Bahsedilen örnek için kayt srasnda istisna çkaran durum ve çkarmayan
durum ayr ayr test edilmi³tir.
³lem yönetimi fonksiyonalite testleri sonucunda, istisna meydana geldi§inde
kaydetme i³leminin gerçekle³medi§i, istisna olmad§ durumda ise kullancnn
belirtti§i veri taban üzerinde kaytlarn olu³tu§u görülmü³tür.
³lem yönetiminin zamansal olarak yükünü gözlemlemek amacyla gerçekle³-
tirilen performans testleri sonucu Tablo 2'de sergilenmektedir. Ekleme i³leminde
kullanlan veri 8 kolonlu varchar içeren 1000 satrdan olu³maktadr. li³kisel veri
tabanlarna eklenmesi önceden yaratlm³ üzerinde index bulunmayan bir tablo
yaps kullanlarak gerçekle³tirilmi³tir. Tablo 2'de ilk satr @transactional no-
yasyonuna sahip, ikinci satr ise sahip olmayan metotlarn sonucunu göstermek-
tedir.
Görülece§i üzere i³lemsellik dü³ük seviyede fazla yük yaratmaktadr. Bununla
birlikte, sebep oldu§u küçük dezavantaja ra§men sistemi hataya kar³ daha sa§-
lam klan (commit ve rollback) mekanizmalar içerdi§inden ötürü kullanlmas
fayda sa§lamaktadr.
Tablo 2: 1000 satrn eklenmesi (Saniye)
MySQL MSSQL ORACLE SYBASE DB2
³lemsel 14 16 55 15 17
³lemsel de§il 10 13 54 10 14
4.2 HBase veri taban performans testleri
HBase ve Hadoop, tek makina ve tam da§tk ³ekilde Cybersoft'a ait sunucular
üzerinde gerçekle³tirilmi³tir. Tek makina tipindeki kurulum 2GB RAM, 3 GHz
tek çekirdek i³lemciye sahip bir sunucuda çal³trlm³tr. Tam da§tk modda,
master makina 2 GB Ram ve 3 GHz çift çekirde§e sahip iken, slave makinalar
her biri 1 gb RAM ve 3GHz tek çekirdek i³lemciye sahip 2 makina üzerinde
kurulmu³tur.
HBase yaps altnda verilerin eklenmesi ve okunmas zamansal etki aç-
sndan incelenmi³tir. A³a§da sonuçlar sunulan testler, UCI Yapay Ö§renme
Veri kayna§ndan (http://archive.ics.uci.edu/ml/datasets/Poker+Hand) çekilen
1025010 satr ve 11 kolon içeren veri kümesi ile gerçekle³tirilmi³tir.
699
Tablo 3'te tek makina ve tam da§tk kon gürasyonlar üzerinde sral (synch-
ronous) ve toplu (batch) veri ekleme sonuçlar gösterilmektedir. Toplu olarak veri
ekleme sonuçlar beklendi§i gibi daha iyi sonuç vermektedir (30 kat daha iyi).
Tam da§tk yaplandrmada ise toplu veri ekleme sonuçlar beklenildi§i gibi tek
makinadan daha iyi sonuç vermektedir.
Tablo 3: 1 milyon satrn eklenmesi (Saniye)
Senkron Toplu
Tek Makina 1865 66
Tam da§tk 2129 26
Tablo 4'te tek makina ve tam da§tk kon gürasyonlar üzerinde JSON'a çevi-
rilerek ve kolon ailelerine bölünerek veri ekleme sonuçlar gösterilmektedir. Snf
yapsna sahip JSON objeleri ile tek bir kolon ailesi üzerinden yaplan testlerin
çoklu kolon ailesi yaps ile gerçekle³tirilen testlere göre daha iyi sonuç verdi§i
saptanm³tr.
Tablo 4: 1 milyon satrn farkl yaplarda eklenmesi (Saniye)
JSON Kolon Ailesi
Tek Makina 37 111
Tam da§tk 25 97
Tablo 5'te tek makina ve tam da§tk yaplandrmalar üzerinde okuma i³lem-
lerinin sonuçlar gösterilmektedir. HBase yaps ile tek makina (3 GHz i³lemci ve
2 GB RAM) üzerinde yaplan testlerin sonucunda 1025010 satrn okunmas 44
saniye sürmü³tür. u ana kadar gerçekle³tirdi§imiz testlerde ili³kisel veri taban
sistemlerinden bu seviyede bir veri okumas gerçekle³tirilememi³tir (3.4 GHz i7
i³lemciye, 8Gb RAM'e sahip bir makina üzerinde). Basit bir hesapla 5000 satr-
lk verinin okunmas en iyi ihtimalle (MySQL) 0,55 sn sürdü§üne göre 1 milyon
satrlk verinin okunmas 0,55*200=110 sn sürecektir.
Tablo 5: 1 milyon satrn okunmas (Saniye)
Okuma
Tek Makina 44
Tam da§tk 45
700
Elde edilen sonuçlara dayal olarak, HBase' in 3 kat daha hzl veri döndü§ü
saptanm³tr. Veri okunmas ksmnda tam da§tk yaplandrmada verinin her
bir makinadan toplanarak getirilmesi söz konusu oldu§undan dolay tek makine
ve tam da§tk yaplandrma arasnda belirgin bir süre farkna rastlanmam³tr.
5 Sonuç ve Gelecekteki Çal³malar
Bu çal³ma kapsamnda, birden fazla veri tabannn ortak kullanmnn oldu§u
sistemlerde kar³la³lan problemlere bir çözüm geli³tirilmektedir. Bu problemler
arasnda, ba§lant problemleri, hangi tablonun hangi veri tabanndan geldi§inin
bilinememesi, i³leme ve geri alma mekanizmalarnn yeterli düzeyde sa§lanama-
mas yer almaktadr.
Önerilen çözüm, Oracle, MySQL, MSSQL, DB2 ve Sybase gibi veri taban-
lar için ortak bir eri³im katman olu³turmakta ve bu farkl veri tabanlarndan
elde edilen büyük hacimli verinin muhafaza edilmesi ve analiz i³lemlerinde kul-
lanlabilmesi için kolon tabanl büyük veri i³leme platformlarn kullanmaktadr.
Çözümün kullanlabilirli§i test etmek amacyla, 5 farkl veri tabanna eri³im
performans testleri ve i³lem yöneticisi fonksiyonalite testleri gerçekle³tirilmi³tir.
Bunlarla birlikte HBase veri taban üzerinde büyük veri yazma ve okuma test-
leri de yaplm³tr. Testler sonucunda elde edilen sonuçlar, önerilen yakla³mn,
i³lemsellik açsnda dü³ük seviyede ek yük yaratt§n göstermektedir. Bununla
birlikte, sebep oldu§u küçük dezavantaja ra§men sistemi hataya kar³ daha sa§-
lam klan commit ve rollback mekanizmalar sayesinde faydalar sa§lamaktadr.
Yine elde edilen, test sonuçlarna göre, çözümde kullanlan MyBatis ve Spring
kütüphaneleri ile olu³turulan sistemin sonuçlar JDBC ba§lantsna göre her veri
taban için daha iyi sonuçlar vermektedir. Toplu olarak veri ekleme sonuçlar ise
beklendi§i gibi daha iyi sonuç vermi³tir.
Gelecek çal³malar arasnda, önerdi§imiz çözümün daha farkl veri tabanlar
üzerinde test edilmesi ve daha kapsaml performans ve yük testlerinin yaplmas
yer almaktadr.
Kaynaklar
1. Database management systems. http://db-engines.com/en/systems, note= Ula³m:
09.01.2015, key= 0
2. Db-engines ranking. http://db-engines.com/en/ranking, note = Ula³m: 09.01.2015,
key= 1
3. Oracle system properties. http://db-engines.com/en/system/Oracle, note= Ula³m:
09.01.2015, key= 2
4. Alapati, S.R.: Expert Oracle Database 11G Administration. Apress, Berkely, CA,
USA, new edn. (2008)
5. George, L.: HBase: the de nitive guide. " O'Reilly Media, Inc." (2011)
6. Ghemawat, S., Gobio, H., Leung, S.T.: The google le system. In: ACM SIGOPS
operating systems review. vol. 37, pp. 2943. ACM (2003)
7. Leavitt, N.: Will nosql databases live up to their promise? Computer 43(2), 1214
(2010)
701
8. Muthukkaruppan, K.: Storage infrastructure behind facebook messages. Proceedings
of HPTS 11 (2011)
9. White, T.: Hadoop: The de nitive guide. " O'Reilly Media, Inc." (2012)
702