Nedir bu NoSQL?

Günümüzde yazılımla uğraşıp, SQL (Structured Query Language) bilmeyen ve duymayan kalmamıştır herhalde. Nasıl yabancı dil eğitimi İlkokullara kadar indiyse, SQL’in temellerinin de İlköğretim Eğitim Programı içine alıp, gençleri erken yaşta veritabanı ve onun küresel dili olan SQL ile tanıştırmanın zamanı geldi de geçiyor. Buradan Milli Eğitim Bakanlığı’na bir mesaj vermiş de olayım.

Ama bu yazının temel konusu SQL değil, NoSQL!

SQL kullanan veritabanlarının geleneksel nimetlerini anlatmayacağım. 1970’lerde IBM için çalışan iki bilim insanı, Donald D. Chamberlin ve Raymond F. Boyce tarafından tasarlanan bu veri işleme dili, bütün ilişkisel veri tabanları için neredeyse standart hale geldi ve günümüze kadar ulaştı.

Öncelikle şu fark ile başlayalım.

SQL; ilişkisel veri tabanlarında, saklanan verileri yönetmek için kullandığımız, veritbanı bağımsız bir dil.

NoSQL ise yeni bir veritabanı sistemi veya modeli olarak adlandırılabilir.

Geleneksel veri tabanı üreticileri (IBM, Oracle, Microsoft vb.) geliştirdikleri veritabanlarıyla (DB2, Oracle, SQLServer) geleneksel veri tiplerini saklamak, yönetmek üzerine tasarlanmış, verinin doğruluğunu, herzaman tutarlı ve kararlı olarak saklanabilmesini, ulaşılabilir olmasını temel kriterleri olarak önceliklendirmişler ve bunlara göre çok sağlam motorlar geliştirmişlerdir. Bu veritabanları yıllar boyunca öncelikle “mission-critical” veri saklanmasını gerektiren bütün alanlarda görevlerini yapmaya devam etmektedirler.

NoSQL olarak adlandırılan model, yukarıdaki geleneksel modelin dışında, veri saklama, veriye ulaşma ve tutarlılığının ikinci planda kaldığı ihtiyaçların daha öne çıkması ile gözüktü. Bıg Data ihtiyaçları, Web ve Mobile uygulamaların ciddi derecede artması NoSQL olgusunu çok geliştirdi. Bu modelde saklanan veriler “yapısal olmayan” verilerden oluşuyor ve “mission-critical” ihtiyaçlar genel olarak yok. Böyle beklentilerin olmadığı NoSQL veritabanları bu anlamda yatay ölçeklemeye daha yatkın olarak düşünülebilir. Daha çok iş yükünü çalıştırmak için daha güçlü sunucular kullanarak dikey büyüme yöntemi yerine, daha ucuz sunucular ile yatay büyümenin tercih edildiği, “High Availability” çözümlerinin veritabanı olanaklarından çok, yazılım geliştirme teknolojileri ile sağlandığı yeni bir dünya burası. Bu dünyada merkezi veritabanından çok, dağıtık veritabanı özendirilir. Geleneksel veritabanlarının olmazsa olmazı ACID (Atomicy, Consistency, Isolation, Durability) kuralları NoSQL dünyasında sağlanmayabilir.

NoSQL veritabanlarında, SQL dili kullanılmıyor anlamı çıkmasın. Bazı yazarlar bunu “Not Only SQL” olarak da tanımlıyorlar yani bir nevi SQL’de kullanabildiğiniz ilişkisel model olmayan veritabanı gibi.

NoSQL veritabanları veriyi saklama metodlarından dolayı “çok büyük” veriyi, ilişkisel olarak saklama ihtiyacının olmadığı, bu veriyi daha hızlı getirmek ön koşulu  üzerine tasarlanmışlardır. Yani geleneksel veritabanlarındaki gibi birbiri ile ilişkili tablolar arasındaki verileri bulup, filtreleyip, işleyip getirmek gibi ihtiyaçlara burada cevap bulmak zordur. İlişkisel Model, veriyi alır birbiri ile ilişkili tablolarda kolon/satır şeklinde saklar. Örneğin “Document Store” modelini kullanan bir NoSQL veritabanı, JSON formatında gelen verilerin her bir kümesini ayrı bir veritabanı nesnesi gibi saklar.

