Tezin Amac ve Katklar

W3C tarafndan önerilen Semantik A§ teknolojileri ve bunlarn standartla³trl- mas, bu alanda yaplan çal³malarn hz kazanmasna yardm etmi³tir. Ancak Semantik A§ teknolojilerinin standartla³trlmalar 1990'l yllarn sonuna do§ru olmasna ra§men, semantik a§n en temel bile³eni olan verinin üretimi, son

yllara kadar ayn hzda gerçekle³memi³tir. Veri üretiminin hzlanmas ve art olarak internet üzerindeki kaynaklarn semantik veriler haline dönü³türülmesinin hzlanmas ile birlikte, verilerin depolanmas ve sorgulanmas konusu önem kazanm³tr. RDF verilerin, tek bilgisayar üzerinde etkin bir biçimde depolanmas ve sorgulanmas konusunda bir çok önemli akademik çal³malar yaplm³tr [2, 36, 29, 18, 22, 34]. Önerilen bu sistemler tek bilgisayar üzerinde performansl bir ³ekilde çal³an üçlü veritabanlardr. Ancak, semantik veri, yaps itibari ile çok büyük boyutlara ula³abilen bir çizge yapsndadr. Dolays ile, verinin büyüklü§ü sorgulama süresi açsndan önemli bir engel olu³turmaktadr. Bu nedenle, semantik a§n geli³tirilmesi açsndan, verinin ölçeklenebilir da§tk sistemler üzerinde depolanabilmesi ve hzl sorgulanabilmesi en öncelikli hedeerden birisini olu³turmaktadr.

Mevcut üçlü veritabanlarnn birço§u ölçeklenebilirlik yetene§ine sahip olmadk- lar için, kstl miktarda veri depolayabilmektedir. Depolanabilen verinin, tek sunucu tarafndan servis edilebilmesi durumunda ise, sorgu cevaplama süreleri çok uzun olmaktadr. Da§tk olarak veri depolayabilen ve sorgulanmasn sa§layan açk kaynak kodlu ve ücretsiz da§tlan çok fazla üçlü veritaban bulunmamaktadr [1, 35]. Ancak bu yetene§e sahip baz ticari ürünler bulunmaktadr [40, 37]. Yukarda bahsedilen nedenlerden ötürü, bu tez çal³masnda, semantik verinin, etkili bir biçimde da§tk olarak depolanabildi§i ve sorgulanabildi§i bir çözüm olu³turmak hedeenmi³tir. Çal³ma srasnda geli³tirilecek olan çözüm yak- la³mnn, bir uygulama ile gerçeklenmesi tez çal³masndaki di§er hedeer arasnda bulunmaktadr. Uygulama sonucunda olu³turulacak olan sistem, geli³tirilen yakla³mn test edilmesi amac ile kullanlacak ve sonuçlar tek sunuculu bir sistem ile kar³la³trmal olarak verilecektir. Geli³tirilecek olan tasarmn, dü³ük a§ kullanm yo§unlu§u sa§lamas, ölçeklenebilir olmas ve sorgular hzl cevaplamas göz önünde tutulacak tasarm kstlar olacaktr. Sorgularn do§ru cevaplar üretiyor olmas, ilk etapta sistem performansndan daha önemli olacaktr. Bu hedef gerçekle³tirildikten sonra, cevaplama sürelerinin dü³ürülmesi sa§lanacaktr.

hedeer göz ard edilecek, sistemin sadece LUBM sorgu kümesini cevaplayabilir olmas sa§lanacaktr.

Tezin, bu alanda yaplan çal³malar açsndan getirece§i en büyük katk, mevcut tek sunuculu sistemlere oranla daha ksa sürede sorgu cevaplayabilen ve ölçek- lenebilen bir da§tk sistem önerisi getirebilmesi, ayrca, bu sistemin, mevcut semantik a§ teknolojilerinin ve açk kaynak kütüphanelerin kullanlmas yolu ile olu³turulabilece§inin gösterilmesidir. Getirilen öneri yaplm³ olan benzer çal³malar içinde bir alternatif olu³turacaktr.

2. LGL ÇALI“MALAR

