Tuesday, March 24, 2009

Proje Voldemort - I

SQL database'leri tahtindan etmek icin eforlar tam gaz devam ediyor. Google'in Bigtable veri tabani hakkinda yazdigi makale pek cok IT programcisi icin surpriz olmustu; Herkes veri depolamasi hakkindaki cekismenin hiyerarsik vs. iliskisel, ya da objesel vs. iliskisel duzlemde oldugunu dusunmekteydi. Iliskisel tabanlar girdikleri savasi 70'li yillarda kazandilar, fakat 21. yuzyilin Web uygulamasinin dehset gereklilikleri karsisinda onlar da yavas yavas mevzi kaybetmeye basladi. Gorunuse gore yuksek olcek dunyasinda kazanan ne objesel, ne hiyerarsik taban oldu. Kazanmaya baslayan giris seviye bilgisayar bilim dersinden hatirlayacagimiz o basit Hash veri yapisinin dagitik halinden ibaretti.

Iliskisel tabanlarin (RDBMS) sorunlarini onceki yazilarda gormeye baslamistik.

Eger ucuz, her yerde bulunabilen donanim (commodity hardware), ve open source bazli cozumler ariyorsak (bu noktaya donecegiz), verinin yatay bir sekilde degisik DB makinalarinda bolunecegini kabul ediyoruz demektir. Bunu kabul ettigimiz anda, zaten bir iliskisel tabanin tablolar arasinda tuttugu o guzel yabanci anahtar (foreign key) bazli iliskileri, butunluluk kontrollerini (integrity check) kullanmiyoruz anlamina gelir.

Veriyi niye yatay boldugumuzu hatirlayalim: Eger bir kullanici istegine servis etmek icin N tane DB makinasinda okuma/yazma yapiyorsak, bu olceklemeyi iyi yapamamisiz demektir. Her kullanici istegini ne kadar "tek" bir makinaya yonlendirebilirsek, o zaman DB kapasitesini arttirmak icin donanim, takviye makina eklemek o olcude yeterli olabilecektir. Yukler N makina yerine N+1 makina arasinda bolunurse, bu sistemin butunu icin bir ilerleme olacaktir.

Ek olarak, iliskisel sistemlerin bize cok kuvvetli indeks bazli, anahtar kolon olmayan kolonlar uzerinden sorgulama yapmamiza izin verdigini biliyoruz. Fakat Internet'in devasa veri depolayan sistemlerinde hicbir akillica sistem zaten ana anahtar kolonu haricindeki kolonlari sorgulamada kullanmaz. Kullaniyorsa da, bunu icin uygulama tarafindan ozel sekilde idare edilen bir veri yapisi kullanir. Facebook sisteminde "tum kadin kullanicilari bana getir" turunden bir sorgulama dusunebilir miyiz? Biraz abartsam da, isin ozu baglaminda anlatilmak istenen buna benzer bir durum.

Devam edelim: Onbellekleme ihtiyaci. Nesnelerimizi SQL uzerinden iliskisel tabana esliyoruz. Sonra onbellekleme ihtiyaci ortaya cikiyor, bu objeleri Hash temelli bir veri yapisina yaziyoruz! Zaten performans icin bu yapiya gecmisiz bile.. Bu baglanti bizim icin arka planda idare ediliyor, ama bu katmanlar arasinda cok fazla entegrasyon eforu demektir. RDBM -> ORM (Hibernate mesela) -> Cache -> Uygulama -> Kullanici derken pek cok katmandan geciyoruz, ve bu katmandaki her birimin ve onun bir alt katmanla olan iliskisi ayri ayri test edilmeli, uzun sure o sekilde kullanilmali ki problemler ortaya ciksin, duzeltilsin, vs. Ve tum bunlarin ustune yatay boldugumuz icin zaten o guzel JOIN kavramini kullanamaz hale geldik.

Biz kendi ihtiyaclarimiz icin arayisimizda yatay bolme, olcekleme dunyasinda tum RDBMS (ve OSS) temelli cozumlerin yari pismis oldugunu gorduk.

MySQL Proxy temelli cozumler de aslinda bizi hic tatmin etmedi. Hibernate Shards'da gelecek var gibi gozukuyor, fakat ORM uzerinde "bir katman daha" bizce fazla.. Zaten bu cozumlerin arkasinda gerekli enerjiyi de goremiyoruz; sebebi ortada. IT dunyasi bir kolektif butun olarak bir yone gitmeye baslamis, ve diger alternatilerden giderek oksijen cekilmeye basliyor. Couch DB'den baslayarak Amazon'un Dynamo yaklasimina kadar giden genis bir yelpaze bu. Dikkat edin: "Niye bu cozum" sorusuna cevaplardan biri olan "herkes yapiyor da ondan" cevabini en sona sakladim, cunku bu cok zayif bir iddiadir. Fakat tum usttekilerden sonra "niye herkes bunu yapiyor" sorusunun cevabini almis olduk herhalde, ve simdi butunun gittigi yonde kalmanin faydalarindan bahsedebiliriz. Bu tabii ki mevcut bilgiden ve tecrubelerden faydalanabilme avantajidir.

Voldemort

Aradigimiz sistemin ozelliklerine en iyi uyan Proje Voldemort oldu. Bu secimi yapisimizda onemli bir faktor suradaki yaziydi. Java arayuzu bizim icin cok onemliydi, iyi dokumantasyon, yatay dagilimin en bastan planlanmis bir konu olmasi cok onemliydi. Sistem buyudukce DB makinasi ekleyebilmeliyim ve aninda DB'nin kapitesi artmali. Bunun icin bir suru takla atmam, geceleri uyku kacirmam gerekmemeli.

Madem anahtar-deger veri tabanlari (hash tipi tabanlar yani) depolama kavramini daha basitlestirdiler, onlara erisim de hakikaten basit olmali. Couch DB anahtar-deger yontemi ustune bir de dokuman kavramini eklemis - hiyerarsik misin, hash misin? Nesin? Kafasi karisik bir teknoloji.

Voldemort bahsedilen tum gereksinimlere uydu. Su anda LinkedIn sirketinde canli/sonuc (production) ortaminda aktif olarak kullaniliyor. Performans problemleri yok (bir diger Java bazli cozum HBase hakkinda performans problemleri isittik, hemen arkamiza bakmadan kactik).

Veri Idaresi

Voldemort ile, mesela, objeler arasindaki iliskileri nasil idare edecegiz? User objesi dusunelim, onun arkadaslari User objeleri olsun. Voldemort'ta "store" kavrami var, bu iliskisel dunyadaki tablo kavramina tekabul etmekte. Bir User store'u olacak. Ayri bir Friendship store'u olacak. Kullanicilarin kendisi birincide, iliskileri ikincide depolanacak. Her iki store'da ana anahtar kullanici ID. Bu ID GUID bazli koca bir integer olabilir, ya da e-mail olabilir. Uygulamanin gereksinimleri bunu belirler.

Kullanici A icin makina #4'e gidebilecegim, o kullanicinin arkadas listesi, ID listesi olarak, o objenin uzerinde, anahtar-degerin deger kisminda yani, java.util.List'te olacak. Bazi ozet bilgiler denormalize olarak bu listede olabilecek. Detaylari gormek icin bir istek olursa, o arkadas ID'si kullanilarak makina #5'e gidilebilecek, ayni anda, A elindeki ozet bilgisi de guncellenecek. Bunu uygulama kodu halledecek. Diger makinalarda olabilecek B, C gibi kullanicilarin ellerindeki ozet onlar ayni detayi isteyene kadar guncellenmeyecek. Bu IT dunyasinda tembel okuma (lazy read) kavrami.. gercekten ihtiyaci olana kadar birine bir seyi vermeme durumu.

Voldemort arka planda veri bazli fiziksel bolmeyi yapacak, dokumanlarina gore sanal bolumler (partition) oncede tanimlanir, ve bir ID degerinin kendisi onu bir bolume esler. Bu bolunme icin "merkezi bir otoriteye" gitmek gerekmez, zaten bu yapilmamalidir, cunku olceklemenin ve cokuse dayanikliligin ilk kurali, merkezi otoriteden kurtulmaktir. Bu bolum, bir makina, yani bir fiziksel 'lokasyon' anlamina gelir. Bir ID'ye baktigimiz anda, hangi makinaya gidecegimizi biliyoruz demektir.

Open Source konusuna donelim. Eger yeterince paraniz varsa, o Oracle lisanslarina yuzbinlerce dolar atmaya devam etmek istiyorsaniz, muhakkak Oracle'i olcekleyebilirsiniz. Bu durumda "tek" tabanin "tek" makinasini buyuttukce buyutursunuz. Daha sukseli Oracle bolunme cozumleri mumkun, ama bu daha fazla ev ici (in house) DBA bilgisi gerektirir, tek bir ticari urune baglanirsiniz, ve Oracle sirketine daha fazla para kazandirmaya devam edersiniz.

Muhakkak SQL ve iliskisel tabanlar belli sistemler icin cok uygunlar. Fakat ideal kullanim haliyle, bir iliskisel tabanin ufak/orta olcek uygulamalar icin oldugu acik. Bir ORM kullanarak bile, nesnesel -> obje eslemesi hala "gariplikler" iceriyor, ve bu evlilik hicbir zaman dogal ve uygun bir evlilik olmadi, ihtiyactan dogan bir evlilik oldu.

Biz onumuzdeki yuksek olcek kullanimi icerecek proje icin Voldemort ile ilerlemeye karar verdik. Kullanilan diger teknolojiler Apache, JBoss, JBoss Seam, Javascript olacak. Hibernate ve MySQL'e ihtiyacimiz kalmadi.

2 comments:

Mustafa said...

Merhaba hocam,

Bu makale için çok teşekkür ederim. Ben de kendi çapımda şöyle bir proje yazıyorum (bu aralar scjp sınavına hazırlandığım için yarım kaldı) mysql in de kullandığı btree algoritmasına dayanan DiskMap isimli bir proje. Bu proje standart Map i implement edecek ama ram yerine disk üzerinde depolama yapacak. Burdaki amacım btree algoritmasını kavramak. Proje şuan %50 oranında tamamlandı bitince yayınlayacağım kodlarıyla. Makalelerinizin devamı bekliyoruz, oldukça işe yarar şeyler yazıyorsunuz tekrar teşekkürler. Bu arada rss abonenizim.

Burak Bayramli said...

Projenizde basarilar dilerim. Iyi calismalar.