Apache Cassandra: gestione di­stri­bui­ta di grandi database

Quando è ne­ces­sa­rio gestire quantità di dati molto grandi, nell’ordine di vari terabyte o ad­di­rit­tu­ra petabyte, i classici sistemi di database non offrono capacità suf­fi­cien­ti. In questi casi è ne­ces­sa­rio ricorrere ad ap­pli­ca­zio­ni di big data che siano anche scalabili, poiché spesso il volume di dati effettivo non può essere stimato sin dall’inizio. Una delle soluzioni ad oggi più ap­prez­za­te è il sistema open source Cassandra, ori­gi­na­ria­men­te svi­lup­pa­to per Facebook.

Apache Cassandra è un sistema di gestione di database (DBMS) open source per database molto grandi, ma comunque strut­tu­ra­ti. Grazie alla buona sca­la­bi­li­tà, questi database possono essere di­stri­bui­ti su diversi cluster, il che significa che Cassandra non è legato a un singolo server.

Cassandra rientra nella categoria dei database NoSQL a colonne, laddove il termine NoSQL va in­ter­pre­ta­to come “Not only SQL“, vale a dire “non solo SQL”, e non come “nessun SQL”. Al contrario dei tipici database SQL, le strutture NoSQL offrono vantaggi si­gni­fi­ca­ti­vi nell’ela­bo­ra­zio­ne di grandi quantità di dati, in quanto non devono sot­to­sta­re alle li­mi­ta­zio­ni del lin­guag­gio di in­ter­ro­ga­zio­ne SQL (Struc­tu­red Query Language).

Apache Cassandra dispone di un proprio lin­guag­gio di in­ter­ro­ga­zio­ne de­no­mi­na­to Cassandra Query Language (CQL) che, seppur simile a SQL, viene di gran lunga preferito dagli svi­lup­pa­to­ri in ragione del fatto che è adattato alle ca­rat­te­ri­sti­che di Cassandra.

Essendo un database NoSQL, Cassandra ha un approccio ri­don­dan­te che aumenta la sicurezza in caso di mal­fun­zio­na­men­ti. Al contrario, la replica dei dati nei sistemi di database re­la­zio­na­li è causa di problemi ri­cor­ren­ti.

Oltre agli svi­lup­pa­to­ri iniziali, al progetto Cassandra con­tri­bui­sco­no anche altre grandi aziende come IBM, Twitter e Rackspace, uno dei prin­ci­pa­li provider di servizi in­for­ma­ti­ci negli Stati Uniti. Un altro im­por­tan­te con­tri­bu­to viene fornito inoltre dall’azienda DataStax, il cui modello di business è in­cen­tra­to es­sen­zial­men­te su un servizio di as­si­sten­za a pagamento, sul supporto all’in­stal­la­zio­ne e su corsi di for­ma­zio­ne sul database Cassandra.

DataStax con­tri­bui­sce oggi, per circa l’80 percento, allo sviluppo open source di Cassandra e offre anche DataStax En­ter­pri­se, una soluzione di database com­mer­cia­le basata sul sistema Cassandra, di­spo­ni­bi­le gra­tui­ta­men­te.

Secondo la nota clas­si­fi­ca dei DB engine, at­tual­men­te Apache Cassandra è il database a colonne più co­no­sciu­to al mondo e ha am­pia­men­te superato nomi di spicco quali Microsoft Azure Cosmos DB o Google Cloud Bigtable.

Essendo un vero e proprio sistema di­stri­bui­to, Cassandra non utilizza alcun master. Tutti i cluster hanno i medesimi diritti e possono elaborare tutte le in­ter­ro­ga­zio­ni del database, cosa che aumenta si­gni­fi­ca­ti­va­men­te l’ef­fi­cien­za del sistema. I dati sono ripartiti tra i nodi e la pos­si­bi­li­tà di ag­giun­ger­ne degli altri rende il sistema fa­cil­men­te scalabile. Dopo l’in­stal­la­zio­ne è ne­ces­sa­rio soltanto di­stri­bui­re i file di con­fi­gu­ra­zio­ne sul nuovo nodo e Cassandra dispone degli strumenti necessari a questo scopo.

Per garantire la sicurezza in caso di mal­fun­zio­na­men­ti e, in caso di emergenza, anche il ri­pri­sti­no dei dati, Apache Cassandra è dotato di un sistema di replica con­fi­gu­ra­bi­le in base alle necessità. La tol­le­ran­za agli errori viene ridotta al minimo at­tra­ver­so la replica au­to­ma­ti­ca dei dati tra i nodi. I nodi non più fun­zio­nan­ti possono essere fa­cil­men­te so­sti­tui­ti e il sistema rimane di­spo­ni­bi­le per le richieste in qualsiasi momento.

