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.