Dieser Blogbeitrag wurde vor der Fusion mit Cloudera auf Hortonworks.com veröffentlicht. Einige Links, Ressourcen oder Referenzen sind möglicherweise nicht mehr korrekt.
Übersicht
Da immer mehr Workloads auf moderne Hardware in der Cloud gebracht werden, ist es für uns wichtig zu verstehen, wie man die besten Datenbanken auswählt, die die beste Hardware nutzen können. Amazon hat Instanzen mit direkt angeschlossener SSD (Solid State Drive) eingeführt. Sowohl Apache HBase als auch Apache Cassandra sind beliebte Schlüsselwertdatenbanken. In diesem Benchmark hoffen wir, mehr darüber zu erfahren, wie sie die direkt angeschlossene SSD in einer Cloud-Umgebung nutzen.
Aufbau des Benchmarks
Der Benchmark wurde für die Ausführung von Apache HBase und Apache Cassandra in einer optimalen Produktionsumgebung entwickelt. Dies bedeutet die Verwendung einer Maschine, die auf High-IO-Operationen mit direkt angeschlossener SSD zugeschnitten ist. Wir haben Write-Ahead-Logs/Commit-Log sowie die Datenspeicherung auf SSDs platziert. Zuvor haben zahlreiche Benchmarks bereits bestätigt, dass beide Lösungen linear skalieren können, daher ist der Skalierungstest nicht Gegenstand dieses Benchmarks.
Ergebnisse
Analyse
Während unseres gesamten Benchmarks haben wir gesehen, dass HBase Cassandra bei leselastigen Workloads durchweg übertrifft. Dies passt gut zu den wichtigsten Anwendungsfällen von HBase wie Suchmaschinen, Hochfrequenz-Transaktionsanwendungen, Protokolldatenanalyse und Messaging-Apps. HBase glänzt bei Workloads, bei denen das Scannen riesiger, zweidimensionaler Tabellen erforderlich ist. Auf der anderen Seite funktionierte Cassandra gut bei schreibintensiver Arbeitslast, die mit Konsistenz einherging. Daher ist es besser geeignet für die Sammlung von Analysedaten oder Sensordaten, wenn die Konsistenz im Laufe der Zeit akzeptabel ist.
Ein weiterer Faktor, der bei der Auswahl von Lösungen zu berücksichtigen ist, ist auch, ob entsprechende Toolsets zur Analyse der Daten vorhanden sind. Im Falle von HBase, das auf der Apache Hadoop-Plattform aufgebaut ist, unterstützt es Map Reduce und eine Vielzahl von Konnektoren zu anderen Lösungen wie Apache Hive und Apache Spark, um größere Aggregationsabfragen und komplexe Analysen zu ermöglichen.
Testaufbau
Maschine:
Der Testcluster besteht aus 5 Maschinen. Maschinendetails:
AWS I3.xlarge
60 GB GP2 zum Ausführen des Betriebssystems
Direkt angeschlossener NVMe-Speicher, 0,95 TB
4 vCPU, jede vCPU (virtuelle CPU) ist ein Hardware-Hyper-Thread auf einem Intel E5-2686 v4 (Broadwell)-Prozessor mit 2,3 GHz.
30,5 GB RAM
Um Noisy Neighbour-Probleme zu minimieren, haben wir die Tests auf AWS-dedizierten Instanzen durchgeführt.
Benchmark-Software:
Testdatensatz:1 TB generiert über YCSB
Testsuite:https://github.com/brianfrankcooper/YCSB
Testskript: https://github.com/2bethere/hbase-cassandra-bench
Software und Umgebung:
HDP 2.6.1
DSE 5.0.8
CentOS 7
Java 8
Um die Hardware voll auszunutzen, haben wir die Anzahl der Handler pro RegionServer in HBase auf 120 geändert. Alle anderen Einstellungen bleiben auf den Standardeinstellungen. Der vollständige Satz von Konfigurationslisten ist am Ende dieses Beitrags verfügbar.
Während der Bereitstellung haben wir uns auch an den hier veröffentlichten Cassandra-Optimierungsleitfaden gehalten:http://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/config/configRecommendedSettings.html
YCSB-Clients befinden sich auf jedem der 5 Knoten und wurden gleichzeitig ausgeführt, um die Last zu erzeugen. Während der Datensatzgenerierung haben wir die Anzahl der Threads auf 40 gesenkt.
Testmethodik
Wir laden den Datensatz mit 40 Threads für jede Arbeitslast, da die Datensatzverteilung für jeden Benchmark unterschiedlich ist. Nach dem Laden warten wir, bis alle Komprimierungsvorgänge abgeschlossen sind, bevor wir mit dem Workload-Test beginnen. Jede Workload wurde dreimal mit 5.000.000 Operationen ausgeführt. Die durchschnittliche Zahl wird aus 3 Tests genommen, um die endgültige Zahl zu erhalten.
Über YCSB
YCSB oder Yahoo! Cloud Serving Benchmark ist ein häufig verwendetes Benchmark-Tool. Es liefert Vergleichsergebnisse über verschiedene Lösungen hinweg. Wir haben die von YCSB bereitgestellte Standardarbeitslast ausgeführt.
Arbeitslast A:Schwere Aktualisierung
Anwendungsbeispiel:Sitzungsspeicher, Aufzeichnung der letzten Aktionen
Workload B:Meistens lesen
Anwendungsbeispiel:Foto-Tagging; Das Hinzufügen eines Tags ist eine Aktualisierung, aber die meisten Operationen dienen zum Lesen von Tags
Workload C:Nur lesen
Anwendungsbeispiel:Benutzerprofil-Cache, wo Profile an anderer Stelle erstellt werden (z. B. Hadoop)
Arbeitslast D:Letzte Arbeitslast lesen
Anwendungsbeispiel:Benutzerstatus-Updates; Menschen möchten die neuesten Informationen lesen
Workload E:Kurze Reichweiten
Anwendungsbeispiel:Thread-Konversationen, bei denen jeder Scan für die Beiträge in einem bestimmten Thread ist (angenommen, dass er nach Thread-ID gruppiert ist)
Arbeitslast F:Arbeitslast Lesen-Ändern-Schreiben
Anwendungsbeispiel:Benutzerdatenbank, in der Benutzerdatensätze vom Benutzer gelesen und geändert werden, oder um Benutzeraktivitäten aufzuzeichnen.
