MongoDB, Cassandra e HBase: i tre database NoSQL da tenere d'occhio

Hadoop ottiene gran parte del credito dei big data, ma la realtà è che i database NoSQL sono distribuiti in modo molto più ampio e molto più ampiamente sviluppati. In effetti, mentre acquistare un fornitore Hadoop è relativamente semplice, scegliere un database NoSQL è tutt'altro. Dopotutto, ci sono più di 100 database NoSQL, come mostra la classifica della popolarità del database DB-Engines.

Quale scegliere?

L'imbarazzo della scelta

Perché scegliere devi. Per quanto bello possa essere vivere in una felice utopia della cosiddetta persistenza poliglotta, "dove qualsiasi impresa di dimensioni decenti avrà una varietà di diverse tecnologie di archiviazione dei dati per diversi tipi di dati", come sostiene Martin Fowler, la realtà è non puoi permetterti di investire nell'apprendimento più di pochi.

Fortunatamente, la scelta sta diventando più facile poiché il mercato si fonde attorno a tre database NoSQL dominanti: MongoDB (supportato dal mio ex datore di lavoro), Cassandra (sviluppato principalmente da DataStax, anche se nato da Facebook) e HBase (strettamente allineato con Hadoop e sviluppato dal stessa comunità).

Nota che escludo intenzionalmente Redis da questo elenco. Sebbene sia un ottimo archivio dati, viene utilizzato principalmente per la memorizzazione nella cache dei dati e non è adatto per un'ampia gamma di carichi di lavoro.

I dati di LinkedIn di 451 Research mostrano come il mercato graviti su MongoDB, Cassandra e HBase:

Questi sono i dati del profilo LinkedIn. Una vista più completa è DB-Engines, che aggrega lavori, ricerche e altri dati per comprendere la popolarità del database. Mentre Oracle, SQL Server e MySQL regnano sovrani, MongoDB (n. 5), Cassandra (n. 9) e HBase (n. 15) stanno dando loro una corsa per i loro soldi.

Sebbene sia troppo presto per chiamare ogni altro database NoSQL un errore di arrotondamento, stiamo raggiungendo rapidamente quel punto, esattamente come è successo nel mercato dei database relazionali.

Per capire meglio perché questi tre database brillano, ho chiesto ai rappresentanti di ciascuno di identificare gli attributi chiave per il loro successo: Kelly Stirman, direttore dei prodotti di MongoDB; Patrick McFadin, capo evangelista di Cassandra presso DataStax; e Justin Kestelyn, direttore senior delle relazioni con gli sviluppatori presso Cloudera.

Ma prima, dobbiamo capire perché NoSQL è importante.

Un mondo costruito con dati non strutturati

Viviamo sempre di più in un mondo in cui i dati non si adattano bene alle righe e alle colonne ordinate di un RDBMS. Mobile, social e cloud computing hanno generato un'enorme marea di dati. Secondo una serie di stime, il 90% dei dati mondiali è stato creato negli ultimi due anni, con Gartner che considera l'80% di tutti i dati aziendali come non strutturati. Inoltre, i dati non strutturati stanno crescendo a una velocità doppia rispetto ai dati strutturati.

Con il cambiamento del mondo, i requisiti di gestione dei dati vanno oltre l'ambito effettivo dei database relazionali tradizionali. Le prime organizzazioni a rilevare la necessità di soluzioni alternative sono state pionieri del Web, agenzie governative e aziende specializzate in servizi di informazione.

Sempre più spesso, le aziende di tutti i tipi stanno cercando di capitalizzare il vantaggio di alternative come NoSQL e Hadoop: NoSQL per creare applicazioni operative che guidano il loro business attraverso sistemi di coinvolgimento e Hadoop per creare applicazioni che analizzano i loro dati in modo retrospettivo e aiutano a fornire informazioni approfondite .

MongoDB: Degli sviluppatori, per gli sviluppatori

Tra le opzioni NoSQL, sottolinea Stirman di MongoDB, MongoDB ha mirato a un approccio bilanciato adatto a un'ampia varietà di applicazioni. Sebbene la funzionalità sia vicina a quella di un database relazionale tradizionale, MongoDB consente agli utenti di capitalizzare i vantaggi dell'infrastruttura cloud con la sua scalabilità orizzontale e di lavorare facilmente con i diversi set di dati in uso oggi grazie al suo modello di dati flessibile.

MongoDB è spesso il primo che gli sviluppatori di database NoSQL proveranno perché è così facile da imparare. Will Shulman, CEO di MongoLab (un fornitore di MongoDB-as-a-service), lo dice in questo modo:

Il successo sproporzionato di MongoDB è in gran parte basato sulla sua innovazione come archivio di strutture dati che ci consente di modellare in modo più semplice ed espressivo le "cose" al centro delle nostre applicazioni….

Avere lo stesso modello di dati di base nel nostro codice e nel database è il metodo migliore per la maggior parte dei casi d'uso, poiché semplifica notevolmente l'attività di sviluppo dell'applicazione ed elimina gli strati di codice di mappatura complesso che sarebbero altrimenti richiesti.

In particolare, MongoDB, come gli altri database in questo elenco, non è un pony con un solo trucco. Le aziende che apprendono MongoDB "possono ammortizzare i loro investimenti in MongoDB in molti, molti progetti, rendendolo uno dei brevi elenchi di standard su cui fanno affidamento per tutta la gestione dei dati", come mi ha detto Stirman.

Ovviamente, come ogni tecnologia, MongoDB ha i suoi punti di forza e di debolezza. MongoDB è progettato per carichi di lavoro OLTP. Può eseguire query complesse, ma non è necessariamente la soluzione migliore per i carichi di lavoro in stile reportistica. O se hai bisogno di transazioni complesse, non sarà una buona scelta. Tuttavia, la semplicità di MongoDB lo rende un ottimo punto di partenza.

Cassandra: Esegui in modo sicuro su larga scala

Esistono almeno due tipi di semplicità del database: semplicità di sviluppo e semplicità operativa. Mentre MongoDB ottiene giustamente il merito di un'esperienza facile e pronta all'uso, Cassandra guadagna il massimo dei voti per essere facile da gestire su larga scala.

Come mi ha detto McFadin di DataStax, gli utenti tendono a gravitare su Cassandra più si scontrano con la difficoltà di rendere i database relazionali più veloci e affidabili, in particolare su larga scala. Un ex DBA di Oracle, McFadin è stato entusiasta di scoprire che "la replica e il ridimensionamento lineare sono primitivi" con Cassandra e le funzionalità erano "l'obiettivo principale del progetto sin dall'inizio".

Nel mondo RDBMS, le funzionalità del database come il ridimensionamento e la replica sono le parti difficili lasciate all'utente. Questo ha funzionato bene nell'impresa di ieri, quando la scala non era un grosso problema. Oggi sta rapidamente diventando il problema.

Come ho sentito da McFadin e altri, Cassandra brilla particolarmente nelle distribuzioni scale-out. Cassandra è dotata di supporto integrato per più data center. Per quanto riguarda l'aggiunta di capacità a un cluster, "Devi semplicemente avviare una nuova macchina e dire a Cassandra dove sono gli altri nodi", ha detto McFadin, "e lui si prende cura del resto".

Questa facilità di scalabilità, unita a prestazioni di scrittura eccezionali ("Tutto quello che stai facendo è aggiungere alla fine di un file di registro") e prestazioni di query prevedibili, si sommano a un cavallo di battaglia ad alte prestazioni in Cassandra.

Un articolo di fede NoSQL che ho a lungo sostenuto è che Cassandra può essere potente su larga scala, ma richiede un dottorato per iniziare. Non è così, ha insistito McFadin:

I percorsi di replica e di lettura e scrittura sono volutamente semplici. Puoi imparare le parti interne fondamentali di Cassandra in poche ore. Ciò può portare molta fiducia quando si distribuisce una nuova tecnologia perché ci sono meno dettagli "scatola nera" che introducono modalità di errore complesse.

Ciò significa che il prezzo per l'ammissione allo sviluppo efficace di Cassandra sta nella comprensione del modello di dati e di come funzionerà con la tua applicazione. Data la familiarità del linguaggio di query CQL di Cassandra (inteso per essere "esattamente come SQL tranne quando non lo è"), ha detto McFadin, non è una curva di apprendimento ripida.

Ancora più importante, mi ha detto, "Cassandra ti premia con l'unica cosa che vuoi da un database: nessun dramma. Questo è il motivo per cui gli utenti adorano usare Cassandra ".

HBase: Seno amico di Hadoop

HBase, come Cassandra, un archivio chiave-valore orientato alle colonne, ottiene molto utilizzo in gran parte a causa del suo pedigree comune con Hadoop. Infatti, come ha affermato Kestelyn di Cloudera, "HBase fornisce un livello di archiviazione basato sui record che consente letture e scritture casuali e veloci sui dati, integrando Hadoop enfatizzando un throughput elevato a scapito dell'I / O a bassa latenza".

Kestelyn continua:

Le modifiche vengono catalogate in modo efficiente in memoria per ottenere il massimo accesso mentre i dati vengono conservati in HDFS. Questo design consente a un EDH [data hub aziendale] basato su Hadoop di fornire letture e scritture casuali per utenti e applicazioni in tempo reale, pur continuando a godere della tolleranza agli errori e della durata di HDFS.

L'affinità con Hadoop non è l'unica ragione per cui HBase continua a crescere nei ranghi di popolarità del database, anche se potrebbe essere sufficiente. Simile a Cassandra, le radici di HBase come implementazione open source di Bigtable di Google si traducono nel database altamente scalabile per progettazione.

Poiché può utilizzare l'archiviazione, la memoria e le risorse della CPU di qualsiasi numero di server, oltre a disporre di funzionalità di scalabilità orizzontale come lo sharding automatico, HBase può scalare senza limiti man mano che aumentano le richieste di carico e prestazioni semplicemente aggiungendo nodi del server. HBase è stato progettato da zero per fornire prestazioni ottimali quando la coerenza è fondamentale.

Ma la scala non è solo utilità. Come ha osservato Kestelyn, "Grazie alla sua stretta integrazione con il resto dell'ecosistema Hadoop, i dati sono prontamente disponibili per utenti e applicazioni tramite query SQL (utilizzando Cloudera Impala, Apache Phoenix o Apache Hive) o persino ricerca di testo libero sfaccettato (utilizzando Cloudera Search). " Pertanto, HBase offre agli sviluppatori un modo per sfruttare l'esperienza esistente con SQL mentre si costruisce su un database più moderno e distribuito.

Ogni database presenta i propri punti di forza e le proprie carenze, ma ciascuno dei tre profili qui descritti ha colmato un grave buco nel panorama dei big data. Sebbene sia possibile che un nuovo database arriverà a rivendicare un posto tra i primi tre NoSQL (DynamoDB?), La realtà è che gli sviluppatori e le aziende che servono stanno già standardizzando alcune forti opzioni: MongoDB, Cassandra e HBase.

Ora VP of Mobile presso Adobe, Matt Asay è stato in precedenza Vice President of Community presso MongoDB, Inc. È un membro emerito del consiglio di Open Source Initiative (OSI) e ha conseguito il dottorato in giurisprudenza a Stanford, dove si è concentrato sull'open source e altro problemi di licenza di proprietà intellettuale e il suo master presso l'Università del Kent a Canterbury e la sua laurea presso la Brigham Young University. Asay è stato uno dei primi blogger.

Il New Tech Forum offre un luogo per esplorare e discutere la tecnologia aziendale emergente in profondità e ampiezza senza precedenti. La selezione è soggettiva, in base alla nostra scelta delle tecnologie che riteniamo importanti e di maggiore interesse per i lettori. non accetta materiale di marketing per la pubblicazione e si riserva il diritto di modificare tutti i contenuti forniti. Invia tutte le richieste a [email protected]