Istatistik Hesaplar, Gerçek-Zamanlı Analizler, sürekli, hızlı ve kontrolsüz büyüyen verilerin saklanması (Twitter) gibi alanlar en yoğun kullanım şekilleridir. Özellikle Twitter gibi uygulamalar, “extreme scale” diyebileceğimiz şekilde büyük ve ucuz ölçekleme ihtiyacı göstermektedir. NoSQL bu alanı adreslemektedir.

Günümüz uygulama geliştirme süreçleri çok hızlı beklentiler içinde olduğundan (rapid application development) ve DBA gereksinimini en aza indirmek içinde NoSQL veritabanları ilgi görmektedir.

Klasik veritabanı API’lerinin veri erişimindeki göreceli olarak “overhead”leri daha fazla olduğundan ve NoSQL API’leri bu anlamda uygulama geliştiriciler tarafından daha revaçta olmaktadır.

Şu günlerde 122’den fazla kendini NoSQL sınıfına koyan veritabanı bulunmaktadır. Daha derin teknik detayları bir başka yazı konusuna bırakarak, kendini NoSQL veritabanı olarak tarifleyenlerin 4 ana grubundan bahsedeyim. 122 ününün yaklaşık %65’i bu 4 modelden birini benimsiyor.

Key Value Stores: Key değerleri, hash olarak tutuluyor. Key kısmındaki veri kısmı ise binary olarak saklanıyor. MemcacheD, REDIS, WebSphere eXtreme Scale bu modele uyan örnekler.

Document Stores: Saklanan veriler/dökümanlar tagged elementler gibi tutuluyor. MongoDB, couchDB bu modeli kullanan NoSQL veritabanları

Column Family: Her Storage bloğunda sadece bir kolon veya kolon kümesine ait veriler saklanıyor. Hbase, Cassandra güzel iki örnek

Graph Store: Key değerleri “graph yapısı” denen bir modelleme ile ilişkilendirilip saklanıyor. Jena, Sesame iki örnek. 

Öyleki, en yukarıda örneklerini verdiğim klasik veritabanları da, mevcut motorlarına yukarıdaki dört modelden birisini seçerek, ek “NoSQL” özellikleri ekliyor.

Örneğin Oracle, Key Value Stores, kullanarak, NoSQL desteği verirken, IBM - DB2 ise  Graph Store modelini kullanarak yollarına devam edeceklerini açıkladılar. Bunun anlamı, JSON dökümanlarına, SQL ile erişilebilecek olması çok yakında. Bu olanak geldiğinde yılların SQL bilgisine sahiplik yok olup gitmeyecek ve aynı becerileri kullanarak NoSQL veritabanlarını kullanabileceğiz.

Şimdilik görünen bunlar ama bu alanda o kadar hızlı gelişmeler oluyor ki siz bu satırları okurken bile bazı şeyler değişmiş olacak.

“Veri Ambarı ve BIG Data elele verirse?!?”

Herkesin dilinde, her etkinlikte BIG Data var. Bu sunuların ilk beş-on dakikası, 3V’yi anlatmakla, dünyadaki verinin saatte kaç kilometre hızla büyüdüğü, yere göğe sığmadığı ve sığmayacağını aktarmakla başlıyor. Bir kavramı anlamak ve anlatmak çok önemli. Kavram anlaşıldığında ve gerçekleştirildiğinde, o kavramın üstünden üretilen teknolojiler, ürünler ve hizmetler doğru şekilde değerlendirilebiliyor.

Bence, BIG Data kavramını ve algısını bir çok üretici farklı açıdan anlatsa da, bu kavram üzerinde bir asgari müşterek oluştu artık. BIG Data’dan “verim” sağlayacak “tüketici”, yani bu ürün ve hizmetleri alacak müşteriler, kurum içinde uygulama yapacakları bir alan arıyorlar. Kurumlar dönüp kendi veri işleme envanterlerine baktıklarında, geçtiğimiz yıllar boyunca Operasyonel/Transactional Sistemlerini kurduklarını, bunun üstüne de Veri Ambarları inşa ettiklerini görüyorlar. OLTP’den, Veri Ambarı’nı besleyerek raporlar çekiyorlar, karar süreçlerini daha doğru verilerle besleyip, daha hızlı karar karar almaya çalışıyorlar. Bu yapılanların üzerine acaba BIG data bana daha fazla ne katabilir diye herkes arayış içinde!

Büyük Veri teknolojisinin kullanılabileceği alanlara bakıldığında beş temel “Use-Case” görüyoruz.

Büyük Veri Arama: Karar verme sürecini daha etkin kılmak için tüm büyük veri kaynaklarını aramak, taramak, görselleştirmek. Buradaki en önemli girdi Sosyal Medya.

