Wednesday, March 25, 2009

Proje Voldemort - II

Yeni nesil Internet sitelerinin gereksinimleri sebebiyle iliskisel modelden bir uzaklasma oldugunu onceki yazida belirttik. Buyuk olcekte calisan Google ve Amazon sirketlerinin sirasiyla Bigtable ve Dynamo teknolojilerini gelistirmis olmalari raslanti degil herhalde. Bu ihtiyac, yeni bir trend, ve anahtar-deger veri tabani gelistirme alaninda bir patlama yaratti - herkes, pek cok dilde, pek cok sekillerde kendi anahtar-deger veri tabani uzerinde calisiyor.

Dogal olarak, toz bulutu yere indiginde, kazananlar, kaybedenler daha belirginlesecek. Bu tur gelecegi olan paketi secmek IT programcisi icin onemli; isten ise, projeden projeye gecerken, yaninda goturebilecegi alet kutusunda daha az degisen arac kumesi tasiyabilir boylece. Bu daha az egitim masrafi demektir. Bir arac uzerindeki tecrubelerini ust uste koyarak, buyutup, derinlestirebilir.

Voldemort'a donersek:

VM onbellekleme isini tamamen kendi uzerine aliyor. Yeni nesil bir tabandan bekledigimiz zaten budur; Veri dagilimi, onbellekleme, cokusten kurtulma gibi "fiziksel" isleri ustune almasi. Bu tur programlama ile ilgisi olmayan (olmamasi gereken) ozellikler icin bizim yeni taklalar atmamizin gerekmemesi.

Veri dagilimi hakkinda onemli bir nokta, veriyi tekrar dengeleme (rebalancing) konusu. VM bir anahtara baktigi anda, onun hangi bolume (partition) gidecegini biliyor. Fakat bunu yapabilmesi icin bolum sayisinin bir kere set edildikten sonra hic degismemesi gerekli. Eger 20 tane bolumum var diyorsaniz, bu database yapisi, hep 20 bolum ile calismali. Bunun fiziksel makinalar ile alakasi ne?

Kurallar soyle. 1) Isterseniz birden fazla bolumu ayni makinaya esleyebilirsiz. 2) Bir bolum sadece belli bir makina uzerinde olabilir, baska makina uzerinde olamaz.

Burada amaclanan sudur. Kumenin fiziksel yapisi degisecegi icin anahtardan makinaya gitme kavrami, anahtardan bolume gitmeye cevrilmis, boylece sistemin degismeyen bir sey ile calisabilmesi saglanmis, fakat siz arka planda makina basina kac bolumun olacagina admin seviyesinde karar veriyorsunuz (tekil makina secimini VM arka planda kendisi yapiyor). Sisteminizin ihtiyaclari buyudukca ayni makina uzerinde daha az bolum gitmeye basliyor. En son olcekleme noktasinda, artik tek bolum tek makina uzerinde oluyor. Bu sistemin gelebilecegi en son nokta, bundan sonra makinalarin daha fazla kapasiteye sahip olmasi gerekli.

Bu pek kisitlayici degil bence, son derece esnek bir yapi. Dikkat edelim, bolum sayisi "soft" bir ayar ve herhangi (makul) bir sayi atamanin az sayida makine ile calisirken bile hicbir ek performans bedeli yok. O zaman projemizin ilk acilisinda DB bolum sayisi 30 diye baslayabiliriz, tek bir fiziksel makina olabilir, sonra daha fazlasi eklenir ve bolumler degismez. 1-15 arasi makina 1'e, 16-30 arasi makina 2'ye gitmeye baslar.

Tekrar dengeleme (rebalancing) islemi iste budur. Bunun dinamik sekilde yapilmasi uzerinde calisiliyor. Sahsen benim icin nihai baglamda onemli bir ozellik, ama yine de projeme hala bu olmadan baslayabilirim. En kotu durumda, Amazon EC2'de yeni bir database kumesi baslatirim, birinci kumeme baglanip tum verileri teker teker okuyup ikinci kumeye toptan sekilde yazarim. Sonra uygulama kodlarimi birinci kumeden ikinciye isaret ettiririm. EC2'de birinci kumenin makinalarini kapatirim. Bu kadar.

Onbellekleme hakkinda fazla detaya gerek yok. Bir buyukluk ayarliyorsunuz, ve islemeye basliyor. Kendi isini kendi yapiyor.

Depolama: Voldemort farkli "depolama" formatlari ile calisabiliyor. BDB dosya formati bunlardan biri, digeri ise MySQL. Bu noktada MySQL aptal bir veri kutusu olarak kullaniliyor sadece, biz kullanmayacagiz fakat bu ozelligin olmasi iyi. Eger sirkette mevcut MySQL admin bilgisi var ise, VM ham verisinin yedeklenmesi, vs. baglaminda, bu bilgiler MySQL seviyesinde devreye sokulabilir. Biz yedeklemeyi BDB dosya seviyesinde, rsync ile yapacagiz.

