sqlog

sql & co
posts - 78, comments - 14, trackbacks - 1

Cassandra 1

Con questo post apro (tempo permettendo ;) ) una serie di post dedicati a questo No-SQL Database.

Cassandra è un database NO-SQL che garantisce alte prestazioni e alti livelli di scalabilità. Le strutture dati messe a disposizione e le relative funzionalità sono (volutamente) ridotte al minimo indispensabile. Come vedremo più avanti, Cassandra non offre funzionalità avanzate per quanto riguarda l'archiviazione dei dati o la ricerca. Uno degli obiettivi che il progetto Cassandra si è posto, è quello di offrire uno strumento che garantisca  prestazioni eccellenti, garantendo sempre la disponibilità dei dati. Prima di trattare più nel dettaglio il funzionamento e le funzionalità messe a disposizione da Cassandra, è bene sapere che ad oggi sono disponibili driver che permettono di interagire con il suddetto database, per piattaforma C#, Java, Python, Php e Ruby. Per ragioni di progetto il sottoscritto ha utilizzato la soluzione Python su Windows / Linux.


Breve (molto breve) introduzione...

Cassandra si allontana parecchio dalla concezione classica di database relazionale; una struttura basata su una matrice di righe e colonne. Non per nulla è classificato fra i database "Column oriented" :-).
A questo punto vale la pena introdurre un paio di concetti nuovi.
Quello che sicuramente può spiazzare in un primo momento è la semplicità delle strutture dati e le funzionalità messe a disposizione da Cassandra.
Tutto in Cassandra si potrebbe riassumere in una struttura ricorsiva (a quattro o cinque livelli) basate sul concetto di chiave / valore.

  • Column Family:è una struttura (forse la più complessa) che funge da contenitore delle Colonne e il relativo Valore.
  • La Chiave: è l'entità principale per mezzo della quale Cassandra può recuperare i dati contenuti in una Column Family. La chiave deve essere univoca a livello di Column Family, può essere generata applicativamente e può essere un numero, una stringa, una data (timestamp) o un generico uuid. Più avanti farò un breve cenno a quali sono i tipi dati supportati da Cassandra.
  • Colonna: all’interno di una Column Family trovano posto una o più coppie chiave / valore, dove la chiave viene chiamata Colonna. L’unione di una chiave il suo relativo set di Colonne è chiamato “Riga”.

Queste tre entità sono le principali e quelle per mezzo delle quali Cassandra gestisce i dati. Per completezza aggiungo:

  • KeySpaces: che si potrebbe paragonare al database, quindi un “contenitore” di Column Family e relative Chiavi. Il KeySpaces ha anche l’importante ruolo di stabilire il fattore di replica (quante copie di ogni singola Riga devono essere garantite) e la tipologia di replica.
  • Super Column: è un aggregato di Column Family. Torna molto utile per creare legami fra più Column Family.
Per quanto riguarda i KeySpaces e le SuperColumns verranno approfonditi più avanti.

Tipi dati supportati

Cassandra ha una gestione dei dati relativamente e volutamente “lasca”. Sia le chiavi che i nomi che verranno dati alle colonne devono essere caratterizzati da una tipologia, questo per due motivi:
  1. la tipologia assegnata ad una entità ne caratterizza anche il suo ordinamento
  2. viene applicato un controllo dei dati in ingresso e se non rispettano la tipologia assegnata all'entità, Cassandra genererà un eccezione.

Detto questo in ogni caso e bene precisare che la tipologia non è obbligatoria assegnarla e nel caso in cui non venga specificata viene applicata quella di default (BytesType) che praticamente accetta di tutto ;-) applicando un generico ordinamento.
Le seguenti tipologie di dati, sono quelle che Cassandra gestisce nativamente. E’ possibile estendere per mezzo di moduli scritti ad-hoc le suddette tipologie native o crearne di nuove.
  • AsciiType
  • BytesType
  • LexicalUUIDType: generico UUID a 128 bit
  • LongType: generico numero a 64bit.
  • IntegerType: generico numero a 32 bit (più veloce da gestire rispetto il Long)
  • TimeUUIDType: Cassandra non gestisce nativamente il tipo dati “Datetime”, bensì lo converte in un UUID a 128 bit.
  • UTF8Type: più lento rispetto al tipo ASCII. Utile nel caso in cui si lavori per esempio con XML.

Con questo chiudiamo. Nel prossimo post approfondiremo le Colonne, SuperColonne e le Chiavi.

Print | posted on mercoledì 27 luglio 2011 14:22 | Filed Under [ Cassandra ]

Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET