Comparazione tra Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j

I database SQL sono strumenti infinitamente utili ma, dopo circa 15 anni, il loro monopolio è alla fine. Non riesco a pensare a quante cose sono state forzate dentro un database relazionale ma che non ci stavano proprio.
Le differenze tra database NoSQL sono molto più grandi di quanto non ci siano tra un database SQL e l’altro. Ciò significa che fin dall’inizio c’è una maggiore responsabilità  affidata ai progettisti software nello scegliere la tecnologia appropriata per un progetto.
Di seguito trovate una breve comparazione tra Cassandra, Mongodb, CouchDB, Redis, Riak, Membase, Neo4j e HBase.

CouchDB (V1.1.1)

• Scritto in: Erlang
• Punto principale: Consistenza DB consistency, facilità d’uso
• Licenza: Apache
• Protocolli: HTTP/REST
• Replicazione bidirezionale continua o ad-hoc con individuazione dei conflitti, replicazione master-master
• MVCC – le operazioni di scrittura non bloccano le letture
• Sono disponibili le versioni precedenti dei documenti
• Progettazione crash-only (reliable)
• Necessità di compattazioni nel tempo
• Viste: embedded map/reduce
• Viste formattate: lists & shows
• Possibilità di validazione server-side dei documenti
• Possibile autenticazione
• Aggiornamenti real-time attraverso _changes (!)
• Gestione degli allegati e, CouchApps (standalone js apps)
• libreria jQuery inclusa

Utilizzo ideale: Per accumulazione dei dati con cambi occasionali sui quali vengono eseguite query predefinite. Situazioni in cui la gestione delle versioni è importante.
Per esempio: CRM, sistemi CMS. Situazioni in cui la replicazione master-master è una caratteristica interessante (ad esempio multisito).

 

Redis (V2.4)

• Scritto in: C/C++
• Punto principale: Velocità
• Licenza: BSD
• Protocolli: Telnet-like
• Disk-backed in-memory database,
• In questo momento non include il disk-swap (VM e Diskstore sono stati abbandonati)
• Replicazione master-slave
• Recupero di valori semplici o intere tables a partire da una chiave
• suppporto ad operazioni complesse come ZREVRANGEBYSCORE.
• INCR (incremento) e  simili (molto utili per gestire limitazioni di valore e statistiche)
• permette l’uso di insiemi (sets) e operazioni su essi (unione/differenza/intersezione)
• permette l’uso di liste (lists) e  operazioni su esse (queue; blocking pop)
• permette l’uso di hashes (oggetti dotati di campi)
• permette l’uso di insiemi ordinati (utili per classifiche, e ricerche su range di valori)
• Redis implementa correttamente le transazioni (!)
• I valori memorizzati possono avere una scadenza temporale (sistemi di cache)
• Implementa facilmente il messaging Publisher/Subscriber (!)

Utilizzo ideale: Adatto a moli di dati (residenti in memoria) di dimensione nota che cambiano frequentemente .
Per esempio: Quotazioni azionistiche. Analisi. Gestione dati in Real-time. Comunicazioni in Real-time.

 

MongoDB

• Scritto in: C++
• Punto principale: Mantiene alcune proprietà utili del modello SQL (Query, index) molto facili da usare.
• Licenza: AGPL (Drivers: Apache)
• Protocollo: Specifico, binario (BSON)
• Replica Master/slave (munita di  failover quando si usano i  “replica sets”)
• Lo Sharding è parte integrante del sistema
• Le intterrogazioni a db (queries) sono espressioni javascript
• Permette l’uso di funzion i javascript lato server
• Update-in-place migliore rispetto a CouchDB
• Usa “memory mapped files” per la persistenza dei dati
• Favorisce la velocità rispetto alle funzionalità implementate
• Journaling (opzione –journal) fortemente consigliato
• Sui sistemi a 32bit risente di una  limitazione sulla quantità di dati a circa 2.5Gb
• Un database vuoto occupa comunque 192Mb
• GridFS per la memorizzazione di “big data + metadata” (effettivamente non è un  FS)
• Indicizzazione geospaziale Geospatial indexing

Utilizzo ideale: se si necessita di query dinamiche. Se si preferisce lavorare con gli indici rispetto ad usare algoritmi map/reduce. Buono se si ha bisogno di velocità quando si lavora con grandi moli di dati.  Adatto a tutti gli scenari in cui si usa CouchDB e non si può scegliere quest’ultimo perchè i dati cambiano troppo riempiendo la memoria fisica.
Per esempio: tutte le situazioni in cui si vorrebbe usare MySQL o PostgreSQL senza avere colonne definite a priori.

Riak (V1.0)

• Scritto in: Erlang & C, some Javascript
• Punto principale: Fault tolerance
• Licenza: Apache
• Protocollo: HTTP/REST o custom binary
• Trade-offs modulabili per replica e distribuzione (N, R, W)
• Hooks di pre- e post-commit in JavaScript o Erlang, per la validazione e la sicurezza.
• Map/reduce in JavaScript o Erlang
• Links & link walking per utilizzarlo come database a grafi
• Indici secondari: ricerca nei metadati
• Supporto per oggetti di grandi dimensioni (Luwak)
• Edizioni sia “open source” che “enterprise”
• Ricerca full-text, indexing e querying con il Riak Search server (beta)
• Sta migrando lo storing di backend da “Bitcask” al “LevelDB” di Google
• La multi-site replication replication senza alcun master e il monitoring SNMP necessitano di una licenza commerciale

