NoSQL konusuna girince (bakınız NoSQL – Herşey SQL değil) bazı veritabalarına da detaylı bakmak gerekiyor.
Mart 2009′dan bu yana kullanıma açılan Redis’te bunlardan birisi…
Özellikle ön-bellekleme (caching) ve istatistiksel verileriniz için ideal bir ortam sunmakta.
Belge ve Anahtar-değer veritabanları grubu içerisinde yer alan Redis’in en büyük özelliği
veriyi bellekte tutması ve dolayısıyla da hızı.

Şimdi bu bellek olayını biraz açmak gerekiyor.
Sabit diske baktığınızda yapı olarak dayanıklı ve yüksek kapasiteli olmalarına rağmen
verilere sıralı erişim yapıyor olması yüksek performans gerektiren işlemlerde bir dezavantaj.
Gecikme sürelerine baktığınızda bellekteki bir bilgiye ulaşma hızınız ortalama bir hardiskteki aynı veriye ulaşma hızınızdan yaklaşık 10000 kat daha fazla.
Unutumadan söyleyelim Redis bellekteki bilgileri arada bir de diske yazıyor…
Bu iş için iki tip yöntem uygulanıyor; bellek kopyalama (snapshotting) ve sadece eklenebilir dosya (append only file)
Bellek kopyalama belirli aralıkla asenkron olarak tüm belleğin diske yazılması. En büyük dezavantajı ise bir çökme anında bazı verilerin diske yazılmamış olması durumu.
Sadece eklenebilir dosya yönteminde ise her yazma komutu çalıştırıldığıda bu bilgi loglanıyor ve sunucu şayet tekrar çalıştırılırsa bu komutlar yeniden işletiliyor.

Redis’e php, java, c#, ruby, python gibi bir çok farklı dil üzerinden erişebiliyoruz. Tabi telnet üzerinden de…
Veri tipi olarak string, list, set ve sorted set ile çalışılabiliniyor…
Replikasyon yapması çok kolay. Master-slave yapıda çalışan bu yineleme için
sadece hangi sunucunun uydusu (slave) olduğu belirtmeniz yeterli oluyor. Ayrıca bir uydunun altına başka uydular da bağlanabiliniyor.

Atlanmaması gerek bir diğer konu da dağıtık yapıya izin veren ve bölümlenme diye tabir edebileceğimiz sharding özelliği.
Basitçe bölümlenme bir bir veritabanındaki tablonun satırlarının ayrı ayrı yerlerde tutulması anlamına geliyor.
Bu yapılanma yine Redis içerisinde kolayca yapılabiliniyor.

Bitirmeden bir şey hatırlatmak isterim.
Verinizin miktarı elinizdeki bellekten daha büyükse redis’i tercih etmek yanlış olacaktır…

Daha fazla bilgi için : http://code.google.com/p/redis/

Bir nevi protesto gibi değil mi?
No sql!! Aslında anlatacağımız “Not Only SQL”…

Programcılık adına çoğumuzun yaptığı bir veritabanın olsun, yazdığın uygulama ona bağlasın, okusun, yazsın.
Kullandığımız uygulama geliştirme ortamına göre yazım şekilleri değişir ama iş veritabanı kısmına geldiğinde; select * from …

1998 yılında ilk kez Carlo Strozzi bu kelimeyi teleffuz ettiğinde sadece kendi yazdığı bir ilişiksel veritabanı yönetim sistemini tanımlamaya çalışmıştı.
Ancak 2009 yılının başlarında bu kelime artık daha farklı bir şey ifade ediyordu. NoSQL artık ilişiksel olmayan, dağıtık, şemasız, açık kaynak kodlu ve yatay olarak ölçeklenebilir yapıda olan yeni nesil veritabanlarına verilen bir ad olmuştu.
Bir sürü alt başlık altında gruplanabilen bu veritabanları da nereden çıkmıştı?
Bir anda ne oldu peki böyle oldu ?

