Cassandra je čistě NoSQL databáze, jejíž návrh naprosto popírá principy SQL. Koncepty datového modelu se nepodobá relačnímu modelu v SQL. Proto pojmy z SQL terminologie nejsou analogické pojmům používaným v terminologii Cassandry. Stejné termíny (např. column) označují v SQL a Cassandře naprosto odlišné koncepty. Rovněž "dobré praktiky" reprezentace dat a práce s databází se v Cassandře a SQL databázích zásadně liší. Z těchto důvodů doporučuji čtenáři, aby se během čtení článku oprostil od svých znalostí SQL světa.

V případě Cassandry všeobecně akceptovaná česká terminologie neexistuje, proto budu používat vlastní překlady anglických termínů.

Datový model Cassandry

V prvním přiblížení lze uložená data chápat jako množinu uspořádaných pětic. Jednotlivé pozice v pětici budu nazývat keyspace, column family (CF), row (řádek), column (sloupec) a value (hodnota). Databáze obsahuje jednu funkci vracející keyspace podle jeho jména, keyspace je funkce zobrazující jména CF na CF, CF je funkce zobrazující jména řádků na řádky...

Tyto relace vždy tvoří strom. Jinými slovy změnou jedné hodnoty jsou vždy změněna data jen v právě jednom sloupci, právě jednom řádku, právě jedné CF a právě jednom keyspace. Tedy například různé řádky nemohou obsahovat stejný sloupec. Naproti tomu jména nemusí být v rámci celého stromu unikátní. Například různé řádky mohou obsahovat stejně pojmenované sloupce.

Jednotlivé pozice v pětici se odlišují svým významem.:

• Keyspace zapouzdřuje data na nejvyšší úrovni. Například každé aplikaci můžeme vyhradit její vlastní keyspace.
• Na další úrovni CF sdružuje všechna data stejného typu. V objektovém programování by konceptu CF odpovídaly definice tříd. Úroveň CF lze z mnoha důvodů chápat jako úplně základní strukturu v databázi Cassandra.
• V analogii s objektovým programováním by úrovni řádků odpovídaly jednotlivé instance tříd.
• Ve zmíněné analogii by jméno sloupce označovalo vlastnost/atribut/funkci objektu.
• Nakonec hodnota reprezentuje uložené hodnoty. Kombinace keyspace, CF, řádek a sloupec jednoznačně určuje hodnotu

Jednotlivá keyspace a CF se musí explicitně založit. Později lze založená CF a keyspace zrušit. Keyspace a CF mají přiřazené různé atributy, jejichž nastavení je důležitou součástí návrhu databáze. Této problematice se bude seriál ještě věnovat. Jména řádků a sloupců nepodléhají žádnému dopředu navrženému schématu. Problematikou datových typů se rovněž bude zabývat až pokračování seriálu.

Různá doplnění datového modelu

Změna hloubky zobrazení

Datový model připouští snížení dimenze. Povoleny jsou "prázdné" keyspace, CF a řádky.

Někdy některé sloupce reprezentují související data a bylo by vhodné je sdružit do "rodičovského" sloupce. Pro tuto situaci umožňuje Cassandra nastavit u column family další dimenzi supersloupce. Vzniklá šestice se označuje jako keyspace, super column family (SCF), super row key (řádek), super columns (supersloupce), subcolumns (podsloupec) a value. Další zvyšování dimenze o "supersupersloupec" již není možné.

Časová razítka

Ke každému sloupci se přibaluje časové razítko timestamp, které odpovídá době vzniku záznamu. Hodnotu razítka může klient specifikovat při vkládání záznamu. Novější verze Cassandry zavádějí vedle časového razítka vzniku záznamu i antagonistické časové razítko zániku záznamu time to life (TTL). Po expiraci takto stanoveného intervalu se záznam automaticky považuje za smazaný. Nastavení razítek se hodí pro záznamy se známou dobou platnosti.

Sekundární indexy

Jméno řádku tvoří "primární index" pro přistupování ke sloupcům a na tento způsob vyhledávání je Cassandra optimalizováná. Kromě hledání podle primárního klíče zvládá Cassandra hledat i podle hodnoty výrazů stanovených z dat ve sloupcích. K optimalizaci takovýchto hledání novější verze Cassandry představily volitelné datové struktury tzv. sekundární indexy, které lze pro požadovaný výraz založit.

UUID

Pro předcházení kolizí jmen je nutné zunikátnit jména. Například typickou situací pro použití TimeUUID typu je loggovací aplikace, která řadí události podle času. Stejný klíč bez uuid be se snadno přiřadil více událostem.

Partitioner, komparátor a řazení

Algoritmus partitioner deterministicky převádí hodnotu klíče řádku na číslo, podle kterého databáze uspořádává řádky. Spočtené číslo je parametr replikační strategie, která z něj určuje, kam klíč "patří". Příkladem partitioneru je defaultní random partitioner, který spočítá MD5 hash a replikační strategie tak obdrží de facto (pseudo)náhodný parametr.

Volba komparátoru určuje řazení sloupců v řádku. Řazení supersloupců a podsloupců se může lišit. Supersloupce řadí komparátor a podsloupce subkomparátor.

V Cassandře se řazení neurčuje jednotlivými dotazy, ale řazení se definitivně zavádí již při návrhu modelu dat.

Práva

Cassandra podporuje přidělování uživatelských práv ro (pouze pro čtení) a rw (čtení a zápis) pro keyspace a column family. Základní metodou autentizace je zadání hesla. Nastavení práv určují konfigurační soubory instalace_cassandry/conf/acces.properties a instalace_cassandry/conf/passwd.properties.

Keyspace system

Zvláštním zabudovaný keyspace pojmenovaný system exportuje metainformace o databázi. Keyspace system není určený k ukládání uživatelských dat.

Ukládání dat na disk

Všech změny dat se nejprve zapisují do souboru s tzv. commit logem. Standardně se comit logy ukládají do adresáře /var/lib/cassandra/commitlog. Do memtablu jsou zpracovávány informace z comit logu. Tato datová struktura se nachází v operační paměti.

Do souborů ve formátu SSTable se přenáší data z memtable (flushing) při automatickém uvolňování paměti například po překročení limitní velikosti memtable. Flushing je neblokující operace. Vzniklé soubory jsou :

• Soubor cesta/data/jméno_keyspace/jméno_CF-verze-Index.db obsahuje indexy.
• Soubor cesta/data/jméno_keyspace/jméno_CF-verze-Data.db obsahuje hodnoty.
• Soubor cesta/data/jméno_keyspace/jméno_CF-verze-Filtr.db ukládá asociovaný bloomův filtr.

Při procesu zkompaktnění (compaction) se do jedné nové SSTable slučují různé SSTable. Splnění nastavených podmínek automaticky spouští zkompaktnění, čímž se redukuje počet zpracovávaných SSTablů. K práci s SSTable slouží v předchozím dílu zmíněná utilita nodetool.

Data z SSTable umí exportovat do běžného JSON formátu mimo jiné utilita instalace_cassandry/bin/sstable2json. Import provádí utilita instalace_cassandry/bin/json2sstable.