Elaboratofinalein BasidiDati NoSQLDatabase:Cassandra · Introduzione PeranniilmodellorelazionaledeiDatabase,introdottodaEdgarF.Coddnel1970,strutturato...

Elaborato finale in Basi di Dati

NoSQL Database: CassandraAnno Accademico 2015/2016

Candidato:Stefano Cutillomatr. N46001738

Indice

Introduzione 2

1 NoSQL Database 31.1 Differenze con i RDBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Teorema CAP e proprietà BASE . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Classificazione dei NoSQL DB 82.1 Column Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Key/Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Document stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Graph stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Apache Cassandra 123.1 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1 Column e Supercolumn . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.2 KeySpace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Applicazioni Cassandra 214.1 KeySpace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.1 Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.1.2 Durable writes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Column Families . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Conclusioni 28

Bibliografia 29

1

Introduzione

Per anni il modello relazionale dei Database, introdotto da Edgar F. Codd nel 1970, strutturatointorno al concetto matematico di relazione, è stato dominante nell’ambito dei sistemi di gestio-ne di basi di dati.Negli anni 2000, la nascita del Web 2.0 provoca una diminuzione dei costi dei sistemi di me-morizzazione e una diffusione dell’ e-Commerce e dei social media con una conseguente crescitaesponenziale dei dati prodotti.A questo punto la scalabilità dei sistemi RDBMS distribuiti non è più sufficiente per stare alpasso con la velocità desiderata di produzione e consumo dei dati. Nascono quindi i databaseNOSQL per rispondere alle esigenze che con i RDBMS non potevano affrontare, ovvero la ne-cessità di una alta scalabilità orizzontale invece che una scalabilità verticale (limitata) tipica deiRDBMS.Il termine NOSQL fu introdotto da Carlo Strozzi nel 1998 per indicare il suo database rela-zionale open-source che non aveva una interfaccia SQL standard. Il termine attualmente indicatutti quei database che sono: non relazionali, distribuiti, open-source (spesso) e scalabili oriz-zontalmente. All’opposto di quanto si potrebbe pensare, il movimento NOSQL non è contrarioall’utilizzo di database relazionali. Il termine NOSQL infatti è acronimo di Not Only SQL, perindicare che esistono diversi casi d’uso per i quali il modello relazionale non è più efficiente, matanti altri per i quali tale modello è ancora la soluzione migliore. Nonostante il termine sia statointrodotto nel 1998, solo nel 2009 i database NoSql hanno acquisito un’importanza rilevante. Iprecursori di questo movimento sono Google con il progetto BigTable e Amazon che ha imple-mentato DynamoDB.

Nel primo capitolo verranno descritti in breve i database non relazionali, evidenziandone leprincipali differenze con gli RDBMS. Inoltre sarà enunciato il Teorema CAP, elencandone poiproprietà e caratteristiche.Nel secondo capitolo verranno distinti i diversi tipi di database non relazionale analizzandone leprincipali peculiarità.Nel terzo capitolo ci concentreremo in particolare su Apache Cassandra, descrivendone la storia,le principali caratteristiche, l’architettura e la struttura del modello dei dati.Infine nel quarto capitolo verranno riportati degli esempi di applicazioni pratiche con Cassandra,in particolare utilizzando la shell cqlsh, che verrà poi approfondita, utile per effettuare query inCQL, un linquaggio fornito da Cassandra.

2

Capitolo 1

NoSQL Database

La crescità esponenziale nell’utilizzo di internet, il boom globale dei social media, come Face-book, e lo sviluppo crescente di applicazioni mobile e servizi di cloud computing, hanno portatoalla necessità di trovare nuovi strumenti e tecnologie per gestire una quantità di dati in continuacrescita, indicati con il nome di BigData.Per questo motivo i tradizionali database relazionali non furono più considerati l’unico modelloda prendere in considerazione, ma si è iniziato a studiare metodi differenti in modo da ottenereun modello dei dati più flessibile che sia in grado di fornire alte prestazioni per le elaborazionisu grandi volumi di dati.Le costanti ricerche hanno portato allo sviluppo di un nuovo tipo di database non relazionali(NRDBMS), i cosidetti NoSQL.

Si parla di Big Data quando si fa riferimento a dati che superano le capacità di elaborazio-ne dei sistemi di database convenzionali. Si tratta di dati che sono troppo estesi, che si evolvonotroppo velocemente o che non soddisfano le strutture del database progettato. Le aziende sitrovano ad affrontare una serie di difficoltà legate alla creazione, manipolazione e organizzazionedi Big Data. Infatti si era iniziato a lavorare con dataset talmente grandi da richiedere strumentinon convenzionali per estrapolare, gestire e processare informazioni entro un tempo ragionevole.I Big Data risultano essere un problema specifico dell’analisi aziendale, poiché gli strumenti e leprocedure standard non sono progettati per cercare e analizzare dataset di tali dimensioni.Non esiste una dimensione di riferimento, ma questa cambia sempre, poiché le macchine sonosempre più veloci e i dataset sono sempre più grandi. Secondo uno studio del 2001, l’anali-sta Doug Laney aveva definito il modello di crescita come tridimensionale (modello delle 3V),affermando che con il passare del tempo aumentano volume, velocità e varietà dei dati.

• Volume: rappresenta la dimensione effettiva del dataset; l’ampio volume di dati che èpossibile raccogliere oggi potrebbe apparentemente rappresentare un problema. In realtàquello del volume dei Big Data è un falso problema, in quanto cloud e virtualizzazioneaiutano nella gestione del grosso volume di dati disponibili, semplificando i processi diraccolta, immagazzinamento e accesso ai dati. Con i big data la mole dei dati è dell’ordinedegli Zettabyte, ovvero miliardi di Terabyte. Quindi si richiede una potenza di calcoloparallelo e massivo con strumenti dedicati eseguiti su decine, centinaia o anche migliaia diserver. Tale volume rappresenta la sfida principale alle convenzionali strutture tecnologiche,richiedendo l’utilizzo di una tecnologia scalabile e distribuita per far fronte alle richieste.

• Velocità: si riferisce alla velocità di generazione dei dati; Il flusso di dati scorre a unavelocità senza precedenti e deve essere gestito in modo tempestivo. Tag RFID, sensori econtatori intelligenti guidano in tempo reale la necessità di gestione di questo flusso. Lasfida di molte organizzazioni è proprio quella di reagire abbastanza velocemente da riuscire

3

a governare la velocità dei dati, tendendo ad effettuare analisi dei dati in tempo reale oquasi.

• Varietà: riferita alle varie tipologie di dati, che sono di natura diversa, e quindi nonadattabili alle classiche strutture relazionali. Quindi non soltanto i dati strutturati, come idatabase, ma anche non strutturati, come immagini, email, dati GPS, transizioni bancarieo informazioni prese dai social network. Gestire, acquisire e governare un’ampia varietà didati sono temi con i quali le organizzazioni si devono confrontare.

La definizione di Big Data è stata poi arricchita con i concetti supplementari di Veridicità eValore, la prima riferita alla correttezza e affidabilità dei dati, la seconda riferita alla capacitàdei dati reperiti di portare un reale beneficio nel processo di analisi.

1.1 Differenze con i RDBMSLe caratteristiche in cui si evidenziano le maggiori differenze tra i due tipi di database sono:

