Det här blogginlägget publicerades på Hortonworks.com före sammanslagningen med Cloudera. Vissa länkar, resurser eller referenser kanske inte längre är korrekta.
Översikt
Eftersom fler och fler arbetsbelastningar överförs till modern hårdvara i molnet, är det viktigt för oss att förstå hur man väljer de bästa databaserna som kan utnyttja den bästa hårdvaran. Amazon har introducerat instanser med direktansluten SSD (Solid State Drive). Både Apache HBase och Apache Cassandra är populära nyckel-värde-databaser. I det här riktmärket hoppas vi lära oss mer om hur de utnyttjar den direktanslutna SSD:n i en molnmiljö.
Utformning av riktmärket
Riktmärket är designat för att köra Apache HBase och Apache Cassandra i en optimal produktionsmiljö. Detta innebär att man använder en maskin som är skräddarsydd för high-io-operationer med direktansluten SSD. Vi har placerat skriv-ahead-logs/commit-loggar samt datalagring på SSD:er. Tidigare har många riktmärken redan bekräftat att båda lösningarna kan skalas linjärt, så skalningstest faller utanför omfattningen av detta riktmärke.
Resultat
Analys
Under hela vårt benchmark har vi sett HBase konsekvent prestera bättre än Cassandra på lästunga arbetsbelastningar. Detta stämmer väl överens med de viktigaste användningsfallen för HBase som sökmotorer, högfrekventa transaktionsapplikationer, loggdataanalys och meddelandeappar. HBase lyser vid arbetsbelastningar där scanning av stora, tvådimensionella tabeller är ett krav. Å andra sidan fungerade Cassandra bra med att lösa skrivtung arbetsbelastning med konsistens. Därför är den mer lämplig för insamling av analysdata eller sensordatainsamling när konsekvens över tid är acceptabel.
En annan faktor att tänka på när man väljer lösningar är också om det finns motsvarande verktygsuppsättningar för att analysera data. När det gäller HBase, som byggs ovanpå Apache Hadoop-plattformen, stöder den Map Reduce och en mängd olika kopplingar till andra lösningar som Apache Hive och Apache Spark för att möjliggöra större aggregeringsfrågor och komplexa analyser.
Testa installationen
Maskin:
Testklustret består av 5 maskiner. Maskindetaljer:
AWS I3.xlarge
60 GB GP2 för att köra OS
Direktansluten NVMe-lagring, 0,95 TB
4 vCPU, varje vCPU (Virtual CPU) är en hårdvaruhypertråd på en Intel E5-2686 v4 (Broadwell)-processor som körs på 2,3 GHz.
30,5 GB RAM
För att minimera störande grannproblem körde vi testerna på AWS-dedikerade instanser.
Benchmark-programvara:
Testdatauppsättning:1TB genererad via YCSB
Testsvit:https://github.com/brianfrankcooper/YCSB
Testskript: https://github.com/2bethere/hbase-cassandra-bench
Programvara och miljö:
HDP 2.6.1
DSE 5.0.8
CentOS 7
Java 8
För att utnyttja hårdvaran fullt ut har vi ändrat Antal hanterare per RegionServer i HBase till 120. Alla andra inställningar är kvar som standard. Fullständig uppsättning konfigurationslistor finns tillgängliga i slutet av detta inlägg.
Under distributionen följde vi även Cassandra-optimeringsguiden som publicerades här:http://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/config/configRecommendedSettings.html
YCSB-klienter finns på var och en av de 5 noderna och kördes samtidigt för att generera belastningen. Under datauppsättningsgenereringen har vi sänkt antalet trådar till 40.
Testmetodik
Vi laddar datauppsättningen med 40 trådar för varje arbetsbelastning eftersom datauppsättningsfördelningen är olika för varje benchmark. Efter lastning väntar vi på att alla packningsoperationer är klara innan vi påbörjar arbetsbelastningstestet. Varje arbetsbelastning kördes 3 gånger med 5 000 000 operationer. Det genomsnittliga antalet tas från 3 tester för att ta fram det slutliga antalet.
Om YCSB
YCSB eller Yahoo! Cloud Serving Benchmark är ett vanligt använt benchmarkverktyg. Det ger jämförande resultat över olika lösningar. Vi har kört standardarbetsbelastningen från YCSB.
Arbetsbelastning A:Uppdatering tung
Applikationsexempel:Sessionsbutik, registrerar senaste åtgärder
Arbetsbelastning B:Läs mest
Applikationsexempel:Fototaggning; Lägg till en tagg är en uppdatering, men de flesta operationer är att läsa taggar
Arbetsbelastning C:Endast läs
Applikationsexempel:användarprofilcache, där profiler konstrueras någon annanstans (t.ex. Hadoop)
Arbetsbelastning D:Läs senaste arbetsbelastningen
Applikationsexempel:Användarstatusuppdateringar; folk vill läsa den senaste informationen
Arbetsbelastning E:Korta avstånd
Applikationsexempel:trådade konversationer, där varje skanning är för inläggen i en given tråd (antas vara klustrade efter tråd-id)
Arbetsbelastning F:Läs-modifiera-skriv arbetsbelastning
Applikationsexempel:användardatabas, där användarposter läses och ändras av användaren eller för att registrera användaraktivitet.