Звучит логично, конечно, однако многое зависит от множества сложившихся условий на кластере и иногда бывает контр-интуитивное поведение. Вот к примеру записал данные в 4 таблицы, всего 4 млрд записей. Потом сбросил на диск и прочитал случайные 400 млн (т.е. 10%). Это заняло 41 секунду:
tables=4, threads=100, batch=100, count=100000, dataSize=100, opType=select: 41814.
Затем был сделан рестарт HBase, чтобы почистить кэш, сделан major_compact и залиты те же самые 400 млн ключей по новой, чтобы они лежали и в memstore и в HFile.
И тут же прочитал, и как ни странно, это заняло меньше времени, всего 33 секунды:
tables=4, threads=100, batch=100, count=100000, dataSize=100, opType=select: 33326
Причем если сбросить данные на диск и замажорить, то чтение займет все равно 33 секунды)
Бывает сильно по разному, например у нас очень часто HB используется для сборки полной версии объекта через комбинацию put-get. Это когда мы получаем вектор изменений (только изменившиеся поля от источника), применяем (put) и тут же делаем get, чтобы получить полный экземпляр объекта для отправки дальше. Однако проверить оба варианта действительно интересно.
Переезд занимает вот столько времени примерно:
ZooKeeper session timeout + split time + assignment/replay time
На практике это может занять прилично времени, в частности сильно зависит от количества WAL файлов, которые нужно обработать. Все это занимает примерно минут 10-30.
>>Насколько это автоматически
На версии 2.1.0 наблюдали как RS упал, а переезд не начался. Есть информация от человека близкого к разработке HBase что административная часть в первых версиях 2.* не очень написана. Есть вероятность что 2.2.3 уже ок. Однако это исключение, такое было один раз пока что, обычно переезд начинается как надо.
Клиенты узнают так, что получают NotServingRegionException и должны висеть ждать пока не выяснится какой RS подхватил регион. В теореме CAP HBase жертвует availability…
Да, это так, я в посте упоминал об этом, скорость после флаша падает примерно в 2 раза. Я пытался привести CS к подобному поведению, увеличивая memtable_heap_space_in_mb, однако это не дало ускорения. Т.е. с одной стороны все верно, а с другой хотелось бы как-то отметить, что HB эффективнее держит данные в памяти. Думаю для полноты картины в финальной версии сравнений выложить два варианта — чтение с дисков и из памяти.
Поработало не всю ночь, однако компактицикация имела место и несколько увеличила нагрузку на диски:
Однако я думаю пока еще рано делать выводы, хочу применить ваши и другие рекомендации (часть из них уже привела к кратному росту скорости чтения) и позже дополню пост.
Спасибо за детальный анализ поста и интерес к теме. Базы безусловно имеют ряд отличий, однако в целом занимают одну нишу — позволяют эффективно оперировать действительно большими объемами. При этом в рамках теоремы CAP они позиционируются по разному, как вы верно заметили. CS считается больше AP, но может быть настроена иначе, тогда как HB это практически полный CP. Однако насчет роли мастера для HB это не верное представление. Как ниже правильно отметили, есть возможность дублировать роль мастера (мы так и делаем) и второй момент в работе с данными мастер не принимает участие. Т.е. выпадение мастера не позволяет выполнять административные функции (создание таблиц и т.д.), но не мешает работе RegionServers (RS).
Насчет дисков, как я понял, у них тут все идентично. Данные легли на все диски равномерно, в комментариях выше это подтвердили. Также WAL пишется в HB как и CS и тоже делает sync.
>>А если сравнивать — пишите в большое кол-во потоков
Поменял схему, вместо записи в 5 потоков батчами по 100 штук писал 100 потоков поштучно. Никакой разницы не было. Однако на чтение вместе с TokenAwarePolicy скорость выросла в 2 раза, с 159 644 до 301 969.
Попозже проведу более полное и тщательное тестирование, с учетом других предложенных оптимизаций и добавлю в конец поста.
Вы хамите. Минусы не дают на это права, если вы не знали.
Во вторых, ни один из поставивших минус не аргументировал. Тогда как это факт очевидности уровня википедии:
«A wide column store can be interpreted as a two-dimensional key-value store.» en.wikipedia.org/wiki/Wide_column_store
Резонно, судя по тестам что на их сайте, она просто космос. Единственный вопрос, почему она до сих пор на 8 месте того же DB-Engines Ranking (см. вторую картинку в посте) и не видно мощной динамики. Возможно инерция IT-сообщества, возможно тоже есть подводные камни. Видимо как это частенько бывает, пока не попробуешь, не узнаешь…
tables=4, threads=100, batch=100, count=100000, dataSize=100, opType=select: 41814.
Затем был сделан рестарт HBase, чтобы почистить кэш, сделан major_compact и залиты те же самые 400 млн ключей по новой, чтобы они лежали и в memstore и в HFile.
И тут же прочитал, и как ни странно, это заняло меньше времени, всего 33 секунды:
tables=4, threads=100, batch=100, count=100000, dataSize=100, opType=select: 33326
Причем если сбросить данные на диск и замажорить, то чтение займет все равно 33 секунды)
ZooKeeper session timeout + split time + assignment/replay time
На практике это может занять прилично времени, в частности сильно зависит от количества WAL файлов, которые нужно обработать. Все это занимает примерно минут 10-30.
>>Насколько это автоматически
На версии 2.1.0 наблюдали как RS упал, а переезд не начался. Есть информация от человека близкого к разработке HBase что административная часть в первых версиях 2.* не очень написана. Есть вероятность что 2.2.3 уже ок. Однако это исключение, такое было один раз пока что, обычно переезд начинается как надо.
Клиенты узнают так, что получают NotServingRegionException и должны висеть ждать пока не выяснится какой RS подхватил регион. В теореме CAP HBase жертвует availability…
Однако я думаю пока еще рано делать выводы, хочу применить ваши и другие рекомендации (часть из них уже привела к кратному росту скорости чтения) и позже дополню пост.
Было: 159 644 ops (4 таблицы, 5 потоков, батч 100).
Добавил:
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
И поигрался с количеством потоков. Получилось следующее:
4 таблицы, 100 потоков, батч = 1 (поштучно): 301 969 ops
4 таблицы, 100 потоков, батч = 10: 447 608 ops
4 таблицы, 100 потоков, батч = 100: 625 655 ops
Потом применю другие советы по тюнингу, прогоню полный цикл тестирования и добавлю результаты в конце поста.
Насчет дисков, как я понял, у них тут все идентично. Данные легли на все диски равномерно, в комментариях выше это подтвердили. Также WAL пишется в HB как и CS и тоже делает sync.
>>А если сравнивать — пишите в большое кол-во потоков
Поменял схему, вместо записи в 5 потоков батчами по 100 штук писал 100 потоков поштучно. Никакой разницы не было. Однако на чтение вместе с TokenAwarePolicy скорость выросла в 2 раза, с 159 644 до 301 969.
Попозже проведу более полное и тщательное тестирование, с учетом других предложенных оптимизаций и добавлю в конец поста.
Hbase – колоночная база данных, реализующая парадигму BigTable
Просто некоторым людям приятнее и важнее считать, что кругом невежды, чем имеет место банальное несовпадение терминологии)
Ну или хотя бы прочитали дальше следующий раздел той же статьи:
Во вторых, ни один из поставивших минус не аргументировал. Тогда как это факт очевидности уровня википедии:
«A wide column store can be interpreted as a two-dimensional key-value store.»
en.wikipedia.org/wiki/Wide_column_store
Понял, поставлю грузиться HB на ночь, чтобы пошла компактификация, посмотрим что получится…