Struttura e tipi di dato memorizzati:I sistemi RDBMS richiedono un processo di normalizzazione sui dati che consente di evi-denziare le caratteristiche essenziali dei dati e le relazioni che tra essi intercorrono e chedetermina la necessità di utilizzare. Il risultato è un modello astratto dei dati, detto sche-ma, che definisce univocamente la struttura e il tipo dei dati e li separa in tabelle. Inoltrelo schema si presenta rigido, in quanto possono essere memorizzati solo i dati conformi alloschema e per aggiungere un campo o una relazione è necessario bloccare l’intero databasefino al completamento della modifica. I sistemi NoSQL non nascono con l’obiettivo di ri-nunciare alle relazioni tra i dati ma, al contrario, dal desiderio di avere la massima libertàpossibile di modificare ed alterare nel tempo sia la struttura dei dati che le relazioni chetra essi intercorrono. Per questo motivo sono caratterizzati da:

1. Leggerezza computazionale : i database NoSQL non prevedono operazioni di ag-gregazione sui dati, in quanto tutte le informazioni sono già raccolte in un unicodocumento associato all’oggetto da trattare. Dato che un elemento contiene tuttele informazioni necessarie non serve usare i dispendiosi (in termini di performance)JOIN come invece avviene per i database relazionali.Negli ambienti SQL la complessità di queste operazioni, e quindi il peso computaziona-le, cresce con l’ingigantirsi della base di dati, del numero di tabelle e delle informazionida trattare. Nel NoSQL, Le informazioni quindi non troveranno più posto in righeelencate in tabelle, ma in oggetti completamente diversi e non necessariamente strut-turati e quindi non ci saranni più limiti di dimensioni in questo senso. Lo svantaggioche provoca tutta questa flessibilità è la duplicazione delle informazioni, anche se inrealtà, i costi sempre meno proibitivi dei sistemi di storage rendono questo svantaggiopoco importante.

2. Assenza di schema : i database NoSQL sono privi di schema in quanto il documentoJSON contiene tutti i campi necessari, senza necessità di definizione. In questo mo-do, possiamo arricchire le nostre applicazioni di nuovi dati e informazioni, definibililiberamente all’interno dei documenti JSON senza rischi per l’integrità dei dati. I da-tabase non relazionali, a differenza di quelli SQL, si rivelano quindi adatti a inglobarevelocemente nuovi tipi di dati e a conservare dati semistrutturati o non strutturati.Per questo motivo eliminano lo schema rigido (schemaless) in modo da consentire diaggiungere nuovi dati, anche molto dissimili dai precedenti, e nuove relazioni senzala necessità di modificare la struttura del database e senza bloccarne l’accesso.

4

La semplicità di questi database, però, porta anche alla mancanza dei controlli fondamen-tali sull’integrità dei dati. Il compito ricade quindi totalmente sull’applicativo che dialogacol database che ovviamente dovrebbe essere testato in modo molto approfondito primadi essere messo in produzione.

Esecuzione di query:Indipendentemente dalla loro licenze, tutti i database relazionali implementano lo standardSQL in una certa misura, quindi possono essere interrogati utilizzando lo Structured QueryLanguage (SQL). Ogni database NoSQL, d’altra parte, implementa un modo tutto suo peroperare con i dati che gestisce.La mancanza di uno standard universale (come può essere l’SQL) può rappresentare peròuno svantaggio, in quanto ogni database ha le proprie API e il suo metodo di storing edi accesso ai dati. Di conseguenza se lo sviluppo del database sul quale abbiamo basato ilnostro applicativo venisse interrotto, il passaggio ad un altro database non sarebbe una cosaimmediata, ma richiederebbe alcuni cambi più o meno radicali da apportare all’applicativo.

Scalabilità Orizzontale:Entrambe le soluzioni sono facili da scalare verticalmente (aumentando cioè le risorse disistema). Tuttavia, essendo applicazioni più moderne (e più semplici), le soluzioni NoSQLoffrono di solito mezzi grazie ai quali è molto più facile scalare orizzontalmente (cioè con lacreazione di un cluster di più macchine). Partizionare orrizontalmente significa partizionarele enormi tabelle su database e server differenti. Per quanto rigurada i database relazio-nali questo però introduce degli svantaggi in quanto per consultare le tabelle c’è bisognonecessariamente del JOIN. Inoltre occorre prestare attenzione durante il partizionamentoper organizzare e coordinare le query in modo adeguato per far si che non si sovrappon-gano tra loro nelle varie entità. Le funzioni disponibili saranno quindi limitate. L’assenzadi aggregazione dei dati e di uno schema definito a priori offre l’opportunità di scalareorizzontalmente i database NoSQL senza difficoltà e senza rischi operativi e soprattuttoevitando le operazioni di giunzione (join).

Affidabilità:Quando si tratta dell’affidabilità dei dati e della sicurezza che le transazioni effettuatesiano garantite, i database SQL sono ancora la soluzione migliore.

Supporto:I DBMS relazionali hanno una storia lunga decenni. Sono estremamente popolari e sonofacili da trovare sia con supporto gratuito che a pagamento. Se si verificasse un problema,sarà quindi molto più facile da risolvere rispetto ai recenti database NoSQL.

Le caratteristiche ed i punti di forza dei sistemi RDBMS vengono spesso sintetizzate con l’a-cronimo ACID, ossia Atomicità, Consistenza, Isolamento e Durabilità. Nei sistemi NoSql questecaratteristiche sono sostituite da proprietà meno stringeti, che sono alla base del teorema CAPe che sono rappresentate dall’acronimo BASE.

1.2 Teorema CAP e proprietà BASEAll’inizio degli anni 2000 a Berkeley, l’univerità della California, lo scienziato informatico EricBrewer formulò una congettura matematica al simposio Principles of Distributed Computing(PODC).Nel 2002 Seth Gilbert e Nancy Lynch del MIT, hanno pubblicato una dimostrazione di tale con-gettura, definendola quindi un teorema.Il Teorema CAP, anche conosciuto quindi come teorema di Brewer, afferma che non è pos-sibile fornire simultaneamente totale coerenza dei dati (Consistency), continua disponibilità

5

(Availability) e tolleranza alle partizioni (Partition tolerance), quando si progetta un sistemadistribuito.

• Consistency : Un sistema è definito completamente coerente quando è in grado di ga-rantire che una volta memorizzato un nuovo stato nel sistema, questo è utilizzato in ognioperazione successiva fino alla successiva modifica dello stesso. Pertanto, tutte le richiestedello stato del sistema, nell’arco di tempo che intercorre tra uno stato e quello successivo,forniscono il medesimo risultato.

• Availability : Un sistema è detto continuamente disponibile quando è sempre in gra-do di soddisfare le varie richieste/erogare i propri servizi. la strategia standard utilizzataper ottenere la continua disponibilità consiste nel ricorrere ad un’opportuna ridondan-za. Ciò, oltre a richiedere opportuni meccanismi per garantire la consistenza, aumenta leproblematiche relative alla tolleranza alle partizioni.

• Partition tolerance : Gilbert e Lynch hanno definito la tolleranza alle partizioni comela proprietà di un sistema di continuare a funzionare correttamente anche in presenza diuna serie di fallimenti dell’infrastruttura fino a che l’interno network fallisca.

Teorema CAP

Quindi è necessario stabilire, di volta in volta in funzione ai requisiti, quale soluzione di com-promesso accettare tra le seguenti coppie possibili: CA, AP e CP.