360^o Müşteri Görüntüsü: İç ve Dış bütün veri kaynaklarıyla müşteri analizi. Sosyal Medya, OLTP ve Veri Ambarını tekmişcesine inceleyebilme beceris.

Güvenlik ve Istihbarat Yetkinlikleri: Düşük risk, gerçek zamanlı dolandırıcılık, izleme ve siber güvenlik algısı. Güvenlikle ilgisi olan herkesin en ilgili olduğu alan.

Operasyon Analizi: Sensor ve Log Analizi yaparak sonuç geliştirme. Özellikle makine, sensor vb. elektronik herşeyin ürettiği sinyalleri anlık işleme ve karar destek süreçlerini besleyebilme yetkinliği.

Veri Ambarı Eklentisi: Operasyonel Verimliliği arttırmak için Büyük Veri ve Veri Ambarı özelliklerini entegre etmek.

Günümüzde, Veri Ambarı olmayan bir kurum artık kalmadığına göre beşinci seçenek, bence bir kurumun BIG Data çözümleriyle tanışıp, uygulaması için en hızlı seçenek olabilir.

Big Data ve Veri Ambarı Eklentisi

Mevcut veri ambarlarımız çoğunlukla, çok büyük miktarlarda yapısal verilerin, yüksek maaliyetli donanımlar üzerinde biriktirildiği ve sürekli gittikçe büyüdüğü, karmaşık sorguların çalıştığı yapıdadır. Kullanıcı sayıları ve kullanıcı taleplerindeki çeşitlilik ve sayının artış eğilimi, ambara giren verilerin de sayısısının artması ile veri ambarlarının motorları klasik veri tabanlarından, appliance dediğimiz çözümlere doğru evrilmekte. Bu evrilme sırasında BIG Data bize başka olanaklar sunuyor.

- Yapısal olan ve olmayan verilerle, akan verilerin büyük resmin içinde olup hep birlikte değerlendirilebilmesi, analitik sürece dahil edilebilmesi.

- Daha sorgulanabilir, göreceli olarak daha düşük maaliyetli bir ortam sağlanması.

- Soğuk Verilerin taşınabileceği, veri saklama, lisans ve bakım maaliyetlerinin aşağı çekilebileceği

- Şimdiye kadar “akan veri analizi”nin mevcut veri ambarlarında hiç yapılmamış olmasından dolayı, bu tip veri kaynaklarının “işlenerek” veri ambarına yazılamasıyla, saklama maaliyetlerinden tasarruf edilmesi.

Bunlar bir çırpıda, göze çarpan hızlı kazançlar.

BIG data teknolojileri ve Veri Ambarlarını eklemlemenin yukarıdaki kazanım ve ihtiyaçlar göz önüne alındığında üç yaklaşımla yapıldığını görüyoruz.

- Ön İşleme

Kurum mimarisinde, BIG Data veri kaynaklarının ön tarafına eklenecek, “staging” görevini üstlenen bir Kurumsal Hadoop Sunucusu, Veri Ambarına hangi verilerin girip girmeyeceğini ve filtrelemesini yapabilir. Bu yaklaşımla, BIG Data kaynaklarındaki veriler, temizlenerek, filtrelenerek ve anlamlı hale gelerek, Veri ambarına yerleştirilir. Bu şekilde hem yeni veri kaynaklarından mevcut ambara, daha önce veri ambarında hiç olmamış verilerin akışı sağlanmış olur, hem de bu ön filtreleme ve analiz ile veri ambarının daha değerli olan saklama ve hesaplama maaliyeti, gereksiz veriler yüklenmediği için, korunmuş olur.

- Sorgulanabilir Arşiv

Bu yaklaşımda, mevcut veri ambarında daha az erişilen soğuk veriler, daha ucuz maaliyetli olan bir Kurumsal Hadoop Sunucusu’na veri aktarım araçları ile taşınabilir. Federation teknolojilerinin yardımı ile son kullanıcılar her iki kaynaktan, tek kaynakmışcasına sorgulama yapmaya devam edebilirler.

- Keşifsel Analiz

Bu yaklaşımda ise, BIG Data kaynakları, akan veri analizi tekniği ile (Stream Computing) incelenip, analiz edilirken, yapılan bu analizlerin sonuçları hem anlık olarak değerlendirilebilir hem de mevcut veri ambarına beslenerek oradaki yapısal sorgulama ortamının bu keşifsel analiz sounçlarından faydalanması sağlanabilir. BU yaklaşımın bir diğer avantajı, BIG Data’yı tekil (unique) yapan teknolojilerin başında gelen “Stream Computing”in mevcut veri ambarı bileşeninin çalışmasını ve çıktılarını etkilemeden, mevcut yapıya en az müdehale ile entegre edilmesini sağlamasıdır.

