[NO-SQL] Appunti su analisi di performance e comparazione dei database NoSQL

Continuando la trattazione dell’argomento dei Database No-SQL, viste le impressioni e segnalazioni via email dei visitatori di questo blog, condivido un pò di appunti in un documento che potete scaricare qui di seguito:

Database NoSQL-Comparazione tecnologie

Il documento raccoglie le considerazioni e le valutazioni oggettive emerse durante la lettura di articoli e documentazioni online sull’argomento dei DB No-SQL. Nello specifico, l’oggetto di studio è stato MongoDB, confrontandolo con altre soluzioni (relazionali e non) e, in particolare, è stata approfondito il suo possibile utilizzo per la gestione di una struttura a grafo.

NoSQL Model

Ecco l’indice dei paragrafi del documento, sperando vi possa essere utile per spunti o per far nascere riflessioni/discussioni sull’argomento:

  1. I database NoSQL
    1. Perché NoSQL? Il teorema di CAP e il No-SQL data model
    2. Un confronto tra le famiglie di DB NoSQL
    3. I database document-oriented e graph-oriented
  2. Breve introduzione su MongoDB
    1. Principali caratteristiche di MongoDB
    2. Comparazione tra MongoDB e MySQL
    3. Ambiti di utilizzo e realizzazione dei direct graph con MongoDB
    4. Soluzioni ibride: MongoDB + database a grafo + RDF triple store
    5. Analisi delle prestazioni di MongoDB all’aumentare dei documenti memorizzati
  3. Confronto tra le performance di MongoDB e di altri database NoSQL
    1. Confronto MongoDB con vari database NoSQL
    2. Confronto HBase e MongoDB
  4. Analisi di performance dei Graph Database
    1. Elenco e caratteristiche di varie implementazioni di Graph Database
    2. Analisi e confronto delle performance di varie implementazioni di Graph Database
    3. Scalabilità
Database NoSQL-Comparazione tecnologie
Titolo: Database NoSQL-Comparazione tecnologie (0 click)
Etichetta:
Filename: database-nosql-comparazione-tecnologie.pdf
Dimensione: 770 kB

[NO-SQL] Not Only SQL: una panoramica sui database NoSQL

NoSQL vs RelIn precedenti articoli su questo blog, si è già accennato al movimento NoSQL (Not Only SQL) e ad una delle sue tecnologie, MongoDB:

Ebbene, da allora (pochi mesi), le tecnologie sono aumentate e l’interesse verso questo modello di dati è esploso, di pari passo alla tematica del Big Data che sta diventando molto di moda nell’ultimo periodo (molti ne parlano, ma chi davvero lo fa???).

Ecco le keywork che riassumono le peculiarità dei DB NoSQL:

  • non-relational: le struttura di memorizzazione dei dati è differente dal modello relazionale. L’approccio a “schema rigido” dei db relazionali non permette di memorizzare dati fortemente dinamici. I db NoSQL sono “schemaless” e consentono di memorizzare “on the fly” attributi, anche senza averli definiti a priori
  • distributed: la flessibilità nella clusterizzazione e nella replicazione dei dati permette di distribuire su più nodi lo storage (e il calcolo), in modo da realizzare potenti sistemi faulttolerance
  • open-source: alla base del movimento NoSQL vi è la filosofia “open-source”, fondamentale per contribuire ad accrescere le potenzialità delle sue tecnologie
  • horizontally scalable: architetture enormemente scalabili, che consentono di memorizzare e gestire una grande quantità di informazioni

Al seguente link, trovate una lista aggiornata dei database NoSQL che rispettano i requisiti su citati: http://nosql-databases.org

Un whitepaper sulla tecnologia dei DB NoSQL l’ho trovato sul sito di CouchBase (un altro DB NoSql document-oriented): NoSQL Database Technology

E ancora, “10 cosa da sapere sui DB NoSQL”: 10 things you should know about NoSQL databases

Essi sono suddivisi nelle seguenti famiglie:

  • Wide Column Store / Column Families

  • Document Store

  • Key Value / Tuple Store

  • Graph Databases

  • Multimodel Databases

  • Object Databases

  • Grid & Cloud Database Solutions

  • XML Databases

  • Multidimensional Databases

  • Multivalue Database

databaseNoSQL

Dal precedente grafico, si possono fare delle considerazioni. Un parametro di valutazione è l’operational complexity: la struttura di memorizzazione dei DB a grafo è particolarmente complessa e anche gli algoritmi che ne permettono la navigazione (traversal) sono i classici algoritmi di routing, di una certa complessità computazione. Ovvio che all’aumentare della complessità nella struttura dati, diminuisce la capacità di memorizzazione dei dati stessi (parametro size). La famiglia dei DB a grafo (graph databases), come NEO4J e OrientDB, dispone di routine di accesso ai dati particolarmente performanti, ma non possono trattare troppi dati – [per una introduzione ben fatta sui database a grafo, eccovi un buon riferimento: Graph Databases An Overview].

Al contrario, la famiglia dei DB a chiave-valore (key-value databases), come Redis, è particolarmente consigliata per memorizzare e gestire grosse quantità di dati. La famiglia dei DB a documenti (document databases), come MongoDB, si trovano in una posizione intermedia.

Un plauso va a due sviluppatori italiani che hanno sviluppato i più utilizzati DB NoSQL del momento:

Un sondaggio aperto agli utilizzatori (previa registrazione) sui vari DB (sia relazionali che non) e che vi permette di comparare le varie caratteristiche, lo trovate a questo link (potete inserire più colonne per confrontare più tecnologie tra loro): http://vschart.com/compare/mongodb/vs/redis-database

Ho cercato online una tesi di laurea in cui poter trovare un benchmark sui DB NoSQL e ho trovato quella ben fatta su Analisi delle performance dei database non relazionali: il caso di studio di MongoDB dell’Università di Padova, dove si compara MongoDB col db relazionale più diffuso, MySQL.

Eccovi un articolo di comparazione tra i principali DB delle famiglie elencate:

Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Couchbase vs Neo4j vs Hypertable vs ElasticSearch vs Accumulo vs VoltDB vs Scalaris comparison

E ancora, un confronto tra alcuni DB NoSQL, dove Cassandra e HBase vincono sul throughput: A vendor-independent comparison of NoSQL databases: Cassandra, HBase, MongoDB, Riak.

Origin of NoSQL

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2013/02/07/no-sql-not-only-sql/.

[NO-SQL] Il Teorema di CAP e il No-SQL data model

Volendo continuare la serie sulla “filosofia” NO-SQL e sulle prerogative per cui è necessaria (vedi l’articolo riportato su questo blog, “NO-SQL e introduzione a MongoDB“), estrapolo qui le motivazioni e le caratteristiche lette negli articoli riportati su BigDataNERD:

Perché NO-SQL?

Per poter rispondere alla domanda occorre esaminare il “teorema di CAP” e ricordare che un concetto fondamentale degli RDBMS è quello delle “ACID transactions” (A=Atomicity, C=Consistency, I=Isolation, D=Durability)

  • A come Atomicità. La transazione è indivisibile, ossia o tutti gli statements che la compongono vengono applicati ad un database o nessuno.
  • C come Consistenza. Il database deve rimanere in uno stato consistente prima e dopo l’esecuzione di una transazione, quindi non devono verificarsi contraddizioni (inconsistency) tra i dati archiviati nel DB.
  • I come Isolamento. Quando transazioni multiple vengono eseguite da uno o più utenti simultaneamente, una transazione non vede gli effetti delle altre transazioni concorrenti.
  • D come Durabilità. Quando una transazione è stata completata (con un commit), i suoi cambiamenti diventano persistenti, ossia non vengono più persi.

I più comuni e diffusi RDBMS supportano le transazioni ACID e i principi su esposti sembrerebbero bastare. Ma dov’è il problema?

Nell’era del Web 2.0, le applicazioni devono lavorare su bilioni e trilioni di dati ogni giorno e la scalabilità è un concetto che in tale ambito ricopre un ruolo importantissimo. Per questo motivo i database hanno bisogno di essere distribuiti sulla rete per realizzare una scalabilità orizzontale. Esaminiamo qui il concetto di “CAP theorem” per valutare le caratteristiche di un siffatto sistema di storage distribuito dei dati.

Il teorema di CAP fu teorizzato da Eric Brewer nel 2000 (C=Consistency, A=Availability, P=Partition-Tolerance). Per maggiori informazioni si veda il seguente articolo: ACID vs. BASE il Teorema di CAP (di Stefano Pedone).

