Learn

All is packed to conquer galaxies. Just here. For Free.

PERCHÈ NOSQL?

little_title_logoPerchè scegliere una soluzione NoSQL?

I Big Users e i Big Data, che dominano gli attuali scenari di business, guidano ad oggi la considerazione e l’adozione di un nuovo modello di database basato su una tecnologia NoSQL, in alternativa ai database relazionali.

Big Users

Oggi la diffusione vertiginosa dell’uso globale di internet, l’aumento del numero di ore trascorse online dagli users e la crescente popolarità di smartphone e tablet fa sì che siano molte le applicazioni con milioni di utenti al giorno.
Il consistente numero di utenti, combinato con la natura dinamica delle tipologie di utenza, rafforzano il bisogno di una tecnologia di database più facilmente scalabile.
Con le tecnologie relazionali molti sviluppatori trovano difficile, se non impossibile, ottenere la scalabilità dinamica di cui necessitano gestendo nel frattempo la richiesta di performance degli utenti.

Big Data

E’ diventato più facile raccogliere dati attraverso terzi come Facebook, D&B e altri: le informazioni personali e i contenuti generati dagli utenti, i dati di geo localizzazione, le statistiche sociali sono solo alcuni esempi della crescente gamma di dati raccolti fino ad oggi.
Gli sviluppatori vorrebbero un database molto flessibile che riesca a supportare facilmente nuovi tipi di dati e non sia vincolato da strutture dati statiche: la maggior parte dei nuovi dati è destrutturata e semi-strutturata, quindi gli sviluppatori necessitano di un database capace di un efficiente metodo di immagazzinamento di tali dati.
Sfortunatamente, il rigido approccio schematico caratteristico dei database relazionali rende impossibile una veloce incorporazione di nuovi tipi di dati e non è adatto a dati destrutturati o semi-strutturati: NoSQL fornisce un modello di dati che si addice meglio a questo tipo di necessità.

I modelli di database relazionali e NoSQL sono molto diversi. Un database relazionale è composto da tabelle che sono messe in relazione fra loro attraverso chiavi esterne, meglio note come foreign keys. In pratica, i dati vengono distribuiti in diverse tabelle che contengono righe e colonne, ossia tuple di dati che prendono senso se collegati ai rispettivi attributi (intestazioni delle colonne), assumendo così la natura di informazioni. In questo modo, anche se i dati descrivono uno stesso oggetto, devono essere comunque memorizzati in tabelle differenti ed essere poi messi in relazione tra loro. Ogni volta che si effettua un’interrogazione, chiamata query, i dati devono essere raccolti dalle differenti tabelle e combinati fra loro per fornire l’informazione richiesta dall’applicazione. Lo stesso vale per le operazioni di cancellazione, inserimento e aggiornamento. Per ogni query eseguita in linguaggio SQL, è necessario verificare le relazioni tra i differenti dati presenti nelle differenti tabelle e applicare le eventuali modifiche richieste, preservando l’integrità del DB da eventuali corruzioni.

Leggi tutto

I database NoSQL sono progettati in maniera differente: ad esempio nei database NoSQL orientati ai documenti, i dati non sono inseriti in tabelle e, soprattutto, non sono distribuiti secondo differenti strutture logiche, ma sono raccolti, aggregati e conservati in documenti nel formato JSON. Ogni JSON è capace di raccogliere in un unico documento/oggetto tutti i dati, logicamente in relazione, ripartiti tra le tabelle del database relazionale, in modo che il documento possa essere trattato dall’applicazione come un vero e proprio oggetto unico. In questo modo si evita il processo di aggregazione dei dati tipico delle elaborazioni SQL, poichè i dati sono già in formato aggregato.

Si ottengono così migliori performance nelle operazioni di accesso al DB, anche se si ha lo svantaggio della duplicazione dei dati dovuta alla loro aggregazione. Di contro, i costi sempre meno proibitivi dei sistemi di storage rendono questo svantaggio di poco importanza, a fronte di un netto guadagno di flessibilità di sistema (facilmente scalabile e distribuibile) offerto dal modello NoSQL.

Un’ulteriore caratteristica che differenzia i database relazionali da quelli NoSQL è la rigida schematizzazione. Per realizzare una tabella di qualsivoglia database relazionale, è necessario definire a priori uno schema (noto come entità-relazione), nel quale si definiscono anche i singoli attributi delle tabelle per la corretta interpretazione dei dati raccolti.

