NoSQL’in Kısa Tarihi

01 Temmuz 2015 Hakan Sarıbıyık Nosql, 4

1 NoSQL’in kısa tarihi

1.1 Eski Güzel Günlerin Bitişi

Eskilerin geçmişi “ah o eski güzel günler” diye andığını ve yeniler için ise “o eski güzel günlerin” henüz gelmediğini bilerek yaşadığımızda, her yeni oluşumun kendine has güzellikleri ile geldiğini de bilmeliyiz. Bilgi teknolojileri dünyasının eski güzel günlerinde, eldeki problemin çözümü için gerekli olanlar az sayıda seçenek arasından seçilirdi. Genel maksatlı bir programlama dili, bir veri tabanı çözümü, bir donanım seçilir ve gerisi şelale tipi proje planının uygulanmasından ibaret olurdu.

Özellikle 2000 li yılların başından itibaren yaşanan gelişmeler ile “eski güzel günleri” bir daha gelmemek üzere geride bıraktık. Hayatın ve bilginin hızlı akışı ile eski alışkanlıklar bir bir değişiyor. Bu oturmuş bir düzende kaçınılmaz olarak “eskiler” ve “yeniler” arasında bir mücadele yaşanmasına da yol açıyor. Eskiler derken, her şeyi kastediyoruz, insanlar, teknolojiler, yöntemler, alışkanlıklar.

Tek bir yazıya sığmayacak kadar geniş olan bu konuda, bu yazımızda amacımız birçok kaynaktan zaten gelişmeleri takip eden siz okurlara farklı bir açıdan genel değişiminin ne olduğunu göstermek olacaktır. Bu yazı fikri, internetten izlediğim bir Renk değiştirme kart numarası videosunu seyrederken uyandı. Bu videoda numarayı yapan kişi, destenin içinden karşısındaki kişinin seçtiği rastgele bir kartın arka rengini el çabukluğu ile değiştiriyor. Numara bittikten sonra ise bu numarayı nasıl yaptığını daha geniş açıdan çekim yapmış bir kameranın yardımı ile görüyoruz. O da ne? Meğerse değişen sadece kartın rengi değilmiş, ekranda görülen her şeyin rengi değişmiş oysaki. Bu video bize dikkatimizi verdiğimiz şeyden büyük bir resim olduğunu ve bu resmi anlamanın gerçek değişimi anlamak olduğunu gösteriyor. Bu nedenle önce büyük resimde nelerin olduğuna bakarak başlayacağız.

Değişim Öncesi

1.2.1 Büyük Resim

2009 yılına kadar, verilerin saklanması ve erişilmesi probleminin çözümü için geliştirilmiş başka veritabanı sistemleri var olsa da, İlişkisel Veri Tabanı Yönetim Sistemleri (RDBMS) bilgi teknolojileri dünyasında ezici bir üstünlük kurmuştu. Bu nedenle ‘veri tabanı’ dendiğinde ilişkisel kelimesi kullanmaya gerek duyulmazdı.

1960 lı yıllara geri gittiğimizde, verilerin saklanması ve bu saklanan verilere hızlı ulaşım problemi için birkaç çözüm önerilmişti. Bunlardan hepimizin bildiği ilişkisel veri tabanları, kümelerin üzerinde tanımlanan ilişkilere dayanmaktadır. Bu yapı üzerine kurgulanan Yapısal Sorgu Dili (SQL), esasen iki kümenin kesişimi, birleşimi, farkı, kartezyen çarpımı gibi kavramların komutlara dönüştürülmüş halidir. Hal böyle olunca, saklanan verinin belli bir yapıda olması, bu yapının da tablolara dayanması çok şaşırtıcı gelmiyor. Esasen bunun arka planında, iş dünyasında dijitalleşme olmadan çok önceleri yaygınlaşan tablo formatlı muhasebe tabloları ve bunun devamı olan ve günümüzde de yaygın olarak kullanılan MS Excel gibi SpreadSheet uygulamalar vardır.