1. CA: elevata coerenza/alta disponibilità. Si tratta del compromesso tipicamente offerto daiRDBMS. I dati sono mantenuti in modo coerente in tutti i nodi del cluster, a patto cheovviamente tali nodi siano disponibili. È sempre possibile leggere e/o scrivere su qualsiasinodo ed essere sicuri che il nuovo dato sia propagato a tutti i nodi del cluster. Non vi è

6

quindi la possibilità che alcuni nodi abbiano delle versioni dei dati non aggiornate. Tuttavia,la totale coerenza può incidere sulle performance (latenza) e sulla scalabilità.

2. CP: elevata coerenza/tolleranza alle partizioni. Questo compromesso è quello preferito dasoluzioni quali MongoDB, HBase, BigTable, Terrastore, Redis e altri. I dati sono mantenu-ti in maniera coerente in tutti i nodi del cluster, e viene garantita la tolleranza partizioneper evitare che dati possano desincronizzarsi. Tuttavia si possono avere problemi di dispo-nibilità quando un nodo diventa non raggiugibile. Quasi tutte le soluzioni prevedono unaconfigurazione in cui un nodo agisce come master e gli altri come slave.

3. AP: continua disponibilità/tolleranza alle partizioni. Questo compromesso è stato prescel-to da soluzioni quali Apache Cassandra, CouchDB, DynamoDB e Riak. I nodi restanoon-line anche nelle situazioni in cui non possono comunicare tra loro. È poi compito delprocesso di risincronizzazione dei dati risolvere eventuali conflitti. Chiaramente non è pos-sibile avere garanzia che tutti i nodi abbiano gli stessi dati con gli stessi valori durante lapartizione e la relativa risoluzione. Soluzioni AP tengono a presentare migliori prestazioniin termini di latency e a scalare in modo più lineare.

Il Teorema CAP sostanzialmente dimostra che è impossibile garantire le proprietà ACID1 inun sistema distribuito e scalabile orizzontalmente. Quindi affinche si voglia costruire un sistemadistribuito, è d’obbligo adottare una versione "rilassata" delle proprietà ACID che favoriscono lareplicazione dei dati per aumentare la scalabilità orizzontale e la disponibilità del dato a scapitodella consistenza (in senso ACID). Queste proprietà sono sintetizzate dall’acronimo : BASE =Basically Available, Soft state, Eventual consistency.

1. Basically Available . L’approccio NoSQL predilige la disponibilità del dato anche inpresenza di molteplici errori. Viene ottenuto utilizzando un approccio altamente distribuitoreplicando i dati su un gran numero di sistemi di memorizzazione. Quindi ci sarà unarisposta a qualsiasi richiesta, anche se la risposta potrebbe ancora essere un fallimento ouna impossibilità a rispondere.

2. Soft state . Si abbandona la consistenza nel senso delle proprietà ACID. Lo stato delsistema può quindi variare nel tempo, anche in periodi di tempo senza input. La consistenzadei dati diventa un problema da risolvere da parte dello sviluppatore e non deve esseregestita dal database.

3. Eventual consistency . Significa che in un qualche istante futuro i dati arriveranno inuno stato consistente (nel senso ACID). Non ci sono garanzie su quando ed in quantotempo questo avverrà. Questo perchè quando nuovi dati vengono aggiunti al sistema essisi propagano gradualmente, in maniera asincrona e un nodo alla volta, fino a far diventareconsistente l’intero sistema.

1

Atomicità: la transazione è indivisibile nella sua esecuzione e non sono ammesse esecuzioni parziali;Consistenza: Durante la transazione il sistema non deve violare eventuali vincoli di integrità, quindi non devonoverificarsi contraddizioni (inconsistenza) tra i dati archiviati nel DB;Isolamento: ogni transazione deve essere eseguita in modo isolato e indipendente dalle altre transazioni, l’eventualefallimento di una transazione non deve interferire con le altre transazioni in esecuzione;Durabilità: una volta modificata una transazione, i cambiamenti apportati non dovranno essere più persi.

7

Capitolo 2

Classificazione dei NoSQL DB

Proprio perché i database NOSQL sono incentrati sui dati, ne esistono diverse tipologie ed esi-stono diverse varianti all’interno della stessa tipologia. I criteri fondamentali in base ai qualipossiamo suddividere i diversi Database NoSQL sono scalabilità, prestazioni(in termini di laten-cy) e consistenza.Le quattro tipologie principali di database NOSQL sono:

• Coloumnfamily : i dati sono organizzati in righe e colonne, ma le righe possono averequante colonne si vogliono e non c’è bisogno di definire le colonne come prima cosa.

• Document store : I dati, a differenza dei normali database relazionali, non vengonoimmagazzinati in tabelle con dei campi fissi, ma vengono messi in un documento che puòcontenere illimitati campi di illimitata lunghezza.

• Graph : i dati vengono immagazzinati sotto forma di strutture a grafi,per favorirnel’accesso da applicativi orientati agli oggetti.

• Key/Value : i dati vengono immagazzinati in un elemento che contiene una chiave assiemeai dati veri e propri.

2.1 Column FamilyI database Column family si ispirano all’articolo di Google nel quale descriveva il suo databaseBigtable, definendolo una sparsa, distribuita e persistente mappa ordinata multi-dimensionale.Altri esempi di DB column family sono Hbase, Hypertable e Cassandra. Column family storeindica che il database è organizzato per colonne invece che per righe come nei RDBMS. Con-trariamente ai normali database relazionali nei quali, durante la lettura dei dati si potrebberoleggere dati non necessari, nei column family store vengono letti soltanto i dati di interesse,rendendoli più veloci e scalabili. Tuttavia la scrittura di una tupla richiede accessi multipli adifferenza dei database row-stores caratterizzati dalla semplicità di aggiungere o modificare unrecord.Inoltre, per evitare la presenza di dati null, ogni riga può avere un numero differente di colonne,che possono essere aggiunte o eliminate all’occorrenza, cosa che di fatto rende questo databaseuna matrice multidimensionale sparsa. I column family si dividono in: Standard column familye Super column family.

• Standard column family : La row key (la chiave più "esterna") identifica l’aggregato,che a sua volta contiene una o più famiglie di colonne dove possono essere presenti diversivalori associati ad una diversa column key.

8

Standard Column family

• Super column family : E’ un’estensione dello standard column family che aggiunge unulteriore livello di indicizzazione, detta appunto super column, fra la row key e l’insiemedelle colonne. Questa chiave viene utilizzata per raggruppare attributi correlati fra di loro,appartenenti allo stesso aggregato. L’estensione presenta diversi vantaggi, in quanto rendei dati più ordinati ed utilizzabili dalle applicazioni e la scalabilità orizzontale (sharding)più efficiente.

Super Column family

I Column family database apportano numerosi benefici:

1. I valori in una singola colonna sono memorizzati in maniera contigua e conservati in specificicolumn datafile.

2. I dati all’interno di ciascun column datafile sono dello stesso tipo, questo li rende idealiper la compressione.

3. La memorizzazione per colonna permette di migliorare le performance delle query in quantopermette l’accesso diretto alle colonne.

2.2 Key/ValueI Key-Value stores puntano sugli aspetti di Availability e Partition Tolerance (AP) del teoremaCAP e prendono origine dall’articolo di Amazon dove descriveva il suo database Dynamo, svi-luppato nel 2007. Lo scopo di Amazon era quello di avere un database altamente scalabile dove