Utilizzo ideale: se si vuole qualcosa di simile a Cassandra (Dynamo), ma non si ha nessuna intenzione di avere a che fare con la realtiva inerente complessità. Se si ha bisogno di un’ottima scalabilità, disponibilità e fault-tolerance per un solo sito ma si è disposti a pagare per la replica multi-sito.
Per esempio: Raccolta dei dati di point-of-sales. Sistemi di controllo aziendali. Situazioni in cui anche il downtime di alcuni secondi può essere rilevante. Potrebbe essere anche utilizzato come un web server estremamente aggiornabile.

 

Membase

• Scritto in: Erlang & C
• Punto principale: Compatibile con memcache ma con persistenza e clustering
• Licenza: Apache 2.0
• Protocollo: memcached con estensioni
• Accesso molto veloce ai dati mediante chiave (200k+/sec)
• Persistenza su disco
• Tutti i nodi sono identici (replicazione master-master)
• Fornisce un sistema a buckets simile a memcached
• De-duplicazione delle scritture per ridurre IO
• Interfaccia GUI per la gestione dei cluster molto interessante
• Aggiornamento software senza mettere offline il database
• Proxy di connessione per il pooling e il multiplexing (Moxi)

Utilizzo ideale: Qualsiasi applicazione dove un bassa latenza dell’accesso ai dati, un’alta concorrenzialità e un’alta disponibilità degli stessi sono requisiti chiave.
Per esempio: Casi in cui c’è necessità di bassa latenza come l’erogazione di servizi di pubblicità mirata (ad targeting)  o alta concorrenza come il giochi online (per esempio Zynga).

Neo4j (V1.5M02)

• Scritto in: Java
• Punto principale: Database a grafi o dati connessi
• Licenza: GPL, salcune caratterstiche con AGPL/commerciale
• Protocollo: HTTP/REST (o incluso in  Java)
• Standalone, o includibile nelle applicazioni Java
• Piena conformità ACID (incluso i dati durable)
• Sia i nodi che le releazioni possono avere dei metadati
• Linquaggio di query basato su pattern-matching (“Cypher”)
• Può anche essere usato il linguaggio di attraversamento dei gravi “Gremlin”
• Indicizzazione dei nodi, delle chiavi e delle relazioni
• Piacevole interfaccia di amministrazione web
• Sono disponibili diversi algoritmi di ricerca dei percorsi
• Ottimizzato per le letture
• Ha le transazioni (nelle API Java)
• Si può usare il linguaggio di scripting Groovy
• Backup online, monitoraggio avanzato e alta disponibilità con licenza AGPL/commerciale

Utilizzo ideale: Per dati interconnessi, semplici o complessi, con struttura a grafo. In questo senso Neo4j is è un po’ diverso dagli altri database noSQL.
Per esempio: Relazioni sociali, collegamenti nei trasposti pubblici, mappe di strade, topologie di rete.

Cassandra

• Scritto in: Java
• Punto principale: Migliore di BigTable e Dynamo
• Licenza: Apache
• Protocollo: Proprietario, binario (Thrift)
• Distribuzione e replicazione attivabile (N, R, W)
• Query possibili mediante colonne e insiemi di chiavi
• Carattersitiche simili a BigTable: colonne, famiglie di colonne
• Indici secondati
• La scrittura è molto più veloce della lettura(!)
• Mappatura e riduzione possibile mediante Apache Hadoop
• I admit being a bit biased against it, because of the bloat and complexity it has partly because of Java (configuration, seeing exceptions, etc)

Utilizzo ideale: Quando si scrive più che leggere (logging). Se ogni componente del sistema deve essere in Java.
Per esempio: Sistemi bancari e industria finanziaria.
Inoltre, siccome le scritture sono più veloci delle letture, una nicchia naturale è l’analisi dei dati in tempo reale.

HBase

• Scritto in: Java
• Punto principale: miliardi di righe con milioni di colonne
• Licenza: Apache
• Protocollo: HTTP/REST (anche Thrift)
• Modellato dopo BigTable
• Mappatura e riduzione con Hadoop
• Costrutti query push down attraverso scansione lato server e con filtri per il get
• ottimizzazione per le query in tempo reale
• E’ un gateway Thrift con alte performance
• HTTP supports XML, Protobuf, and binary
• Cascading, hive, and pig source and sink modules
• Shell basata su Jruby (JIRB)
• Punti di ripristino multipli
• Rolling restart for configuration changes and minor upgrades
• L’accesso random ai dati è paragonabile a quello di MySQL

Utilizzo ideale: Se siete innamorati di BigTable. 🙂 e quando c’è la necessità di un accesso in lettura e scrittura, random e in tempo reale alla grande quantità di dati.
Per esempio: il database dei messaggi in Facebook.

 

 

Tutti i sistemi menzionati hanno altre caratteristiche non discusse in questo articolo. Mi sono limitato ad elencare solo le funzioni più importanti sulle quali ho basato le mie decisioni. Va detto che tutti i progetti sono in una fase di sviluppo molto attiva e per questo quanto elencato è soggetto a cambiamento.

 

Testo tratto dall’articolo http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Si ringrazia per l’aiuto nella traduzione ragionata: Daniele e Tommaso.