Deze blogpost is gepubliceerd op Hortonworks.com vóór de fusie met Cloudera. Sommige links, bronnen of verwijzingen zijn mogelijk niet langer nauwkeurig.
Overzicht
Aangezien steeds meer workloads naar moderne hardware in de cloud worden gebracht, is het belangrijk voor ons om te begrijpen hoe we de beste databases kunnen kiezen die de beste hardware kunnen gebruiken. Amazon heeft instances geïntroduceerd met direct aangesloten SSD (Solid state drive). Zowel Apache HBase als Apache Cassandra zijn populaire sleutelwaardedatabases. In deze benchmark hopen we meer te leren over hoe ze gebruik maken van de direct aangesloten SSD in een cloudomgeving.
Ontwerp van de benchmark
De benchmark is ontworpen om Apache HBase en Apache Cassandra in een optimale productieomgeving te laten draaien. Dit betekent het gebruik van een machine die is afgestemd op high-io-bewerkingen met direct aangesloten SSD. We hebben write-ahead-logs/commit log en gegevensopslag op SSD's geplaatst. Eerder hebben talrijke benchmarks al bevestigd dat beide oplossingen lineair kunnen schalen, dus schaaltest valt buiten het bestek van deze benchmark.
Resultaten
Analyse
Tijdens onze benchmark hebben we gezien dat HBase consequent beter presteerde dan Cassandra bij leesintensieve workloads. Dit sluit goed aan bij de belangrijkste gebruiksscenario's van HBase, zoals zoekmachines, hoogfrequente transactietoepassingen, loggegevensanalyse en berichten-apps. HBase blinkt uit bij workloads waar het scannen van enorme, tweedimensionale tabellen een vereiste is. Aan de andere kant werkte Cassandra goed aan de schrijfzware werklast die consistent werd afgewisseld. Het is dus meer geschikt voor het verzamelen van analytische gegevens of het verzamelen van sensorgegevens wanneer consistentie in de tijd acceptabel is.
Een andere factor waarmee rekening moet worden gehouden bij het kiezen van oplossingen, is of er overeenkomstige toolsets zijn voor het analyseren van de gegevens. In het geval van HBase, dat bovenop het Apache Hadoop-platform is gebouwd, ondersteunt het Map Reduce en een verscheidenheid aan connectoren voor andere oplossingen zoals Apache Hive en Apache Spark om grotere aggregatiequery's en complexe analyses mogelijk te maken.
Testopstelling
Machine:
Het testcluster bestaat uit 5 machines. Machinedetails:
AWS I3.xlarge
60 GB GP2 om besturingssysteem uit te voeren
Direct aangesloten NVMe-opslag, 0,95 TB
4 vCPU, elke vCPU (virtuele CPU) is een hardware hyper-thread op een Intel E5-2686 v4 (Broadwell) processor die draait op 2,3 GHz.
30,5 GB RAM
Om problemen met luidruchtige buren tot een minimum te beperken, hebben we de tests uitgevoerd op speciale AWS-instanties.
Benchmarksoftware:
Testdataset:1TB gegenereerd via YCSB
Testsuite:https://github.com/brianfrankcooper/YCSB
Testscript: https://github.com/2bethere/hbase-cassandra-bench
Software en omgeving:
HDP 2.6.1
DSE 5.0.8
CentOS 7
Java 8
Om de hardware volledig te benutten, hebben we het aantal handlers per regioserver in HBase gewijzigd in 120. Alle andere instellingen blijven standaard. De volledige set configuratielijsten is beschikbaar aan het einde van dit bericht.
Tijdens de implementatie hebben we ook de Cassandra-optimalisatiegids gevolgd die hier is gepost:http://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/config/configRecommendedSettings.html
YCSB-clients bevinden zich op elk van de 5 knooppunten en werden gelijktijdig uitgevoerd om de belasting te genereren. Tijdens het genereren van datasets hebben we het aantal threads verlaagd tot 40.
Testmethodologie
We laden de dataset met 40 threads voor elke workload, aangezien de distributie van de dataset voor elke benchmark anders is. Na het laden wachten we tot alle verdichtingsbewerkingen zijn voltooid voordat we de werkbelastingstest starten. Elke workload werd 3 keer uitgevoerd met 5.000.000 bewerkingen. Het gemiddelde aantal wordt genomen uit 3 tests om het uiteindelijke aantal te produceren.
Over YCSB
YCSB, of Yahoo! Cloud Serving Benchmark is een veelgebruikte benchmarktool. Het biedt vergelijkende resultaten voor verschillende oplossingen. We hebben de standaard werklast van YCSB uitgevoerd.
Werklast A:update zwaar
Toepassingsvoorbeeld:Sessieopslag, recente acties opnemen
Werklast B:Lees vooral
Toepassingsvoorbeeld:Foto tagging; een tag toevoegen is een update, maar de meeste bewerkingen zijn om tags te lezen
Werklast C:alleen-lezen
Toepassingsvoorbeeld:gebruikersprofielcache, waar profielen elders worden gemaakt (bijv. Hadoop)
Werklast D:Lees de laatste werklast
Toepassingsvoorbeeld:updates van gebruikersstatus; mensen willen de laatste informatie lezen
Werklast E:korte afstanden
Toepassingsvoorbeeld:conversaties met threads, waarbij elke scan is voor de berichten in een bepaalde thread (aangenomen te worden geclusterd op thread-ID)
Werkbelasting F:werkbelasting lezen-wijzigen-schrijven
Toepassingsvoorbeeld:gebruikersdatabase, waar gebruikersrecords worden gelezen en gewijzigd door de gebruiker of om gebruikersactiviteit vast te leggen.