Questo post sul blog è stato pubblicato su Hortonworks.com prima della fusione con Cloudera. Alcuni collegamenti, risorse o riferimenti potrebbero non essere più accurati.

Panoramica

Poiché sempre più carichi di lavoro vengono trasferiti su hardware moderno nel cloud, è importante per noi capire come scegliere i migliori database in grado di sfruttare l'hardware migliore. Amazon ha introdotto istanze con SSD (Solid State Drive) direttamente collegato. Sia Apache HBase che Apache Cassandra sono database chiave-valore popolari. In questo benchmark, speriamo di saperne di più su come sfruttano l'SSD collegato direttamente in un ambiente cloud.

Progettazione del benchmark

Il benchmark è progettato per eseguire Apache HBase e Apache Cassandra in un ambiente di produzione ottimale. Ciò significa utilizzare una macchina su misura per operazioni high-io con SSD direttamente collegato. Abbiamo inserito registri write-ahead/commit log e archiviazione dati su SSD. In precedenza, numerosi benchmark hanno già confermato che entrambe le soluzioni possono scalare linearmente, quindi il test di ridimensionamento non rientra nell'ambito di questo benchmark.

Risultati

Analisi

Durante il nostro benchmark, abbiamo visto HBase superare costantemente Cassandra con carichi di lavoro di lettura pesante. Ciò si allinea bene con i casi d'uso chiave di HBase come motori di ricerca, applicazioni di transazione ad alta frequenza, analisi dei dati di registro e app di messaggistica. HBase eccelle nei carichi di lavoro in cui è richiesta la scansione di enormi tabelle bidimensionali. D'altra parte, Cassandra ha funzionato bene su carichi di lavoro pesanti in scrittura, scambiando con coerenza. Pertanto è più adatto per la raccolta di dati di analisi o di sensori quando la coerenza nel tempo è accettabile.

Un altro fattore da considerare quando si selezionano le soluzioni è anche se esistono set di strumenti corrispondenti per l'analisi dei dati. Nel caso di HBase, essendo costruito sulla piattaforma Apache Hadoop, supporta Map Reduce e una varietà di connettori ad altre soluzioni come Apache Hive e Apache Spark per abilitare query di aggregazione più ampie e analisi complesse.

Impostazione di prova

Macchina:

Il cluster di test è composto da 5 macchine. Dettagli macchina:

AWS I3.xlarge

60 GB GP2 per eseguire il sistema operativo

Storage NVMe collegato direttamente, 0,95 TB

4 vCPU, ogni vCPU (CPU virtuale) è un hyper-thread hardware su un processore Intel E5-2686 v4 (Broadwell) in esecuzione a 2,3 GHz.

30,5 GB di RAM

Per ridurre al minimo i problemi dei vicini rumorosi, abbiamo eseguito i test su istanze dedicate di AWS.

Software di riferimento:

Set di dati di test:1 TB generato tramite YCSB

Suite di test:https://github.com/brianfrankcooper/YCSB

Script di prova: https://github.com/2bethere/hbase-cassandra-bench

Software e ambiente:

HDP 2.6.1
DSE 5.0.8
CentOS 7
Java 8

Per utilizzare appieno l'hardware, abbiamo modificato il numero di gestori per RegionServer in HBase a 120. Tutte le altre impostazioni vengono lasciate come predefinite. Il set completo di elenchi di configurazione è disponibile alla fine di questo post.

Durante l'implementazione, abbiamo anche seguito la guida all'ottimizzazione di Cassandra pubblicata qui:http://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/config/configRecommendedSettings.html

I client YCSB si trovano su ciascuno dei 5 nodi e vengono eseguiti contemporaneamente per generare il carico. Durante la generazione del set di dati, abbiamo ridotto il numero di thread a 40.

Metodologia di prova

Stiamo caricando il set di dati con 40 thread per ogni carico di lavoro, dato che la distribuzione del set di dati è diversa per ogni benchmark. Dopo il caricamento, attendiamo il termine di tutte le operazioni di compattazione prima di iniziare il test del carico di lavoro. Ogni carico di lavoro è stato eseguito 3 volte con 5.000.000 di operazioni. Il numero medio è preso da 3 test per produrre il numero finale.

Informazioni su YCSB

YCSB, o Yahoo! Cloud Serving Benchmark è uno strumento di benchmark comunemente usato. Fornisce risultati comparativi tra diverse soluzioni. Abbiamo eseguito il carico di lavoro predefinito fornito da YCSB.

Carico di lavoro A:aggiornamento pesante
Esempio di applicazione:archivio sessioni, registrazione delle azioni recenti

Carico di lavoro B:leggi principalmente
Esempio di applicazione:tagging di foto; l'aggiunta di un tag è un aggiornamento, ma la maggior parte delle operazioni consiste nella lettura dei tag

Carico di lavoro C:sola lettura
Esempio di applicazione:cache del profilo utente, in cui i profili sono costruiti altrove (ad es. Hadoop)

Carico di lavoro D:leggi il carico di lavoro più recente
Esempio di applicazione:aggiornamenti dello stato dell'utente; le persone vogliono leggere le ultime informazioni

Carico di lavoro E:brevi distanze
Esempio di applicazione:conversazioni in thread, in cui ogni scansione riguarda i post in un determinato thread (che si presume siano raggruppati in base all'ID thread)

Carico di lavoro F:carico di lavoro di lettura-modifica-scrittura
Esempio di applicazione:database utenti, in cui i record utente vengono letti e modificati dall'utente o per registrare l'attività dell'utente.