Tento blogový příspěvek byl publikován na Hortonworks.com před sloučením s Cloudera. Některé odkazy, zdroje nebo reference již nemusí být přesné.
Přehled
Vzhledem k tomu, že na moderní hardware v cloudu se přenáší stále více pracovních zátěží, je důležité, abychom pochopili, jak vybrat ty nejlepší databáze, které dokážou využít ten nejlepší hardware. Amazon představil instance s přímo připojeným SSD (Solid State Drive). Apache HBase i Apache Cassandra jsou oblíbené databáze klíč–hodnota. Doufáme, že v tomto benchmarku se dozvíme více o tom, jak využívají přímo připojený SSD v cloudovém prostředí.
Návrh benchmarku
Benchmark je navržen pro běh Apache HBase a Apache Cassandra v optimálním produkčním prostředí. To znamená použití stroje šitého na míru pro operace s vysokým io s přímo připojeným SSD. Na disky SSD jsme umístili protokoly zápisu/protokol potvrzení a také úložiště dat. Již dříve četné benchmarky potvrdily, že obě řešení mohou škálovat lineárně, takže test škálování je mimo rozsah tohoto benchmarku.
Výsledky
Analýza
V celém našem srovnávacím testu jsme viděli, že HBase trvale překonává Cassandru při zátěži pro čtení. To je v souladu s klíčovými případy použití HBase, jako jsou vyhledávače, aplikace pro vysokofrekvenční transakce, analýzy dat protokolů a aplikace pro zasílání zpráv. HBase zazáří při pracovní zátěži, kde je požadavkem skenování obrovských, dvourozměrných tabulek. Na druhou stranu Cassandra pracovala dobře na důsledném obchodování s velkou zátěží. Je tedy vhodnější pro sběr analytických dat nebo sběr dat ze senzorů, kdy je konzistence v čase přijatelná.
Dalším faktorem, který je třeba vzít v úvahu při výběru řešení, je také to, zda existují odpovídající sady nástrojů pro analýzu dat. V případě HBase, který je postaven na platformě Apache Hadoop, podporuje Map Reduce a řadu konektorů k dalším řešením, jako jsou Apache Hive a Apache Spark, které umožňují větší agregační dotazy a komplexní analýzy.
Testovací nastavení
Stroj:
Testovací cluster se skládá z 5 strojů. Podrobnosti o stroji:
AWS I3.xlarge
60 GB GP2 pro spuštění OS
Přímo připojené úložiště NVMe, 0,95 TB
4 vCPU, každý vCPU (virtuální CPU) je hardwarové hyper-vlákno na procesoru Intel E5-2686 v4 (Broadwell) běžícím na frekvenci 2,3 GHz.
30,5 GB RAM
Abychom minimalizovali problémy s hlučnými sousedy, provedli jsme testy na dedikovaných instancích AWS.
Srovnávací software:
Testovací datová sada:1TB generovaná prostřednictvím YCSB
Testovací sada:https://github.com/brianfrankcooper/YCSB
Testovací skript: https://github.com/2bethere/hbase-cassandra-bench
Software a prostředí:
HDP 2.6.1
DSE 5.0.8
CentOS 7
Java 8
Abychom plně využili hardware, změnili jsme Počet obslužných rutin na RegionServer v HBase na 120. Všechna ostatní nastavení jsou ponechána jako výchozí. Úplná sada výpisů konfigurace je k dispozici na konci tohoto příspěvku.
Během nasazování jsme také postupovali podle průvodce optimalizací Cassandry zveřejněného zde:http://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/config/configRecommendedSettings.html
Klienti YCSB jsou umístěni na každém z 5 uzlů a běží současně, aby generovali zátěž. Během generování datové sady jsme počet vláken snížili na 40.
Metodika testu
Načítáme datovou sadu se 40 vlákny pro každé pracovní zatížení, protože distribuce datové sady je pro každý benchmark jiná. Po naložení počkáme na dokončení všech zhutňovacích operací, než zahájíme test zátěže. Každá pracovní zátěž byla spuštěna 3krát s 5 000 000 operacemi. Průměrný počet se získá ze 3 testů, aby se získal konečný počet.
O YCSB
YCSB nebo Yahoo! Cloud Serving Benchmark je běžně používaný benchmarkový nástroj. Poskytuje srovnatelné výsledky napříč různými řešeními. Spustili jsme výchozí pracovní zátěž poskytovanou YCSB.
Úloha A:Aktualizace těžké
Příklad aplikace:Obchod relací, záznam nedávných akcí
Úkol B:Převážně čtěte
Příklad aplikace:Označování fotografií; přidat značku je aktualizace, ale většina operací spočívá ve čtení značek
Úloha C:Pouze pro čtení
Příklad aplikace:mezipaměť uživatelského profilu, kde jsou profily vytvořeny jinde (např. Hadoop)
Úloha D:Přečtěte si nejnovější pracovní zátěž
Příklad aplikace:Aktualizace stavu uživatele; lidé chtějí číst nejnovější informace
Pracovní zátěž E:krátké dosahy
Příklad aplikace:konverzace ve vláknech, kde každé skenování je zaměřeno na příspěvky v daném vláknu (předpokládá se, že jsou seskupené podle ID vlákna)
Úloha F:Úloha čtení-úpravy-zápisu
Příklad aplikace:databáze uživatelů, kde jsou uživatelské záznamy čteny a upravovány uživatelem nebo zaznamenávány aktivity uživatele.