Bu temel yapının üzerine, veriye erişimin hızlanması için indekslemeler, güvenlik için erişim yetkileri, yerden tasarruf için sıkıştırma algoritmaları, zaman içinde çıkan bu problemlerin dışındaki önemli bazı problemlerin çözümü için Atomiklik, Tutarlılık, İzolasyon, Sağlamlık (ACID) kelimeleri ile özetlenen özellikler geldi.

İlk Alternatifler

İlişkisel veri tabanlarına alternatif arayışlarının geçmişi 1970 lerin sonlarına gider. Alternatifler derken üç ayrı grubun var olduğunu baştan söylemekte fayda var.

1.2.2.1 Birinci grup

1.2.2.1.1 NoSQL veri tabanları

Veri modelinin ilişkisel olduğu fakat sorgu dilinin SQL olmadığı gruptur. Bu grubun iyi bir örneği olan Ingres veritabanı 1970 ile 1985 arasında gelişti ve 1980 lerin başında ORACLE ile rekabet ediyordu. Sorgu dili SQL değil Quel di. Her ne kadar rekabete dayanamadıysa da, küllerinden Sybase, MS SQL Server gibi veri tabanları doğdu. Hatta Postgres projesi ile (Post Ingres) PostgreSQL e evrilmiştir.

NoSQL kelimesini ilk olarak kullanan, 1998 yılında geliştirdiği açık kaynak kodlu ilişkisel veri tabanına sorgulama dili olarak SQL kullanmadığı için NoSQL DB ismini veren Carlo Strozzi dir. Kendisi bu nedenle, şu anda ilişkisel olmayan veri modeline dayanan veri tabanları için yaygın olarak kullanılan NoSQL kelimesi yerine NoREL (No Relational) kelimesinin daha uygun olacağını belirtmiştir. Yani ilk kullanıldığında NoSQL gerçekten ‘SQL i olmayan’ anlamında kullanılmıştır.

1.2.2.2 İkinci grup

İlişkisel veri modeline dayanan ama kayıtların satır bazında değil sütün bazında tutulduğu veritabanlarıdır.

1.2.2.2.1 Kolon bazlı ilişkisel veri tabanları

1996 yılında Sybase IQ, ilk kolon bazlı analitik platform oldu.

1.2.2.3 Üçüncü grup

Veri modelinin de farklı olduğu veri tabanlarıdır.

1.2.2.3.1 Nesne ilişkili veri tabanları

Nesne tabanlı yazılım dillerinin yaygınlaşmaya başlaması ile birlikte nesne ilişkili veri tabanları (object relational databases) öne çıksa da yaygınlaşması mümkün olmamıştır. En büyük avantajları veritabanı ile uygulamanın geliştirildiği programlama dilinin aynı veri modelini kullanıyor olmaları idi.

1980 sonrasında nesne tabanlı veri tabanları konusunda ciddi çalışmalar ticari ürünlere dönüştü. GemStone (Smalltalk), Objectivity/DB gibi nesne veri tabanları örnek verilebilir. 1981 de ‘UNIX üzerindeki bilgi’ Informix (INFORMation on unIX) adı verilen nesne ilişkili bulit-in desteği olan Informix DB kullanılmaya başlandı.

1.2.2.3.2 Anahtar-değer (Key-Value) veri tabanları

Verilerin bir anahtar değere ve buna karşılık gelen herhangi bir tipteki veriyle birlikte tutulmasıdır. Örnek olarak telefon rehberindeki telefon numaraları ve karşı gelen ad soyad bilgilerini verebiliriz. Tabii anahtar değerin tekil olması zorunluluğu vardır. Bunun bildiğim en erken örneği 1970 li yılların başında MUMPS (Massachusetts General Hospital Utility Multi-Programming System) ın şemasız M veri tabanıdır.

1.2.2.3.3 Graf veri tabanları

Graf teorisine dayanan ve verinin düğümler ve bu düğümleri birbirine bağlayan bağlantı çizgileri ile ifade edildiği bir veri tabanı yapısıdır. Bu bağlantılar doğrudan gösterge (pointer) denen bellek adresi ile verildiği için indeksleme ihtiyacı olmadan hızlı erişim olanağı verir. Graf teorisinin temel uğraşları olan iki düğüm arasındaki en kısa yolun bulunması, alt grupların belirlenmesi gibi sorulara graf veritabanları ile hızlı şekilde cevap bulunabilir. Uzun yıllar ilişkisel veritabanlarının gölgesinde kalmış olsalar da son zamanlarda yeniden popülerlik kazanmaya başlamıştır.