9

si potesse accedere ai dati in modo affidabile il più velocemente possibile in quanto i databaserelazionali non scalavano alla velocità necessaria.Altri eseempi di database sono Voldemort (Linkedin), MemcacheDB, Riak, e BerkleyDB.I database Key-Value stores sono la più semplice tipologia di database NOSQL. I dati vengonomemorizzati in coppie chiave/valore, infatti ogni chiave identifica un blob binario "oscuro" chepuò contenere qualsiasi tipologia di dato (stringa di testo, documento, immagine, video).Il vantaggio è che si ha una struttura altamente scalabile, grazie all’assenza di legami tra le variecoppie key/value, che potranno essere distribuite su server differenti.Questo tipo di database può essere visto come una hash table, che consente quindi le seguentioperazioni: si può aggiungere una coppia key/value, recuperare un blob data la sua chiave, can-cellare una chiave per rimuovere un elemento o modificare il valore associato ad una chiave.Le differenze principali rispetto al modello relazionale sono che una query restituisce un soloelemento e che i value possono contenere qualsiasi tipo di dato.Questo rappresenta uno svantaggio, poichè non c’è nessun modo di eseguire query basate sulcontenuto del valore in quanto i blob sono "oscuri".Per questo motivo tale metodo, nonostante la semplicità di implementazione, non è ideale sesi vuole aggiornare solo parte del valore associato alla chiave o se si vuole fare una query suldatabase.

2.3 Document storesI Document stores sono orientati alla conservazione di documenti, quindi a differenza di quantoaccade con i Key-Value stores, il contenuto non è una black-box ma è accessibile ed indicizzabile.Esempi di DB: MongoDB, CouchDB, Couchbase.Lo scopo di questa tipologia di database è quella di archiviare in modo efficiente sia i documen-ti che il loro contenuto, per questo è possibile recuperare i documenti effettuando non solo laricerca per chiave, come avviene dei database key/value, ma anche in base al loro contenuto,metadati o combinazioni di essi. Inoltre, gli indici sono quasi sempre realizzati simili a quelletipiche dei sistemi RDBMS che consentono ricerche per uguaglianza, intervallo, indici su piùattributi e riferimenti ad altri documenti.I dati non sono memorizzati in tabelle con campi uniformi per ogni record, ma questi ultimivengono memorizzati come documenti, ognuno con le proprie caratteristiche ai quali poter ag-giungere un diverso numero di campi, con lunghezze anche differenti in modo tale da non averecampi vuoti all’interno dei documenti.A differenza degli RDBMS, I JOIN non sono presenti, ma i riferimenti verso altri documentipossono essere visti come una sorta JOIN. Inoltre i documenti non hanno uno schema e quindipossono essere costituiti da coppie key/value, coppie key/array, o anche documenti annidati.I valori memorizzati provvedono alcune strutture di codificazione e gestione dati: Il formato piùutilizzato per la codifica è il JSON, gli altri formati utilizzati sono XML, YAML e BSON. Questoè dovuto principalmente anche alla forte integrazione che questi database hanno con Javascript.Inoltre, la possibilità di ottenere modelli di dati complessi senza rinunciare alle performance, liha resi molto diffusi per siti web e di e-commerce, e gestione documentale.

10

Document stores

2.4 Graph storesI Graph stores sono ispirati dalla teoria dei grafi, infatti non vengono utilizzati i formati rigididi SQL o la rappresentazione a colonne o tabelle, ma è utilizzata una rappresentazione tramitegrafi flessibili che rientra perfettamente nelle richieste specifiche di scalabilità. E’ la tipologia didatabase ideale per la gestione di social network e simili, nonché sistemi intelligenti che faccianouso di clustering e generazione di regole.Una base di dati a grafo usa nodi e archi per rappresentare e archiviare l’informazione . Larappresentazione dei dati mediante grafi, nei quali i nodi del grafo sono dati che possiedono coppiekey/value e gli archi sono le relazioni che intercorrono tra essi, offre un’alternativa al modellorelazionale che fa uso di tabelle, o ai database orientati al documento (che usano documenti).I database a grafo sono spesso più veloci di quelli relazionali nell’associazione di set di dati, emappano in maniera più diretta le strutture di applicazioni orientate agli oggetti. Scalano piùfacilmente a grandi quantità di dati e non richiedono le tipiche e onerose operazioni di unione(join). Dipendono meno da un rigido schema entità-relazione e sono molto più adeguati pergestire dati mutevoli con schemi evolutivi. Al contrario, i database relazionali sono tipicamentepiù veloci nell’eseguire le stesse operazioni su un grande numero di dati.

Graph stores

11

Capitolo 3

Apache Cassandra

Con l’avvento del Web 2.0 la rete ha sperimentato per la prima volta le criticità legate allagestione infrastrutturale di un ambiente che dovesse sostenere ed accentrare le attività tipichedi una community. In particolare era diventato necessario un massiccio miglioramento nei tempidi risposta e la gestione di grossissimi volumi di dati.Il codice di Cassandra è stato inizialmente sviluppato all’interno di Facebook, dove già MySqlveniva utilizzato in modo poco ortodosso, per potenziare la ricerca all’interno del sistema diposta e per migliorare la tecnica di memorizzazione dei messaggi nella Inbox. La progettazioneiniziale si deve a Avinash Lakshman(uno degli sviluppatori di Amazon Dynamo) e PrashantMalik. In seguito nel luglio del 2008, Cassandra è stato rilasciato come progetto open source,rendendo disponibili i sorgenti, su Google Code. Dal marzo 2009 è entrato a far parte del proget-to Incubator di Apache Software Foundation1, data in cui l’intero progetto ha iniziato a esseredistribuito sotto la Apache License 2.L’architettura di Cassandra privilegia alta disponibilità e tolleranza al partizionamento (AP)trascurando appunto la totale consistenza. Da notare che una delle scelte più frequenti nellaprogettazione dei sistemi NoSQL, consiste nella rinuncia della coerenza totale a favore di formepiù blande, tanto che da qualche tempo si è iniziato a parlare di eventual consistency("coerenzafinale"). Sistemi a consistenza finale garantiscono che, qualora non vi siano nuovi aggiornamentiper un certo lasso di tempo relative a un determinato dato, alla fine tutti le richieste dello stessorestituiscono il medesimo valore, risultato dell’ultimo aggiornamento. Cassandra è appunto unasoluzione a coerenza finale.

Apache Cassandra è un database open source, fault-tolerant, distribuito e decentralizzato, per1ASF (nata nel 1999) è una fondazione no-profit ed una comunità di sviluppo di progetti software come il web

server Apache (il progetto principale) e la suite da ufficio Apache OpenOffice

12

la gestione di grandi quantità di dati strutturati sparsi in tutto il mondo.E’ stato progettato per funzionare su hardware di largo consumo a basso costo ed è caratteriz-zato da una grandissima velocità di esecuzione e scrittura, in quanto è in grado di memorizzarecentinaia di terabyte di dati, senza sacrificare l’efficienza di lettura.Oltre a Facebook, Cassandra riscontra un grande bacino di utenze, ad esempio:Twitter passa a Cassandra perché può essere eseguito su diversi cluster server ed è capace di

mantenere un’innumerevole quantità di dati;