Bu üç seçenekten birisi ile kurumdaki veri ambarının yanına bir BIG Data çözümü eklemleyerek, bu teknolojiyle tanışıp, kullanmaya başlamak artık an meselesi.

Nedir bu Hadoop ?

Herkesin dilinde bir “Hadoop” var ama nedir bu Hadoop ?

Apache-Hadoop güvenilir, ölçeklenebilir bir dağıtık hesaplama (distributed computing) ortamı yaratabilmek amacıyla ortaya çıkmış, açık kaynak kodlu bir yazılım geliştirme projesinden başka bir şey değil.

Bu projeye katkı verenler arasında Yahoo, Microsoft, Cloudera, facebook, linkedin, twitter, IBM gibi büyük yazılım şirketleri de bulunuyor.

Hadoop, basit programlama modeli kullanarak, kümelenmiş (cluster) bilgisayarlar arasında, büyük hacimli verilerin dağıtık olarak işlenmesini sağlayan bir yazılım kütüphanesi olarak ortaya çıktı. Tasarımı gereği, tekil bir sunucuda da, her birinin kendi CPU ve hafıza birimi bulunan binlerce sunucuyu barındıran bir küme (cluster) üzerinde de çalışabilir, büyüyebilir. Hadoop’un tasarımındaki önemli bir fark, bu yazılım geliştirme teknolojisinin, “High-Availability (HA)” ihtiyaçları için arka planda kullanılabilecek pahalı donanım çözümlerine ihtiyaç duyması yerine, kesintiyi uygulama seviyesinde farkedip, çözümleme üstüne tasarlanmasıdır. Hadoop, arka plandaki kümelenmiş bilgisayarların üstüne kurguladığı uygulama seviyesindeki HA çözümüyle farklı, ucuz bir alternatif olmayı hedefliyor.

Hadoop Projesi 4 modülden oluşuyor.

• Hadoop Common: Bütün Hadoop modüllerini destekleyen ortak modüller.

• Hadoop Hadoop Distributed File System (HDFS™): Büyük miktardaki veriye yüksek iş/zaman oranı (throughput) ile erişim sağlayan Dağıtık Dosya Yönetim Sistemidir. Birçok makinedeki dosya sistemlerini birbiriyle bağlayarak tek bir dosya sistemi gibi gözükmesini sağlar. HDFS, düğüm noktalarının (node’ların) her zaman %100 çalışamayacağını, kesintiler olabileceğini baştan kabul eder. Bu yüzden veri güvenliğini, verinin birden fazla düğüm noktasına kopyalayarak sağlar.

• Hadoop YARN: İş zamanlayıcı (job scheduler) ve kaynak yönetimini yapan bir dizi kütüphane.

• Hadoop MapReduce: YARN temelli, büyük miktarda veriyi parallel olarak işlemeye yarayan bir sistem. Gelen iş yükünü tanıyarak, arka plandaki bilgisayar düğüm noktalarına bu iş yükünü tahsis eden imkanlar sunar.

Hadoop kullanmaya başladığınızda, kesinlikle karşılaşacağınız Hadoop temelli bazı projeler de var. Bunlardan en popüler olan bazıları şöyle:

• Cassandra: Ölçeklenebilir, çok-nodlu, kümelenmiş veritabanı.

• Chukwa: Dağıtık ve Büyük Sistemleri yönetmek için veri toplama sistemi.

• Hive: Veri Özetleme ve “ad hoc” sorgu yazma ortamı sağlayan bir veri ambarı mimarisi.

• Pig: Parallel İşlem Tasarımı yapmak için hazırlanmış, veri akışlarını ve çalıştırma planlaması yapılabilecek bir dil.

Hadoop projesi ne getiriyor?

Hadoop, özellikle büyük hacimli verinin işlenmesinde, ekonomik değerleri ve dinamikleri kökten değiştirebilir. Çeşitli ihtiyaçlar için sistem mimarisi tasarlarken, ölçeklenebilirlik, süreklilik, hatadan kurtarma, paralel işlem yetenekleri, fiyat/performans, esnek tasarım gibi parametreler kullanıyoruz. Hadoop aşağıdaki 4 temel özelliği ile bu parametrelerin hepsinin aynı anda gerçekleşmesini sağlayabilir.