1.2.2.3.4 Alana özel veri tabanları

Bu kategoride, belli bir iş alanına özel ihtiyaçları karşılamak için özel olarak dizayn edilmiş veritabanlarını toplayabiliriz. Bunlara örnek, 1980 li yılların başından itibaren Electronic design automation (EDA or ECAD) entegre devre veya baskılı devre kartları gibi elektronik sistem tasarımı yapan şirketlerin kullandıkları yazılımları desteklemek için geliştirilmiş EDA database elektronik dizayn veritabanı. 1986 yılında kurulan Amerikan Synopsys şirketi bu alanda önde gelen firmadır.

1.3 Değişimin başlaması

Anlatılan bu büyük resmin değişiminde, Web in 90 lı yıllarda gelişip yaygınlaşmasının katkısını en ön sırada görebiliriz.

1.3.1 CAP Teoremi

Bu bakımdan CAP teoremi olarak anılan ve

“Dağıtık bir sistem inşa ederken, olmasını isteyeceğiniz üç özellikten; tutarlılık (consistency), cevap verebilme (availability) ve ağdaki parçalanmalara tolerans (tolerance of network partitions) dan sadece ikisine sahip olabilirsiniz.”

şeklinde özetlenebilen teoremin ilk olarak Eric Brewer tarafından 1998 yılında ortaya atılması şaşırtıcı değildir. Temel bileşenler;

• Tutarlılık (Consistency): Bütün düğümlerden aynı veri görülür, tutarsızlık yoktur.
• Cevap verebilme (Availability): Her talep bir şekilde cevaplanır, olumlu veya olumsuz.
• Ağdaki parçalanmalara tolerans (tolerance of network Partitions): Ağdaki problemler nedeni ile düğümlerin birbirlerinden haber alamamaları, kopmaları durumlarında bile sistemin operasyonuna devam edebilmesi.

CAP Teoremi dağıtık sistemler konusunda çalışan araştırmacıların ve uygulayıcıların zaman zaman eleştirdikleri, üzerinde tartışmaların yapıldığı bir konudur. Bu bakımdan, Eric Brewer’in 12 yıl sonra konu hakkında yayınladığı yazısı meraklısının ilgisini çekebilir. Konu hakkındaki örnek bir tartışma için Daniel Abadi’nin yazısına ve gelen yorumlara bakabilirsiniz. Esasen bu üç özellikten; Tutarlılık ve Cevap verebilme, ağda parçalanma olduğu zaman birbirleri ile rekabet eden iki özelliktir. Bu teoreme pratik bir uygulama örneğini Brewer şu şekilde veriyor. ATM lerde para çekme, para yatırma ve bakiye sorgulama sistemini ele alalım.

Tutarlılık her zaman istenen bir özellik midir? Yani C A yı yener mi? Teorik olarak evet, fakat pratikte hayır. Yüksek hizmete açık olma (availability) yüksek gelir ve müşteri memnuniyeti anlamına gelmektedir. Ana kural bakiyenin sıfır veya üstünde olmasıdır. Bunu ihlal edecek operasyon para çekme olacağı için buna özel önem verilmelidir. Diğerleri her zaman çalıştırılabilir. ATM dizaynı yapanlar ağda kopma olduğu zamanlarda para çekmeye engel olmalıdırlar. Bu ise çok kısıtlayıcı bir etki olarak hizmete açık olmayı (availability) düşürür. Bunun yerine tek başına çalışma modunda belirlenen bir miktar kadar para çekilebilmesine izin vermek çözüm olabilir.

1.3.2 Hadoop un doğuşu

