Производительность Hbase

Question

Я использую Spring + Datanucleus JDO + Hbase. Hbase работает в полностью распределенном режиме с двумя узлами. Здесь у меня серьезные проблемы с производительностью.

Мое веб-приложение можно рассматривать как пингер, который просто пингует URL-адреса и сохраняет их ответ. Как только мое приложение запускает несколько потоков для вставки в БД. Я заметил, что как только число одновременных записей превышает около 20, вставки начинают занимать много времени (некоторые занимают даже 1000 секунд). И когда это происходит, READS тоже начинает работать, и мое веб-приложение не может извлечь какие-либо данные из БД (мое веб-приложение зависает). Я не особо разбираюсь в NoSQL db и поэтому не знаю, с чего начать поиск производительности.

Мои основные конфигурации: Размер кворума Zookeeper: 1 Hbase регион серверов: 2 Узлы данных: 2 hbase.zookeeper.property.maxClientCnxns: 400 коэффициент тиражирования: 3

Нужно ли увеличивать размер кучи для Hbase? Должна ли высокая производительность WRITE влиять на READ?

Я что-то не так с конфигурацией? Кажется, что запись в файл будет быстрее, чем запись данных в Hbase. Это мой последний выстрел в Hbase. Пожалуйста, помогите

Answer 1

Большая проблема, которую я вижу, заключается в том, что вы запускаете HBase на 2 узлах с коэффициентом репликации 3 (на самом деле это всего лишь 2, поскольку существует только 2 узла для репликации). Это означает, что все записи должны быть реплицированы на оба узла. HBase действительно нужно как минимум 5 или около того узлов, чтобы начать работу.

Звучит так, как будто вы заполняете свой первый регион, и он разделяется; во время разделения после заполнения MemStore вы начнете блокировать. Вам следует изучить возможность предварительного разделения таблицы на несколько областей, что обеспечит равномерное распределение записей.

Я рекомендую взглянуть на главу книги HBase по производительности , в частности, на таблицы предварительного разделения .

Вам также следует использовать сжатие , убедитесь, что вы работаете с собственным сжатием (gzip, lzo или snappy) - не используйте чистое сжатие Java, в противном случае вы будете действительно очень медленными, ссылка обсуждается это немного.

Answer 2

Если вы собираетесь писать в HBase, используя несколько потоков, вам необходимо убедиться, что вы повторно используете свою конфигурацию HBaseConfiguration как можно чаще. В противном случае каждый поток создает новое соединение, и ZK в конечном итоге перестанет предлагать соединения, пока старые не закроются.

Быстрое решение - позволить одноэлементной обработке передать конфигурацию вашим объектам HTable. Это должно гарантировать, что используется та же конфигурация, и минимизирует количество одновременных подключений.