Digg , che è il maggiore sito di social news, ha annunciato l’utilizzo di Cassandra dal 9 settembre2009;

Netflix usa Cassandra per gestire i dati dei suoi sottoscrittori.

3.1 ArchitetturaIl database Cassandra è distribuito su numerose macchine che operano insieme. Il contenitoreesterno è noto come il Cluster, nel quale i nodi, ai quali vengono assegnati i dati, sono organizzatiin un formato ad anello (ring network).L’anello rappresenta l’andamento ciclico dello spazio dei token, che vengono generati in basealla chiave di riga e servono ad individuare in quale nodo è memorizzato il dato. Ad ogni nodoè assegnata una posizione nell’anello basata sui token che deve gestire. ad ogni operazione diinserimento verrà attribuito un determinato valore che permetterà di determinare su quale nododella rete andrà collocato, ottenendo così una facile distribuzione dei dati mediante una funzionedi hash.

Per mappare le chiavi di riga nello spazio dei token viene usato un partitioner che è unafunzione che stabilisce un token per una data riga in ingresso a partire dalla sua chiave di parti-zione, tipicamente mediante un hash table. Ogni riga di dati inserita viene distribuita attraversoil cluster in base al valore del token. I partitioner in Cassandra sono:

1. RandomPartitioner : è la soluzione di default per le versioni di cassadra precedenti alla1.2. Il token viene generato attraverso una funzione hash MD5 e i dati vengono distribuitinel cluster basandosi sui valori di questa funzione hash, non mantenendo quindi l’ordinedelle chiavi. Questo permette di bilanciare il carico fra i nodi.

2. Murmur3Partitioner : è il partitioner di default per le versioni di Cassadra successivealla 1.2. Funzionalmente è lo stesso del Random partitioner, con la differenza che utilizzauna funzione hash chiamata Murmur3, molto più veloce di MD5.

3. ByteOrderedPartitioner : effettua una distribuzione ordinata dei dati basata sul lessicoper bytes di chiave. Non è consigliato.

4. OrderPreservingPartitioner : in questo caso viene assunto che le chiavi siano stringeUTF8 (Unicode). E’ mantenuto l’ordine fra le chiavi anche nei token. Ad esempio se lechiavi sono A, B e C allora si deve avere che token(A) < token(B) < token(C). Questasoluzione non è consigliata poichè può portare ad avere uno sbilanciamento di informazionifra i nodi, in quanto le partizioni vicine tra loro avranno più attività di altre e quindi ilnodo che le ospita tenderebbe a sovraccaricarsi. Tuttavia questa soluzione consente diottimizzare gli accessi nel caso in cui si debbano recuperare i dati ordinati.

All’interno di Cassandra tutti i nodi in un cluster hanno gli stessi compiti e funzionalità, inquesto modo non esiste all’interno del cluster una specificità critica che in caso di malfunziona-mento possa rendere inoperante il database, ossia non esiste un nodo master (la comunicazione

13

è peer-to-peer). Per questo motivo si dice che Cassandra non ha alcun single-point-of failure (haun’architettura decentralizzata e distribuita) ed è continuamente disponibile per le applicazionibusiness-critical che non possono permettersi un fallimento.

Cassandra è scalabile ed elastico (elastic scalability), in quanto il modello di distribuzionepeer-to-peer permette di aggiungere e/o rimuovere nodi senza problemi (con strategia di replicaadeguata) a seconda del requisito. Quando un nodo viene aggiunto al cluster per prima cosaindividua la topologia dello stesso e riceve i dati per i quali sarà responsabile, successivamentepotrà accettare le richieste dai client. Quindi l’aumento di nodi è seguito da un aumento delleperformance, che scalano in maniera lineare, in modo che i dati siano sempre distribuiti in modobilanciato e che si abbiano tempi di risposta rapidi.

Scalabilità

Un’altra caratteristica importante di Cassandra è la Failure Tolerance. I dati sono automati-camente duplicati su più nodi, per garantire che, all’eventuale crash di un elemento dell’insieme,non debba necessariamente seguire la perdita di informazioni importanti o lo stallo dell’interaistanza. Questo è realizzabile indicando nel keystore il replica factor, che indica il numero deinodi nel quale deve essere mantenuto il dato. Si noti che i nodi sono successivi secondo la topo-logia dell’anello.Le strategie di replication esistenti sono due:

1. SimpleStrategy : si ha un solo datacenter, specifica un fattore di replica semplice e idati sono memorizzati in nodi successivi sull’anello. Si segue, all’aumentare del replicationfactor, la circolarità dell’anello fino alla memorizzazione di tutte le copie.

2. NetworkTopologyStrategy : i dati possono essere trasmessi su più datacenter e in ognu-no di essi i dati sono memorizzati in nodi successivi in senso orario, in base al partitionerselezionato su quel datacenter, fino al raggiungimento del primo nodo del rack successivo.Utilizzando questa opzione, è possibile impostare il fattore di replica per ogni datacenter inmodo indipendente. In questo caso si da priorità alla distribuzione su vari anelli poichè cisi aspetta che nodi appartenenti allo stesso rack abbiano più probabilità di fallire, a causadi problemi di elettricità o alla rete, piuttosto che nodi inseriti in anelli diversi, tenendoanche in considerazione la vicinanzafisica delle macchine.

Oltre al replica factor, l’altro fattore importante per la memorizzazione dei dati in Cassandra èla consistency che si riferisce a come sono aggiornate e sincronizzate le righe dei dati su tutte le

14

repliche. Questa è modificabile e regolabile a run-time sia in lettura che scrittura: aumentandoil numero di nodi da leggere, così come aumentando quelli da scrivere per quanto riguarda lefunzioni di write, si ottiene un lineare miglioramento nella consistenza del dato a scapito delleperformance. E’ quindi importante decidere con attenzione quale sia il miglior compromesso perla propria applicazione.Le possibili strategie sono:

• ANY (solo in scrittura): La scrittura deve avvenire almeno su un nodo. Se nessun nodoè disponibile, il coordinatore si fa carico di mantenere i dati fino a quando uno dei nodicontenente la replica non è recuperato.

• ONE : in scrittura il nodo coordinatore (quello a cui si è collegato il client) deve scriveresul commit log e memtable di almeno un nodo in cui risiede la replica.In lettura il nodo coordinatore legge il dato dal nodo più vicino (determinato dal coordi-natore) che contiene la replica. Di default, viene effettuata la riparazione in backgroundper rendere le altre repliche consistenti.

• ALL : La scrittura deve avvenire sul commit log e memtable di tutti i nodi nel clustercontenente una replica della riga.In lettura restituisce il record con il timestamp più recente, dopo che tutte le replichehanno risposto. L’operazione di lettura fallisce se una delle repliche non risponde.

• QUORUM : La scrittura deve avvenire sul commit log e memtable in un QUORUM dinodi contenenti una replica. In particolare EACH QUORUM si riferisce ad un QUORUMdi nodi in tutti i datacenter e LOCAL QUORUM ad un quorum di nodi appartenenti allostesso datacenter del nodo coordinatore. Per quanto riguarda il LOCAL QUORUM, inscrittura il nodo coordinatore scrive in tutti i nodi appartenenti al suo stesso data center(quorum di nodi) dove risiede la replica del dato e aspetta l’ack dal quorum dei nodi perrispondere al client mentre gli ack degli altri nodi arrivano in maniera asincrona. Il valoredel quorum è dato da: replication factors/2+1 arrotondato per difetto.In lettura il nodo coordinatore, appena ha avuto risposta dal quorum dei nodi, tramette alclient il dato più aggiornato (timestamp più recente) e aggiorna il dato memorizzato nellerepliche.