Herşeyden önce depolanan veri miktarı çok ama çok artmaya başladı.
IDC verilerine göre 2006 yılında 161 milyar gigabyte veri oluşturuldu. Bu, şimdiye kadar yazılmış kitaplardaki bilgilerin 3 milyon katı.
Başka bir nokta ise bilgilerin birbirleriyle olan ilişkilerinin, bağlantılarının hergeçen gün daha da artıyor olması.
Mesela bir web sayfasındaki linkler yada blogdaki bir yazının üzerindeki etiketler…
Birde yapısallaşmaya doğru giden bir yol var ki artık elimizdeki veriyi tek bir ifade ile belirtemiyoruz.
Her bir varlık için daha çok daha fazla veri, parametre, ilişki vs. tutmamız gerekiyor.
Tabi alt yapılarımızda değişti artık bir uygulama + bir veritabanı formülünü çöpe attık diyebiliriz. çok uygulama + bir veri tabanı formülünün ise ömrü bitti bitecek.
Artık ayrık mimariden ve bulutlardan bahsediyoruz…

Klasik bir uygulama yazıyorsanız belki bunlar size çok şey ifade etmeyebilir. Ama sosyal ağları düşünün.
Twitter, facebook gibi çok büyük verilerle uğraşan sistemlerde veri karmaşıklığı çok yüksektir ve ilişiksel veritabanları bu durum karşısında performans sıkıntıları doğuracaktır.
İşte NoSQL veritabanları bu problemlere yönelim çözümler geliştirmek adında ortaya çıkan veritabanlarına verilen genel bir ad.
Bir çok alt başlıkta gruplanabildiğinden bahsetmiştik. Şöyle bir kaç belli başlı başlığa göz atalım;

• Key-Value (Anahtar – Değer): Büyük miktardaki veriyi ölçeklendirecek ve bu yükü kaldırabilecek şekilde tasarlanmıştır. Amazon’un Dynamo adını verdiği dağıtık veri depolama projesi bu kategorinin ilk örneğidir. Dynomite, Voldemort (LinkedIn), Tokyo diğerleri arasında sayılabilir. Bu yapıda her nesenin bir anahtar adı vardır ve bu anahtar üzeridnen nesneye ulaşılır.
• BigTable (BüyükTablo): İlişiksel veritabanlarına çok benzemekle beraber petabytelar seviyesinde ölçeklenebilmektedir. Ayrıca tablolar çok boyutludur (örneğin versiyonlama için zaman boyutu). Google’ın kendi uygulamaları için kullandığı bu veritabanın diğer alternatifleri HBase, Hypertable,Cassandra
• Document (Belge): Lotus Notes yapısından etkilenerek hazırlanmış bu veritabanları anahtar-değer yapısına benzer bir yapıdadır. Aradaki fark veritabanın değer kısmınıda biliyor olmasıdır. Örnek olarak CouchDB, MongoDB, Redis gösterilebilir.
• Graph DB (Grafik VT): Daha ziyade veri yapısının modellenmesi felsefesi üzerine kurulmuş bu tip veritabaları yüksek veri karmaşıklığını ölçekleyebilmektedir. Neo4j, AllegroGraph, Sones graphDB

Elimizdeki verileri nasıl sorgulayacağımız geldiğimizde bizlere yollar sunulmuş
Örneğin bazı veritabanları SQL alternatifi sorgulama dilleri geliştirmiş, bazısı ise kendi API’lerini oluşturmuş. Bazılarında veri üzerinde değişiklik için JSON gibi formatlar kullanılmış. Hepsi ayrı ayrı konuşulması gereken şeyler belki ama genel fikir şu;

Herşey SQL değil…

Kaynaklar: http://nosql-database.org/ sitesi bu işi size anlatacak yegane site diyebilirim. Konuyu daha çok sitede de bulabileceğiniz Tobias Ivarsson’ın sunumu üzerinden anlattım…