Sayfalar

4 Şubat 2013 Pazartesi

NoSQL Nedir?

Merhaba, saygıdeğer bay/bayan bilişimci ( L&M İsmail abi tadında)

Önemi giderek artan bir teknoloji olan NoSql nedir? Neden çıkmıştır, ne işimize yarar ve geleceği nasıldır?

Aceleci olanlar için kısa tarifi: NoSql ilişkisel veri tabanındaki(RDBMS)  tüm verileri farklı tablolar yerine tek bir dökümanda saklayan veri tabanı modelidir. Bu nedenle döküman tabanlı veri tabanı denmektedir. Daha iyi anlaşılabilmesi için şöyle bir örnek vermek güzel olacak;
İlişkisel veri tabanlarında kişi, il, ilçe ve mahalle/köy tablolarını düşünün. Buna göre elimizde birbirlerine foreign key/yabancı anahtar ile bağlı 4 tablo var. Örnek olarak ta Ahmet arkadaşımız 20 milyonluk İstanbul'da yaşayan azınlık 2 milyon İstanbulludan biri olduğunu ve Üsküdar Altunizade'de yaşadığını düşünebilirsin. Buna göre nosql veri tabanında tüm bilgiler tam da burada yazdığımız/düşündüğümüz gibi saklanacaktır. Nereden olduğunu öğrenmek için birleştiren sorgular falan yazmanıza gerek yoktur. RDBMS de bu bilgileri toplamak için ilgili tüm tabloları birleştirmek gerekiyor. Sql sonucu ise döküman tabanlı veriye benzeyecektir. Burada hemen akla şu gelmektedir. Döküman tabanlı veri tabanında doğal olarak milyonlarca insanda birbirinin tekrarı milyonlarca bilgi olacağı kesindir. Bu da veri tabanı boyutunun büyümesine neden olacaktır. İlişkisel veri tabanı kullanıcılarının burun kıvıracağı bu noktada, şunu söylemek gerek, veri boyutu bilişim dünyasında şu an korkulacak en son şeydir.



Aslında NoSql isimlendirme konusunda biraz kafa karışıklığı oluşturmaktadır. İlk anlamı sql değil anlamındadır. Bu adın kullanılmasının en büyük nedeni yeni bir teknolojinin etkileyici bir şekilde sunulmak istenmesi olmalıdır. Diğer adları çok tercih edilmemiştir. Diğer adlarından bazıları NonRel, NoRDBMS (ilişkisel değil anlamında) 'dir. NoSQL için not only sql tabiri de kullanılmakta. Yani sadece sql değil deniyor. Bunun nedeni sql sorgularına alışmış geliştiriciler olarak aynı sorgu mantığının adapte edilmeye çalışılmasında yatıyor.

Yazının devamına bu yazı içinde birkaç alıntı yapacağım, Shashank Tiwari'nin Professional NoSql kitabının başlangıcındaki yaklaşımı olduğu gibi vermek güzel olacak.
Geliştiriciler dünyasında NoSql söz konusu olduğunda 3 yaklaşım var. Bunlar, sevenler, inkar eden/gereksiz bulanlar ve görmezden gelen/önemsemeyen  olmak üzere 3 gruptur.
Aslında bu yaklaşım sanırım tüm yeni teknolojiler için söz konusu. Konuyu anlattıktan sonra NoSql teknolojisinin önemine kendiniz karar verebilirsiniz.