Cambiare in itinere il suddetto schema, ad esempio introducendo nuovi attributi, è problematico e, spesso, sconsigliato proprio per evitare di compromettere i dati e la struttura del DB. Tale limite rende i database relazionali poco adatti alla caratteristica dinamica dei Big Data e alla scalabilità richiesta dalle condizioni di Big User e dalle tecnologie di cloud computing .

La valida alternativa che risolverebbe il problema è il modello NoSQL, detto schemaless, ossia privo di qualsiasi schema della struttura dei dati definito a priori. Ad esempio, nei database NoSQL orientati ai documenti,è possibile inserire nei documenti JSON tutti i campi necessari, senza necessità di specificarli. In questo modo, i dati inseriti possono variare in qualsiasi momento per arricchire le applicazioni, senza rischi per l’integrità del DB.

Da questa caratteristica deriva che i database relazionali sono poco adatti a incorporare velocemente nuovi tipi di dati e sono sconsigliati per la conservazione di dati semi-strutturati o non strutturati, al contrario di quelli NoSQL che si rivelano utili ed efficienti in entrambi i casi.
Se si vuole quindi realizzare un’applicazione scalabile senza grosse problematiche, a costi contenuti, distribuibile nel cloud computing e le cui informazioni devono essere sottoposte ad analisi dei Big Data, la scelta giusta risiede nei database NoSQL.

Il Satellite Volta, in particolare, fornisce soluzioni e strumenti per l’uso di Apache Cassandra, database NoSQL di tipo ”chiave/valore eventually consistent”, sviluppato dall’Apache Software Foundation e rilasciato con licenza open source. Pur seguendo le regole sopra elencate, caratterizzanti dei database NoSQL in generale, i punti di forza di Cassandra sono l’ottimizzazione della gestione di grandi quantità di dati e la sua natura distribuita: un cluster di nodi Cassandra non presenta single points of failure e garantisce, quindi, alta affidabilità e ottime performance.

Proprio per queste ragioni negli ultimi tempi grandi aziende, come Ebay, hanno deciso di orientarsi verso una soluzione NoSQL, ottenendo, nel caso specifico, un miglioramento del tempo di risposta SLA di 6 miliardi di scritture e 5 miliardi di letture al giorno gestendo, nel frattempo, 250TB di dati attraverso Cassandra.

Una volta determinato che la soluzione NoSQL è la più adatta alla tua situazione aziendale, Satellite Volta può fornirti software, servizi e consulenza strategica per garantire performance di successo con la tecnologia NoSQL.

FAQ

little_title_logoSatellite Volta

Cos’è il progetto Volta?

Per informazioni approfondite sul progetto Volta, clicca qui.

Cos’è Volta Control?

Volta Control è un tool che permette la progettazione, l’implementazione e la gestione di database Cassandra tramite interfaccia grafica. Tramite questo strumento si potrà visualizzare l’elenco di keyspace e le relative tabelle presenti in un nodo ed effettuare operazioni di scrittura/lettura/cancellazione tramite codice CQL.

Come posso segnalare un bug?

I prodotti Volta sono progetti in evoluzione: hai trovato un bug? Se vuoi, segnalacelo nelle nostre pagine SourceForge nel caso delle librerie Volta, o al nostro indirizzo support@satellitevolta.com nel caso dei tool.

Posso contribuire ai prodotti Volta? Come?

I suggerimenti e i feedback sono sempre bene accetti! Le librerie Volta sono progetti open source a tutti gli effetti: le loro pagine su SourceForge forniscono sia il download del pacchetto .jar sia l’intero codice scaricabile tramite SVN. I tool Volta sono gratuiti, ma non open source: tuttavia, restiamo aperti a suggerimenti, che possono essere inviati all’indirizzo support@satellitevolta.com.

Quali licenze sono applicate ai prodotti Volta?