Nell’ambito di un sistema di storage distribuito, i 3 principi hanno la seguente definizione:

Consistency: se viene scritto un dato in un nodo e viene letto da un altro nodo in un sistema distribuito, il sistema ritornerà l’ultimo valore scritto (quello consistente).

Availability: Ogni nodo di un sistema distribuito deve sempre rispondere ad una query a meno che non sia indisponibile.

Partition-Tolerance: è la capacità di un sistema di essere tollerante ad una aggiunta o una rimozione di un nodo nel sistema distribuito (partizionamento) o alla perdita di messaggi sulla rete.

Secondo la teoria CAP, è impossibile garantire tutti e tre i principi del teorema di CAP. Infatti, si consideri un sistema distribuito e si supponga di aggiornare un dato su un nodo 1 e di leggerlo da un nodo 2, si verificheranno le seguenti conseguenze:

  1. Il nodo 2 deve ritornare l’ultima “miglior” versione del dato (quella consistente) per non violare il principio della Consistenza
  2. Si potrebbe attendere la propagazione del dato modificato nel nodo 2 e, quest’ultimo, potrebbe mettersi in attesa della versione più aggiornata, ma, in un sistema distribuito, si ha un’alta possibilità di perdita del messaggio di aggiornamento e il nodo 2 potrebbe attenderlo a lungo. Così non risponderebbe alle query (indisponibilità), violando il principio dell’Availability
  3. Se volessimo garantire sia la Consistency che l’Availability, non dovremmo partizionare la rete, violando il principio del Partition-Tolerance

Le web applications progettate in ottica Web 2.0, caratterizzate da architetture altamente scalabili e profondamente distribuite con politiche di prossimità geografica, puntano in maniera forte sulla garanzia di alte prestazioni ed estrema disponibilità dei dati. Si trovano quindi ad essere altamente scalabili e partizionate. La filosofia NO-SQL è sbilanciata verso la ridondanza dei nodi e la scalabilità.

Di seguito, si riporta una tabella dei maggiori database NO-SQL del momento:

Il NoSQL data model può essere implementato seguendo differenti approcci a seconda delle strutture dati con cui si rappresentano i record di dato.

  • Famiglie di colonne o “wide column store” (come Cassandra e HBase): le informazioni sono memorizzate in colonne, in coppie chiave/valore. Tipicamente sono usati nell’ambito della memorizzazione distribuita dei dati;
  • Document Store (come CouchDB, MongoDB): le informazioni sono organizzate in “Document“, rappresentati in XML, JSON o BSON, e l’accesso ai dati avviene attraverso API che interrogano veri e propri dizionari. Sono molto usati nello sviluppo di attuali web applications;
  • Key/Value Store (come Membase, Redis): la struttura dati di memorizzazione è una Hash Table (coppia chiave-valore). Indicate per sistemi di caching o Hash Table distribuite;
  • Graph Data Store (come Neo4J, InfoGrid, OrientDB). Il modello di programmazione è il grafo e l’accesso ad archi e nodi avviene attraverso algoritmi di ricerca su grafo. Tipicamente si usano nei social network.

 

NO-SQL e introduzione a MongoDB

 

NO-SQL è un movimento che negli ultimi anni si è molto affermato, producendo dei risultati soddisfacenti con la creazione di progetti e iniziative utilizzate anche su larga scala. Tale movimento vuole “rompere” la storica linea dei database relazionali e definire delle nuove linee guida per l’implementazione di database che non utilizzano il linguaggio di interrogazione SQL e non siano strettamente legati ad una definizione “rigida” dello schema dati.

La filosofia del NO-SQL è descritta molto bene sul sito di Carlo Strozzi e si può riassumere nei seguenti punti, partendo dalla domanda “Perchè avere altri DBMS se esistono quelli relazionali?“:

  1. I database relazionali sono troppo costosi e spesso quelli che svolgono bene il loro lavoro sono commerciali. NO-SQL abbraccia totalmente la filosofia open-source;
  2. NO-SQL è semplice da usare e non occorre uno specialista di DBMS per poterlo utilizzare. Il paradigma di programmazione è, infatti, a oggetti
  3. I dati sono altamente portabili su sistemi differenti, da Macintosh a DOS;
  4. Non definisce uno schema “rigido” (schemaless) e non occorre tipare i campi, per cui non esistono limiti o restrizioni ai dati memorizzati nei database NO-SQL
  5. Velocità di esecuzione, di interrogazione di grosse quantità di dati e possibilità di distribuirli su più sistemi eterogenei (replicazione dei dati), con un meccanismo totalmente trasparente all’utilizzatore;
  6. I DBMS NO-SQL si focalizzano su una scalabilità orizzontale e non verticale come quelli relazionali.

Dall’altro lato, NO-SQL non garantisce i requisiti ACID su cui si basano i sistemi relazionali, per cui si è ancora particolarmente scettici sull’utilizzo di questi nuovi DBMS.

Scrivo qui una breve introduzione di un DBMS NO-SQL che sta avendo parecchio successo: MongoDB.

Concetti e definizioni

  • Collection (Tabella) – Document (Tupla o Oggetto) – Proprietà (attributo-colonna tabella)
  • Una relazione 1-to-Many si mappa inserendo un Document in un altro Document.
  • Una relazione Many-to-Many si mappa inserendo programmaticamente una join tra gli elementi di una collection.
from datetime import datetime

user_doc = {

        "username" : "janedoe",

        "firstname" : "Jane",

        "surname" : "Doe",

        "dateofbirth" : datetime(1974, 4, 12),

        "email" : "janedoe74@example.com",

        "score" : 0

}

MongoDB (il cui nome deriva da “humongous”) è un database NOSQL open-source,scalabile e altamente performante.

Ecco il link al codice sorgente del progetto: http://www.mongodb.org/display/DOCS/Source+Code

Scritto in C++, ecco le sua caratteristiche distintive:

  • Document-oriented storage: i dati vengono archiviati sotto forma di document in stile JSON con schema dinamici, secondo una struttura molto semplice e potente;
  • Full Index Support: indicizzazione di qualsiasi attributo
  • Replication & High Availability: facilità nella replicazione dei dati attraverso la rete e alta scalabilità;
  • Auto-Sharding: scalabilità orizzontale senza compromettere nessuna funzionalità;
  • Query document-based
  • Fast In-Place Updates: modifiche atomiche in-place con performance elevate
  • Map/Reduce: aggregazione flessibile e data processing
  • GridFS: memorizzazione di file di qualsiasi dimensione senza appesantimenti dello stack
  • Commercial Support: Enterprise support, corsi di apprendimento e consulenze online.

Continua la lettura

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2012/03/14/no-sql-e-introduzione-a-mongodb/.

[iOs] Introduzione a SQLite e integrazione in un XCode Project

SQLITE è un Relational DBMS embedded, ovvero è disponibile sotto forma di libreria che viene inclusa in una applicazione. Non vi è alcun database che gira in background e tutte le operazioni che devono essere effettuate su tale database vengono lanciate dall’applicazione sotto forma di chiamate a funzioni contenute nella libreria SQLite.
SQLite è scritto in linguaggio C e occorre utilizzare SQLite in un progetto XCode direttamente con chiamate a funzioni in C per accedere alle strutture dati.

C’è da dire che come DBMS non è eccezionalmente performante. Già il fatto che materializza le strutture dati su un singolo file memorizzato localmente all’applicazione, fa capire che può essere impiegato in contesti in cui non occorre avere il massimo delle performance (accessi in concorrenza, grosse quantità di dati, join tra più tabelle, …). Eppure nei contesti mobile, dove comunque le strutture dati non sono molto complesse, SQLite risulta una soluzione molto versatile e comoda.

Per informazioni dettagliate su SQLite riferirsi al sito ufficiale: www.sqlite.org. Di seguito, viene fatta una panoramica veloce sugli aspetti introduttivi e sull’integrazione di questo RDBMS in un progetto XCode.

Structured Query Language (SQL)
Si accede ai dati di un database in SQLite usando il linguaggio ad alto livello conosciuto come Structured Query Language (SQL), conforme allo standard SQL-92.

Se vi interessa creare un database SQLite potete consultare le due sezioni spiegate nel resto di questo wiki: Utilizzare SQLite su MacOS X (in cui si descrive la creazione di un database e la sua gestione da Terminale) oppure Creazione di un database SQLite con SQLite Manager (add-ons di Filefox)

Continua la lettura