Cassandra http://blogs.ugidotnet.org/sqlog/category/Cassandra.aspx Cassandra it-IT pietro partescano Subtext Version 2.6.0.0 Cassandra 1 http://blogs.ugidotnet.org/sqlog/archive/2011/07/27/cassandra-1.aspx <font size="2">Con questo post apro (tempo permettendo ;) ) una serie di post dedicati a questo No-SQL Database.<br /> <br /> 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.</font> <font size="2"><br /> <br /> </font> <div style="text-align: center;"><font size="2"><span style="font-weight: bold;">Breve (molto breve) introduzione...</span><br /> </font> </div> <font size="2"><br /> 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" :-).<br /> A questo punto vale la pena introdurre un paio di concetti nuovi.<br /> Quello che sicuramente può spiazzare in un primo momento è la semplicità delle strutture dati e le funzionalità messe a disposizione da Cassandra.<br /> Tutto in Cassandra si potrebbe riassumere in una struttura ricorsiva (a quattro o cinque livelli) basate sul concetto di chiave / valore.<br /> <br /> </font> <ul> <li><font size="2"><span style="font-style: italic;">Column Family</span>:è una struttura (forse la più complessa) che funge da contenitore delle Colonne e il relativo Valore.</font></li> <li><font size="2"><span style="font-style: italic;">La Chiave</span>: è 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.</font></li> <li><font size="2"><span style="font-style: italic;">Colonna</span>: 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”.</font></li> </ul> <font size="2"><br /> Queste tre entità sono le principali e quelle per mezzo delle quali Cassandra gestisce i dati. Per completezza aggiungo:<br /> <br /> </font> <ul> <li><font size="2"><span style="font-style: italic;">KeySpaces</span>: 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.</font></li> <li><font size="2">Super Column: è un aggregato di Column Family. Torna molto utile per creare legami fra più Column Family.</font></li> </ul> <font size="2"> Per quanto riguarda i KeySpaces e le SuperColumns verranno approfonditi più avanti.<br /> <br /> </font> <div style="text-align: center;"><font size="2"><span style="font-weight: bold;">Tipi dati supportati</span><br /> </font> </div> <font size="2"><br /> 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:<br /> </font> <ol> <li><font size="2">la tipologia assegnata ad una entità ne caratterizza anche il suo ordinamento</font></li> <li><font size="2">viene applicato un controllo dei dati in ingresso e se non rispettano la tipologia assegnata all'entità, Cassandra genererà un eccezione.</font></li> </ol> <font size="2"><br /> 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.<br /> 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.<br /> </font> <ul> <li><font size="2">AsciiType</font></li> <li><font size="2">BytesType</font></li> <li><font size="2">LexicalUUIDType: generico UUID a 128 bit</font></li> <li><font size="2">LongType: generico numero a 64bit.</font></li> <li><font size="2">IntegerType: generico numero a 32 bit (più veloce da gestire rispetto il Long)</font></li> <li><font size="2">TimeUUIDType: Cassandra non gestisce nativamente il tipo dati “Datetime”, bensì lo converte in un UUID a 128 bit.</font></li> <li><font size="2">UTF8Type: più lento rispetto al tipo ASCII. Utile nel caso in cui si lavori per esempio con XML.</font></li> </ul> <font size="2"><br /> Con questo chiudiamo. Nel prossimo post approfondiremo le Colonne, SuperColonne e le Chiavi.<br /> <br /> </font><img src="http://blogs.ugidotnet.org/sqlog/aggbug/100235.aspx" width="1" height="1" /> pietro partescano http://blogs.ugidotnet.org/sqlog/archive/2011/07/27/cassandra-1.aspx Wed, 27 Jul 2011 12:22:33 GMT http://blogs.ugidotnet.org/sqlog/archive/2011/07/27/cassandra-1.aspx#feedback http://blogs.ugidotnet.org/sqlog/comments/commentRss/100235.aspx http://blogs.ugidotnet.org/sqlog/services/trackbacks/100235.aspx