Cassandra offre inoltre un’elevata di­spo­ni­bi­li­tà e tol­le­ran­za di par­ti­zio­ne. Secondo il teorema CAP dell’in­for­ma­ti­ca, non è mai possibile fornire si­mul­ta­nea­men­te le garanzie di coerenza (con­si­sten­cy), di­spo­ni­bi­li­tà (avai­la­bi­li­ty) e tol­le­ran­za di par­ti­zio­ne (partition tolerance). Per questo, come avviene in molti sistemi di big data, la priorità più bassa viene assegnata alla coerenza, ossia al fatto che tutti i nodi vedano gli stessi dati con­tem­po­ra­nea­men­te. Questo perché, in caso di mal­fun­zio­na­men­to, la coerenza può essere nuo­va­men­te garantita in breve tempo at­tra­ver­so il ri­pri­sti­no dei dati, mentre le altre due proprietà devono sempre essere garantite.

I database Cassandra sono com­pa­ti­bi­li con il modello di pro­gram­ma­zio­ne svi­lup­pa­to da Google MapReduce per calcoli con grandi quantità di dati su sistemi di­stri­bui­ti. Il lin­guag­gio di in­ter­ro­ga­zio­ne di database CQL (Cassandra Query Language) è spe­ci­fi­ca­men­te adattato alle strutture dei database Cassandra.

Uno dei vantaggi prin­ci­pa­li di Cassandra è la buona sca­la­bi­li­tà e l’elevata sicurezza in caso di mal­fun­zio­na­men­ti; pre­sup­po­sti fon­da­men­ta­li, questi, per le ap­pli­ca­zio­ni di big data. Nel caso di Cassandra si parla di una sca­la­bi­li­tà oriz­zon­ta­le, ossia della pos­si­bi­li­tà di aumentare la capacità e l’ef­fi­cien­za del sistema at­tra­ver­so l’aggiunta di nodi.

Nel caso della sca­la­bi­li­tà verticale, invece, qualora la potenza o la capacità non sia più adeguata alle esigenze, l’unico database server esistente deve essere equi­pag­gia­to con pro­ces­so­ri più potenti e dischi rigidi più grandi. Essendo possibile lavorare con hardware server co­mu­ne­men­te di­spo­ni­bi­li sul mercato, la sca­la­bi­li­tà oriz­zon­ta­le è, nella maggior parte dei casi, la soluzione più con­ve­nien­te.

Il modello di dati di Cassandra è basato su tabelle hash (hash table), in cui ciascuna riga ha un numero qualunque di colonne. Con­tra­ria­men­te a una classica tabella di database, queste colonne non devono ne­ces­sa­ria­men­te essere uguali in ogni riga. Nei benchmark e negli scenari ap­pli­ca­ti­vi reali, Apache Cassandra convince inoltre per un notevole vantaggio in termini di velocità rispetto ad altri database NoSQL.

Uno degli obiettivi prin­ci­pa­li per cui Cassandra è stato svi­lup­pa­to era quello di per­met­te­re una ricerca agevole tra i messaggi in arrivo su Facebook, inviati dagli utenti. L’azienda ha uti­liz­za­to a questo scopo un cluster formato da oltre 150 nodi singoli. Non a caso Cassandra, le cui strutture fon­da­men­ta­li sono simili ad Amazon Dynamo e Google Bigtable, viene oggi spesso uti­liz­za­to dai provider di grandi social network per i quali è ne­ces­sa­rio collegare numerosi dati tra gli utenti.

Oltre a Twitter, tra i clienti più noti di Cassandra figurano Instagram, Spotify e anche il fornitore di social bookmark Digg e l’ag­gre­ga­to­re di social news Reddit.

Anche molte altre reti con grandi quantità di dati uti­liz­za­no Cassandra sia come database prin­ci­pa­le sia come com­po­nen­te se­con­da­rio per de­ter­mi­na­ti compiti. Tra gli esempi citiamo eBay, GitHub, Netflix, The Weather Channel e il Large Hadron Collider presso il centro di ricerca nucleare europeo CERN (all’incirca 30.000 terabyte di dati all’anno). Una delle maggiori in­stal­la­zio­ni di Cassandra, con 75.000 nodi, è stata rea­liz­za­ta presso la Apple.

Apache Cassandra funziona sui sistemi UNIX-like e, pre­fe­ri­bil­men­te, sui server Linux. Essendo pro­gram­ma­to in Java, Cassandra richiede il cor­ri­spon­den­te runtime di Java. I pacchetti di in­stal­la­zio­ne sono lo­ca­liz­za­ti come pacchetti Debian o RPM sui server Apache. Per eseguire l’in­stal­la­zio­ne, ag­giun­ge­te il re­po­si­to­ry adatto. Dopo l’in­stal­la­zio­ne è ne­ces­sa­rio creare le tipiche directory di dati, cache e pro­to­col­lo e con­fi­gu­ra­re il file cassandra.yaml.

Cassandra ha strumenti a riga di comando propri per compiti am­mi­ni­stra­ti­vi. Il più im­por­tan­te è la shell, il Cassandra Query Language cqlsh.

Con il comando seguente potete vi­sua­liz­za­re una pa­no­ra­mi­ca di tutti i possibili comandi:

Un’in­tro­du­zio­ne chiara ad Apache Cassandra è fornita dal seguente video su YouTube: