Последний раз обсуждаем бой тяжеловесов Кассандра против HBase вызвало очень бурную дискуссию, в ходе которой много раз упоминалась Сцилла – что расположен как более быстрый аналог Кассандры (далее CS).
Еще меня заинтересовал очень интересный Aerospike (далее AS), который в своих тестах предсказуемо побеждает CS с разгромным счетом.
По удивительному совпадению, Scylla (далее SC) также легко обыгрывает CS, которым гордится отчеты прямо на вашей домашней странице: 
Вот и естественно возникает вопрос, кто кого возьмет, кита или слона?
В моем тест оптимизированная версия HBase (далее HB) работает с CS на равных, поэтому она не будет здесь претендентом на победу, а лишь постольку, поскольку вся наша обработка построена на HB и мы хотим понять ее возможности в сравнение с лидерами.
Понятно, что бесплатность HB и CS — это огромный плюс, но с другой стороны, если для достижения той же производительности нужно в Х раз больше оборудования, возможно, выгоднее платить за ПО, чем выделять пол в дата-центр для дорогих грелок.
Особенно учитывая, что если говорить о производительности, то поскольку HDD в принципе не способны обеспечить хотя бы приемлемую скорость произвольного чтения (см.
Почему жесткий диск и быстрое чтение с произвольным доступом несовместимы "), что в свою очередь означает покупку SSD, что в необходимых для настоящих BigData объемах - очень дорогое удовольствие.
Итак, было сделано следующее.
Я арендовал 4 сервера в облаке AWS в конфигурации i3en.6xlarge, где на борту каждого: ЦП — 24 виртуальных процессора ПАМЯТЬ - 192 ГБ SSD – 2 х 7500 ГБ Если кто захочет повторить, сразу отметим, что для воспроизводимости очень важно брать конфигурации с полной емкостью диска (7500 ГБ).
В противном случае диски придется делить с непредсказуемыми соседями, которые обязательно испортят ваши тесты, так как наверняка посчитают это очень ценной нагрузкой.
Далее я развернул SC, используя дизайнер , который любезно предоставил производитель на собственном сайте.
Затем я залил на каждую ноду кластера утилиту YCSB (которая является практически стандартом сравнительного тестирования баз данных).
Есть только один важный нюанс; почти во всех случаях мы используем следующую схему: прочитать запись перед изменением + записать новое значение.
Поэтому я изменил обновлять следующим образом:
Далее я запустил загрузку одновременно со всех 4-х хостов (тех самых, где расположены серверы баз данных).@Override public Status update(String table, String key, Map<String, ByteIterator> values) { read(table, key, null, null); // << added read before write return write(table, key, updatePolicy, values); }
Это было сделано намеренно, поскольку некоторые клиенты баз данных могут потреблять больше ресурсов ЦП, чем другие.
Учитывая, что размер кластера ограничен, хотелось бы понять общую эффективность реализации как серверной, так и клиентской части.
Результаты тестов будут представлены ниже, но прежде чем мы перейдем к ним, стоит учесть еще несколько важных нюансов.
Что касается AS, то это очень привлекательная база данных, лидер в категории удовлетворенности клиентов с точки зрения версии ресурс г2. 
Честно говоря, мне она тоже чем-то понравилась.
Легко установить, вот так сценарий Он довольно легко превращается в облако.
Стабильно, настраивать одно удовольствие.
Однако у него есть один очень большой недостаток.
Для каждого ключа выделяется 64 байта оперативной памяти.
Вроде немного, но в промышленных количествах это становится проблемой.
Типичная запись в наших таблицах имеет размер 500 байт. Именно такое значение я использовал почти* во всех тестах (*почему почти, будет сказано ниже).
Поскольку мы храним по 3 копии каждой записи, то получается, что для хранения 1 ПБ чистых данных (3 ПБ грязных) нам придется выделить всего 400 ТБ оперативной памяти.
Идем дальше.
нет что?! Подожди секунду, мы можем что-нибудь с этим сделать? — спросили мы продавца.
Ха, конечно можно много чего, скрестим пальцы:
- Упаковать несколько записей в одну ( прыгать ).
- То же, что и в пункте 1, только за счет расширения количества полей.
- Включите режим полной очистки.
Идея состоит в том, чтобы хранить индекс не в памяти, а на диске.
Правда есть нюанс, Ватсон, опция доступна только в Entreprise версии (в моем случае она доступна в рамках пробного периода).
Для установки Hadoop у Amazon есть платформа EMR, которая позволяет легко развернуть нужный вам кластер.
Мне оставалось только поднять лимиты на количество процессов и открытых файлов, иначе крашилось под нагрузкой, и заменил hbase-server на свою оптимизированную сборку (подробнее здесь ).
Второй момент — HB невероятно медленный при работе с одиночными запросами, это факт. Поэтому мы работаем только партиями.
В этом тесте партия = 100. В таблице 100 регионов.
Ну и последний момент, все базы данных тестировались в режиме «сильной согласованности».
Для HB это из коробки.
AS доступен только в корпоративной версии (т. е.
в этом тесте он был включен).
SC работал в режиме согласованности записи = все.
Фактор репликации везде 3. Итак, начнем.
Вставляем в АС: 10 сек: 360554 операций; 36055,4 текущих операций в секунду; 20 сек: 698872 операции; 33831,8 текущих операций в секунду; … 230 сек: 7412626 операций; 22938,8 текущих операций в секунду; 240 сек: 7542091 операций; 12946,5 текущих операций/сек; 250 сек: 7589682 операций; 4759,1 текущих операций/сек; 260 сек: 7599525 операций; 984,3 текущих операций в секунду; 270 сек: 7602150 операций; 262,5 текущих операций/сек; 280 сек: 7602752 операции; 60,2 текущих операций/сек; 290 сек: 7602918 операций; 16,6 текущих операций/сек; 300 сек: 7603269 операций; 35,1 текущих операций в секунду; 310 сек: 7603674 операций; 40,5 текущих операций/сек; Ошибка при записи ключа user4809083164780879263: com.aerospike.client.AerospikeException$Timeout: Тайм-аут клиента: timeout=10000 итераций=1 errorNodes=0 errorConns=0 LastNode=5600000A 127.0.0.1:3000 Ошибка при вставке, повторная попытка невозможна.
количество попыток: 1. Предел повторных попыток вставки: 0. Упс, вы точно продюсер с производственной базой? Вы можете так подумать на первый взгляд. Однако оказалось, что проблема была в ядре Amazon-версии Linux. На них был открыт тикет и проблема исправлена в версии amzn2-ami-hvm-2.0.20210326.0-x86_64-gp2. Но для этих тестов вендор предложил использовать ansible-скрипты для развертывания ubuntu, где данной проблемы не возникало (для этого нужно выбрать соответствующий ветвь в дачах).
Хорошо, продолжим.
Начинаем загружать 200 миллионов записей (INSERT), затем UPDATE, затем GET. Вот что произошло (ops — операций в секунду): 
ВАЖНЫЙ! Это скорость одного узла! Всего их 4, т.е.
чтобы получить общую скорость нужно умножить на 4. В первом столбце 10 полей, это не совсем честный тест. Те.
это когда индекс находится в памяти, что недостижимо в реальной ситуации с BigData. Второй столбец — это упаковка 10 записей в 1. Т.
е.
Здесь реальная экономия памяти, ровно в 10 раз.
Как хорошо видно из теста, такая хитрость не напрасна; производительность существенно падает. Причина очевидна: каждый раз для обработки одной записи приходится иметь дело с 9 соседними.
Накладные расходы короче.
И наконец, все вровень, картина примерно такая же.
Чистые вставки хуже, но операция обновления ключа выполняется быстрее, поэтому в дальнейшем будем сравнивать только с all-flush.
Собственно, не будем тащить кота, перейдем сразу к делу: 
(ops — операций в секунду)
Все в целом понятно, но что тут стоит добавить.
- Поставщик AS подтвердил, что приведенные выше результаты в его базе данных актуальны.
- Вставки SC были какие-то не очень корректные, вот более подробный график с разбивкой по серверам:
Но я все настроил внутри и снаружи скриптом от вендора, так что мопед не мой, все вопросы к нему.
Также нужно понимать, что это очень скромный объем данных и с увеличением объемов ситуация может измениться.
За время экспериментов я сжег несколько сотен баксов, так что энтузиазма мне хватило только на длительный тест лидера и в режиме, ограниченном одним сервером.
Почему он так сильно затонул и какое оживление в последней трети – загадка природы.
Также можно заметить, что скорость радикально выше, чем в чуть более высоких тестах.
Я думаю, это потому, что режим строгой согласованности отключен (поскольку сервер только один).
И, наконец, GET+WRITE (помимо более чем трех миллиардов записей, заполненных тестами): 
Что это за просадка, я в душе понятия не имею.
Никаких посторонних процессов не запускалось.
Возможно, дело как-то в SSD-кэше, ведь за все время тестирования AS в режиме all-flush загрузка составила 100%.
Вот и все.
Выводы в целом очевидны: необходимы дополнительные тесты.
Желательно все самые популярные базы на одинаковых условиях.
В Интернете этого жанра не так уж и много.
Было бы хорошо, тогда у производителей баз данных появится мотивация к оптимизации, а у нас – к осознанному выбору лучшего.
Теги: #Хранение данных #Хранение данных #Высокая производительность #Большие данные #Hadoop #bigdata #hbase #aerospike #scylla #NT
-
H Веб-Мастер, Во Что Ты Ввязался!?
19 Oct, 24 -
Firefox – Будущее Серфинга
19 Oct, 24 -
Гагаузский Язык
19 Oct, 24 -
Назначение И Поддержка Fqdn Сервера 3Cx
19 Oct, 24 -
Яндекс Пополнился Новыми Словарями
19 Oct, 24