Yıllarca ilişkisel veri tabanı öğrenmeye çalıştık. Çok ta alıştık ve her bilgiyi adapte edebilecek şekilde şemalar, tablolar düşünür olduk. Ancak internetin hızlanması ve çok sayılı kullanıcının işin içine girmesi bazı ihtiyaçları ortaya çıkardı. En büyük ihtiyaçlardan bir tanesi veri tabanı şemasının sıklıkla değiştirilmesi zorunluluğu oldu. Couchbase firmasının yaptığı bir ankete göre problemlerin en büyüğü (%50'ye yakın) şema esnekliğinin çok zayıf olması. Ama önce NoSql yapısının bize getireceği bir diğer faydayı da yazmak istiyorum.

ORM

Ben bir daha ayrıntılı şekilde yazmak istemiyorum. ORM ile ilgili kısa bilgiye (kısa bir araştırma sonrası bulduğum) bir başka blogdan, buradan, ulaşabilirsiniz. ORM hakkında şunu söyleyebiliriz ki, veri tabanı ile çalışan programlarda sistemi yoran, fazladan kodlar yazmanızı veya kütüphaneler yüklemenizi gerektiren bir teknoloji. Bu nedenle getirdiği avantajlara rağmen aslında çok tercih edilmek istenmemekte. Performans ile ilgili sıkıntıları da cabası. Google da kısa bir arama metni ile bu sorunu görebilirsiniz. NoSql yaklaşımının en sevdiğim yönü de burada geliyor. Verilerinizi okumak ve yazmak için oluşturduğunuz katmanı doğrudan veri tabanına kaydetsek daha iyi olmaz mıydı? Bir nevi class serialization gibi. Verileriniz için veri tipi sınırınız da yok. Oh ne âlâ. İlgili veriyi okuduktan sonra da olduğu gibi yazdırabilmek mümkün hale gelecektir. Bu kısa faydasından sonra anlatmaya devam ediyorum.

Satır-Sütun Veri Tabanı 

Konuyla ilgisi olmayanlar için bu başlık şu an hiçbir şey ifade etmiyor olabilir. Örneğimizden sonra yeniden başlığı düşünebilirsiniz.
Büyük bir kurum olduğunuzu düşünün. Diyelim ki her yıl  ve binlerce personelinizden 1 kişiye 10 kişiye artık kaç adet ise ödül verdiğinizi düşünün. Bu ödül alanlar veri tabanında nasıl tutulacaklar? Her sene 10 kişi için binlerce kişiye ödül yok veya NULL bilgisi ile dolu olan bir sütun açmakla başlanabilir. Sorguda daha zorlu olacaktır ama ilk başta bu tarz ihtimallerle karşılaşacağınızı düşünüp, ek bilgiler diye bir alt tablo açabilirsiniz veya diğer, vs gibi adlarla tanımlayacağınız bir sütun. Son sütunda ödül2010=1 gibi bilgi yerleştirebilirsiniz. Ancak değişiklik böyle basit bir şeyden çok daha karışık ise ne olur? Bir de sosyal oyun firması olduğunuzu düşünün. Milyonlarca kişi bilgisi tutuluyor ve zaman içerisinde binlerce yenilik yapılıyor oyunda. Bu bilgiler için bir daha bir daha veri tabanı şeması ile oynanabilmesi mümkün olabilir mi?
Bu sorunların üstesinden gelmek için verilerin satır olarak saklandığı yaklaşımdan, sütun olarak saklandıkları yaklaşıma geçmek gerekiyor. Şöyle ki;



Adı
Soyadı
TcNo
Ödül 2010
Ödül 2011
Abc
Abc
1231231
NULL
1
Def
def
567567
1
NULL
Fgh
fgh
3453453
1
NULL

Adı
Abc
Def
Fgh
Soyadı
Abc
def
fgh
TcNo
1231231
567567
3453453
Ödül 2010

1
1
Ödül 2011
1



JSON yazımı ile daha iyi anlaşılacaktır. 
{ "adi":"Abc","soyadi":"Abc","TcNo":1231231,"Odul2011":1 }
{ "adi":"def","soyadi":"def","TcNo":567567,"Odul2010":1 }
{ "adi":"fgh","soyadi":"fgh","TcNo":3453453,"Odul2010":1 }

Şemalara olan bağımlılık bu sayede çözülmüş oluyor. Ancak bu sefer de, bu verinin nasıl işleneceği/filtreleneceği/sorgulanacağı problemi ortaya çıkıyor. 

MapReduce

Biraz önce bahsettiğimiz çok kullanıcılı bir firmanın karşılaşabileceği problem ile tahmin edebileceğiniz üzere ilk Google karşılaştı ve bir çözüm geliştirdi. Büyük verilerin saklanıp nasıl işleneceğine dair bir teknoloji üretti.
  • Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. “The Google File System”; pub.19th ACM Symposium on Operating Systems Principles, Lake George, NY, October 2003.URL: http://labs.google.com/papers/gfs.html
  •  Jeffrey Dean and Sanjay Ghemawat. “MapReduce: Simplified Data Processing onLarge Clusters”; pub. OSDI’04: Sixth Symposium on Operating System Design and Implementation, San Francisco, CA, December 2004. URL: http://labs.google.com/papers/mapreduce.html             
  •  Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, and Robert E. Gruber. “Bigtable: A Distributed Storage System for Structured Data”; pub. OSDI’06: Seventh Symposium on Operating System Design and Implementation, Seattle, WA, November 2006. URL: http://labs.google.com/papers/bigtable.html
  • Mike Burrows. “The Chubby Lock Service for Loosely-Coupled Distributed Systems”; pub.OSDI’06: Seventh Symposium on Operating System Design and Implementation, Seattle,WA, November 2006. URL: http://labs.google.com/papers/chubby.html


Teknolojinin patenti kendilerinde ancak kullanılması konusunda bilişim dünyasını özgür bırakmışlardır. Eğer google'ın ürettiği bu teknoloji olmasa böylesine büyük siteler ve datacenter'lar kurulamayacaktı. Bu konuya belki talep olursa daha ayrıntılı değinebiliriz. Teknik açıdan çok önemli bir konu ancak, bizim gibi son kullanıcılar açısından şu an bu konuyu anlatmak meseleyi daha anlaşılır kılmayacak. Bu nedenle kısa geçiyorum.

Ölçeklenebilirlik

RDBMS veri tabanının en büyük problemlerinden bir diğeri ölçeklenebilirlik problemidir. Yukarıdaki resimde de görüleceği üzere ikinci problem bu. Bana kalırsa en büyük problem bu olmalı. Çünkü kullanıcı sayısı hızla artarken donanımı istediğiniz kadar da artırsanız bir müddet sonra hizmeti karşılayamayacak aşamaya geliyorsunuz.
Yandaki resimde de görüleceği üzere, bir noktadan sonra ne kadar sistemi geliştirirseniz geliştirin artık donanımınız hizmet veremeyecektir. Zaten maliyetler düşünüldüğünde de böyle bir hizmeti vermenin anlamı kalmayacaktır. 

Bu noktada mevcut RDBMS sistemlerini geliştirmek için çalışılıyor. NewSql dedikleri bu yaklaşımla mevcut yapıları gelişen şartlar karşısında hayatta tutulmaya çalışılmaktadır. 


Performans & Gecikme

Bu başlık altında farklı firmaların ürettikleri performans verileri var. Gerçek bir başarı örneği için zynga-couchbase ile ilgili bir grafiği paylaşmak istiyorum. 20 gündeki ortaya çıkan veri trafiğini düşünün. Diğer bir slaytta gecikmelerin 100 ms'nin altında olduğunu gösteriyordu.


Bu resimlerin kaynağı aşağıdaki sunumdadır. Bu sunumu da incelemenizi şiddetle tavsiye ederim. Aklınıza takılan bir soru varsa yorumlardan cevap yazmaya çalışacağım.

Sonuç

Yüksek internet hızı ve çok sayıda kullanıcının zorladığı teknolojik sınırlar insanları değişik çözümler üretmeye itmektedir. Şu an için değişken ve büyük veri yapıları için nosql kullanılabilecek yegane teknolojidir. Ancak başka zaman yine değinme ihtimalimiz olan fire and forget olarak adlandırılan bir özelliği var. Buna göre siz veriyi veritabanına gönderirsiniz. Yazıp yazmadığı hakkında bilgi beklemezsiniz. Sosyal oyun oynayanlar tecrübi olarak bilirler bu durumu. Devamlı birşeyler değiştirirler ve bunlar bir şekilde veri tabanında kayıt olur. Fakat bankacılık gibi sektörlerde bu özellik bir işe yaramaz ve hatta çok risklidir. Bunun için son güncellemeleri ile neredeyse tüm firmalar ACID kurallarını uygulamaktadırlar. Oracle'ın da nosql dünyasında olduğunu söylemek yeterli olacaktır sanırım.

Teknolojiyi geriden takip eden ve kullanan geliştiriciler olmak yerine yeni teknolojileri yakından takip ederek yeni işler üretmek ve ülkemize katkılar sağlamak dileğiyle. 

Sağlıcakla kalınız.

Kaynak Sunum: http://www.slideshare.net/sharonyb/couchbase-at-the-academic-bisilim-turkey

1 yorum: