[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/.

[BigData] Il Big Data Forum 2012 a Roma: le soluzioni ICT per un vantaggio competitivo

Il 21 Novembre scorso si è tenuta a Roma la 2° edizione del Big Data Forum, dallo slogan “Big Data Forum 2012: per fare chiarezza sul fenomeno dell’esplosione dei dati e scoprire le soluzioni ICT che consentono di trasformarlo in vantaggio competitivo“.

L’evento, pubblicizzato da ICT4Executive, con partner di eccezione come Microsoft, Oracle e Informatica Software, è stato condotto da relatori di riguardo, particolarmente distinti sia nel campo della ricerca ICT (in particolare, nella Business Intelligence), che in quello strategico aziendale.

Ho partecipato all’evento e vi riporto un resoconto dettagliato delle tematiche affrontate ed estrapolate dagli interventi dei relatori presenti.

 

La Big Data Analysis

Il moderatore Carlo Vercellis, responsabile dell’Osservatorio di Business Intelligence & Big Data Analytics e professore alla School Management del Politecnico di Milano, ha sottolineato che il BigData è un tema di attualità molto in voga nell’ultimo periodo, come il cloud computing del resto, ma che da fenomeno del momento deve trasformarsi in innovazione tecnologica, in grado di cambiare gli attuali schemi e paradigmi del modo di trattare le informazioni su Internet.
Come non citare lo slogan di Tim Berners-LeeROW DATA, NOW!“. Dati grezzi da trattare, che sono diventati (e diventeranno ancora) troppi e dai cui è difficile poter estrarre informazione. Un fenomeno di cui si vocifera particolarmente nell’ultimo periodo, visti gli impegni delle varie iniziative di Open Data e eGov, che “impongono” ai detentori illegittimi di dati (ndr. come pubbliche amministrazioni) di distribuire informazioni di proprietà dei cittadini.

 

I dati diventano “interessanti” solo se siamo capaci di estrarre da essi un contenuto utile, da trasformare in servizio per gli utenti finali.

 

Continua la lettura