Web in hızlı bir gelişim sürecine girdiği 2000 li yılların başlarından itibaren oyunun kuralları yavaş yavaş değişmeye başladı. Bu yavaş değişim 2009 yılında ki büyük patlamaya kadar daha çok webde doğan Google, Yahoo!, Amazon gibi şirketlerin, kendi problemlerine çözüm çabaları olarak bilindi ve sınırlı bir alanda etkili oldu. Birçok bilgi teknolojileri çalışanı dahi gelişmelerden habersizdi. Değişimin fitilini ateşleyen Google un yaptığı çalışmaları makale olarak yayınlaması, bilgi birikimini kısmen de olsa dünya ile paylaşması oldu. 2003 yılında The Google File System, 2004 yılında MapReduce, 2006 yılında Bigtable makaleleri yazılım dünyasında heyecan uyandırdı. Açık kaynak kodlu, dağıtık, kümeleme yapısı üzerinde veri işleme yapabilen mimari üzerine kurulmuş bir çözüm için şartlar hazırlanmıştı.

2002 yılında açık kaynak kodlu bir Web arama motoru yapmak için kolları sıvamış olan Mike Cafarella ve Doug Cutting topladıkları text veriyi işleme konusunda uygun bir çözüm üretmeye çalışırken Google un makalelerini okudular. Nutch ismi verilen ve amacı web i tarayıp topladığı veriyi indeksleyerek etkin bir arama motoru yapmak olan ana projede ihtiyaç olan, dağıtık bir veri işleme altyapısı olarak, Cutting in Hadoop ismini verdiği benzer bir yazılımı geliştirmeye başladılar. Bu noktada Yahoo!, Cutting i işe alarak oyuna dahil oldu. Altı ay içinde Yahoo! nun kullandığı teknolojilerden birisi oldu, iki sene sonra ise vazgeçilmezi haline geldi.

Hadoop ile güçlendirilen veri analizi, reklam alanında kişilerin ilgileri ve reklamın hedef kitleye ulaşması konusunda yapılan analizlerde kullanıldı. Yapılan analizlerden birisi kişilerin browser homepage ini değiştirmesine neden olan hikayeyi ortaya çıkarmaktı. Yahoo on milyonlarca dolar harcadığı tahmin edilen Hadoop u açık kaynak olarak tutmaya devam etti. Bu değişimin ateşinin çok uzaklardan görülebilmesini sağladı. 2008 yılında Microsoft, kendi arama sistemini geliştirmek için doğal dil işleme yöntemlerini kullanarak arama sorgusu problemini çözme konusunda çalışan ve Hadoop a destek veren start-up firmalarından Powerset‘i satın alarak oyuna girdi. Satın alma sonrasında bu desteğin devam etmesi konusunda yeşil ışık yakarak Hadoop un geliştirilmesine destek verenlere katıldı. Facebook elindeki milyarlarca fotoğrafı işlemek için Hadoop teknolojisini kullanmaya başladı.

1.3.3 Değişimin katalizörleri

1.3.3.1 Çevik yöntemler

Bu yöntemler şemasız çalışmayı destekleyen yöntemlerdir. BT projelerinin iş ihtiyaçlarından kaynaklı hızlı değişim ve gelişim taleplerine cevap verebilmesi nedeni ile çevik (agile) yöntem ve benzerlerinin popülerliği artmıştır.

1.3.3.2 Polyglot programlama

Gittikçe artan bir şekilde, genel uygulama dilini belirlemek ve o dilde uzman geliştiricileri projeye dahil etmek kendi başına yeterli olmadığı, çıkan alt problemleri çözmek için farklı programlama dillerini kullanmanın olağanlaştığı bir döneme girildi. Tek bir programlama dilinin yetmediği bir dönemin başladığını ilk haber verenlerden birisi olan Neal Ford, 5 Aralık 2006’da bloğunda Polyglot Programming‘i tanımlarken şöyle demişti:

“tek bir genel maksatlı dil ile uygulama yazma devri kapanmıştır, alana özel dilleri eklemeye başlayacağız.”

Bu iddia temel olarak bir lisanı öğrenen insanların diğer lisanları öğrenirken temel kavramları zaten bildikleri için çok hızlı bir şekilde öğrenebileceklerine dair yapılan araştırmalara dayanmaktadır. İnsanların konuştukları dillerde olduğu gibi, programlama dillerinde de geçerli bir çıkarım olduğu düşüncesi temelinde şekillenmektedir.

1.3.3.3 Polyglot dayanıklılık

