24 Jul 2015

İ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.

No comments: