Kurumlar tarafndan barndrlan veri ve bu verilere eri‡im skl§ gittike artmaktadr. Artan veri boyutuyla analiz i‡lemleri de karma‡k hale gelmektedir. Gnmzde birden ok veri taban ayn amaca ynelik i‡lemlerde beraber kullanlabilmektedir. Veri tabanlarnn ortak kullanmlarnda ba§lant problemleri, hangi tablonun hangi veri tabanndan geldi§inin bilinememesi, i‡leme (commit) ve geri alma (rollback) mekanizmalarnn yeterli dzeyde sa§lanamamas gibi sorunlar meydana kabilmektedir. Bu al‡ma, birden ok veri tabannn bulundu§u sistemlerde bahsedilen problemlere bir zm sunmaktadr. Bu zmle birlikte geni‡ lekte kullanlan Oracle, MySQL, MSSQL, DB2 ve Sybase gibi veri tabanlar iin ortak bir eri‡im katman olu‡turulmaktadr. Bununla birlikte, birden ok veri tabanndan elde edilen byk hacimli verinin muhafaza edilmesi ve analiz i‡lemlerinde kullanlabilmesi iin kolon tabanl byk veri i‡leme platformlar da kullanlmaktadr. Bu platformlardan yaygn olarak kullanlan, ak-kaynakl, HBase ve Hadoop mimarileri, byk verinin muhafazas ve istenildi§inde eri‡ilmesi amalaryla kullanlm‡tr. Gerekle‡tirilen arala farkl ili‡kisel veri taban sistemleri ile i‡lemlerin (transaction) sorunsuz bir ‡ekilde ynetilebilmesi ve bu veri tabanlarndan alnan verinin byk veri i‡leme platformuna ta‡nmas sa§lanabilmi‡tir. Geli‡tirilen zmn kullanlabilirli§ini ve performansn ortaya koymak adna, i‡levsel ve ba‡arm testleri gerekle‡tirilmi‡ ve olumlu sonular elde edilmi‡tir. ? Bu al‡ma Yldz Teknik niversitesi Yazlm Kalite Ara‡trma Grubu ve Cybersoft rmas Ar-Ge birimlerinin i‡birli§i erevesinde gerekle‡tirilmi‡tir. Yazarlar, Cybersoft rmasna sa§lanan al‡ma ortam iin; Cybersoft Ar-Ge Mdr Umut Orun Turgut'a ve Cybersoft al‡anlarndan ek Temel'e de katklar iin te‡ekkr etmektedir. Bu al‡ma ayn zamanda, Yldz Teknik niversitesi BAP Projesi (Proje No: 2013-04-01-KAP03) kapsamnda gerekle‡tirilmi‡tir.
Gn iinde insanlar tarafndan gerekle‡tirilen pek ok i‡lem, e‡itli veri taban sistemleri aracl§yla, farkl tipteki veri kaynaklarna kaydedilmektedir. Bu durum, srekli artan ve farkl tipteki veri taban sistemlerinde bulunan verinin ynetimi ve birle‡tirilmesi iin, bir ihtiya olarak ortaya kmaktadr. Kaydedilen bu veriler ile yaplacak raporlama ve analiz al‡malarnda kullanlmak zere, btn bu veritaban sistemleri ile tek bir noktadan ileti‡ime geebilecek 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 dzeyde sa§lanamamas gibi sorunlar meydana kabilmektedir. Bu al‡mann amalarndan biri, birden ok veri tabannn bulundu§u sistemlerde bahsedilen problemlere bir zm sunmaktadr. Bu zmle birlikte geni‡ lekte kullanlan Oracle, MySQL, MSSQL, DB2 ve Sybase gibi veri tabanlar iin ortak bir eri‡im katman olu‡turulmaktadr.
Birden ok veri kayna§na sahip bu sistemlerde, veri kayna§ndan gelen
verilerin i‡lenerek kullan‡l bilgiye evrilmesi gerekmektedir. Yksek hacimli bu
veriler i‡lenmek istendi§inde da§tk al‡abilen NoSQL veri tabanlarnda
muhafaza edilebilirler. Google, ili‡kisel veri taban ynetim sistemlerinin byk
verileri mevcut dosya sisteminde kontrol etme ve verileri efektif kullanma
konusundaki sorunuyla yzle‡mi‡tir. Bunun neticesinde geli‡tirdikleri Google File
System (GFS) [
Bu bildiride; birden ok veri taban i‡letim sistemi aracl§ ile kayt edilmi‡ verilerin okunarak i‡lenmeye hazr hale getirilmesi, farkl veri taban sistemlerinden gelebilecek i‡lemsel istisnalarn (transactional exception) Spring Framework kullanlarak gerekle‡tirilen i‡lem yneticisi (transaction manager) aracl§ ile ynetiminin yaplmas ve analizi yaplan verinin da§tk olarak al‡an sunucularda bulunan Hadoop da§tk dosyalama sistemine ve HBase veri taban sistemine ta‡nmasnn deneyimlerinin sonular 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 blmde de testler ve sonular payla‡lacaktr. 2
li‡kisel ve NoSQL Veri Tabanlar
li‡kisel veri taban sistemleri 1960’l yllarda General Electric laboratuvarlarnda
ortaya km‡tr [
li‡kisel veri tabanlar ACID (Atomik Atomicity, Tutarllk Consistency, Yaltm Isolation, Sreklilik - Durability) ‡artlarnn hepsini sa§larken, NoSQL veri tabanlar bu ‡artlar tamamen sa§lamamaktadr. Bunun yerine da§tk sistemdeki herhangi bir kme elemannda sorun oldu§unda al‡maya devam edebilmesi ve verinin btnl§n koruyabilmesi ‡artlarn en n srada tutmaktadrlar. li‡kisel veri tabanlarnn aksine NoSQL veri tabanlarnda, verilere tekil anahtar zerinden eri‡ilmekte, fakat verilere eri‡im SQL yapsndaki kadar kolay olmamaktadr. Bu bildiri hazrlanrken popler olarak kullanlan ili‡kisel veri taban sistemleri ve HBase NoSQL veri taban sistemi incelenmi‡tir.
li‡kisel veritabanlar arasnda, Oracle, yaygn kullanlan, popler bir veri
taban ynetim sistemidir [
HBase, kolon temelli NoSQL veri taban olarak snandrlr. Kolon ailesi
(column family) yaps ile ayn satra (row) ait farkl kolon aileleri olu‡turularak
verilere eri‡imin hzlandrlmas mmkndr. Bir kolon ailesindeki veriye eri‡im,
ba‡ka bir kolon ailesindeki veriye eri‡imi performans anlamnda
etkilememektedir. Ba‡ka bir deyi‡le kolon temelli yap veri aktarm esnasnda satrn
tamamen kilitlenmesine sebep olmamaktadr. Kolon temelli veri tabanlar d‡nda
Anahtar-De§er (Key-Value), dokman 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
performansla al‡abilece§i da§tk bir dosyalama sisteminin varl§ HBase’i elastik ve
leklenebilir klmaktadr. Bununla birlikte, rastlantsal okuma ve yazma
konusunda etkili olmas HBase’in di§er NoSQL veri taban sistemlerine gre avantaj
sa§lad§ ba‡ka bir noktadr. Facebook Messages’n da tercih etti§i ve yaptklar
testlerde en iyi sonular veren veri taban sistemi NoSQL olmu‡tur [
Gerekle‡tirilen al‡ma esnasnda, farkl veri tabanlarna ba§lanmak iin Spring ˙ats (Framework) ve MyBatis Srerlik ˙ats (Persistence Framework) kullanlm‡tr. Genel sistem mimarisi ekil 1’de gsterilmektedir.
Spring, bir uygulamann gerekle‡tirilmesi esnasnda gerekecek birok modl iinde barndran bir uygulama atsdr. Bu al‡mada Spring’in i‡lem yneticisi (Transaction Manager) modlne yer verilmi‡tir.
ekil 1: Genel Sistem Tasarm .
MyBatis Srerlik ˙ats, ili‡ki nesne modellerinden (ORM) farkl olarak sakl yordamlarn (stored procedure) nesne olarak Java ortamnda tutulmasna veya SQL cmlelerinin birer Java metotu olarak kullanlmasna olanak vermektedir. MyBatis, kullanld§ projelerde, genel olarak, tek bir veri taban kaynak olarak kullanlmaktadr.
Spring Application-Context modl i‡lem yneticisini barndrmaktadr. MyBatis modl, e‡leyicileri (mapper) tutmaktadr ve SQL ifadeleri aracl§ ile veri tabanndaki verinin ekilmesini sa§lamaktadr. ‡lem yneticisi SQL cmleciklerinin al‡trlmas esnasnda do§abilecek istisnalar do§rultusunda i‡lemleri (Commit ve Rollback) ynetmektedir
˙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‡turulmaktadr. 2. MyBatis’te veri taban i‡lemleri (r: create, update, insert, vb.) servisler aracl§ ile gerekle‡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‡abilmesi iin bir nceki a‡amada yaratlan SqlSessionFactory kullanlarak veri taban oturumu olu‡turulmaktadr. 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 grntleme yapldktan sonra, istemci tarafndaki veri taban oturumu yine istemci tarafndan kapatlmaktadr.
Bu al‡mann hedeedi§i gereksinimlerinden biri olan farkl veri tabanlarna ba§lanma ve i‡lem ynetimi Blm 3.1’de, verilerin HBase’e aktarm ve eri‡imi Blm 3.2’de anlatlmaktadr. 3.1
Farkl li‡kisel Veri Taban Sistemlerine Ba§lanabilme ve ‡lemlerin Ynetilmesi Bu projede Oracle, MSSQL, MySQL, Sybase ve DB2 veri taban sistemlerinin hepsi birden veri kayna§ olarak kullanmak istenmektedir. Bunun bir sonucu olarak yukarda anlatlan MyBatis al‡ma prensibi Spring’in zellikleri kullanlarak geli‡tirilmi‡tir. MyBatis-Spring Ktphanesi aracl§ ile Spring’in MyBatis ile entegrasyonu gerekle‡tirilmi‡tir (Bknz. ekil 2). Entegrasyonun sonucunda ortaya kan yap ‡u ‡ekilde al‡maktadr: 1. Spring, Application-Context Container modl iinde servis ynetimini gerekle‡tirir. Bu modl ierisindeki i‡levsel nesnelerden biri olan Datasource Bean, proje kapsamnda kullanlacak farkl veri taban sistemlerine ait bilgilere 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) amaktadr. 2. Bir di§er i‡levsel nesne olan SqlSession Bean, Datasource Bean ’in olu‡turdu§u ba§lanty kullanarak veri taban oturumunu amaktadr. 3. Veri taban zerindeki i‡lemleri gerekle‡tirmek amacyla kullanlan MyBatis servisleri birer Bean nesnesi olarak Container ierisinde yazlmc tarafndan tanmlanmaktadr. Bu servisler olu‡turulurken bir nceki admda yaratlan SqlSession enjekte edilmektedir. Ba§mllk enjeksiyonu (Dependency Injection) diye de adlandrlan bu yap sayesinde enjekte edilen oturum bilgisine gre servis, farkl veri taban sistemi ile etkile‡ebilmektedir. 4. Aktif olan veri tabannda i‡lem yaptktan sonra ba‡ka bir veri tabanyla etkile‡ime geilmek 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 arayzden gelen bir istek ile gerekle‡tirilebilir. De§i‡im tamamlandktan sonra Container yenilenir. Servisler yeni oturum bilgileri ile gncellenir ve etkile‡ime hazr hale getirilir.
Farkl veri tabanlarna ba§lant ve sorgulama amac ile kurulan sistem a‡a§daki srada i‡lemleri gerekle‡tirmektedir. 1. Veri taban de§i‡ikli§i istemi gnderilir. 2. Ba§lanlacak veri tabanna ait bilgiler Spring ApplicationContext Container’a iletilir. 3. Ba§lant Alr. 4. SqlSession Bean ba§lanty sa§lar. 5. Veri tabannda oturum alr. 6. Oturum Service Bean ’e enjekte edilir. 7. Veri tabanndaki i‡lemi gerekle‡tirilecek servis a§rlr. 8. Servis, Mapper’n gerekli metodunu a§rr. 9. Mapper a§rlan metota uygun SQL cmleci§ini bulur. 10. Ba‡langta karar verilmi‡ olan veri taban ile etkile‡ime geerek SQL cmleci§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 (exception) ynetimidir. Bu noktada da Spring Framework’n sa§lad§ i‡lem ynetimi (Transaction Management) modl kullanlmaktadr. Servislerin ierisindeki metotlardan 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 Blm 4.1.’de yaplacaktr.
Veri tabanlar zerinde kullanc tarafndan yaratlacak olan sorgular iin ilgili ‡emada hangi tablolarn bulundu§u bilgisine ihtiya duyulmaktadr. Her veri tabannn farkl bir yapya sahip olmasndan dolay bu tablolar listeleyebilmek probleme neden olmaktadr. Projede bu probleme zm iin Java’nn veri taban tablo isim listesi, view isim listesi gibi meta data bilgilerini getiren java.sql paketi iindeki DatabaseMetaData snf kullanlmaktadr. Bu snf birok veri taban tasarmcs kurulu‡ ile ortak olu‡turulmu‡tur ve veri taban ile ilgili yapsal btn bilgileri bize sunabilmektedir. 3.2
HBase, Hadoop ile en verimli ‡ekilde al‡maktadr. Hadoop’un da§tk mimarisi HBase’in performans ve sa§lamlk asndan optimum dzeyde al‡masn sa§lamaktadr. Bu sebepten al‡mamzda ilk a‡ama olarak Hadoop kurulumu gerekle‡mi‡tir.
Bu a‡amada Hadoop’un kurulacak olan versiyonunu seerken, al‡lmaya karar verilmi‡ olan HBase versiyonu ile uyumlulu§una dikkat edilmi‡tir. Gerekle‡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 stne Hadoop kurulumu gerekle‡tirilirken i‡letim sistemine ve Hadoop’a ait hosts, core-site.xml ve hdfs-site.xml dosyalar zerinde ayarlarn yaplmas gerekmektedir. Bu dosyalar Hadoop’un temel 3 sreci (process) olan Namenode (veri a§ac yapsn saklar cluster iinde hangi verinin nerede tutuldu§unun kaydn barndrr), Datanode (verileri saklar) ve SecondaryNamenode’un (Namenode’un yede§idir) al‡masnda temel olmaktadr. Bir master makinada Namenode tutulurken i‡i makinalarda Datanode al‡maktadr.
SecondaryNamenode, Namenode’dan ba‡ka bir makinada tutulmaktadr. Bu sayede Namenode’un kmesi durumunda SecondaryNamenode’daki bilgiler kullanlarak sistem aya§a kaldrlabilir. Hosts, core-site.xml ve hdfs-site.xml dosyalar master ve slave makinalarn her biri iin ayarlanmaldr.
Hadoop kurulumu ve kongrasyonu tamamlandktan sonra HBase kurulumu gerekle‡tirilir. HBase’in temel sreleri HMaster (Namenode’un ko‡turuldu§u makinada ko‡turulur metadatalar saklar.), HRegionServer (Datanode’larn al‡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 ynetir.)’dir.
HBase kurulurken hbase-site.xml kongre edilmektedir. HDFS’nin yordam (HDFS Path) burada belirtilmektedir. Yaplan kongrasyon HBase’in tablolarn HDFS yaps altnda tutmasn sa§lamaktadr. Ayrca, Hadoop’un al‡ma moduna gre (Fully Distributed, Pseudo Distributed, Single Node) HBase’in al‡ma modu bu dosyada belirlenmektedir. Bu al‡mada single node (tek makina) ve fully distributed (tamamen da§tk) modlar testlerde kullanlmaktadr.
HBase’in tablo yaps kolon aileleri (Column Family) iermektedir. Ayrca, veriyi baytlar halinde tuttu§undan dolay kayt edilen verinin baytlara evirilerek kayt edilmesi gerekmektedir. JSON kaydedilecek verinin snf yapsnda baytlara evrilerek kaydedilmesini sa§lamaktadr. Yaplacak testlerde kolon aileleri kullanlarak veri kayt edilmesi ve verinin JSON objesine evrilerek kayt edilmesi ayr ayr incelenmektedir. Bir sonraki blmde gerekle‡tirilen testler incelenecek ve sonular payla‡lacaktr. 4
Sistem gereksinimleri dahilinde 5 farkl veri taban i‡letim sistemine eri‡im performans testleri ve i‡lem yneticisi fonksiyonalite testleri gerekle‡tirilmi‡tir. Bunlarla birlikte HBase veri taban zerinde byk veri yazma ve okuma testleri yaplm‡tr. Blm 4.1’de ili‡kisel veri tabanlar zerinde yaplan testler, Blm 4.2’de HBase zerinde gerekle‡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 gerekle‡tirilmi‡tir. li‡kisel veri tabanna ynelik fonksiyonel testler olarak, ba§lant kontrol ve i‡lem ynetimi testleri gerekle‡tirilmi‡tir. Ba§lant kontrolnde (ekil 2’de detaylandrlan), veri tabanlarna ba§lant ve oturum ama kontrol bahsi geen tm veri tabanlar iin gerekle‡tirilmi‡tir. Bu test srasnda veri tabanlarndan sadece veri getirme amacyla kullanlan (select sorgular ieren) servisler a§rlm‡tr. Servis a§rlarnn sonucunda her veri tabannn kendisine ait olan veriyi eksiksiz bir ‡ekilde getirdi§i grlm‡tr.
Farkl veri taban i‡letim sistemlerinde bulunan, index iermeyen ve 8 kolonluk varchar bilgi saklayan tablolardan 5000 satrn getirilmesi (select) ile gerekle‡tirilen testlerin sonular Tablo 1’de gsterilmektedir. MyBatis-Spring ktphanesi ile geli‡tirilen ili‡kisel veri taban eri‡imi testlerinin sonular Tablo 1’in ilk satrnda, JDBC ile gerekle‡tirilen testlerin sonular tablonun ikinci satrnda gsterilmektedir. Test sonularna gre MyBatis-Spring ktphanesi ile olu‡turulan sistemin sonular JDBC ba§lantsna gre her veri taban iin daha iyi sonular 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 ynetimi testinde, Cybersoft tarafndan kullanlan hatasz al‡mas beklenen servisler kullanlmaktadr. rne§in baz durumlarda, kullancnn web uygulamas zerinde oturum ap, i‡ledi§i veriyi kaydetmek iin ilgili servisi a§rmas gerekmektedir. ekil 1’de gsterildi§i zere Application Context ierisinde bulunan ilgili servis, aktif olan veri taban oturumu kullanlarak al‡trlr. Bylelikle, kayt i‡lemlerini kendisine enjekte edilmi‡ oturum zerinden gerekle‡tirebilmektedir.
E§er metot i‡lemselse yani @transactional notasyonuna sahip ise; Application Context ierisinde yer alan i‡lem ynetimi (transaction manager) aracl§yla istisnalar ynetebilmektedir. Metot ierisinde istisna (exception) ortaya karsa yaplan i‡lemin geri alnmasn (rollback) ya da istisna olu‡mam‡sa metottan dnld§ srada i‡lemin onaylanmasnn (commit) sa§lamas gerekle‡mektedir. Bahsedilen rnek iin kayt srasnda istisna karan durum ve karmayan durum ayr ayr test edilmi‡tir.
‡lem ynetimi fonksiyonalite testleri sonucunda, istisna meydana geldi§inde kaydetme i‡leminin gerekle‡medi§i, istisna olmad§ durumda ise kullancnn belirtti§i veri taban zerinde kaytlarn olu‡tu§u grlm‡tr.
‡lem ynetiminin zamansal olarak ykn gzlemlemek amacyla gerekle‡tirilen performans testleri sonucu Tablo 2’de sergilenmektedir. Ekleme i‡leminde kullanlan veri 8 kolonlu varchar ieren 1000 satrdan olu‡maktadr. li‡kisel veri tabanlarna eklenmesi nceden yaratlm‡ zerinde index bulunmayan bir tablo yaps kullanlarak gerekle‡tirilmi‡tir. Tablo 2’de ilk satr @transactional noyasyonuna sahip, ikinci satr ise sahip olmayan metotlarn sonucunu gstermektedir.
Grlece§i zere i‡lemsellik d‡k seviyede fazla yk yaratmaktadr. Bununla birlikte, sebep oldu§u kk dezavantaja ra§men sistemi hataya kar‡ daha sa§lam klan (commit ve rollback) mekanizmalar ierdi§inden tr kullanlmas fayda sa§lamaktadr.
Tablo 2: 1000 satrn eklenmesi (Saniye)
HBase ve Hadoop, tek makina ve tam da§tk ‡ekilde Cybersoft’a ait sunucular zerinde gerekle‡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 asndan incelenmi‡tir. A‡a§da sonular sunulan testler, UCI Yapay §renme Veri kayna§ndan (http://archive.ics.uci.edu/ml/datasets/Poker+Hand) ekilen 1025010 satr ve 11 kolon ieren veri kmesi ile gerekle‡tirilmi‡tir.
Tablo 3’te tek makina ve tam da§tk kongrasyonlar zerinde sral (synchronous) ve toplu (batch) veri ekleme sonular gsterilmektedir. Toplu olarak veri ekleme sonular beklendi§i gibi daha iyi sonu vermektedir (30 kat daha iyi). Tam da§tk yaplandrmada ise toplu veri ekleme sonular beklenildi§i gibi tek makinadan daha iyi sonu vermektedir.
Tablo 3: 1 milyon satrn eklenmesi (Saniye)
Tablo 4’te tek makina ve tam da§tk kongrasyonlar zerinde JSON’a evirilerek ve kolon ailelerine blnerek veri ekleme sonular gsterilmektedir. Snf yapsna sahip JSON objeleri ile tek bir kolon ailesi zerinden yaplan testlerin oklu kolon ailesi yaps ile gerekle‡tirilen testlere gre 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‡lemlerinin sonular gsterilmektedir. HBase yaps ile tek makina (3 GHz i‡lemci ve 2 GB RAM) zerinde yaplan testlerin sonucunda 1025010 satrn okunmas 44 saniye srm‡tr. u ana kadar gerekle‡tirdi§imiz testlerde ili‡kisel veri taban sistemlerinden bu seviyede bir veri okumas gerekle‡tirilememi‡tir (3.4 GHz i7 i‡lemciye, 8Gb RAM’e sahip bir makina zerinde). Basit bir hesapla 5000 satrlk verinin okunmas en iyi ihtimalle (MySQL) 0,55 sn srd§ne gre 1 milyon satrlk verinin okunmas 0,55*200=110 sn srecektir.
Tablo 5: 1 milyon satrn okunmas (Saniye)
Elde edilen sonulara dayal olarak, HBase’ in 3 kat daha hzl veri dnd§ saptanm‡tr. Veri okunmas ksmnda tam da§tk yaplandrmada verinin her bir makinadan toplanarak getirilmesi sz konusu oldu§undan dolay tek makine ve tam da§tk yaplandrma arasnda belirgin bir sre farkna rastlanmam‡tr. 5
Bu al‡ma kapsamnda, birden fazla veri tabannn ortak kullanmnn oldu§u sistemlerde kar‡la‡lan problemlere bir zm geli‡tirilmektedir. Bu problemler arasnda, ba§lant problemleri, hangi tablonun hangi veri tabanndan geldi§inin bilinememesi, i‡leme ve geri alma mekanizmalarnn yeterli dzeyde sa§lanamamas yer almaktadr.
nerilen zm, Oracle, MySQL, MSSQL, DB2 ve Sybase gibi veri tabanlar iin ortak bir eri‡im katman olu‡turmakta ve bu farkl veri tabanlarndan elde edilen byk hacimli verinin muhafaza edilmesi ve analiz i‡lemlerinde kullanlabilmesi iin kolon tabanl byk veri i‡leme platformlarn kullanmaktadr. ˙zmn kullanlabilirli§i test etmek amacyla, 5 farkl veri tabanna eri‡im performans testleri ve i‡lem yneticisi fonksiyonalite testleri gerekle‡tirilmi‡tir. Bunlarla birlikte HBase veri taban zerinde byk veri yazma ve okuma testleri de yaplm‡tr. Testler sonucunda elde edilen sonular, nerilen yakla‡mn, i‡lemsellik asnda d‡k seviyede ek yk yaratt§n gstermektedir. Bununla birlikte, sebep oldu§u kk dezavantaja ra§men sistemi hataya kar‡ daha sa§lam klan commit ve rollback mekanizmalar sayesinde faydalar sa§lamaktadr. Yine elde edilen, test sonularna gre, zmde kullanlan MyBatis ve Spring ktphaneleri ile olu‡turulan sistemin sonular JDBC ba§lantsna gre her veri taban iin daha iyi sonular vermektedir. Toplu olarak veri ekleme sonular ise beklendi§i gibi daha iyi sonu vermi‡tir.
Gelecek al‡malar arasnda, nerdi§imiz zmn daha farkl veri tabanlar zerinde test edilmesi ve daha kapsaml performans ve yk testlerinin yaplmas yer almaktadr.
Kaynaklar