document-oriented database ^*

• (bkz: dod)
• (bkz: redis)(bkz: couchdb)(bkz: mongodb)
  
  ayrica windows azure storage'da blob service de buna ornek gosterilebilir.
  
  verilerin iliskisel ^* degil, sanki bilgisayariniza kayitli ayri ayri belgelermis gibi saklandigi, fakat bazilarinda index'ler olusturulabilen, bazilari da key ile get-put edilebilen veritabanlari.
• (bkz: nosql)
• facebook'da bu konuda yazdigim note'lardan derlediklerimi yazmak isterim. muhtemelen aklima geldikce editleyip yeni seyler ekleyecegim o yuzden konuyla ilgiliyseniz arada degisiklik var mi diye bakmaniz iyi olabilir. ote yandan yazdiklarim temel duzeyde sql, json, mysql gibi kavramlari bilmeyi gerektiriyor.
  
  belgeye dayali veritabani sistemleri, nosql ile tecrubesi olmayan ve uzunca sure sql tabanli [aslinda, daha cok iliskisel] veritabani kullanmis olan programcilar icin anlasilmasi o kadar kolay olmayan, biraz zaman ve dusunce tarzinda degisiklik isteyen bir konu. kisaca anlatmak gerekirse, icerisindeki en ufak anlamli veri hucresini bir “belge”nin olusturdugu ve icerdigi belgeler arasinda hic bir iliskisel baglanti kurmayan ayni zamanda da onceden tanimlanmis hic bir veri semasi icermedigi icin tablo gibi bir kavram icermeyen ve dolayisi ile belgelerin tanimlanmasinda kisitlamalar yapmayan veritabani sistemleri olarak ozetleyebiliriz.
  
  gunumuzde en populer iki document-oriented database sistemi mongodb ve couchbase. her ikisi de "document" yani "belge" olarak ifade edilen veri birimini tanimlamak icin json kullaniyor. yani temel olarak json belgelerini sakliyorlar.
  
  ornegin mysql kullanarak soyle bir yapi kurdunuz. (keske eksi sozluk'te entry icerisindeki linklere preview ozelligi olsa)
  
  http://pastebin.com/gny1m1sk
  
  nedir ? oncelikle adi “actors” olan bir tablo var, verilerimizi bu tablo iceriyor. sonra, bu tablonun bir yapisi var. bu tablo id, name ve groupid isimlerine sahip uc kolondan olusuyor ve bu uc kolonun da null disinda degerlere sahip olmasi gerekiyor. ayni sekilde veri tipleri de sabit: sirasi ile int, varchar(100) ve int olmak zorunda. bu tabloya ekledigimiz her kayit (row) birbirleriyle ayni tabloda olmak seklinde bir iliskiye sahipler.
  
  bu yapiyi couchbase veya mongodb'de tuttugumuzda ise olan biten sundan ibaret.
  
  http://pastebin.com/p8dlpqw6
  
  yani sql dunyasinda her bir row'a karsilik gelen birim, bir belge.
  
  simdi diyelim ki, bazi kayitlarimiz cinsiyet (gender) bilgisini de icersin istiyoruz. rdbms’de ne yapariz? alter table ile yeni bir kolon olustururuz degil mi? peki o veriyi icermeyen kayitlar ne olacak? evet, null ekleyecegiz. soyle ki;
  
  http://pastebin.com/vrx1nxnj
  
  yani neymis? bir tablodaki tek bir kayit icin bile degisiklik yapmamiz gerekse dahi, o tablodaki tum kayitlari etkileyecek sekilde tum tablonun yapisini degistirmemiz gerekiyormus. ayni isleme dod’de bakalim.
  
  http://pastebin.com/xdhepwpa
  
  ne oldu simdi ? ilk uc belge gender diye bir veri icerirken, digerleri icermiyor. cunku icermeleri gerekmiyor zira birbirleri ile tamamen ilgisizler, ayni sekilde belgelerin bazilari farkli sayilarda bambaska veriler de icerebilirlerdi ve bu veritabaninda bir belirsizlige yol acmazdi.
  
  sonuc itibari ile bir veritabani sistemi, verileri saklamaya yaradigi gibi ayni zamanda da o verileri gerektiginde geri vermeye yararlar. dolayisi ile simdi bunun nasil olduguna bakalim. yazinin burasina kadar ortak kavramlardan bahsettigim icin mongodb ve couchbase diyordum ama yolun geri kalanina couchbase ile devam edecegiz.
  
  couchbase temel olarak bir key-value store. yani bir key degeri icin bir value degeri belirliyorsunuz, sonra o key'i verdiginiz ve "nedir bunun degeri?" dediginizde size value degiskeninin degerini veriyor. cok basit. e o zaman json ne oldu ? diyeceksiniz. soyle ki, couchbase'de bir json belgesi saklarken ona ait key _id adli field oluyor ve bu field her belge icin unique bir deger tasiyor. value da tahmin edeceginiz uzere json belgesinin kendisi. dolayisi ile her belgeye, o belgenin _id key'i ile ulasiyorsunuz.
  
  yani daha once ornek verdigim sql tablosundaki satirlara ulasmak icin
  
  select * from actors where id=2;
  
  gibi bir sorgu yapiyor, dolayisi ile id'si 2 olan satiri aliyorsunuz.
  
  "e peki is mi bu? ne bilecegim ben belgenin id'sini ? ben trilyon tane belgenin id'sini mi ezberleyecegim?" diye sarlayabilirsiniz ki en dogal hakkiniz. iste bu durumda devreye view kavrami giriyor.
  
  bir view, javascript ile yazilmis bir map (zorunlu) ve bir reduce (opsiyonel) fonksiyonlari iceren ve belgelerin icerisindeki herhangi bir veya birden fazla field'i key olarak tanimlamamiza olanak saglayan dolayisi ile belgeler arasinda arama islemi yapmayi mumkun kilan bir yapi.
  
  soyle ki, daha once ornek verdigim sql tablosunda diyelim ki soyle bir islem yapmak istiyorsunuz.
  
  select * from actors where groupid=1;
  
  gordugunuz gibi arama yapma kriterimiz groupid, id degil. dolayisi ile siz couchbase'e istediginiz belgelerin id'sini vermiyorsunuz, onun da o belgelerin nerede olduguna dair bir fikri yok. tanimladigimiz view su sekilde oluyor.
  
  http://pastebin.com/z27rqwgt
  
  burada gordugunuz view'in map fonksiyonu. bu fonksiyon her zaman bir tane arguman (doc) aliyor. siz bir view olusturdugunuzda [cagirdiginizda demiyorum, aralarinda cok ciddi fark var] couchbase tum belgeler icin bu fonksiyonu cagiriyor, parametre olarak da her bir belgeyi gonderiyor. bu fonksiyon ornegimizde sunu yapiyor:
  
  eger belgede groupid field'i varsa, yeni bir key-value cifti yarat. key doc.groupid olsun, value ise doc'un tamami olsun.
  
  dolayisi ile belgelerimizin key'i eskiden id field'i iken bu view icin groupid haline geldi. dolayisi ile artik bu view'i cagirirken bir key belirtir (key=1) isek artik bize key'in degeri 1 olan belgeleri listeleyecek. dolayisi ile groupid'si 1 olan belgeleri almis olacagiz. aslinda sql mantigindan kendimizi soyutladigimizda cok basit bir islem (:
  
  peki olusturmak ile cagirmak arasinda ne fark var ? su fark var. tahmin edebileceginiz uzere 10 belgemiz varken dert degil ama 100 milyon belgemiz varken bir view'in map fonksiyonuna o 100 milyon belgeyi teker teker sokmak ciddi bir zaman ve is yuku yaratiyor, dolayisi ile bu is boyle yurumuyor olmali. dogru, siz bir view'i yarattiginizda couchbase onu development mode'da tutuyor ve development mode'daki view'lar aynen bu gerizekali yontemle calisiyor. adi uzerinde development, uzerinde degisiklik yapiyorsunuz ..vs.. filan fistik.
  
  siz view'i "tamam budur" diye son haline getirdiginizde ve production olarak isaretlediginizde ise [couchbase bu isleme publish adini veriyor] couchbase son bir kez bu yontemle tum belgeleri cagiriyor ve bu sefer farkli olarak bir de index olusturuyor. production'daki bir view ise indexe sahip oldugu icin artik cok daha kisa surede calisip, cok hizli bir sekilde cevap veriyor.
  
  reduce fonksiyonuna kisaca deginmek gerekirse, o da sql'deki aggregation islemlerini [group by, count ..vs..] yapmaya yariyor.
  
  temel olarak couchbase ve document-oriented database kavrami budur. mongodb'nin farkli olarak kendisine ait bir query dili oldugunu ve view yaratmadan veriler uzerinde direk arama yapabildiginizi eklemek isterim.
  
  not: pastebin linklerinin turkiye'den acilamadigina dair bir mesaj aldim, bu sorunu baska yasayan var mi ?
• (bkz: file system)
• relational database'lere göre tasarımların nasıl yapılması gerektiğine dair mongodb blog sayfasında paylaşılan güzel iki yazı. okumaya değer.
  birincisi
  ikincisi
  
  not: sırayla okuyunuz.