Cet article de blog a été publié sur Hortonworks.com avant la fusion avec Cloudera. Certains liens, ressources ou références peuvent ne plus être exacts.
Aperçu
Alors que de plus en plus de charges de travail sont transférées sur du matériel moderne dans le cloud, il est important pour nous de comprendre comment sélectionner les meilleures bases de données capables de tirer parti du meilleur matériel. Amazon a introduit des instances avec SSD (Solid State Drive) directement attaché. Apache HBase et Apache Cassandra sont des bases de données clé-valeur populaires. Dans ce benchmark, nous espérons en savoir plus sur la manière dont ils exploitent le SSD directement connecté dans un environnement cloud.
Conception du benchmark
Le benchmark est conçu pour exécuter Apache HBase et Apache Cassandra dans un environnement de production optimal. Cela signifie utiliser une machine adaptée aux opérations à haut débit avec un SSD directement connecté. Nous avons placé des journaux d'écriture anticipée/journal de validation ainsi que le stockage de données sur des disques SSD. Auparavant, de nombreux benchmarks ont déjà confirmé que les deux solutions peuvent évoluer de manière linéaire, donc le test de mise à l'échelle n'entre pas dans le cadre de ce benchmark.
Résultats
Analyse
Tout au long de notre benchmark, nous avons constaté que HBase surpassait constamment Cassandra sur les charges de travail à lecture intensive. Cela correspond bien aux cas d'utilisation clés de HBase tels que les moteurs de recherche, les applications de transaction à haute fréquence, l'analyse des données de journal et les applications de messagerie. HBase brille pour les charges de travail où l'analyse d'énormes tables bidimensionnelles est une exigence. D'un autre côté, Cassandra a bien travaillé sur une charge de travail lourde en écriture en échangeant avec cohérence. Il est donc plus adapté à la collecte de données analytiques ou à la collecte de données de capteurs lorsque la cohérence dans le temps est acceptable.
Un autre facteur à prendre en compte lors du choix des solutions est également de savoir s'il existe des ensembles d'outils correspondants pour analyser les données. Dans le cas de HBase, construit sur la plate-forme Apache Hadoop, il prend en charge Map Reduce et une variété de connecteurs vers d'autres solutions telles qu'Apache Hive et Apache Spark pour permettre des requêtes d'agrégation plus importantes et des analyses complexes.
Configuration du test
Machine :
Le cluster de test est composé de 5 machines. Détails de l'appareil :
AWS I3.xlarge
60 Go GP2 pour exécuter le système d'exploitation
Stockage NVMe directement connecté, 0,95 To
4 vCPU, chaque vCPU (Virtual CPU) est un hyper-thread matériel sur un processeur Intel E5-2686 v4 (Broadwell) fonctionnant à 2,3 GHz.
30,5 Go de RAM
Pour minimiser les problèmes de voisinage bruyant, nous avons effectué les tests sur des instances AWS dédiées.
Logiciel de référence :
Ensemble de données de test :1 To généré via YCSB
Suite de tests :https://github.com/brianfrankcooper/YCSB
Script de test : https://github.com/2bethere/hbase-cassandra-bench
Logiciel et environnement :
HDP 2.6.1
DSE 5.0.8
CentOS 7
Java 8
Pour utiliser pleinement le matériel, nous avons changé le nombre de gestionnaires par serveur de région dans HBase à 120. Tous les autres paramètres sont laissés par défaut. Un ensemble complet de listes de configuration est disponible à la fin de cet article.
Lors du déploiement, nous avons également suivi le guide d'optimisation de Cassandra publié ici :http://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/config/configRecommendedSettings.html
Les clients YCSB sont situés sur chacun des 5 nœuds et s'exécutent simultanément pour générer la charge. Lors de la génération de l'ensemble de données, nous avons réduit le nombre de threads à 40.
Méthodologie des tests
Nous chargeons l'ensemble de données avec 40 threads pour chaque charge de travail étant donné que la distribution de l'ensemble de données est différente pour chaque référence. Après le chargement, nous attendons que toutes les opérations de compactage soient terminées avant de commencer le test de charge de travail. Chaque charge de travail a été exécutée 3 fois avec 5 000 000 d'opérations. Le nombre moyen est tiré de 3 tests pour produire le nombre final.
À propos du BSJC
YCSB, ou Yahoo! Cloud Serving Benchmark est un outil de référence couramment utilisé. Il fournit des résultats comparatifs entre différentes solutions. Nous avons exécuté la charge de travail par défaut fournie par YCSB.
Charge de travail A :mise à jour lourde
Exemple d'application :magasin de session, enregistrement des actions récentes
Charge de travail B :Lire principalement
Exemple d'application :étiquetage de photos ; ajouter une balise est une mise à jour, mais la plupart des opérations consistent à lire les balises
Charge de travail C :lecture seule
Exemple d'application :cache de profil utilisateur, où les profils sont créés ailleurs (par exemple, Hadoop)
Charge de travail D :Lire la dernière charge de travail
Exemple d'application :Mises à jour du statut de l'utilisateur; les gens veulent lire les dernières infos
Charge de travail E :plages courtes
Exemple d'application :conversations par fil de discussion, où chaque analyse concerne les messages d'un fil de discussion donné (supposés être regroupés par identifiant de fil de discussion)
Charge de travail F :charge de travail de lecture-modification-écriture
Exemple d'application :base de données d'utilisateurs, où les enregistrements d'utilisateurs sont lus et modifiés par l'utilisateur ou pour enregistrer l'activité de l'utilisateur.