Scott Leberknight, 15 ekim 2008 de yazdığı yazıda programlama dillerindeki polyglot kavramını veritabanı dünyasına uyarlıyor. Dayanıklılık (persistance) kelimesi, zor koşullar altında ayakta durma, kendine verilen görevleri yerine getirme için kullanılmaktadır. Polyglot Persistance, veri tabanlarından beklenen persistance özelliğinin tek bir veri modeline dayalı olarak istenen şekilde sağlanmasının, mevcut problemlere istenen performans özelliklerini kazandırmak için yeterli olmadığı fikrini savunuyor. Farklı veri modellerine dayanan birden fazla veri tabanlı çözümlerin yaygınlaşacağını iddia ediyor. Bunun anlamı aşağı yukarı benzer yapıya sahip, benzer performans özellikleri olan alternatifler içinden bir Veri Tabanı Yönetim Sistemi (DBMS) seçme devrinin kapanmasıdır. Eski güzel günlerin baskın ilişkisel veri modeli artık hiç düşünülmeden seçilen bir veri modeli olmaktan çıkmaya başlamıştır.

1.3.3.4 Entegrasyon

24 Kasım 2008’de yazdığı bir yazıda Martin Fowler; 1980 li yıllardaki nesne ilişkili veri tabanlarının yaygınlaşmamasının en önemli sebebinin, ilişkisel veri tabanlarının bir entegrasyon aracı olarak ve SQL in bir protokolmüş gibi değişik uygulamaların birbiri ile olan veri alış verişinde kullanılıyor olmasından kaynaklandığını söylemektedir. Alternatif yolların özellikle Webservice lerin çıkması ile, çoğunlukla XML formatlı text dokümanlar kullanılarak uygulamaların birbirleri ile sql olmadan konuşmaları sağlanarak, farklı veri tabanları kullanmanın önündeki en önemli engelin aşıldığını öne sürmektedir. Her uygulamanın kendi veri modeline en uygun olana karar vermede hiç olmadığı kadar özgür olduğunun değişimin en önemli sebebi olduğunu dile getirmiştir. 16 Kasım 2011 tarihli yazısında da konuyu daha geniş kitlelere duyurmuştur.

1.4 NOSQL 2009

Last.fm isimli, kişilere dinledikleri müziğe göre önerilerde bulunan (music discovery & recommendation system) bir firmanın Londra’daki ofisinde çalışan Johan Oskarrson, yukarıda özetini verdiğimiz gelişmeler sonrası popüler olan Hadoop konusunda son gelişmelerin konuşulup tartışılacağı Hadoop Submit e katılmak için Haziran 2009’da San Francisco ya gitmeye karar veriyor. Konu ile ilgili birçok kişinin orada olacağı düşüncesi ile katılımın ücretsiz olduğu açık kaynak kodlu, dağıtık, ilişkisel olmayan veri tabanları konulu bir etkinlik NOSQL meetup düzenlemek istiyor ve bloğunda bunu şöyle duyuruyor:

‘To make the most of the flight money I’m putting together a free meetup about “open source, distributed, non relational databases” or NOSQL for short.’

Oskarrson, kısa NOSQL kelimesini büyük ihtimalle tweeter da kullanmak ve akılda kalıcı olması nedeni ile üzerinde çok düşünmeden seçmişti. İlgi çok yoğundu, mevcut 100 kişilik katılımcı kapasitesi beş saatte doldurulunca, yoğun talep üzerine ek 50 kişilik kontenjan da açılmıştı.

O toplantıda kapalı kaynak kodlu Google un BigTable ı, Amazon un Dynamo su ve Yahoo! PNUTS’ından ilham alınarak yapılan, açık kaynak kodlu NRDBMS ler (NonRelational Database Management Systems) konuşuldu. Bu toplantı ilk olarak NoSQL kelimesinin ilişkisel olmayan (non relational) olarak kullanılmaya başlanması olarak alınabilir. Toplantıdaki içeriklere ulaşmak için tıklayın.

1.4.1.1 İsim arayışları

