Amatörler için In-Memory Veritabanı…

Haziran sayısında Big Data’ya nereden başlasak demiştim. Yapılan anketlere göre kurum dışı veriler yerine kurum içi verilerle, transaction bilgileri, Sistem Logları gibi, yola çıkmanın genel kabul gördüğü ortadaydı. Bir yandan da insanlık olarak çılgınca veri ve bilgi üretmeye devam ediyoruz. Google CEO’su Eric Schmidt’e göre insanlığın sadece iki gün içinde ürettiği bilgi miktarı, uygarlığın başından 2003’e kadar geçen zamanda üretilen miktara eşit. Bir başka tahminse, her yıl üretilen verilerin toplamı, 2020’de 44 zettabyte olacak. (1 ZettaByte = 1 Milyar Terabyte)

Bu tahminler doğru olsa da olmasa da gerçek olan, geleneksel veri tabanlarının ve araçlarının, bu patlayan hacimlerde ki veriyi saklamak ve işlemek için çok da uygun olmayacağı yönünde. Örneğin Hadoop, açık kaynak veri saklama ve işleme mimarisi, sadece birkaç yılda Web 2.0 şirketlerinin giriş mimarisinden, modern kurumsal veri mimarilerine doğru geçiş döneminde.  Ama hep şunu diyoruz ki, saklamak ve işlemek önemli ama değer üretmedikçe, bu değeri de zamanında son kullanıcıya servis edemedikçe, arkadaki mükemmel teknolojinin de önemi değersizleşiyor. Örneğin bir perakende uygulamasında, müşteriye sunulacak hizmet veya katma değerli ürünün zamanında analiz edilip servis edilmemesi rekabet koşullarında olmazsa olmaz.

Hadoop Teknolojileri, büyük miktar veriyi saklamak ve işlemek için ideal olsa da, Real-Time Operation, Real-Time Analytic, Inline Analytic, InDatabase Scoring gibi yükler için uygun değil hala. Bu tarz yükler için yeni bir model gerekiyor ki o da “In-Memory VeriTabanları”

In-Memory VeriTabanları’nın, Geleneksel veritabanları ve Hadoop sistemlerinden ayrılan en önemli farkı, verileri geleneksel dönen başlıklı diskler yerine, dynamic random-access memory (DRAM) üzerinde saklamalarıdır. DRAM üzerinde yapılan I/O işlermleri, diğer diskler üzerine yapılanlardan ciddi oranda daha hızlıdır ki bu da veri merkezli analiz uygulamalarında yüksek performans beklentisinin gereği olarak önümüze konur.

In-memory veritabanları yeni olmamakla birlikte, ana akım kurumsal uygulamalarda gittikçe daha fazla yer alıyor. Bunun en önemli sebebi, son on yılda memory fiatlarının ciddi oranda ucuzlaması ve bütün verilerin DRAM’da saklanarak, In-Memory Database tabanlı uygulamanın fiat/performansının satın alınabilir, uygulanabilir hale gelmesidir. Bununla beraber, Columnar Mimarisi, Data Skipping Teknolojileri, Yüksek-Oranlı veri sıkıştırmaları gibi yetenekler de In-Memory VeriTabanları’nın uygulanabilirliğini arttırmıştır.

In-Memory Veritabanlarının ilk uygulamaları ad-tech işindedir. Örneğin bir ticari web sitesine logon olduğunuzda, size uygun ürünlerin teklif edilmesi veya size uygun reklamların önünüze çıkması ad-tech olarak adlandırılır. Bütün bunlar ancak ışık hızı ile yapılan analiz uygulamaları yani arka planda In-Memory VeriTabanları ile mümkün.

Veritabanı üreticileri de bu gelişmelere kayıtsız kalamayacakları için geleneksel ürünlerine In-Memory Database özellikleri eklemekte ya da yeni ürünler çıkarmaktadır.

 

Gerçek hayatta In-Memory Veritabanları ve Hadoop Platformları birbirlerinin tamamlayıcı olarak karşımıza çıkarlar. Kurumsal Big Data Mimarilerinde denklemin bu iki yanını bir araya getiren işletmeler diğerlerinden bir adım önde olacak.

İlişkisel Model’den, NoSQL’e

