Тази публикация в блога е публикувана на Hortonworks.com преди сливането с Cloudera. Някои връзки, ресурси или препратки може вече да не са точни.
Общ преглед
Тъй като все повече и повече натоварвания се пренасят върху съвременния хардуер в облака, за нас е важно да разберем как да изберем най-добрите бази данни, които могат да използват най-добрия хардуер. Amazon представи екземпляри с директно свързан SSD (Solid state drive). Както Apache HBase, така и Apache Cassandra са популярни бази данни ключ-стойност. В този бенчмарк се надяваме да научим повече за това как те използват директно свързания SSD в облачна среда.
Дизайн на бенчмарка
Бенчмаркът е предназначен за стартиране на Apache HBase и Apache Cassandra в оптимална производствена среда. Това означава използване на машина, пригодена за операции с висока IO с директно прикачен SSD. Поставихме дневници с предварителна запис/регистрация, както и съхранение на данни на SSD. По-рано многобройни бенчмаркове вече потвърдиха, че и двете решения могат да се мащабират линейно, така че тестът за мащабиране е извън обхвата на този бенчмарк.
Резултати
Анализ
По време на нашия сравнителен анализ видяхме, че HBase постоянно превъзхожда Cassandra при тежки натоварвания с четене. Това е в съответствие с ключовите случаи на използване на HBase като търсачки, приложения за високочестотни транзакции, анализ на данни от регистрационни файлове и приложения за съобщения. HBase блести при натоварвания, където сканирането на огромни двуизмерни таблици е изискване. От друга страна, Касандра работи добре по отношение на тежкото работно натоварване, което се разменя с последователност. По този начин е по-подходящ за събиране на данни от анализ или събиране на данни от сензори, когато последователността във времето е приемлива.
Друг фактор, който трябва да се вземе предвид при избора на решения, е също дали има съответни набори от инструменти за анализиране на данните. В случай на HBase, изграден върху платформата Apache Hadoop, той поддържа Map Reduce и различни конектори към други решения като Apache Hive и Apache Spark, за да позволи по-големи заявки за агрегиране и сложни анализи.
Тестова настройка
Машина:
Тестовият клъстер се състои от 5 машини. Подробности за машината:
AWS I3.xlarge
60GB GP2 за работа с ОС
Директно свързано съхранение на NVMe, 0,95TB
4 vCPU, всеки vCPU (виртуален CPU) е хардуерен хипер-нишка на процесор Intel E5-2686 v4 (Broadwell), работещ на 2,3 GHz.
30,5 GB RAM
За да сведем до минимум проблемите с шумните съседи, проведохме тестове на специални екземпляри на AWS.
Софтуер за сравнителен анализ:
Набор от тестови данни:1TB генериран чрез YCSB
Тестов пакет:https://github.com/brianfrankcooper/YCSB
Тестов скрипт: https://github.com/2bethere/hbase-cassandra-bench
Софтуер и среда:
HDP 2.6.1
DSE 5.0.8
CentOS 7
Java 8
За да използваме напълно хардуера, променихме Брой манипулатори на RegionServer в HBase на 120. Всички други настройки са оставени по подразбиране. Пълният набор от списъци с конфигурации е наличен в края на тази публикация.
По време на внедряването, ние също следвахме ръководството за оптимизация на Cassandra, публикувано тук:http://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/config/configRecommendedSettings.html
YCSB клиентите са разположени на всеки от 5-те възела и работят едновременно, за да генерират натоварването. По време на генерирането на набор от данни намалихме броя на нишките до 40.
Методология на тестване
Зареждаме набора от данни с 40 нишки за всяко работно натоварване, като се има предвид, че разпределението на набора от данни е различно за всеки бенчмарк. След зареждането изчакваме да приключат всички операции по уплътняване, преди да започнем теста за натоварване. Всяко работно натоварване е изпълнявано 3 пъти с 5 000 000 операции. Средният брой се взема от 3 теста, за да се получи окончателното число.
Относно YCSB
YCSB или Yahoo! Сравнението за облачно обслужване е често използван инструмент за сравнителен анализ. Той предоставя сравнителни резултати за различни решения. Изпълнихме работното натоварване по подразбиране, предоставено от YCSB.
Работно натоварване A:Актуализиране тежко
Пример за приложение:Съхранение на сесии, запис на последните действия
Работно натоварване Б:Четете предимно
Пример за приложение:Маркиране на снимки; добавянето на маркер е актуализация, но повечето операции са за четене на етикети
Работно натоварване C:Само за четене
Пример за приложение:кеш на потребителския профил, където профилите се изграждат другаде (напр. Hadoop)
Работно натоварване D:Прочетете най-новото работно натоварване
Пример за приложение:Актуализации на потребителското състояние; хората искат да прочетат най-новата информация
Работно натоварване E:Кратки обхвати
Пример за приложение:разговори с нишки, където всяко сканиране е за публикациите в дадена нишка (приема се, че са групирани по идентификатор на нишка)
Работа F:Работно натоварване за четене, модифициране и запис
Пример за приложение:потребителска база данни, където потребителските записи се четат и променят от потребителя или за записване на потребителска активност.
