Belki de NoSQL veritabanlarından bahsedildiğinde ilk akla gelen veritabanı mongoDB… Belge bazlı veritabanlarından biri olan bu veritabanın yine yüksek ölçeklenebilirlikle şemasız bir yapı sunuyor. Bu yapıda klasik ilişiksel veritabanlarında tablo olarak tanımladığımız yapının karşılığı kolleksiyon, tablonun satırları ise belge olarak nitelendiriliyor. Hızı, uygulama geliştirme sürecine getirdiği kolaylık, verileri binary olarak JSON formatında (BSON) tutuyor olması sahip olduğu diğer özellikler arasında.

MongoDB php den ruby’e bir çok programlama dili üzerinden kullanılabilmekte. Ayrıca dinamik sorgulama ve indeksleme yeteneğine sahip ve Redis‘te olduğu gibi bölümlenme (sharding) otomatik olarak sağlanıyor. Bölümlenmeyi tekrar izah etmek gerekirse bir tablodaki satırların ayrı ayrı yerlerde tutulması olarak tarifleyebiliriz.

Web uygulamalarında , ön-bellekleme ihtiyacı olduğu durumlarda, yüksek hacimli veriler çalışıldığında yada ölçeklendirme ihtiyacının olduğu durumlarda iyi bir çözüm olarak mongoDB değerlendirilebilinir.

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…

Klasik yaklaşıma göre bir uygulama uzun ömürlü ve sağlam olmadır. Ama artık eğilimler bu yönde değil. Yazılacak uygulamalar esnek olmak zorunda. Bu konu zaten yazılım mimarisininde önemli ilkelerinden biri. Gelecekte uygulamanın yeni ihtiyaçlar ve sıkıntılarda nasıl değişebileceğinin ele alınması ve bu durumu destekleyecek esneklikte yapılandırmaya gidilmesi gerekli. Peki nasıl mı?

Bir yazılım mimarı olarak geleceği görümeniz lazım. Bilgi ve tecrübeleriniz size işlerin nereye varacağını tahmin etmenizde yol gösterecektir. Uygulamanın, kullanıcıların ve işletmenin yapısına ne kadar hakim olursanız o kadar uzağı görebilirsiniz.

Esneklik sağlamaya çabalarken asıl amaçlanan hedefinizden asla sapmayın. Ek özellikler ve işlevler yüzünden asıl önceliklerinizi kaybetmeyin. Sonu gelmez ek özellikler okyanusunda boğulmamak için önce geminizi bitirin.

Bir diğer noktada uygulamanızın birimselliği(modülerlik). Değişime yatkınlık ve esneklik bakımından  birimlerin/sınıfların zayıf ilişkili (loosely coupled) olması ileride karşılaşabileceğiniz talihsizliklerden kolay bir şekilde kurtulmanızı sağlayacaktır.

Ve tabiki açıklık. Her türlü değişik düşünce ve yaklaşıma önyargısız yaklaşın. Uygulamaya katabileceklerini görmeye çalışın. Tabi gerekli gereksiz her yeni teknolojiyi uygulamanıza gömmeye çalışmaktan bahsetmiyoruz. Mümkün olduğunca basit ve sade bir biçim kurgulamaya çalışmalısınız. Kendi yarattığınız bir karmaşa ortamından kurtulmanız zor olabilir.

Bir düşünün…
Şu anda ilgilendiğiniz proje ne kadar çabuk değişebilir?
Çevrenizdeki değişikliklere ne kadar çabuk ayak uydurabilir?

MS-Sql server da yeni yaptığım geliştirmeleri canlı ortama aktarmam gerekiyordu.

Daha önceleri yakın geçmişteki işlemleri karşılaştırmak için sys.objects tablosundan yaptığım tarih  karşılaştırmaları işimi görüyordu ancak bu sefer durum daha farklı… Yeni tablolar, yeni yordamlar vs. vs. Durum böyleyken ne ekledim ne çıkardım bulmak çok daha  zor.

Fark betiği kolayca nasıl alırım diye düşünürken iki veritabanını karşılaştırmak için iki tane ücretsiz uygulama buldum;

DBComparer

Verdiğiniz iki veritabanını biraz yavaşta olsa tek tek tüm nesneler için karşılaştırıp ekrana çıkartıyor.
Bir yordama yada tabloya tıkladığınızda neyin farklı olduğunu görebiliyorsunuz. Ancak kötü yanı  bu sonuçları kaydedemiyorsunuz.

Free Database Compare

Access, MySQL  veritabanlarını da destekleyen bu uygulama diğerine göre daha hızlı çalışıyor ama uygulama daha amatör bir görünüme sahip.
Veritabanlarının o anki durumlarını kaydedip daha sonra  karşılaştırma imkanı da sunuyor.

Sonuçta ne yazık ki her iki uygulama da fark betiği oluşturmuyor.
Üstelik tabloların yaratma betiklerinde gerekmediği halde alanların dil bilgileri (collation) bulunuyor.

Peki ben ne yaptım?

Sonuçta farklılıkları bulmak için bu uygulamalar yardım etti ama fark betiği işi yine bana kaldı …