Dette blogindlæg blev offentliggjort på Hortonworks.com før fusionen med Cloudera. Nogle links, ressourcer eller referencer er muligvis ikke længere nøjagtige.
Oversigt
Efterhånden som flere og flere arbejdsbelastninger bringes til moderne hardware i skyen, er det vigtigt for os at forstå, hvordan man vælger de bedste databaser, der kan udnytte den bedste hardware. Amazon har introduceret instanser med direkte tilsluttet SSD (Solid state drive). Både Apache HBase og Apache Cassandra er populære nøgleværdidatabaser. I dette benchmark håber vi at lære mere om, hvordan de udnytter den direkte tilsluttede SSD i et cloudmiljø.
Design af benchmark
Benchmark er designet til at køre Apache HBase og Apache Cassandra i et optimalt produktionsmiljø. Det betyder at bruge maskine, der er skræddersyet til high-io-operationer med direkte tilsluttet SSD. Vi har placeret skrive-ahead-logs/commit-log samt datalagring på SSD'er. Tidligere har adskillige benchmarks allerede bekræftet, at begge løsninger kan skaleres lineært, så skaleringstest er uden for dette benchmarks anvendelsesområde.
Resultater
Analyse
Gennem hele vores benchmark har vi set HBase konsekvent klare sig bedre end Cassandra på læsetunge arbejdsbelastninger. Dette stemmer godt overens med de vigtigste anvendelsesmuligheder for HBase, såsom søgemaskiner, højfrekvente transaktionsapplikationer, logdataanalyse og beskedapps. HBase brillerer ved arbejdsbelastninger, hvor scanning af store, todimensionelle tabeller er et krav. På den anden side arbejdede Cassandra godt på skrivetung arbejdsbyrde, der afviklede med konsistens. Det er således mere velegnet til analysedataindsamling eller sensordataindsamling, når konsistens over tid er acceptabel.
En anden faktor, man skal overveje, når man vælger løsninger, er også, om der er tilsvarende værktøjssæt til at analysere dataene. I tilfælde af HBase, der er bygget oven på Apache Hadoop-platformen, understøtter den Map Reduce og en række forbindelser til andre løsninger såsom Apache Hive og Apache Spark for at muliggøre større aggregeringsforespørgsler og komplekse analyser.
Test opsætning
Maskin:
Testklyngen består af 5 maskiner. Maskindetaljer:
AWS I3.xlarge
60 GB GP2 for at køre OS
Direkte tilsluttet NVMe-lager, 0,95 TB
4 vCPU, hver vCPU (Virtuel CPU) er en hardware-hyper-tråd på en Intel E5-2686 v4 (Broadwell)-processor, der kører ved 2,3 GHz.
30,5 GB RAM
For at minimere støjende naboproblemer kørte vi testene på AWS-dedikerede forekomster.
Benchmark-software:
Testdatasæt:1TB genereret via YCSB
Testpakke:https://github.com/brianfrankcooper/YCSB
Testscript: https://github.com/2bethere/hbase-cassandra-bench
Software og miljø:
HDP 2.6.1
DSE 5.0.8
CentOS 7
Java 8
For at udnytte hardwaren fuldt ud, har vi ændret Antal handlere pr. RegionServer i HBase til 120. Alle andre indstillinger er tilbage som standard. Komplet sæt konfigurationslister er tilgængelige i slutningen af dette indlæg.
Under implementeringen fulgte vi også Cassandra-optimeringsvejledningen, der blev offentliggjort her:http://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/config/configRecommendedSettings.html
YCSB-klienter er placeret på hver af de 5 noder og kørte samtidigt for at generere belastningen. Under datasætgenerering har vi sænket trådantallet til 40.
Testmetode
Vi indlæser datasættet med 40 tråde for hver arbejdsbelastning, da datasætfordelingen er forskellig for hvert benchmark. Efter indlæsning venter vi på, at alle komprimeringsoperationer er færdige, før vi starter arbejdsbelastningstesten. Hver arbejdsbelastning blev kørt 3 gange med 5.000.000 operationer. Det gennemsnitlige antal er taget fra 3 test for at producere det endelige antal.
Om YCSB
YCSB eller Yahoo! Cloud Serving Benchmark er et almindeligt brugt benchmarkværktøj. Det giver sammenlignelige resultater på tværs af forskellige løsninger. Vi har kørt standardarbejdsbyrden leveret af YCSB.
Workload A:Opdatering tung
Applikationseksempel:Sessionsbutik, optagelse af seneste handlinger
Arbejdsbelastning B:Læs mest
Anvendelseseksempel:Fotomærkning; tilføje et tag er en opdatering, men de fleste handlinger er at læse tags
Workload C:Skrivebeskyttet
Applikationseksempel:brugerprofilcache, hvor profiler er konstrueret andre steder (f.eks. Hadoop)
Workload D:Læs den seneste workload
Applikationseksempel:Brugerstatusopdateringer; folk ønsker at læse den seneste information
Arbejdsbelastning E:Korte intervaller
Applikationseksempel:trådede samtaler, hvor hver scanning er for indlæg i en given tråd (antages at være grupperet efter tråd-id)
Workload F:Læs-modificere-skriv-arbejdsbelastning
Applikationseksempel:brugerdatabase, hvor brugerregistreringer læses og ændres af brugeren eller for at registrere brugeraktivitet.