Cokusten kurtulma icin VM'in cozumu bir nodun verisini kismen "yedek olarak" diger kumelerde tutmaktir. Eger bir nod cokerse, ayni bolum, baska makinadan calismaya devam eder. Coken makina geri gelince bolum bilgisi geri alinir, isler eskisi gibi devam eder. Bu ozellik test edilmis ve isliyor.

Mimari olarak VM "hicbir sey paylasmayan (share nothing)" mimarisidir (cokusten kurtulma durumunda olan kopyalamanin "yedekleme" amacli oldugunu hatirlatirim). Internet'te yuksek olcegi baska turlu karsilamak mumkun degil zaten... Veri yatay olarak bolundu mu, tam bolunmeli. Ahmet, Bora makina 1'de ise, Can, Dogan makina 2 uzerindedir. Bu kisilerin yan bilgilerinin "tamami" da ayni makinalar uzerindedir. Hicbir sey paylasilmaz. Boylece isteklerin "cogunlukla" sadece tek bir makinaya giderek islerini bitirebilmeleri saglanir. Bu paralelizasyonun iyi isledigi anlamina gelir. Her istek, tum makinalari, surekli mesgul ediyorsa, bolunme iyi yapilmamis demektir. Bu durumda normal RDBMS yapisina geri donulmustur. Hicbir avantaj saglanmamistir.

6 comments:

onur said...

Merhaba Burak bey,

Yazilarinizi takip ediyorum gercekten onemli konulara deginiyorsunuz.

VM hakkinda yatay olcekleme konusunda diger nodelarla bilgi paylasmadigini yazmissiniz, peki server failure oldugunda o node'daki veriler ne oluyor?

Tum nodelarda data replicated olmasa bile en azindan her 1 node'da, diger baska 1 tane node'un backup'ini tutup, cokme aninda diger node'un yerini almasi gibi durumlar soz konusumudur?

Tesekkurler.

Burak Bayramli said...

Evet replikasyon destegi var, bilgi paylasmama sozunu "canli islemlerin basariyla gerceklesmesi icin bilgi paylasimi yok" olarak detaylamak daha dogru olurdu herhalde. Fakat cokusten kurtulma amacli olarak yedekleme yapiliyor. Hem Voldemort, hem de Schemafree bizim paket) bunu destekliyor. Replikasyon faktor parametresine gore (1,2,3,vs..) o kadar ek makinaya canli verinin kopyalanmasi mumkun. Tabii fazla abartmamak lazim, cok fazla replikasyon canli sistemin islemesini yavaslatir.

onur said...

Oracle Coherence Cache urunune lisans sorunlari yuzunden alternatif bir urun ariyordum, sanirim Voldemort bu cache urununun database versiyonu mutlaka deneyecegim.

Eger ilgileniyorsaniz Hadoop ve HBase hakkinda da makaleler yazabilirseniz inanin cok faydali olur, cunku bu konularda "anlasilabilir" bir kaynak bulmak zor.

Iyi calismalar dilerim.

YILDIRAY YILMAZ said...

Merhaba Burak Bey,

Öncelikle yazılarınız için teşekkür ederim. Konuyu daha iyi anlayabilmek için bir kaç sorum olacak.

1.Voldemort başka hangi alanlarda kullanilabilir?
2.Voldemort gibi anahtar/değer şeklindeki database'ler Twitter, Facebook gibi yüksek ölçekli sitelerde feedlerin alınması gibi durumlarda kullanılabilir mi?
3.Bu tip islemler icin RDBMS dışında baska bir yapı önerebilirmisiniz?

İyi çalışmalar.

Burak Bayramli said...

Pur caching cozumune ihtiyaciniz varsa, memcached iyi bir cozum. Biz Schemafree icinde memcached entegrasyonu yaptik, JAva kodlarina oradan bakabilirsiniz. Not olarak sunu da ekleyeyim; Biz Voldemort urununu kullanmaktan vazgectik, paylasilan listelerin guncellemesinde istedigimiz bazi ozelliklere sahip degildi ama bu urunden cok sey ogrendik,ve Schemafree projesini baslattik.

Hadoop yazilar olabilir. HBase'in performans problemleri var, onu listeden atmak zorunda kalmistik. Su yazi faydali

http://highscalability.com/anti-rdbms-list-distributed-key-value-stores

Burak Bayramli said...

Yildiray Bey,

Veriyi yatay olarak rahat bolebildiginiz ve yuksek olcek gerektiren herhangi bir yerde VM kullanilabilir. VM RSS Feed almak icin ne tur bir veri yapiniz var onu bilmeden konusamam, ama genel olarak ben hic bir rdbms ozelliginin eksikligini hissetmedim simdiye kadar, Facebook feed olusturmak icin bu yapiyi kullaniyor.

Ayrica biz Schemafree'ye ozellikle zaman bazli sayfalama ozelligi ekledik, bu yapida IdentifierCollection adli bir ozel objemiz var, bu obje uzerindeki get/put islemleri sirasiyla sayfa almak ve sadece "tek bir obje geri yazabilecek" sekilde ayarlandi. Boylece hep "en yeni" olani tabandan almak cok kolay oluyor, feed sistemi boyle bir ozelligi kullanabilir.