Cassandra DB - II.

Dnešní díl seriálu o NoSQL databázi Cassandra popíše její instalaci a nejdůležitější spustitelné soubory. Druhá polovina článku vysvětluje základní principy fungování Cassandry, které každý uživatel této databáze musí pochopit.

26.7.2011 00:00 | František Bártík | Články autora | přečteno 9213×

Získání softwaru a jeho instalace

Oficiální binární distribuce Cassandry je ke stažení ve formě tar.gz archivu o velikosti přibližně 10MB na oficiálních stránkách projektu. Zdrojové kódy získáte například pořízením klonu oficiálního GIT repozitáře příkazem git clone git://git.apache.org/cassandra.git. Sestavení zdrojových kódů se provádí s pomocí známého systému Apache Ant. Cassandra je uvolněna pod licencí Apache License v2.

Cassandra je napsána v Javě. Přiložený soubor README.txt informuje o minimální požadované verzi Javy. Stažená distribuce Cassandry obsahuje spustitelné soubory. Po svém spuštění bude program pracovat s adresáři /var/log/cassandra a /var/lib/cassandra, což pravděpodobně neumožní přednastavená práva. Řešením je rozšířit práva u adresářů nebo spouštět Cassandru pod superuživatelem root. Tím je instalace dokončena.

Obsah základní instalace

Samotná distribuce se skládá z adresářů conf, interface, javadoc, lib, bin a několika obvyklých souborů jako README.txt nebo LICENSE.txt. Adresář conf obsahuje konfigurační soubory, které se sami dokumentují zakomentovanými volbami a popisem. Cassandru si lze vyzkoušet na běžném PC bez nutnosti úprav továrního nastavení konfiguračních souborů. Adresář interface definuje rozhraní pro vzdálené volání databáze klienty. Právě tato vyšší rozhraní se doporučují jako základní způsob komunikace klienta s databází. (S vyjímkou CQL u nejnovější verze Cassandra ani neobsahuje žádný dotazovací jazyk.) V adresáři lib naleznete použité knihovny. Do adresáře javadoc se přikládají html soubory s automaticky vygenerovanou dokumentací.

Adresář bin obsahuje spustitelné soubory. Soubor bin/cassandra je samotná databáze. Po spuštění příkazem bin/cassandra -f databáze poslouchá podle defaultního nastavení na portu 9160. Soubor bin/cassandra-cli je administrátorská konzole pro práci s databází. Příkazy se oddělují středníky. Příkaz connect určení_pozice/určení_portu; (např. connect localhost/9160;) připojí k databázi. Možné příkazy vypíše help;. Konzole bin/cassandra-cli se soustředí na vlastní uložená data. Naopak utilita bin/nodetool se soustředí na administraci, síťování a optimalizaci serverů. Například příkaz bin/nodetool -h localhost info vypíše základní informace jako uptime, aktuální zátěž nebo spotřeba paměti o Cassandře běžící na localhostu, bin/nodetool -h localhost decommission odpojí localhosta, bin/nodetool -h localhost join připojí k localhosta... Samotný bin/nodetool bez dalších voleb vypíše všechny své přepínače.

Výpis možností nástroje nodetool

Při pochopení principů fungování Cassandry a datového modelu jsou názvy příkazů v cassandra-cli a přepínačů v nodetool samovysvětlující. Zbytek dnešního dílu popisuje základní principy zasíťování Cassandry.

Základní principy fungování Cassandry

Jednotlivé instalace jsou propojeny do clusteru (ring). Mezi uzly neexistuje žádná hierarchie a každý uzel dokáže zajišťovat všechny funkce. Cassandra ani nevyžaduje nějaké konkrétní zapojení sítě. Rozdíl mezi klasickým hierarchickým clusterem typu nadřazený uzel (master) a závislé uzly (slave) a peer to peer sítí u Cassandry ilustruje následující obrázek.

vlevo P2P síť bez hierarchie, vpravo hierarchická síť master/slave

Databáze Cassandra ukládá každý jeden záznam na pevně zadaný počet různých uzlů. Požadovaný počet replik se dá nastavit a rovněž lze vybrat z několika strategií distribuce replik v clusteru. Počet požadovaných replik v clusteru se označuje jako replikační faktor (replication factor) a logika výběru uzlů pro umístění replik se označuje jako replikační strategie (replica placement strategy, replication strategy). Při změně dat dochází k propagaci a všechny repliky jsou tak postupně aktualizovány na nejnovější hodnotu.

Rozdílné replikační strategie uložily stejná data (barevné tečky) se stejným replikačním faktorem jiným způsobem.

Databáze Cassandra nepodporuje klasické transakce a podobné "složitosti", proto jsou pro pochopení základního principu fungování databáze důležité jen operace zapisování a čtení dat. Při čtení si uzel schromažďuje jednotlivé repliky. Při získávání replik může principiálně nastat pět situací.

• Přečte se již známá verze dat.
• Přečte se ještě neznámá verze dat. Následně se posoudí aktuálnost nově přečtené verze.
• Na čteném uzlu ještě není uložena žádná verze repliky.
• Přečte se informace, že příslušná data byla již smazána. Příznak smazání (tzv. tombstone) rozliší novější stav, kdy jsou data již smazána, od staršího stavu, kdy data nebyla ještě vytvořena. Smazané repliky odstraňuje korektním způsobem garbage collector.
• Je detekován chybový stav (např. porucha některého serveru).

Nastavení požadovaného počtu přečtených replik spoluurčuje míru konzistence. Příklady možných předdefinovaných úrovní jsou ONE, QUORUM, LOCAL_QUORUM, EACH_QUORUM a ALL.

• Při nastevení ONE se čtení dokončí hned po přečtení první repliky.
• Při nastavení QUORUM je čtení dokončeno při přečtení nadpoloviční většiny replik.
• Nastavení ALL vyžaduje přečtení všech replik.
• Speciální úrovně LOCAL_QUORUM, EACH_QUORUM a DCQUORUM kladou dodatečné podmínky v situaci s více datacentry. Pochopitelně jejich použití se omezuje jen na replikační strategii definující datacentra.

• Při nastavení ZERO je zapsaní považováno za okamžitě provedené při obdržení požadavku.
• Při nastavení ANY dokončení nastává v okamžiku, kdy je zřejmé, že replika již byla zapsána. V tomto okamžiku však mohou být vykonávány různé blokující úkony, takže vložená replika nemusí být hned dostupná pro čtení.

Odolnost vůči selhání

V ideálním případě každý uzel dokáže navázat spojení s libovolným uzlem a žádný server se neporouchal. Pro kontrolu se běžící uzly se vzájemně náhodně kontaktují a tím vzájemně testují svoji dostupnost a funkčnost. V případě detekce výpadku se aktivují opravné mechanismy, které například redistribuují ztracené repliky podle znalosti zbývajících replik. Při rozumném počtu uzlů a rozumném nastavení replikační strategie je Cassandra v praxi imunní proti náhodným poruchám serverů.

Verze pro tisk