Veri Tabanı ile çalışmayan kalmadı. Klasik uğraşı alanları, DBA, Uygulama Programcısı, Veri Modeli Tasarımcılığından, Veri Madenciliği, Veri Bilimcisi gibi yepyeni iş alanlarına kadar türlü çeşit uzmanlık alanı ortaya çıktı. Yazılımla uğraşıp, SQL (Structured Query Language) bilmeyen ve duymayan da kalmamıştır herhalde.

NoSQL’de bu dönem o şekilde. NoSQL 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 ortaya çıktı. Bu belirleyici faktör özellikle veri modelcilerin bakış açılarını da değiştirmesini gerektiriyor. Ama Nasıl ?

Ölçekleme Modeli

Ölçekleme açısından bakılınca, İlişkisel Model, “scale up” olarak adlandırılan bir teknolojidir. Kapasite eklemek için, gerek depolama ünitesi, gerekse I/O artışı anlamında, daha büyük sunucular almak gerekir, yani dikine büyüme. Yeni Uygulama mimarilerinde ki bakış açısı ise tam tersi olan “scale out”, yani büyüme ihtiyacı olduğunda sunucuyu dikine büyütmek yerine, göreceli olarak daha ucuz sunuculardan eklenti yapmak, sanallaşmak veya bulut hizmeti alarak bütün bu birleşimi bir load-balancer’ın arkasına dizerek sanki “devasa bir sunucu”ymuş gibi hizmet vermektir, yani enine büyüme. “Scale Out” kavramı uygulama sunucularında uzun süredir var olmakla birlikte, veritabanı sunucularında da artık kullanılagelmektedir.

Veri Modeli

Veri Modelleme açısından bakınca, bilindiği üzere, ilişkisel modelde veri tabanına kayıt girilmeden önce, şema ve veri modeli tanımlanır, girilecek veriler bu yapıya uygun olmak zorundadır (veri tipi, veri uzunluğu, vb.). Her kayıt aynı yapıya sahip olmak zorundadır. NoSQL modelinde, kayıt girişinden önce veri modelinin oluşturulması zorunluluğu yoktur. Örneğin:

Bir NoSQL kayıtı aşağıdaki gibi gözükür. Kayıt içindeki elementlerin bir veri tipi olmamakla birlikte, kendi kendilerini açıklayacak istenen isim verilebilir. XML, HTML ve JSON yapıları buna en güzel örneklerdir.

{

“ID”: 1,

“ERR”: “Out of Memory”,

“TIME”: “2004-09-16T23:59:58.75”,

“DC”: “NYC”,

“NUM”: “212-223-2332”

}{

“ID”: 2,

“ERR”: “ECC Error”,

“TIME”: “2004-09-16T23:59:59.00”,

“DC”: “NYC”,

“NUM”: “212-223-2332”

}

Veri denormalize olarak saklanır.

Bu kısacık girişle bile yıllardır ilişkisel veri modeli ile çalışanların nasıl yani der gibi olduğunu duyabiliyorum. 40 yılın alışkanlıklarını kırıp, yeni bir bakış açısı getirmek çok kolay değil. Örneğin NoSQL dünyasında döküman nurması tek ve yeterli Primary Key ve Index. Bu ID genellikle her Database’de bir tane olması yeterli. Halbuki ilişkisel modelde her tablo veya şema için ayrı Primary Key’ler düşünmek gerekiyor.

Sonuç olarak NoSQL veri tabanları bizlere aşağıdaki yeni imkanları sunuyor.

-        

   - Verinin ticari sunuculara dağıtılarak enine büyüme yöntemi ile daha az maaliyetli bir büyüme

      - Uygulamaların yazılmasından önce, kuralları önceden belirlenmiş veri modelleri ve şemaların tanımlanmasına, sonrasında bunlar üzerinde değişiklik yapmak için belirli kesintilerin olmasına imkan vermeden hızlıca kod geliştirilebilmesine imkan verme.

-      - Zengin ve sınırsız veri modelleme imkanları ile karmaşık veri modelleri ve sorgulamayı daha kolay sağlama.

NoSQL mimarisi denormalizasyondan dolayı, daha fazla saklama alanı kullanma ihtiyacı olsa da, performans, ölçeklenebilme ve esneklik konusunda getirdiği yenilikler, veri tasarımcılarını seçim konusunda daha yenilikçi düşünmeye yönlendiriyor.