Tez çal³mas srasnda üzerinde durulacak olan temel konu SPARQL sorgularnn da§tk bir ortamda depolanm³ olan veriler üzerinde, da§tk olarak çal³trlmas konusudur. Konuyla ilgili yaplm³ farkl akademik çal³malar bulunmaktadr. Bu bölümde, yaplan bu çal³malarn bazlar hakknda bilgiler verilecek ve ksa de§erlendirmeler yaplacaktr. Da§tk sorgulama ve depolama konusundaki yak- la³m biçimleri ve yöntemleri, bu tez çal³masnn yakla³m ile kar³la³trlacaktr. Da§tk depolama ve sorgulama alannda yaplan çal³malarn bir ksm, sfrdan yeni bir da§tk üçlü veritaban geli³tirmek yerine, mevcut üçlü veritabanlarnn da§tk olarak kullanlmasn sa§layacak olan, altyaplar geli³tirmek yolunu seçmi³lerdir [28, 39, 23]. Burada asl hedef, da§tk halde çal³mas amac ile tasarlanmam³ olan üçlü veritabanlarnn, bir yazlm bile³eni olarak kullanlmas yolu ile, da§tk çal³ma yetene§i olan bir sistemin veri depolama ve sorgulama katmann olu³turmasn sa§lamaktr. Bu yakla³mn en önemli nedeni, geli³tirme sürelerini ksa tutmak ve halihazrda, geli³tirilmi³ ve kullanlm³ olmalar nedeni ile, yeterli olgunlu§a eri³mi³ yazlmlar bile³en olarak kullanmaktr. Ayrca her üçlü veritaban, gelen SPARQL sorgularn cevaplamak amac ile kullanlacak olan sorgu uç birimlerini (SPARQL Endpoint) içermekte oldu§undan bu uç birimlerin geli³tirilmesi gerekmemektedir. Ancak, bu yakla³ma alternatif olacak ³ekilde farkl depolama araçlar kullanlmas durumunda, depolama amaçl kullanlan her uç birimde, SPARQL sorgularn yürütülmesini sa§lamak amac ile, birer SPARQL uç biriminin geli³tirilmesi gerekecektir. Bu yakla³mn art yanlar oldu§u gibi, eksi yanlar da bulunmaktadr. Var olan üçlü veritabanlarn kullanmann getirdi§i en önemli eksi ise, mevcut olan üçlü veritabanlarnn birço§unun üçüncü

parti yazlmlarla entegre edilmelerinin kolay olmay³dr. Entegrasyonun sorun olmasnn en önemli nedeni ise, bu üçlü veritabanlarnn büyük bir ço§unlu§unun bir API ve uzaktan sorgulama için bir eri³im protokolü sa§lamyor olmalardr. Üçlü veritabanlar, en genel seviyede, gelen SPARQL sorgularn i³lemek ile sorumlu olan bir sorgu motoru (Query Engine) ve verinin depolanmas için bir veritaban sisteminden olu³maktadrlar. Da§tk bir üçlü veritabannn geli³tirilmesi srasnda bu iki bile³enin de, da§tk yap içinde bulunmas gerekir. Üçlü veritabanlar RDF dosyalarnn sorgulanmas amac ile optimize edilmi³ indeksler olu³turmaktadr. Bu açdan, mevcut ili³kisel veritabanlarndan daha fazla performans göstermektedirler. Tüm üçlü veritabanlar, bu i³lemleri yerine getiren birer yazlm bile³enini halihazrda çal³trmaktadr. Hazr bir üçlü veritabann kullanmak bu bile³enleri geli³tirme yükünü ortadan kaldrmaktadr. Ancak, bu iki yapy ayr ayr geli³tirmek ve ayr ayr kullanmak mümkündür. Baz çal³malar, bu iki bile³enden biri olan veritaban bile³eni ihtiyacn, mev- cut ili³kisel veritabanlarn (RDBMS) veya NoSQL veritabanlarn kullanarak sa§lamakta ve SPARQL sorgularn i³lemek için mevcut ve genel kullanma açk projeleri kendi projelerine eklemektedirler [17, 3, 55, 32, 20, 4, 15]. Ancak genel olarak, ili³kisel veritabanlar çizge yapl veri depolama amac ile optimize edilmedikleri için dü³ük performans göstermektedirler [3]. Bu çal³malarn bazlarnda, sorgularn cevaplanmas amac ile SPARQL uç birimleri çal³trmak yerine, SPARQL sorgularnn SQL sorgularna çevrilmesi yolu önerilmi³tir [15, 3]. Di§erlerinde ise, kullanlacak olan veritabannn önünde çal³trlmas öngörülen, ayr SPARQL sorgu uç birimlerinin kullanlmasna olanak veren ara yazlm katmanlarnn kullanlmasn önermektedir. En yaygn olarak kullanlan SPARQL sorgu motorlarnn bazlar "Sesame2" [38], "ARQ" [12] ve "OpenLink Virtuoso" [37] olarak saylabilir. Mevcut üçlü veritabanlarnn ve SPARQL uç birimlerinin daha geni³ bir listesi, W3C web sayfalarnda bulunabilir [52]. Veritabanlarnn ili³kisel veritabanlarndan veya mevcut NoSQL veritabanlarndan seçilmelerinin nedenleri farkldr. li³kisel veritabanlarnn kullanlmasnn nedeni, genel olarak, mevcut teknolojik altyapnn kullanlabilirli§ini, semantik a§ alanna da geni³let- mek iken, NoSQL veritabanlar yüksek ölçeklenebilirlikleri nedeni ile tercih edilmektedirler.

