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