NetworkTopolgyStrategy

15

Cassandra utilizza il protocollo Gossip in background per consentire ai nodi di comunicare traloro e rilevare eventuali nodi difettosi nel cluster.Gossip è un protocollo di comunicazione peer-to-peer in cui i nodi scambiano periodicamenteinformazioni sul loro stato e sui nodi di cui hanno informazioni. La procedura di gossip vieneeseguita periodicamente ogni secondo e consente lo scambio di messaggi di stato al massimo a 3nodi del cluster. La comunicazione avviene iniziando una gossip session, composta da tre scambidi messaggi simile a quanto avviene nella procedurathree-way handshake nel protocollo TCP.I nodi scambiano informazioni su se stessi e sui nodi con cui hanno già scambiato messaggi Gos-sip, quindi in modo rapido tutti i nodi avranno informazioni su tutti gli altri nodi del cluster.Ogni messaggio di gossip ha una versione (timestamp) associata con esso, quindi durante l’opera-zione di scambio dei messaggi, le vecchie informazioni memorizzate nel nodo vengono sovrascritteda quelle più recenti ricevute.Quando un nodo è avviato per la prima volta ottiene due informazioni necessarie all’avvio dal filedi configurazione (Cassandra.yaml): la prima è il nome del cluster di appartenenza e la secondaè la lista dei nodi detti Seeds, da contattare per ottenere le informazioni relative agli altri nodidel cluster.Il primo avvio è ovviamente quello più critico e, per evitare problemi di partizionamento, tuttii nodi del cluster hanno la stessa lista di nodi Seeds nel file configurazione; inoltre un nodomemorizzerà per default i nodi con cui ha scambiato informazioni di gossip nei riavvii successivi.

Mediante lo stato determinato dai messaggi di gossip, è possibile effettuare l’operazione di fai-lure detection ovvero la determinazione dello stato di un altro nodo del sistema, per verificarese questo è attivo o meno. Tale meccanismo è utilizzato inoltre da Cassandra per evitare che lerichieste di un client vengano instradate verso un nodo non raggiungibile. Cassandra inoltre fasì da non inviare richieste a nodi che sono attivi, ma le cui prestazioni non sono efficienti. Le in-formazioni che gossip ottiene sull’attività dei nodi possono essere dirette (comunicazione direttacon il nodo interessato) e indiretta (nodi secondari o terziari che vengono informati sullo statodel nodo). Invece di avere un semplice meccanismo di soglia per la determinazione di fallimentodi un nodo, Cassandra utilizza un sistema d’individuazione ad accumulo per calcolare una sogliaper-nodo che tiene in considerazione le condizioni di rete, il carico del nodo e altre informazioniche possono influire sulla percezione dello stato del nodo. Durante l’operazione di gossip, ogninodo mantiene una sliding window di arrivo dei messaggi di gossip dagli altri nodi del cluster; ilvalore di tale finestra è stabilito da un parametro di configurazione detto "phi convict threshold"che, variato, cambia la sensibilità del failure detector.

Quando un client si connette a un nodo e richiede un’operazione di lettura o scrittura, quelnodo funge da coordinatore per quell’operazione del client. Il compito del coordinatore è quellodi agire come un proxy tra l’applicazione client e i nodi che contengono i dati richiesti (o unaloro replica); la determinazione di quale nodo nel ring debba gestire la richiesta è decisa dallaconfigurazione del partizionatore e dalla strategia di replicazione del Cluster.I componenti chiave di Cassandra per le operazioni di lettura e scrittura sono i seguenti:

• CommitLog : uno specifico registro su disco, in cui vengono scritte inizialmente tutte leoperazioni di write.

• Mem-Table : una struttura dati residente in memoria. Dopo che sono stati scritti nelCommitLog, i dati vengono memorizzati nella MemTable, a cui Cassandra accede tramiteuna chiave.

• SSTable : è un file su disco nel quale vengono memorizzati i file, una volta che la Mem-Table è piena, svuotandola tramite un’operazione di flushing. I dati conservati nel commit

16

log vengono eliminati nel momento in cui i corrispondenti dati nella Memtable subisconol’operazione di flush e quindi la funzione del commit log è solo quella di recuperare i daticonservati nella Memtable nell’eventualità di problemi hardware. Le SSTables sono immu-tabili: Non è possibile effettuarci operazioni di sovrascrittura dopo il flush da Memtable.

Operazione di write

• Filtro Bloom : Si tratta di particolari tipi di cache, nelle quali vengono eseguiti rapidialgoritmi per testare se un elemento è membro di un insieme, che si attivano ad ogni queryper le operazioni di read. Quindi una volta consultato il filtro Bloom, Cassandra accedeall’ SSTable opportuna con i dati richiesti dalla query.

Operazione di read

3.2 Data ModelCassandra come già accennato in precedenza, appartiene alla categoria dei database NoSQL co-lumn family. Quindi le colonne sono raggruppate in insiemi chiamate famiglie (column families),le quali si dividono in tipo semplice e tipo super. Il tipo super column può essere rappresentatocome una famiglia contenuta in un’altra famiglia e la radice è chiamata Keyspace.Cassandra gestisce mappe di 4 oppure 5 dimensioni, a seconda se si tratti di column o supercolumn.Una tabella in Cassandra è una mappa multi-dimensionale, distribuita, indicizzata da una chia-ve; il valore è un oggetto altamente strutturato. La tupla in una tabella è una stringa senzarestrizioni sulla lunghezza, tipicamente lunga da 16 a 36 byte.

17

Ogni operazione per ogni singola tupla è atomica, a prescindere da quante colonne o righe sa-ranno lette o modificate.Essenzialmente è un aggregato di Hash e Array che però rivestono, a seconda della loro posizione,ruoli e funzioni ben distinte.

Data Model

3.2.1 Column e Supercolumn

Una column è un Hash formato dalle chiavi name, value e timestamp che sono stabilite a priori.I valori delle chiavi name e value sono considerati da Cassandra come array di byte e quindipossono contenere praticamente qualsiasi cosa, a differenza del timestamp, che è per necessitàun campo intero (i64). Esempi di column sono:

{name : " age " ,va lue : " 26 " ,timestamp : 123456743}{name : " fu l lname " ,va lue : " Sandro Paganott i " ,timestamp : 836123423}

La column dei NoSQL database è paragonabile ad una cella all’interno di un record che a suavolta è contenuto in una tabella, per quanto riguarda i database relazionali.

Gruppi di column possono essere raggruppati all’interno di supercolumn, che possono essere vistecome column il cui campo value contiene un array di column. Spesso sono usate per raggrupparecolonne con attributi correlati fra di loro, appartenenti allo stesso aggregato. Attualmente peròle SuperColumn in Cassandra sono sempre meno usate in quanto non molto performanti a causadell’impossibilità di indicizzare le subcolumn all’interno di una super column.Un esempio di supercolumn potrebbe essere il seguente:

18

{name : " te l ephone number " ,va lue : {

{name : " p r e f i x " ,va lue : " 349 " ,timestamp : 123123141241

} ,{

name : " number " ,va lue : "0516558976" ,timestamp : 231231231434

}}

}