Birçok NoSQL veritaban bulunsa da, Apache Hadoop temelleri üzerinde geli³tir- ilmi³ olan Apache HBase [9] en ba³arl ölçeklenebilir NoSQL veritabanlarn- dan bir tanesidir. Temelinde, sadece bir anahtar-de§er (key-value) tablosu sunucusudur ve Google tarafndan yaynlanan Google BigTable [19] çal³masn örnek alarak geli³tirilmi³tir. BigTable, ölçeklenebilirli§i sa§layabilmek için ili³kisel veritabanlarnn sa§lad§ baz OLTP (Online Transaction Processing) özelliklerini uygulamam³ veya daha basit olacak ³ekilde uygulam³tr. Ayrca yapsal veriler için tasarlanan bu sistemde SQL deste§i de bulunmamakta, sorgulama amac ile SQL benzeri GQL1 _{isimli bir dil kullanlmaktadr. Jena-}

HBase isimli çal³ma [32], Hadoop [7] temelli olmas dolays ile, yüksek hata tolerans, çok etkin bir veri yedeklili§i altyaps ve güçlü bir yük da§lm yönetimi sunan, HBase veritabann kullanmaktadr. HBase ile veri sorgulama amac için, SQL benzeri bir sorgulama dili deste§i bulunan, Apache Hive2 _arayüzü

kullanlabilmektedir. Ancak API seviyesinde eri³im ve sorgulama da mümkündür. HBase, küme büyüklü§üne do§rudan ba§ml bir performans yapsna sahiptir. Bu yüzden, Jena-HBase çal³masnda, veri depolama katman olarak HBase tercih edilmi³tir. Ancak, HBase performans konusunda ba³arl olmasna ra§men, indeksleme açsndan snrl bir yetene§e sahiptir [9]. Jena-HBase projesi, sorgularn yönetilmesi amac için Apache Jena uygulama geli³tirme arayüzünü (Jena API) [34, 10] kullanr. Bu uygulama geli³tirme arayüzü, SPARQL sorgularn i³lemek için gerekli birçok fonksiyon sunmaktadr. Jena da§tmlar TDB [45] ve SDB [44] isimli iki üçlü veritaban ile birlikte kullanlabilmektedir. Bunlar Jena projesi altnda geli³tirilen üçlü veritabanlardr. Ancak Jena sadece bu iki üçlü veritaban ile snrl ³ekilde çal³mamaktadr. Sa§lanan arayüzler sayesinde, gerekli sürücü yazlmlar ile birlikte, arka planda çal³acak üçlü veritaban olarak, kullancnn seçmi³ oldu§u ba³ka bir veritaban ile de çal³abilmektedir. Jena-HBase projesi, Jena uygulama geli³tirme arayüzünü kullanarak yazlan SPARQL i³leme yazlmn HBase ile kullanlmasn sa§layan sürücü yazlmlarn da geli³tirmi³tir.

Hadoop temelli benzer ba³ka bir proje olan SHARD [42] ise, verileri, HBase