Per le librerie Volta viene applicata la licenza Apache Software License 2.0.
Al tool Volta Control viene invece applicata la seguente licenza:
Satellite Volta Software License, Version 1.0, September 2014
By downloading and using this software, you agree to the terms and conditions of Satellite Volta Software License (SVSL) for use, reproduction, and distribution.
SVSL sets the same terms and conditions of the Apache Software License 2.0 (http://www.apache.org/licenses/LICENSE-2.0.html), with the exception that:
– You may distribute copies of this software, but only without modifications, only in Object form and only free of charge
– This software is released in Object form only

Cos’è Volta Criteria?

Volta Criteria è una libreria java che permette di effettuare query e statement CQL senza la necessità di scrivere codice (e quindi di conoscere la sintassi) CQL. Pensato per chi desidera integrare un database Cassandra all’interno della propria applicazione java, fornisce metodi intuitivi per costruire statement. La libreria Volta Criteria è disponibile come progetto open source su SourceForge.

Cos’è Volta Log?

Analogamente al classico log4j, Volta Log è una libreria java che permette di gestire i log della propria applicazione, salvandoli in Cassandra all’interno di apposite strutture invece che in un file. Ciò permetterà un accesso più rapido ai log e una gestione più efficiente. La libreria Volta Log è disponibile come progetto open source su SourceForge.

Cos’è Volta Monitor?

Volta Monitor è un tool che permette il monitoraggio dello stato di salute di un cluster: connettendosi ad un nodo, sarà possibile visualizzare la topologia del cluster e controllare lo stato, il carico di dati e le statistiche di ogni singolo nodo.

little_title_logoApache Cassandra

Cos’è un database NoSQL?

Il termine NoSQL sta per ”Not only SQL” e si riferisce a tutti quei database management system che non utilizzano il classico modello relazionale e, quindi, nemmeno il linguaggio SQL, comunemente usato per l’interrogazione di database relazionali. Le caratteristiche principali del database NoSQL sono:
• L’assenza di uno schema fisso: i dati sono spesso memorizzati in strutture dinamiche
• L’assenza di operazioni di join: non potendo mantenere relazioni tra i dati, non ha più senso parlare di operazioni di unione tra di essi
• La denormalizzazione dei dati: in totale controtendenza rispetto ai database relazionali, i database NoSQL incoraggiano la replicazione di dati in più strutture
• La non garanzia di tutte le proprietà ACID: un database NoSQL non garantisce l’atomicità né l’isolamento delle proprie operazioni; la consistenza è solo in alcuni casi di tipo ”eventually” (ovvero, ”prima o poi” verrà raggiunta).

Cos’è Apache Cassandra?

Apache Cassandra è un database NoSQL di tipo ”chiave/valore eventually consistent”, sviluppato dall’Apache Software Foundation e rilasciato con licenza open source. I suoi punti di forza sono l’ottimizzazione della gestione di grandi quantità di dati e la sua natura distribuita: un cluster di nodi Cassandra non presenta single points of failure e garantisce, quindi, alta affidabilità e ottime performance.

Che tipo di architettura usa Apache Cassandra?

Apache Cassandra ha un’architettura distribuita di tipo peer-to-peer: ogni nodo del cluster ha la stessa importanza degli altri e i dati vengono distribuiti il più uniformemente possibile. L’assenza di elementi master-slave nell’architettura di Cassandra e la possibilità di replicazione di dati, garantisce una forte affidabilità.

Quali vantaggi ho nell’usare Apache Cassandra?

Un database NoSQL come Apache Cassandra fornisce uno strumento perfetto per gestire, con ottime performance, grandi moli di dati grazie alla sua scalabilità orizzontale. Inoltre, essendo pensato come sistema distribuito peer-to-peer su più nodi o eventualmente su più datacenter, non ha single points of failure e garantisce quindi un’alta affidabilità e disponibilità di dati.

Apache Cassandra è la scelta ideale per la mia applicazione?

I database NoSQL non intendono soppiantare gli RDBMS, ma affiancarsi ad essi: ci sono situazioni in cui Cassandra risolve tutti i problemi legati all’applicazione che si sta sviluppando e situazioni in cui un database relazionale resta la scelta più adatta. Apache Cassandra si presta particolarmente a progetti in cui ci sono molte scritture. Casi d’uso comuni sono:
• Gestione di time series
• Messaggistica nei social network
• Monitoraggio di dispositivi
• Gestione di log
• Streaming di media (audio, video…)
• Analisi di dati real time
• Analisi di dati statistici
• Messaggistica nei giochi real time

Quali sono i limiti di Apache Cassandra?

Esistono alcuni tipi di applicazioni per cui un database NoSQL e Apache Cassandra in particolare si presta perfettamente, mentre per altre situazioni un database relazionale resta la scelta migliore. Nella decisione di quale DBMS usare per il proprio progetto, bisogna tenere conto delle seguenti limitazioni di Cassandra:
• In Cassandra non esistono funzionalità di join o aggregazione di dati in genere: questo è dovuto sia alla struttura di base di Cassandra, sia alla necessità di denormalizzare i dati per poterli leggere da un singolo nodo del cluster laddove sia possibile.
• L’ordinamento di dati è disponibile solo all’interno delle singole partizioni: questo è dovuto alla predisposizione di Cassandra per la gestione di grandi moli di dati. Ordinare milioni di tuple sarebbe un’operazione estremamente costosa.
• I dati che appartengono ad una singola partizione devono poter essere salvati su un solo nodo: questo è dovuto al meccanismo che Cassandra usa per salvare/leggere i dati tramite chiavi primarie.
• I limiti ”fisici” sui dati salvati sono i seguenti: una singola colonna non può essere più grande di 2GB; i dati di tipo collection non possono superare i 64 KB; il massimo numero di celle che possono essere contenute in una singola partizione è di 2 miliardi.
• La non garanzia di tutte le proprietà ACID: Cassandra non garantisce l’isolamento delle proprie operazioni; l’atomicità viene fornita solo parzialmente e comporta costi aggiuntivi; la consistenza è solo di tipo ”eventually” (ovvero, ”prima o poi” verrà raggiunta).

Per quali applicazioni è disponibile Apache Cassandra?

Apache Sofware Foundation fornisce gratuitamente e con licenza open-source il download della versione di Cassandra per ambiente Linux. Esistono versioni sia gratuite, sia a pagamento per gli altri sistemi operativi, tra cui Microsoft Windows, Mac OS e le varie distribuzioni di Linux quali CentOS, Debian e Ubuntu.

Da dove posso scaricare Apache Cassandra?

Apache Cassandra è un software gratuito e open source: è possibile scaricarne la versione per ambiente Linux direttamente dal sito del progetto: http://cassandra.apache.org/download/ . In esso è possibile trovare riferimenti anche ad altre versioni sviluppate privatamente e disponibili anche per Microsoft Windows e Mac OS.

little_title_logoCQL e le strutture dati in Cassandra

Cos’è il CQL?

Il CQL (Cassandra Query Language) è un linguaggio implementato per fornire agli sviluppatori e agli utilizzatori di Cassandra un modo meno ostico del Thrift (il linguaggio nativo di Cassandra) per effettuare interrogazioni al database. Come sintassi, il CQL si rifà il più possibile a SQL, usando keywords classiche come SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ecc. Ovviamente sono presenti alcune differenze e alcune limitazioni dovute al tipo di architettura diversa rispetto a quella dei database relazionali: non sono presenti funzionalità di join, l’ordinamento è limitato alle clustering key, l’insieme dei data types supportati è diverso.

Quali sono i tipi di dati supportati da Cassandra?

I data types supportati da Apache Cassandra sono i seguenti:
• ascii, text, varchar: dati testuali
• bigint, decimal, double, float, int, varint: dati numerici
• boolean: dati booleani
• blob: file e/o array di byte
• counter: contatori
• inet: indirizzi IP
• timestamp: dati temporali
• uuid, timeuuid: identificativi univoci
• list, set, map: collezioni

Cos’è un keyspace?

Un keyspace in Cassandra è ciò che nei database relazionali viene comunemente chiamato ”database schema”, ovvero, un contenitore di tabelle. Ogni keyspace può contenere più column family (tabelle). Al momento della creazione andrà specificata la strategia che si vuole seguire per la replicazione di quel keyspace e il fattore di replicazione associato (ovvero, su quanti nodi andranno replicati i dati contenuti in esso).

Cos’è una column family?

Nel tentativo di avvicinare i concetti dei database NoSQL a quelli dei database relazionali (in generale meno ostici per chi arriva dal modello classico), si può dire che una column family corrisponde al concetto di tabella. Per essere più precisi, una column family è un insieme di column, per ciascuna delle quali verranno specificati il tipo di dato e il nome.

Cos’è una column?

Una column in Cassandra è una tupla contenente tre valori: il nome della column, il valore in essa contenuto e il timestamp dell’ultima scrittura effettuata su di essa. In CQL una column è facilmente associabile ad una colonna di una tabella, per cui verranno specificati il tipo di dato contenuto e il nome.

Cos’è una primary key?

Una primary key è, come accade in SQL, una colonna o un insieme di colonne i cui valori identificano univocamente la riga. Se la primary key è composta da più column, parte di esse costituirà la partitioning key, le altre saranno le clustering column.

Cos’è una partitioning key?

La partitioning key è una colonna o un insieme di colonne contenute nella primary key che indicano a quale partizione appartengono i dati della riga associata e, quindi, in quale nodo del cluster andranno salvati.

Cos’è una clustering column?

Una clustering column è una colonna che fa parte della primary key, ma non della partitioning key. Non indica, quindi, la partizione a cui i dati appartegono, bensì definisce l’ordinamento che i dati seguono all’interno di quella partizione. Le clustering column possono essere o meno presenti e possono essere una o più per ogni primary key.