Si nota che un’altra piccola differenza tra column e supercolumn è l’assenza in queste ultime delcampo timestamp.

Column e supercolumn vengono raccolte in strutture chiamate rispettivamente columnfamilye supercolumnfamily che si sostituiscono al costrutto "tabella" dei database relazionali.La supercolumn family è un’estensione dello standard column family che aggiunge un ulteriorelivello di indicizzazione, detta appunto super column, fra la row key e l’insieme delle colonne.Una columnfamily è contraddistinta da un nome che la identifica e da un array di coppie chiavevalore; ogni elemento di questo array è chiamato row ed è paragonabile al concetto di record deiRDBMS.La chiave di una row funge da identificatore mentre il valore è a sua volta un array di tutti gliattributi del record in questione. Tali attributi possono essere soltanto column, nel caso in cui sistia definendo una columnfamily, o soltanto supercolumn, nel caso in cui il costrutto sia di tiposupercolumnfamily. Ecco un esempio di columnfamily:

User = {sandropaganott i : {age : " 26 " ,emai l : " sandro . paganotti@gmail . com" ,gender : " male " ,username : " spx2 "} ,ja son : {age : " 20 " ,job t i t l e : " p r o f e s s i o n a l b ike r "}}

Non esiste nessuno schema predefinito per le singole row, ne in senso assoluto ne tra le row diuna stessa family.Inoltre è necessario inserire e documentare le column e supercolumn family all’interno del fileiniziale di configurazione, e quindi non è possibile crearle a runtime.

19

Le differenze sostanziali con il modello relazionale sono:

1. Modello Relazionale : Lo schema nel modello relazionale è fisso. Una volta deinite lecolonne per una tabella, durante l’inserimento, in ogni riga tutte le colonne devono essereriempite da almeno un valore NULL.Le tabelle relazionali definiscono solo le colonne, mentre l’utente riempie la tabella con ivalori.

2. Cassandra : In Cassandra, sebbene le column families sono definite, le colonne non losono. Si può liberamente aggiungere qualsiasi colonna a qualsiasi column family, in qualsiasimomento.Una tabella contiene colonne, o può essere definita come una super column family.

3.2.2 KeySpace

L’ultimo gradino in questa gerarchia di strutture dati è occupato dal keyspace, che è il con-tenitore più esterno dei dati in Cassandra. Ricopre lo stesso ruolo assegnato al database perquanto riguarda il modello relazionale e deve essere creato prima di poter effettuare qualsiasioperazione.Esso è un namespace che definisce come i dati vengono replicati nei nodi.

Gli attributi di un keyspace in Cassandra sono:

1. Fattore di replica : come già detto, è il numero di macchine nel cluster che ricevono lacopia dello stesso dato.

2. Strategia di replica : indica il tipo di strategia con cui sistemare le repliche nell’anello.Le possibili strategie sono la SimpleStrategy e la NetworkTopologyStrategy, descritte inprecedenza.

3. Column families : è il contenitore di una collezione di righe. ogni riga, a sua volta,contiene colonne ordinate. Ogni keyspace ha almeno una (spesso molte) column family.

In particolare conterrà tutte le singole tabelle le quali erediteranno tutti gli attributi (replicafactor e column families) definiti sul KeySpace che le contiene.Tipicamente in un cluster esiste un solo keyspace per applicazione e ogni keyspace contieneil set di columnfamily specifico di un’applicazione. Anche questo tipo di struttura deve esseredichiarata nel file di configurazione all’interno del tag KeySpaces, ecco un esempio:

<Keyspace Name=" Inven ta r i o "><ColumnFamily CompareWith="BytesType " Name=" S c a f f a l e "/><ColumnFamily CompareWith="BytesType " Name="Oggetto"/><ColumnFamily CompareWith="BytesType " Name="Tipo l og i e "/></Keyspace>

L’attributo CompareWith indica il metro di ordinamento, sempre sulla chiave, mai sul valore,delle column/supercolumn all’interno delle singole row.

20

Capitolo 4

Applicazioni Cassandra

A differenza di molti altri database NoSQL Cassandra dispone di un proprio linguaggio di querydetto Cassandra Query Language (CQL). L’assonanza nel nome vuole richiamare le forti simi-litudini con SQL.Gli utenti interagiscono con Cassandra attraverso i suoi nodi, utilizzando questo particolare lin-guaggio, che tratta il database (keyspace) come un contenitore di tabelle.Il Cassandra Query Language, CQL3, è arrivato alla sua terza versione ed è diventato l’API diinterrogazione dei dati predefinita e la precedente API, la CLI, è ormai deprecata ed è stata ri-mossa a partire dalla versione 3.x di Cassandra. Il CQL può essere utilizzato via API o attraversouna shell chiamata cqlsh. In Cassandra ogni operazione di write è inizialmente scritta in unospecifico registro detto CommitLog. In seguito i dati passano dal CommitLog alla MemTable,una struttura dati residente in memoria. Quando la MemTable è piena, i dati verranno scrittiin un file su disco detto SSTable.Per le operazioni di read, Cassandra prende i valori nella MemTable, e consulta un particolarefiltro detto filtro Bloom. Si tratta di particolari tipi di cache che si attivano ad ogni query, nel-le quali vengono eseguiti rapidi algoritmi per testare se un elemento è membro di un insieme.Quindi una volta consultato il filtro Bloom, Cassandra accede all’ SSTable opportuna con i datirichiesti dalla query.

Per i nostri esempi utilizzeremo un particolare programma rilasciato da datastax detto Da-taStax Distribution of Apache Cassandra (DDC). In particolare verrà utilizzata la CommunityEdition, che contiene un terminal Cassandra, in cui è possibile formulare le query CQL graziealla shell cqlsh, ed inoltre è fornito di un DataStax OpsCenter con cui poter gestire e modificarei differenti clusters e i loro nodi tramite una pagina web.

4.1 KeySpaceLa sintassi per la creazione di una Keyspace è:

�CREATE KEYSPACE <identifier > WITH <properties >� �In particolare, il comando CREATE KEYSPACE ha due proprietà: replication e durable writes.

21

�CREATE KEYSPACE " KeySpace Name"WITH replication = {’class ’: " Strategy name", ’replication_factor ’ :

"No.Of replicas "}AND durable_writes = " Boolean value ";� �Si noti che però in caso di più datacenter (con la NetworkTopologyStrategy) questa scritturanon è più adatta in quanto bisogna specificare il fattore di replica per ognuno dei datacenterpresenti nel cluster:

�CREATE KEYSPACE " KeySpace Name"WITH replication = {’class ’: " Strategy name", ’datacentername1 ’ :

"No.Of replicas ", ’datacentername2 ’ :"No.Of replicas " ,..}

AND durable_writes = " Boolean value ";� �4.1.1 Replication

Lo scopo della replicazione è di specificare la strategia di replica, che abbiamo elencato in pre-cedenza, e il numero di repliche del dato richieste.

EsempioIn questo esempio vogliamo creare, tramite la shell CQL fornita da DataStax CommunityEdition, un keyspace chiamato "persone", utilizzando la prima strategia (SimpleStrategy)e scegliendo il fattore di replica per 3 copie.

Create Keyspace

E’ possibile inoltre verificare se la tabella viene creata, utilizzando il comando DESCRIBEkeyspaces. Così facendo verranno mostrati tutti i keyspace creati.

