• database-nosql-cassandra

    Il database NoSQL Cassandra

    In questo articolo vedremo una panoramica del database NoSQL Cassandra.

    In un precedente articolo dal titolo “I database NoSQL” su questo blog abbiamo affrontato l’argomento dei database NoSQL, con le loro caratteristiche e le differenze rispetto ai database relazionali. Questo articolo è un’introduzione al database NoSQL Cassandra, che riveste sempre più importanza per le aziende e gestiscono grandi volumi di dati in rapida evoluzione.

     

    Caratteristiche del database Cassandra

    Cassandra è un database NoSQL, originariamente sviluppato da Facebook per potenziare la ricerca all’interno del sistema di posta e tuttora utilizzato. Nel 2008 sono stati resi disponibili i sorgenti su Google Code, mentre dal 2009 il progetto ha cominciato ad essere distribuito sotto la Apache Licence 2 (una licenza di software libero della Apache Software Foundation (ASF) che obbliga gli utenti a preservare l’informativa di diritto d’autore e d’esclusione di responsabilità nelle versioni modificate).

    Dal punto di vista del teorema CAP (vedi l’articolo dal titolo “I database NoSQL” su questo blog), Cassandra è caratterizzato da due proprietà:

    • Availability (disponibilità): ad una richiesta, il sistema è sempre in grado di dare una risposta, in altre parole, il sistema è sempre disponibile.
    • Partition Tolerance (tolleranza di partizione): se le comunicazioni si interrompono tra due punti del sistema, il sistema non fallisce ma continua ad essere disponibile.

    Per questi aspetti è simile ad altri database NoSQL, come CouchDB. Ma ci sono anche diverse differenze o specificità:

    • L’interrogazione in Cassandra non viene eseguita su HTTP;
    • Ciascun linguaggio ha un proprio driver nativo per la connessione diretta al database;
    • Cassandra è decentralizzato: i nodi nel cluster sono identici e non esiste alcun single point of failure (una componente che in caso di malfunzionamento o anomalia causa la disfunzione dell’intero sistema);
    • La modalità di storage di Cassandra è un incrocio tra un archivio di chiavi/valori e un database a tabelle; ogni chiave si associa a una o più colonne e tali colonne possono essere raggruppate in famiglie di colonne.
    • Cassandra è Fault-tolerant: i dati vengono replicati automaticamente su più nodi. È supportata la replica mediante diversi data center, e la sostituzione dei nodi può essere effettuata senza alcun downtime
    • Il livello di consistenza (sia in scrittura che in lettura) può essere modificato, ma a scapito della disponibilità dei dati.
    • Scalabilità:I nodi hardware possono essere aggiunti a Cassandra senza disservizi e quindi senza perdita di tempi aggiuntivi. Cassandra è quindi facilmente scalabile: man mano che l’applicazione cresce, è possibile aggiungere altro hardware e Cassandra continuerà a funzionare..

    Per effettuare delle query, Cassandra fornisce il proprio linguaggio di query (specificamente progettato per i gruppi di colonne), che è simile a SQL.

     

    Cassandra e i database relazionali

    I database relazionali sono il tipo di database più utilizzato e sebbene funzionino bene in molti casi, alcune applicazioni presentano requisiti difficili da soddisfare con i database relazionali (ad esempio quando occorre scrivere grandi volumi di dati rapidamente, o quando sono richiesti tempi di risposta delle query estremamente rapidi).

    database-relazionali

    I database relazionali assicurano che le operazioni di lettura e scrittura siano coerenti (tutti gli utenti vedono l’ultima versione corretta dei dati), con un notevole sovraccarico alle operazioni. Quando è più importante avere operazioni significativamente più veloci, anche con un livello di coerenza più basso, forse è più adatto l’utilizzo di un database non relazionale.

    Vediamo alcune somiglianze e differenze di Cassandra con i database relazionali.

    • Cassandra utilizza le tabelle come struttura di dati di base come i DBMS. Le tabelle sono costituite da colonne che memorizzano gli attributi (con tipi di dati familiari a uno sviluppatore di DBMS, come Integer, Varchar e Date). Le tabelle Cassandra hanno chiavi primarie, che identificano in modo univoco le righe in una tabella. Le chiavi primarie vengono utilizzate per accedere ai dati in Cassandra, ma non sono sufficienti per trovare le righe, perché Cassandra è progettato per funzionare su un cluster di server.
    • In un ambiente di sviluppo possiamo lanciare Cassandra su una macchina singola, ma in ambiente di produzione si usano cluster di server multipli. Poiché le tabelle sono distribuite su più server (nodi), per recuperare le righe all’interno delle tabelle si utilizzando due tipi aggiuntivi di chiavi:
      • la chiave di partizione definisce quale nodo del cluster usare per memorizzare o recuperare una riga;
      • una clustering column definisce l’ordine di memorizzazione delle righe.
    • Cassandra ha un linguaggio di interrogazione, chiamato CQL (Cassandra Query Language). È simile a SQL, ma ha più restrizioni.
    • Non esiste una struttura fissa per le tabelle: alcune righe possono avere colonne diverse rispetto ad altre righe.
    • Cassandra conserva più copie dei dati su diversi nodi, e questo comporta che potrebbero esserci periodi, in genere piuttosto brevi, in cui le repliche di una riga hanno versioni diverse dei dati. Nel caso in cui un nodo non sia disponibile, gli utenti possono ancora ottenere i loro dati da una replica su un altro nodo, che potrebbe essere una vecchia versione di dati. Questa differenza nelle copie dei dati è nota come incoerenza. Alla fine, l’incoerenza verrà corretta.

     

     

    Keyspace, tabelle e colonne in Cassandra

    In Cassandra, la struttura dei dati di livello superiore è Keyspace, l’equivalente dello schema nei database relazionali. I Keyspace sono contenitori logici per tabelle, indici e altre strutture dati.

    cassandra-keyspace

    Oltre a fornire uno spazio dei nomi per l’organizzazione dei dati, il Keyspace ha attributi che controllano alcune importanti caratteristiche di Cassandra. Quando si definisce uno spazio per le chiavi, si definisce anche una strategia di replica, cioè come vengono eseguite le repliche dei dati. Esistono due tipi di strategie di replica:

    1. SimpleStrategy: viene utilizzata per impostare un numero di repliche quando tutti i nodi si trovano in un singolo Data Center per un cluster;
    2. NetworkTopologyStrategy: viene utilizzata per impostare un numero di repliche quando i nodi sono distribuiti in più Data Center.

    Ad esempio, il seguente comando crea un keyspace di nome HR, con strategia di Replica SimpleStrategy e replication_factor=3 (quindi abbiamo 3 repliche).

    TBD

    Una volta definito il keyspace, occorre usarlo per crearvi degli oggetti.

    Una volta definito il keyspace corrente, possiamo creare una tabella usando il comando CREATE TABLE. La sintassi è molto simile a quella di SQL. Con il seguente comando verrà creata una tabella employees, con un identificativo, dei campi testo, data e intero. Viene definita anche la chiave primaria.

    Le colonne possono essere un singolo valore o un gruppo di più valori (collections). I singoli valori sono definiti con i tipi di dati classici, ad esempio int per numeri interi, text per stringhe di testo, float per numeri in virgola mobile, date per date, blob per flussi di byte arbitrari e uuid perUniversally Unique Identifier. Oltre a questi tipi atomici, ci sono tre tipi di collections:

    1. List, che memorizza uno o più elementi in modo ordinato;
    2. Map, che memorizza coppie di tipo chiave-valore;
    3. Set, che memorizza uno o più elementi, senza duplicati in modo non ordinato.

    Le collections sono utili quando si desidera mantenere più valori in una singola colonna. Ad esempio, potrebbe essere utile modificare la colonna phone per poter memorizzare più numeri di telefono dell’impiegato.

    Un’istruzione di INSERT su questa tabella ad esempio è la seguente:

    E un’istruzione per recuperare il contenuto della tabella employees sarà del tipo:

    E il risultato sarà:

    cassandra-tabella-employees

     

     

    Giulio Cantali – IT Consultant

    Creatore di Database Master, il primo percorso per diventare esperti di database

Lascia un commento

Se vuoi condividere la tua opinione, lascia un commento

Puoi usare questi tag e attributi: HTML:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">