• Ölçeklenebilir: İhtiyaç duyulduğunda, verinin kendisini,  formatını, yerini değiştirmeden, çalışan işlerin ve uygulamaların nasıl yazıldığını dikkate almadan yeni düğüm noktası eklenebilir.

• Hesaplı Çözüm: Yüksek hacimli verinin, fazla CPU gücü ile işlenmesini gerektiren parallel çözüm ihtiyaçlarını, daha ucuz veya hesaplı bilgisayar altyapısı ile gerçekleşitirlmesini sağlar. Sonuç olarak her TB Saklama alanı için maaliyetler düştüğünden, kurumun bütün verisini fiyat endişesini daha ikinci plana iterek modellemesini sağlar.

• Esneklik: Hadoop’un şemasız, yapısal olan veya olmayan bütün veri tiplerini, her kaynaktan işleyebilen bir mimarisi var. Farklı kaynaklardan gelen, farklı veri tipleri birbirleriyle birleştirilip, özetlenebilir ve işlenebilir.

• Hatadan Kurtarma: Düğüm noktalarından biri ulaşılamaz olduğunda, sistem, gelen yükü diğer düğüm noktalarına paylaştırarak kesintisiz hizmete devam eder.

Hadoop size uygun mu?

Dünyadaki verilerin %80’i yapısal değil. Öyle ki, birçok kurum bu veriyi kendi avantajına dönüştürecek şekilde kullanma becerisi ve yatırım esnekliğinden de uzak. Bir an için hayal edin: Kurumun ürettiği veya kendisine dışardan gelen, istisnasız olarak her verinin gerektiğinde saklanabildiği, işlenebildiği, kurumun var olan diğer karar destek sistemleri ile entegre olabilen, ölçeklenebilir, hesaplı, esnek bir mimari kurguluyorsanız, Hadoop temelli çözümleri düşünmenin zamanı gelmiş demektir.

Hadoop’un çalışması “Yığın İşlem – Batch Processing” üzerine kurulu. Veri Ambarları ile bir Hadoop sistemi arasındaki en temel farklardan biri performans olacaktır. Dikkat edilirse, yukarıdaki değerlendirme parametreleri içinde perfromans bulunmuyor. Çünkü, Veri Ambarı sistemlerini karakterize eden erişim ve cevap süresi paternlerine baktığımızda, Hadoop temelli sistemlerde aynı beklenti içinde olmamız şimdilik doğru olmaz. Hadoop “Batch Processing” yapan bir çerçeve mimari sağlamaktadır ve cevap süresi olarak şimdilik veri ambarları ile aynı beklentide olmamak daha doğru olacaktır.

Örneğin; Bir Hadoop Sistemi, mevcut Veri Ambarı sisteminin arşivleme altyapısı için kullanılabilir. Müşteri Profillerini saklayan ve değerlendiren, iyi cevap süresi vermek üzere kurgulanmış ve yatırımı yapılmış bir veri ambarı sistemi, son iki yıllık bilgiyi saklarken, daha eski veriler bir Hadoop sistemine aktarılarak 20 yıllık bilgiler de burada saklanabilir ve gerektiğinde erişilebilir. Burada dikkat edilmesi gerekenlerden birisi de, SQL tabanlı olan Veri Ambarı sistemine erişen uygulamaların, aynı arayüzlerle Hadoop sistemine erişebilmeleridir; SQL ve NoSQL dünyasının bir arada çalışabilme gerekliliği vardır. Her iki mimari farklı hizmetler ve beklentiler için tasarlanmıştır, birbirinin yerini almak için değil, birbirini tamamlamak için kullanılmalıdır.

Hadoop’u kendiniz indirip kurup, kullanmaya başlayacağınız gibi, Hadoop Projesini destekleyen Microsoft, IBM gibi büyük oyuncuların kurumsal çözümleri ile de kullanmaya başlayabilirsiniz.

Hadoop, mevcut sistemlerinizin bir alternatifi değildir. Geleneksel veritabanı motorları ve yeni veri işleme motorları (Hadoop vb.) bir kurumun sol ve sağ kolları gibidir. Kuruma uyarlanacak BIG Data çözümünün, mevcut sistemle entegre olması, ayrık şekilde çalışmıyor olması en önemli önşartlardan birisi olmalıdır.

Yakında her eve bir “fil” girecek diyor Hadoop’u geliştirenler.

Hep beraber göreceğiz ve gerçek olup olmadığı da çok uzakta bir tarih değil!...

BT Haber