4.1.2 Durable writes

Utilizzando questa opzione, è possibile istruire Cassandra se utilizzare commitlog per gli aggior-namenti sulla keyspace corrente. Come si nota dall’esempio precedente, di default la proprietà

22

durable writes di una tabella è impostata su true, ma può anche essere settata a false. Inoltreper questa proprietà non è possibile utilizzare la SimpleStrategy.

EsempioVogliamo creare un keyspace di nome "prova" che abbia la proprietà di durable writessettata a false. Si noti che in questo caso, per specificare il numero di repliche dobbiamospecificare il nome del datacenter considerato. È possibile verificare se la proprietà durable

writes è stata impostata su false, interrogando il keyspace di sistema. Questa query ti datutte le KeySpaces con le loro proprietà.

�cqlsh > SELECT * FROM system . schema_keyspaces ;� �

Che presenterà un output di questo tipo:

Se volessimo modificare le proprietà dello spazio delle chiavi, il comando da utilizzare è ALTERKEYSPACE. Cosi come CREATE KEYSPACE, anche questo comando agisce su due proprietà:replica e durable writes. La sintassi è la seguente�ALTER KEYSPACE <identifier > WITH <properties >� �vale a dire:

23

�ALTER KEYSPACE " KeySpace Name"WITH replication = {’class ’: " Strategy name", ’replication_factor ’ :

"No.Of replicas2 };� �Esempio

Nell’esempio che segue prendiamo in considerazione il keyspace di nome "prova", creatoprecendentemente, modificando la proprietà di durable writes da false a true:

Alter Keyspace

Inoltre è possibile eliminare un spazio delle chiavi utilizzando lo spazio delle chiavi comandoDROP. La sintassi è la seguente:

�DROP KEYSPACE <identifier >� �4.2 Column FamiliesPer popolare i keyspaces precedentemente creati con delle column families la sintassi è moltosimile al linguaggio SQL. Prima di tutto però bisogna scegliere il keyspace in cui inserire letabelle, questo è possibile grazie al comando USE, la cui sintassi è:

�USE <identifier >� �In particolare nell’esempio che verrà trattato, sarà considerato il keyspace "persone" creato inprecedenza: E’ possibile creare una column family utilizzando il comando CREATE TABLE,

la cui sintassi è:

24

�CREATE TABLE tablename (column1 name datatype PRIMARYKEY ,column2 name data type ,column3 name data type ,PRIMARY KEY ( column1 ))� �La chiave primaria è una colonna che viene utilizzata per identificare in modo univoco unariga, pertanto è obbligatorio definirla durante la creazione di una tabella. Una chiave primariaè costituita da una o più colonne di una tabella.Esempio

In questo esempio si vuole creare una tabella "studenti" popolata con gli attributi id, nomee email. Inoltre si considerano come chiavi primarie sia l’id che l’email dello studente. Perverificare che la tabella è stata creata si utilizza il comando DESCRIBE TABLE.

Create Table

Anche per quanto riguarda le operazioni di scrittura e lettura delle tabelle la sintassi è moltosimile a quella del linguaggio SQL. In particolare per la scrittura si utilizza il comando INSERTcome segue:

�INSERT INTO table_name( column_name , column_name ...)VALUES ( value , value ... )� �Per le query di lettura si utilizza il comando SELECT:

�SELECT column_name FROM table_name� �

25

EsempioSi vuole popolare la tabella studenti creata in precedenza con degli studenti e i loro at-tributi. Per quanto riguarda la lettura, si verifica prima se l’inserimento è andato a buonfine, selezionando tutta la tabella, e poi si esegue una query in particolare.

Esempi di query

Se si volessero eseguire più query nello stesso momento, basta far precedere le stesse dalcomando BEGIN BATCH e al termine delle query aggiungere: APPLY BATCH.

Per gestire e modificare i diversi cluster e i nodi contenuti in esso, DataStax mette a disposizioneun OpsCenter la cui interfaccia è mostrata in seguito:

OpsCenter

Come si può notare da qui si possono monitorare sia il numero di nodi e datacenter appartenential cluster, sia una grade varietà di grafici che mostrano il traffico di dati avvenuto in un deter-minato periodo. Ad esempio nell’immagine sopra si può notare come il grafico Write Requesttestimoni la scrittura del keyspace e delle tabelle, fatta negli esempi precedenti.

26

Per gestire il cluster, ad esempio aggiungendo nodi, basta andare su cluster actions e selezionareadd node.

Inoltre l’OpsCenter fornisce una soluzione alternativa alla shell cqlsh di cassandra utilizzatain precedenza. Infatti accedendo alla sezione data si possono comodamente creare e gestire key-space e tabelle come mostrato in figura.

Per poter modificare un keyspace precedentemente creato, basta cliccare sullo stesso ed anda-re nella sezione edit. In questo modo si possono modificare numero e strategia di replica e laproprietà di durable_writes, oppure eliminare l’intero keyspace.

27

Conclusioni

In questo elaborato abbiamo messo in luce come il modello relazionale, che fino a pochi anni fasembrava un modello insostituibile per la rappresentazione dei dati, nell’era dei Big Data, hainiziato a mostrare le sue debolezze di fronte alle dimensioni e alla variabilità delle informazioni.Infatti, sebbene rimanga ancora il modello più diffuso, il modello E-R non si è dimostrato il piùadatto quando si ha a che fare con domini molto dinamici, caratterizzati da dati non strutturatie da moli di informazioni con rapidi incrementi che è opportuno affrontare con sistemi flessibiliin grado di scalare orizzontalmente, senza compromettere i dati esistenti.Si è giunti, pertanto, alla nascita dei cosiddetti database NoSQL dei quali abbiamo inanzituttoelencato le principali differenze con i RDBMS, per sottolinearne vataggi e svantaggi.

Si noti che i NoSql database, nonostante siano stati introdotti solo agli inizi degli anni 2000,abbiano già avuto un massiccio sviluppo e abbiano riscontrato un grandissimo bacino di utenze,come alcuni dei principali social network (Facebook e Twitter), oppure aziende che fornisconoun servizio efficiente di streaming (Netflix).Con l’avanzare degli anni e quindi con l’incremento delle tecnlogie informatiche, si può dedurreche la mole di dati da gestire crescerà eponenzialmente, portando i NoSql database ad essere imodelli maggiormente usati in quest’ambito. Questo anche grazie al fatto che i modelli svilup-pati sono numerosi e ognuno di essi è idoneo a soddisfare dei requisiti specifici.

Tuttavia, come già accennato nell’elaborato, il tradizionale modello relazionale non è desti-nato a scomparire, in quanto ci sono ancora molte applicazioni in cui il modello E-R è ancorala soluzione migliore.

28

Bibliografia

[1] https://docs.datastax.com/en/cassandra.

[2] http://www.w3ii.com/it/cassandra/cassandra_referenced_api.html.

[3] http://www.datastax.com/.

[4] http://cassandra.apache.org/.

[5] http://dassia.crs4.it/wp-content/uploads/2014/11/04_CASSANDRA.pdf

[6] http://www.html.it/articoli/introduzione-a-apache-cassandra-1/

[7] http://www.html.it/articoli/sql-e-nosql-a-documenti-il-confronto-2/

[8] https://wiki.apache.org/cassandra/

[9] http://dassia.crs4.it/wp-content/uploads/2014/11/01_NOSQL.pdf

29