1_{https://developers.google.com/datastore/docs/apis/gql/gql_reference} 2_{http://hive.apache.org/}

gibi bir NoSQL veritaban içindeki tablo objeleri içinde depolamak yerine, Hadoop tarafndan sa§lanan HDFS [8] dosya sistemini kullanarak, düz metin dosyalar içinde depolama yapmaktadr. Bu durumda, veri okuma yazma i³lemleri için do§rudan dosya sistemine eri³ilebildi§i için, zaman kazançlar daha fazla olabilmektedir. SHARD, sorgu i³leme amac ile map-reduce uygulamalar kullan- makta ve girilen SPARQL sorgularn, alt sorgular halinde ele alarak, her alt sorgu için verinin tümü üzerinde bir döngü yapmaktadr. Bu döngülerin her birinde, alt sorgu içinde verilen yolu sa§layan de§erler, sonuç kümesine eklenmektedir. Bu çözüm yakla³m, esasen çok basit ve sadece, Hadoop'un tekrarl i³leri yapmak konusunda çok ba³arl ve yüksek zaman kazanc sa§lyor olmasna dayanan bir çözüm yakla³mdr. Bu projedeki yakla³mn gerçekle³tirilebilmesi için, SPARQL sorgularnn bile³enlerine ayrldktan sonra, Hadoop dosya sistemi yöneticisinin bu dosyalara eri³imini sa§layan ara yazlm katmanlarnn yazlmas gerekmektedir. Çünkü dosya bloklarnn hangi küme birimleri üzerinde depoland§ sadece Hadoop Namenode sunucusu tarafndan bilinmektedir. Veri parçalama i³lemi için herhangi özel bir yakla³m sa§lamamaktadr. Bu i³ tamamen Hadoop NameNode sunucusuna braklm³tr. NameNode, verinin eri³ilebilirli§ini ve yedeklili§ini arttrmak amac ile, kendisine verilen tüm dosyalar, 64 Byte büyüklü§ünde bloklar halinde, en az 3 küme birimi üzerine bulunacak biçimde da§tmaktadr. Bu 3 küme birimi genellikle rastgele seçilmektedir. Da§tlan bloklar ile ilgili tüm bilgiler, Namenode sunucusunda üst veri(metadata) olarak depolanmaktadr. Bu bilgiler, blo§un hangi küme birimlerinde bulundu§unu gösteren bilgilerdir, verinin içeri§i hakknda bir bilgi içermemektedir. Veriye eri³im gerekti§i zaman, Namenode, küme birimlerinin yük durumlarn göz önüne alarak, hangi bloklarn hangi küme birimlerinden okunmas gerekti§i bilgisini sa§lamaktadr. Bu açdan SHARD içinde, verinin nasl da§tlaca§ Hadoop NameNode tarafndan belirlenmektedir.

Verinin parçalanmas biçiminin, daha ön planda oldu§u, ancak yine Hadoop temelli olan ba³ka bir da§tk sistem önerisi de Jiewen Huang, Daniel J. Abadi ve Kun Renve tarafndan yaplm³tr [28]. Bu çal³mada verinin parçalanma biçiminin, sorgu sürelerine etkileri üzerinde durulmakta ve "directed n-hop guarantee" isimli bir veri da§tma algoritmas ve bunu göz önüne alarak sorgulama

yapan bir sistem önerilmektedir. Algoritma, SPARQL sorgularnn yapsna istatistiksel bir yakla³m ile bakarak, herhangi bir sorgu içinde, sa§lanmas gereken alt çizge büyüklü§ünün belli snrlar a³mad§ tespitini kullanmaktadr. Çizge parçalama amac ile METIS [27] kullanlm³tr3_{. Bu algoritmaya göre}

da§tlan veriler, farkl uç birimlerde tekrarlanm³ olarak bulunabilmekte ve depolama etkinli§ini azaltmaktadr4_{. Ancak bu durum, birbiri ile alakal}

üçlülerin, tek birim üzerinde bulunma ve dolays ile bunlar sorgulayan sorgularn tek birim tarafndan cevaplanmas ³ansn arttrmaktadr. Sonuç olarak, uç birimler aras bilgi aktarmlar en alt seviyede tutulmu³ ve uç birim cevaplar ile olu³an veri birle³tirme zorunlu§u ortadan kaldrlm³ olmaktadr. Bu sistem Hadoop altyapsn sorgularn cevaplarnn birle³tirilmesi gerekti§i durumlarda kullanmaktadr. Ald§ sonuçlar itibari ile hzl bir sistem olmasna ra§men, sorgu biçimleri ile ilgili yapmakta oldu§u varsaym itibar ile her sorguda benzer sonuçlar elde etmesi mümkün de§ildir.

Jena-HBase projesine büyük oranda benzeyen, ancak HBase yerine, Google BigTable benzeri bir anahtar-de§er veritaban kullanan ba³ka bir proje ise Rya [41] projesidir. HBase yerine Accumulo [5] isimli ba³ka bir anahtar-de§er tablo sunucusu kullanlm³tr. Accumulo, HBase ile benzer ³ekilde, Google BigTable tasarmn referans olarak kullanm³tr. Ancak, HBase'den farkl olarak, HBase üzerinde bulunmayan, hesaplama performans ve güvenlik sa§layan baz ekstra özelliklere sahip oldu§u için Rya projesinde bu veritabann seçmi³tir. Rya projesinin SPARQL i³leme katmannda, Jena yerine, benzer yetenekler sa§layan ba³ka bir uygulama geli³tirme arayüzü olan Sesame Uygulama Çats (Sesame Framework) [38] kullanlm³tr5_{. Jena-HBase projesindekine benzer bir ³ekilde,}

sorgular ilk admda parçalara ayrlmakta ve daha sonra Sesame içinde bulunan, SAIL uygulama geli³tirme arayüzü kullanlarak yazlan yazlm birimi tarafndan parçalara ayrlmakta, daha sonra veritaban içinde ilgili kaytlar arama i³lemi

3_{Çal³ma detaylarnn anlatld§ makalede, di§er bir veri parçalama yöntemi olarak, Hash}

Partitioning ile veri parçalanmas i³lemi anlatlm³ ve METIS kullanlarak yaplan parçalama i³lemi ile kyaslanm³tr.

4_{Önerilen sistem, depolama alan kullanma etkinli§i ve sorgu cevaplama süreleri arasnda}

bir alakaya dayanmaktadr.

5_{Jena ve Sesame Java programlama dili ile gerçekle³tirilmi³lerdir, uygulama geli³tirme}

yürütülmektedir. Bu arama i³lemi, Accumulo içinde sa§lanan Batch Scanner isimli bir birim tarafndan yaplmaktadr. Çal³ma ile ilgili makalede [41], Accumulo ile HBase arasnda en önemli performans farklarndan birini, bu birimin sa§lad§ belirtilmi³tir. Çal³ma ekibi, elde ettikleri sonuçlarn SHARD ve yukarda anlatlan çizge parçalama (Graph Partitioning) çal³malar ile kar³la³trm³, veri yükleme ve sorgu cevaplama süreleri açsndan Rya projesinin daha iyi sonuçlar elde etti§ini göstermi³tir.

Yukarda belirtilenler d³nda, Hadoop teknolojisine dayanmakszn, da§tk RDF üçlü veritaban geli³tiren çal³malar da bulunmaktadr. Bunlardan en önemlisi 4- Store [1, 23] projesidir. 4-Store projesi üçlüleri model-özne-ili³ki-nesne ³eklindeki dörtlüler yaps ile saklamaktadr. Bu projede, kullanlan ziksel küme yaps, proje kapsamnda geli³tirilen TCP/IP tabanl, birimler aras haberle³me altyaps üzerinden veri al³ veri³i yapmaktadr. Küme içinde bulunan bilgisayarlar depolama birimi ve i³leme birimi olmak üzere iki snfa ayrlm³lardr. ³leme birimleri, sadece depolama birimleri ile haberle³mekte ancak kendi aralarnda veri al³ veri³i yapmamaktadrlar. Depolama birimlerinin her biri verinin belli bir dilimini içermektedirler. Sorgular proje kapsamnda geli³tirilen SPARQL i³leme birimi ile i³lendikten sonra i³leme birimleri üzerinden çal³trlrlar. Her i³leme birimi, yük da§lmlarn da göz önüne alarak sorguyu cevaplayacak olan depolama birimini tespit ederek sorgu cevabn ister. Verinin da§tlmas basit bir Hashing metoduna dayanmakta oldu§u için i³lemci birimler cevaplarn hangi birimlerde oldu§unu hesaplayabilmektedirler. 4-Store, di§er alternatiere oranla, daha uzun süre gerçek kullanm alannda test edilmi³ bir uygulama oldu§u, hatalar en çok ayklanm³ üçlü veritabanlarndan bir tanesidir. 4-Store tasarm, 32 birimlik bir küme için optimize edilmi³tir. Ancak daha büyük kümelerde çal³trlmas sonucu elde edilen verilere dair bir bilgi bulunamam³tr6_.

Bu tez çal³masnda önerilecek olan sistem yukarda ksaca de§inilen sistem önerileri ile baz paralellikler içeriyor olsa da, yakn seviyede benzeyen bir sistem yakla³m bulunmamaktadr. Bu tez çal³masnda verinin uç birimlerine

6_{4-Store üçlü veritabannn Hadoop temelli sistemlerle kar³la³trlmasn içeren bir kaynak}

da§tlmas srasnda Çizge Parçalama projesinde [28] kullanlan METIS kul- lanlacaktr. METIS veriyi çizge özelliklerini göz önüne alarak, ili³kili çizge dü§ümleri ayn çizge parças içinde kalacak ³ekilde parçalamakta, bu sayede sorgularn mümkün oldu§unca az uç birim tarafndan cevaplanabilir kalmasn sa§lamaktadr. Çizge Parçalama projesinde cevap veren uç birim saysnn daha da dü³ürülmesi amac ile bir çizge parçasna atanm³ üçlüler, çizge snrnda kom³u olunan di§er çizge parçalarna da kopyalanm³tr. Ancak bu tez çal³masnda, Çizge Parçalama projesinde oldu§u gibi ayn üçlülerin birden fazla uç birim üzerinde tekrarlanmas sa§lanmayacaktr. METIS kullanarak, her ne kadar cevap veren uç birim says en dü³ük seviyeye indiriliyor olsa da, cevabn tamamnn tek birimden cevaplanmasn sa§lamak amac ile veri tekrarlama gere§i görülmemektedir. Çünkü veri tekrar yaplmas, sistemin toplamda, depolama açsndan etkinli§i azaltmaktadr. Yukarda anlatlan sistemlerin ço§unda Hadoop verinin da§tlmas ve sorgularn i³letilmesi süreçlerine aktif olarak katlmakta olmasna kar³n, bizim çal³mamzda, verinin ön i³leme süreci d³nda Hadoop kullanlmayacaktr. Sorgu i³leme için Jena-HBase projesindeki gibi, Jena uygulama geli³tirme arayüzü kullanlacaktr. Sesame2 yerine Jena'nn seçilmesinin sebebi, Jena TDB üçlü veritabannn veri yükleme süreçlerinde daha hzl cevap vermesi ve ölçeklenebilirli§idir [16]. Buna kar³n Sesame2 sorgu cevaplama performanslar açsndan daha ba³arldr. Ancak yaplan deneyler srasnda büyük miktarlarda verilerin çok sk yüklenmesi ve silinmesi gerekti§i için Jena seçilmi³tir. Di§er bir seçim nedeni, Jena'nn HTTP protokolü üzerinden sorgular cevaplayabilen, Fuseki (SPARQL query end point)7 _{isimli alt bile³eninin}

olmasdr. Depolama altyaps olarak ise di§er projelerde kullanlmam³ olan Jena TDB üçlü veritaban seçilmi³tir. Bu seçimin sebebi ise, TDB üçlü veritabannn, kullanlan Jena yazlm geli³tirme arayüzü ile daha kolay entegre edilebilir olmasdr. Önerilen sistemde, birimlerin kendi aralarndaki veri al³veri³leri için ise Apache Java Commons API [6] kullanlarak HTTP üzerinden haberle³me yaplmasna karar verilmi³tir. Sistem içindeki uç birimlerin topolojik yaps ise, sorgularn cevaplanmas sürecinde, uç birimlerin birbirlerine sorgu göndermesini sa§layan bir örgü yapsdr.

Burada açklanan örnek çal³malara ait özet bilgiler Çizelge 2.1'de verilmi³tir. Çizelge 2.1: li³kili çal³malarn kar³la³trmal özeti

Çal³ma Ad Veri Depolama Altyaps Sorgu Katman Veri Parçalama Yöntemi

Vertical Partitioning [3] PostgreSQL Sesame Vertical Partitioning

Jena-HBase [32] HBase Jena+HBase API HBase(Hadoop Namenode)

SHARD [42] Hadoop HDFS Hadoop+MapReduce Hadoop Namenode

GraphPartitioning [28] RDF3X RDF3X Metis

Rya [41] Accumulo Sesame2 Accumulo

3. RDF VERLERNN DA‡ITIK

ORTAMDA DEPOLANMASI VE

SORGULANMASI

Bu bölümde tez çal³mas srasnda tasarlanan sisteme ait detayl bilgiler verilecektir. lk olarak sisteme genel bir bak³ yaplacak, sistemin mantksal ve ziksel mimari yaps hakknda bilgiler verilecektir. Daha sonraki bölümlerde, sras ile verinin sisteme verilmesi öncesinde yaplan ön i³lemler, tezde önerilen çözüm yakla³mnn bir gerçekle³tirimi olan DRS (Distributed RDF Store) uygulamas aracl§ ile, verinin parçalanmas ve da§tk ortamda depolanmak üzere a§a gönderilmesi i³lemleri anlatlacaktr. Son ksmda sistem üzerine da§tlm³ olan verinin nasl sorguland§ açklanacaktr.