NoSQL isminin mevcut harekete, uygun olmadığı yolundaki eleştiriler alternatif önerileri ile birlikte geldi. Adam Keys tarafından Ağustos 2009’da Post-relational kelimesi önerildi. nosql-database.org‘un arşivlerine başlıklarda geçen NoSQL ve NOSQL kelimelerinin kullanımı olarak baktığımızda, NOSQLin 2 Kasım 2009 da Debasish Ghosh nun ‘NOSQL Movement’ yazısında ‘Call it NoSQL (~SQL) or NOSQL (Not Only SQL), the movement has a mission.’ ile geçtiğini görüyoruz. Yine aynı arşivde en son 15 Aralık 2009 da NOSQL i Nati Shalom un bloğundan alınan yazının başlığında ‘The Common Principles Behind the NOSQL Alternatives’ ve yazıda aşağıdaki resim görülüyor.

Sonrasında Not Only SQL açıklaması kullanılmaya devam ediliyor fakat NoSQL şeklinde yazılma kabul görüyor. Bu sitenin ana sayfasında da belirtildiği üzere:

‘The original intention has been modern web-scale databases. The movement began early 2009 and is growing rapidly. Often more characteristics apply such as: schema-free, easy replication support, simple API, eventually consistent / BASE (not ACID), a huge amount of data and more. So the misleading term “nosql” (the community now translates it mostly with “not only sql“) should be seen as an alias to something like the definition above.’

Sonuç olarak yanlış anlaşmalara yol açsa da NoSQL in bir alias olarak kullanılması genel kabul görüyor.

1.5 Günümüz

Açık kaynak kodlu, dağıtık, kümeleme yapısı üzerinde veri işleme yapabilen mimari üzerine kurulmuş çözümlerin sayısının arttığı, RDBMS ve NoSQL sistemlerin birbirlerine benzemeye başladığı bir dönemi yaşıyoruz. NoSQL ve Hadoop çözümlerinde SQL e benzeyen dillerin daha çok kullanılıyor olması, NoSQL veri tabanlarında kaçınılan join operasyonunun kolay ve etkin bir şekilde yapılabilmesini sağlayan ürünlerin ön plana çıktığı, SSD diskler gibi disk teknolojilerindeki gelişimlerin veritabanlarının mimarisine etki ettiği bir zaman dilimindeyiz. RDBMS lerde olan birbirine çok benzeme, en azından yakın zamanlarda NoSQL veritabanları için geçerli olmayacak gibi görünüyor. Bir projede farklı veritabanları kullanmanın sıradan olduğu bir döneme giriyoruz. Stream verinin işlenmesinin yaygınlaşması sonucu dağıtık işleme yapma özelliğinin batch ile birlikte stream özelliği kazandığını da görüyoruz. Bu ise diske yazmadan RAM yani bellekde verilerin işlenmesine dayanan in-memory veritabanlarının daha çok kullanıldığı bir uygulama mimarisine götürüyor bizleri. Veritabanına özel saklama motoru (Storage engine) kullanmak yerine probleme uygun saklama motoru kullanmaya izin veren veri tabanlarının öne çıktığını görüyoruz. Hatta yıllardır kullanılan saklama motorları yenileri ile değiştirilmeye veya alternatif olarak sunulmaya başlandı. Örnek olarak CouchDB nin yeni saklama motoru ForestDB Ekim 2014’de duyurulmuştu. MongoDB ninki okuma yoğun çözümler için MMAP, yazma yoğun çözümler için yeni storage engine WiredTiger, veya 3rd party diğer motorlar kullanılabilmektedir.

1.6 Sonuç

Yeni BT dünyasında, iş kullanıcılarının verilere erişim ve analiz konusundaki aylar alan ve ciddi maliyetler getiren isteklerinin karşılanması için NoSQL seçenekler yeni alternatifler sunuyor. Bu alternatiflerin değerlendirilmesi için eski alışkanlıkların değiştirilmesi gerekiyor. Yeni tip yazılımcı, veri analisti, veri bilimci kısaca veriden değer üretenleri daha çok konuda bilgi sahibi olmaları gerekecek dinamik bir gelecek bekliyor. Bu yazının bu anlamda faydalı olacağını umuyorum.

Big Data, BigTable, MapRed, NoSQLDB

R Programlama Dili MongoDB Replica Set Kullanımı