Azok a clusterezési technológiák és szoftverek, amik uniform szervereket várnak el futtatókörnyezetként, komoly hátrányban vannak azokkal szemben, amelyek képesek a hardware különbségeit (pl memória méret, elérési sebesség, sustainable és random IO, CPU-k száma és sebessége, hálózat, satöbbi) kezelni. Ugyanis az ügyfelek nem szeretnék évekkel vagy akár csak hónapokkal előre megvenni a hardware kapacítást. Pl egyes projectek esetében nem nagyon lehet kitalálni, hogy mekkora kapacításra van szükség. Meg hát nem is tudják, kapnak egy adott összeget egy üzleti évre és legközelebb majd a következő üzleti évben lehet hardware-t vásárolni. Akkor már más lesz a kinálat. Még ha mindig a listán is van a régi szerver tipus, akkor is valószinűleg más hardware fogja akkor megérni, más az akciós, satöbbi.
Például nekem a cassandra, amikor teszteltem nagyon makacsul ragaszkodott ahhoz, hogy egyenlően ossza fel a keyspace-t minden alkalommal, amikor új node-t csatlakoztatok.
Ezt gondoltam csak azért írom ide fel, mert nem olvastam egy könyvben sem eddig, ez amolyan magánvélemény.
Ötlet: Csak példaként egy private cloud-ba érdekes lehetne olyan logikát írni, ami felstartol mégegy mongodb szervert, ha a cluster átlagos terhelése X főlé nő, lekapcsol egyet, ha Y alá csökken, megtart tartalékba Z-t mindig. Nyilván nem csinál ilyet az oVirt, de más rendszerek biztosan igen. Bocsi, hogy megint oVirt lett belőle...
Ez persze a fizikai vasakon futó rendszereken nem segít, nem "silver bullet", de egy egyszerű megoldás lenne a probléma java részére.
A következő címkéjű bejegyzések mutatása: cassandra. Összes bejegyzés megjelenítése
A következő címkéjű bejegyzések mutatása: cassandra. Összes bejegyzés megjelenítése
2012. július 24., kedd
2011. október 29., szombat
Cassandra: további kisérletek
Tanulgatok. Már egy pár hete hajtom a cassandrát és igazából egészen elégedett voltam vele 1 node-on. Összetúrtam 30 GB adatot hozzá a netről, meg írtam egy kis crawler jellegű programot, ami folyamatosan túr további adatokat hozzá. Mondjuk napi 2-3 GB adattal nő. Szóval az adatbázisomat szorgalmas írásnak is és olvasásnak is alávetem. Gondoltam kihúzom az adatbázisomat 2 node-ra. Ez valami marha egyszerű dolog. Felstartolsz mégegy processzt mondjuk egy másik gépen, aminek azt mondod, hogy az elsőtől ismerkedjen a cluster topológiájával. Azonnal ránéztem nodetool ring-gel, láttam hogy cassandra úgy döntött, az adatbázisom 40%-át, 9 GB adatot átküld a másik node-ra. Villámsebesen átmásolta, gigabites hálózat van a kettő gép között, sajnos inkáb a vincsi volt a szűk keresztmetszet. Az első érdekes dolog az volt, hogy bár az második node-on létrejött 9 GB, az elsőn nem tünt el. Aztán lekapcsoltam a második node-ot nodetool decommission parnaccsal, elkezdett visszareplkálni az első node-ra. Pár perc alatt kész lett, de ahelyett, hogy az adatbázis mérete megmaradt volna 30 GB, megnőtt úgy 40 GB-ra. Mégegy ugyanilyen kör után már 50 GB körül volt, aztán 60 GB körül. Ami azért bosszantó, mert még mindig csak 30 GB adatot tartok benne :-) Itt már kicsit bosszús voltam és nem akartam tovább rontani a helyzetet, hagytam ott az adatbázist, ahol van. Közben a cassandra őrült módon tekerte a merevlemezt, a crawler futott tovább, én meg elslattyogtam egyet sétálni. Most nem mentem 50 kilómétert, csak a parkba mentünk le. Mire hazaértem az adatbázis mérete visszaesett 30 GB-ra. Akkor esett le, a cassandra gyorsan szedte át az adatokat a második node-ról, de aztán viszonylag sok időbe tellett neki újraoptimalizálni a saját adatstruktúráját. Szóval erre figyelni kell akkor, amikor a clustert buheráljuk.
A másik számomra bosszantó jelenség az az, hogy startkor valamiért végignyalogatja az összes adatfilet. 30 GB egy gépen az nem valami sok úgy egyébként, de azért nem szivesen várom meg amíg azt mind felolvassa arról az öreg sata vincsiről. Erre a dologra még nem találtam magyarázatot...
Ja és a cassandra nyithatott volna egy saját kis fejezetet a konfigurációs témánkban is, yaml konfig. Hogy szinesebb legyen a kép :-)
A másik számomra bosszantó jelenség az az, hogy startkor valamiért végignyalogatja az összes adatfilet. 30 GB egy gépen az nem valami sok úgy egyébként, de azért nem szivesen várom meg amíg azt mind felolvassa arról az öreg sata vincsiről. Erre a dologra még nem találtam magyarázatot...
Ja és a cassandra nyithatott volna egy saját kis fejezetet a konfigurációs témánkban is, yaml konfig. Hogy szinesebb legyen a kép :-)
Amúgy idáig nagyon tréfás kis adatbázis, jó móka játszani vele. Vettem hozzá könyvet is, hogy jobban haladjak.
Lecseréltem a favicont. Hogy tetszik? :-)
Lecseréltem a favicont. Hogy tetszik? :-)
2011. július 12., kedd
Cassandra - eddig
Mostanában szabad pillanataimban a Cassandra adatbáziskezelőt próbálgatom. Ez amolyan szakmai kirándulásféle nálam, mindenféle konkrét cél nélkül kipróbálok dolgokat. Nem jutottam még messzire vele, tényleg a bemelegítő gyakorlatok: működtetés, programozás, őszintén szólva nekem a thrift is teljesen új volt - bár nem újszerű, engem a dolog valahogy nagyon emlékeztet a CORBA-ra, de nem jutottam ezzel se olyan messzire, hogy elkezdjem osztani az észt két kézzel.
Eddigi olyan igazi járatlan út szaga van a Cassandrának. A dokumentáció felületes és jobbára törött, az API minden release-ben változik, programozni kicsit hosszadalmas és fapados érzés, a hibaüzeneteihez tolmácsra van szükség. A legtragikusabbnak az üzemeltetés tűnik.
Viszont amire kitalálták, arra ailghanem jó: nagy mennyiségű adat analízis jellegű feldolgozása. Majd ha befejeztem a teszteket akkor valószinűleg én is azt mondom majd, hogy baró és tetszik. De legtöbb embernek nincsen annyi adata, hogy ilyenekre legyen szüksége. Ez egy igencsak speciális eszköz. Kéremszépen legyenek szivesek megtekinteni a wikipédiát, ami kiválló példa arra, hogy a legtradícionálisabb LAMP architektúra is képes top 10 weboldalra jellemző terhelést elvinni. A lenézett és döglődő MySQL szolgálja ki.
Komolyan tartok tőle, hogy a NoSQL felhasználók jelentős része valójában csak a szép új technológia miatt nyomul az új generációs adatbáziskezelők körül.
Eddigi olyan igazi járatlan út szaga van a Cassandrának. A dokumentáció felületes és jobbára törött, az API minden release-ben változik, programozni kicsit hosszadalmas és fapados érzés, a hibaüzeneteihez tolmácsra van szükség. A legtragikusabbnak az üzemeltetés tűnik.
Viszont amire kitalálták, arra ailghanem jó: nagy mennyiségű adat analízis jellegű feldolgozása. Majd ha befejeztem a teszteket akkor valószinűleg én is azt mondom majd, hogy baró és tetszik. De legtöbb embernek nincsen annyi adata, hogy ilyenekre legyen szüksége. Ez egy igencsak speciális eszköz. Kéremszépen legyenek szivesek megtekinteni a wikipédiát, ami kiválló példa arra, hogy a legtradícionálisabb LAMP architektúra is képes top 10 weboldalra jellemző terhelést elvinni. A lenézett és döglődő MySQL szolgálja ki.
Komolyan tartok tőle, hogy a NoSQL felhasználók jelentős része valójában csak a szép új technológia miatt nyomul az új generációs adatbáziskezelők körül.
Feliratkozás:
Bejegyzések (Atom)