Bilgisayar Mühendisliği Bölümü Veri Tabanı Yönetim Sistemleri 2 Ders 8 Oracle NoSQL Veritabanına Genel Bakış Yrd. Doç. Dr. Altan MESUT Trakya Üniversitesi Bilgisayar Mühendisliği Bölümü

Büyük Veri (Big Data) Tablet ve akıllı cep telefonu gibi Internet'e bağlanarak veri veri alışverişinde bulunan mobil cihazların hızla artması ile dünya çapında gün geçtikçe daha çok veri üretilmektedir. Sensörler gibi insanlar tarafından üretilmeyen veriler de gün geçtikçe artmaktadır. Üretilen veri belirli bir biçimde olmayıp, ilişkisel veritabanları gibi şema bağımlı yapılarda saklanması güç olduğu için büyük verileri saklamak amacıyla daha çok NoSQL adı verilen veri tabanı yapıları tercih edilmektedir.

Büyük veri için 5 V kuralı Büyük verinin temel karakteristiğini temsil etmek için genellikle "5 V" tanımı kullanılır. Volume: Verinin büyüklüğü Velocity: Verinin büyüme hızı Variety: Verinin farklılığı (farklı kaynaklardan alınan ve belirli bir yapısı olmayan verinin RDBMS'lerde saklanmasının zorluğu) Value: Büyük verinin içinden belirli bir kurum veya konu için değerli olan verinin elde edilmesi Veracity: Verinin doğruluğu (güvenilirliği)

NoSQL Veritabanı "Yapısal olmayan" veriyi şemasız biçimde, yani "İlişkisel olmayan" yapıda saklar. NoSQL veritabanları bazen SQL benzeri sorgu dillerini de kullandıkları için "Not Only SQL" olarak ta tanımlanabilirler. NoSQL veritabanları için en çok tercih edilen veri modelleri: Key-value store: Yapısal olmayan veri için basit ama etkili ve esnek bir modeldir (Oracle NoSQL, Voldemort, Dynamo) Columnar: bilgi yoğunluğu az olan veri setleri (sparse dataset), gruplama ve toplam alma için uygundur (Cassandra, Hbase) Document: XML depoları ve kendini tanımlayan nesneler için elverişlidir (MongoDB, CouchDB, Lotus Notes) Graph: İlşikinin iki yönde de gerçeklenebilmesi için iyi olan bu model gelen aramalar için yavaştır (Neo4J, Allegro, OrientDB)

RDBMS NoSQL Yüksek değerli, yüksek yoğunluklu, karmaşık veri Karmaşık veri ilişkileri Birleşme (Join) var Şema temelli Yayılma değil büyütmeye göre tasarlanmış İyi tanımlanmış standartlar Veritabanı-merkezli Düşük değerli, düşük yoğunluklu, basit veri Çok basit ilişkiler Join yok Şemasız, yapısal olmayan veya yarı yapısal veri Dağıtık saklama ve işlem Standartlar tam belirgin değil Uygulama-merkezli ve geliştici-merkezli

Durum Tespiti: Senaryo 1 Sağlık Hizmeti Sistemi Ülkede yaşayan tüm vatandaşların sağlık kayıtlarının tutulması istenmektedir. Doktorlar hastaların sağlık özgeçmişlerini görebilmek için bu sistemi kullanacaklardır. Sistem farklı türde verileri saklayabilecek yetenekte olmalıdır. Saklanacak olan veri zamanla değişebilecektir. Milyonlarca kişi için röntgen görüntüleri gibi veriler de saklanacak ise petabyte'lar boyutunda veri: Volume Doktoraların hastalara ayıracak çok zamanı olmadığı düşünülürse hızlı çalışacak bir sistem olmalı: Velocity Hastalar hakkında, röntgen sonuçlar, laboratuar sonuçları, kullanılan ilaçlar ve doktor girişleri gibi birçok farklı türde veri saklanacak: Variety Farklı hastanelerin farklı veri saklama politikaları olabilir ve bu politikalar (değerli olan bilgi) zamanla değişebilir: Value NoSQL kullanmak uygun olur.

Durum Tespiti: Senaryo 2 İnsan Kaynakları Sistemi Firmadaki tüm çalışanların (eski çalışanlar dahil) bilgilerini saklanacaktır. İşe başlama, işten ayrılma (veya emeklilik) tarihleri, ailesel bilgiler, sağlık bilgileri, kazançlar gibi birçok veri saklanacaktır. Önemli dokümanların taranmış halleri, parmak izi verileri, ses örnekleri gibi metin bazlı olmayan verilerin de saklanabilmesi gereklidir. Firma menfaati ve çalışanlar ile ilgili iç politikalar zamanla değişebilir. Her ne kadar farklı türde veriler saklanacak olsa da, saklanacak olan bilgiler için bir yapı öngörülebilir. Saklanacak olan tüm personel bilgileri değerlidir. Kişiye özel bilgiler güvenlikli bir şekilde saklanmalıdır. RDBMS uygundur.

Oracle NoSQL Veritabanı Oracle NoSQL veritabanı key-value store (anahtar-değer deposu) modelinde, Java dili ile yazılmış olan ve Java API'leri kullanılarak erişilebilen bir veri tabanıdır. Oracle'ın büyük veri elde etme çözümü olan bu veritabanı Berkeley DB Java Sürümü üzerine kuruludur. Özellikleri: Ölçeklenebilirdir (veri arttıkça ek düğüm eklenebilir) Her saklama düğümünün bir veya daha fazla replikası olabileceği için yüksek erişilebilirliğe sahiptir. Master ve replica düğümler arasında otomatik yük-dengeleyici (load balancing) mekanizmaya sahiptir.

Oracle NoSQL Veritabanı Nasıl Çalışır?

Oracle NoSQL Veritabanı Bileşenleri

KVStore Oracle NoSQL Veritabanının temel bileşeni, farklı veri merkezleri (data centers) üzerinde bulunabilecek olan birçok saklama düğümünden oluşan Key-Value Store (KVStore)'dur. Saklama düğümü fiziksel veya sanal bir makinedir. Genellikle saklama düğümleri birisi ana düğüm (master) diğer(ler)i de onun kopyaları (replica) olan birçok düğümün birleşmesi ile oluşan replication group (shard) altında organize edilirler. Uygulamalarınızdan Java API'lerini kullanarak KVStore'a erişebilirsiniz. Bunun için Oracle NoSQL Veritabanı Sürücüsü'nü uygulamanıza tanıtmalısınız. Yönetimsel işler için komut istemi arayüzünü kullanarak veya web-tabanlı grafiksel arayüzü kullanarak ta erişebilirsiniz.

KVLite Oracle NoSQL Veritabanı kurulunca gelen basitleştirilmiş bir sürümüdür. Sadece 1 saklama düğümünü destekler Replica düğüm bulunmaz Konfigürasyon gerektirmez Tek bir işlem (process) üzerinde çalışır Genellikle eğitim ve test amaçlı kullanılır

KVLite'ı Başlatma host: KVLite'ın çalışacağı makine (varsayılan: localhost) admin: Web-tabanlı yönetim için erişim portu (varsayılan: 5001) port: İstemcilerin bağlanacağı port (varsayılan: 5000) store: Yeni başlatılacak store'un ismi (varsayılan: kvstore) root: KVHome klasörünün yolu

KVLite'ın çalıştığını test etme Eğer KVLite durursa, aynı seçenekler ile KVLite'ı tekrar başlatmak için run-kvlite.sh çalıştırılabilir veya yeni seçenekler ile çalıştırmak için KVRoot klasörü silinerek tekrar önceki slayttaki komut kullanılabilir.

Oracle NoSQL VT için Şema Yapısı Oracle NoSQL VT'de her kayıt key ve value çiftinden oluşur. NoSQL veritabanının şemasız bir mimariye sahip olduğunu belirtmiştik. İlişkisel veritabanına benzetmeye çalışırsak key ve value adında iki sütuna sahip bir tablo olarak düşünebiliriz. Fakat bu sütunların belirli bir biçimi yoktur. Key-value modelinde şema kendini tanımlayamaz. VT'yi kullanan uygulama bu key ve value için veri yapısını bilmek zorundadır.

Key (Anahtar) Her kaydı tekil olarak tanımlamak için yapısı VT yöneticisi tarafından belirlenecek olan String türünde bir değerdir. Bu string değer birçok majör ve birçok minör bileşenden oluşabilir (en az 1 majör bileşen bulunmalıdır, minör olmayabilir). Bu bileşenlerin yapısı veritabanı tarafından bilinmez (kendini tanımlayamaz: 'self-describing' değil), uygulamayı geliştirenin bilmesi gerekir. Majör bileşenleri aynı olan kayıtlar aynı bölümde saklanır (sorgular için iyi).

Anahtar belirleme örneği Örnek olarak ad ve soyad bilgilerinin majör bileşen, doğum tarihi, telefon numarası, eposta ve resim gibi bilgilerin minör bileşen olarak kararlaştırıldığını düşünelim. ad/soyad.doğumtar ad/soyad.tel ad/soyad.eposta ad/soyad.resim Bu durumda adı ve soyadı aynı olan her kayıt aynı bölümde (partition) yer alacaktır. Oysa ki eposta adreslerinin tekil olacağı düşünülerek, eposta majör bileşen, ad ve soyad minör bileşenler olarak ta düşünülebilirdi. Hiç minör bileşen kullanılmaz ise kayıt sayısı arttıkça performans düşebilir. Örneğimizde majör bileşeni oluşturan elemanlar '/' ile ayrıldı. Majör-Minör bileşen ayrımı ise '.' karakteri ile yapıldı.

Anahtarı uygun şekilde belirmek için Uygulama performansının iyi olması için anahtarı en uygun şekilde belirlemek çok önemlidir. Anahtarı belirlerken şu sorulara uygun cevaplar aranmalıdır: Saklamak istediğiniz veri (değer: value) nedir? Hangi verilere her zaman birlikte erişilir? Hangi verilere bağımsız olarak erişilir? Değer bileşeninin büyüklüğü nedir? Veriye hangi sıklıkta erişim yapılır? KVStore içinde kaç bölüm (partition) var?

Value (Değer) Saklanacak değer bileşeni bir bayt dizisidir ve neyi temsil ettiği yine uygulama tarafından bilinir ('self-describing' değil). Bu değerin büyüklüğü anahtarın belirlenme biçimine göre değişecektir (Maksimum 4GB olabilir): Örneğin anahtar olarak sadece eposta adresini majör-key belirlediyseniz, değer içinde ad, soyad, doğum tarihi, resim, … gibi o kişi ile ilgili her şeyi saklamak zorunda kalırsınız (bu bilgilerin birbiri ile karışmaması için de belirli bir ayıraç işaretine ihtiyacınız olacaktır). Eğer önceki örneğimizde olduğu gibi minör-key'ler kullanılırsa farklı anahtarlara bölünme olacağı için value büyüklüğü azalır.

Oracle NoSQL VT için uygulama geliştirme Uygulama geliştirirken 3 temel kavram dikkate alınmalıdır: Consistency (tutarlılık): Master ve Replica düğümlerindeki kayıtların birbiri ile tutarlı olması Durability (dayanıklılık): Veritabanında bir hata oluştuğunda verinin kaybolmaması Versioning (güncelleme zamanı): Kayıt eklendiğinde ve güncellendiğinde zaman bilgisi tutma VTYS1-Ders1'de Hareket Yöneticisinden bahsederken belirttiğimiz ACID (Atomicity, Consistency, Isolation, Durability) kavramında bunlardan ikisi yer almaktaydı.

Consistency (Tutarlılık) Tutarlılığı varsayılan bir politika tanımlayarak KVStore'un tamamı için geçerli kılabileceğiniz gibi, bu politikayı tanımlamadan belirli işlemlerde kendiniz tutarlılık politikası verebilirsiniz (veya belirli işlemler için varsayılan politikadan farklı bir durumu sağlatabilirsiniz). Eğer yüksek düzeyde tutarlılık sağlamak isterseniz bunun sonucu düşük yazma performansı olacaktır.

Tutarlılık Örneği Consistency.ABOLUTE ifadesi master düğümde tutarlı veri olmasını sağlar. Aşağıda CreditCard.java örneğinden bir bölüm yer almaktadır:

Durability (Dayanıklılık) Master düğümlerdeki tüm değişiklikler eğer anında replica düğümlere yansıtılırsa, yazma performansı düşüren bu durum tutarlılığın yanında dayanıklılığı da sağlayacaktır (master düğümün hata vermesi durumunda replica'nın birebir master ile aynı olması önemlidir). Yazma işlemlerinde önce hafızadaki bilgi değişir, sonra dosya sistemindeki buffer'a değişiklik yansıtılır, en sonunda kalıcı hafıza ile senkronizasyon sağlanır. Bu durumların her biri için replica'lara güncelleme yapılması yerine, bir defa güncellenmesi yazma işlemini hızlandırabilir.

KVStore Handle Oracle NoSQL VT'ye erişimi kontrol eden bir kaynaktır. Store üzerindeki tüm işlemleri yapmak için ve store'u açmak/kapatmak için kullanılır. KVStore Handle yaratmak için öncelikle KVStoreConfig sınıfından bir nesne yaratılır. Daha sonra bu nesne handle'ı döndürecek olan KVStoreFactory sınıfına verilir. Handle elde edildiğinde Store otomatik olarak açılacaktır.

s Bazı erişilebilir yöntemler: Örnek:

KVStoreFactory Sınıfı Sadece KVStore handle'ını döndüren getStore yöntemine sahip olan statik bir sınıftır. NOT: Aşağıdaki paketler import edilmelidir oracle.kv.KVStore oracle.kv.KVStoreConfig oracle.kv.KVStoreFactory

Anahtar Tanımlama Eğer Major veya Minor anahtar birden çok bileşenden oluşacak ise String türünde bir ArrayList oluşturulup bileşenler bu listeye eklenebilir: Eğer anahtarlar tek bileşenden oluşacak ise listeye gerek yoktur (sadece String).

Anahtar ve Değer Oluşturma Key sınıfının createKey yöntemi ile kayıt anahtarı oluşturulur: Key sınıfının createValue yöntemi ile kayıt değeri oluşturulur:

Kayıt Yaratma örneği: Gerekli paketler: java.util.ArrayList oracle.kv.Key oracle.kv.Value

Kayıt Yazma işlemi Eğer yazılmak istenen değer Store içinde yoksa yeni kayıt olarak yazılır, varsa eski kayıt güncellenir (RDBMS'de Merge işlemi gibi).

Yazma, Silme ve Okuma Yöntemleri put(); putIfAbsent(); putIfPresent(); putIfVersion(); Silme delete(); multiDelete(); deleteIfVersion(); Okuma get(); multiGet(); multiGetIterator(); storeIterator(); gerekli paket: oracle.kv

İlgili Exception'lar DurabilityException: Yazma veya silme işlemi belirlenen tutarlılık politikası ile uyuşmaz ise RequestTimeoutException: Okuma, yazma veya silme işlemi verilen zamanda bitirilemez ise FaultException: Uygulama tarafından bilinmeyen bir hata oluştuğunda ConsistencyException: Okuma işlemi belirlenen tutarlılık politikası ile uyuşmadıysa

Put, Delete & MultiDelete

Yazma ve Silme Örnekleri:

Get & MultiGet