Могу ли я улучшить производительность HBase, уменьшив размер блока hdfs?

У меня есть около 2500 таблиц, участвующих в расчете. В моей среде разработки у меня очень мало данных в этих таблицах, 10–10 000 строк, причем большинство таблиц находятся в нижней части этого диапазона. Мой расчет просканирует все эти таблицы много раз. Хотя весь набор данных поместился бы в памяти, доступ к нему через HBase невероятно медленный, с огромным объемом дисковой активности.

Как вы думаете, это поможет уменьшить размер блока hdfs? Я полагаю, что если каждая таблица находится в своем собственном блоке, то огромное количество памяти будет потрачено впустую, что предотвратит размещение всего набора данных в ОЗУ. Значительно уменьшенный размер блока позволит системе хранить большую часть, если не все данные в оперативной памяти. В настоящее время размер блока составляет 64 МБ.

Окончательная система будет использоваться в более крупном кластере с гораздо большим объемом памяти и узлов, это сделано исключительно для ускорения моей среды разработки.


hbase
person user1098798    schedule 14.12.2011    source источник

Ответы (2)


arrow_upward
5
arrow_downward

HBase хранит свои данные в HFiles (которые, в свою очередь, хранятся в файлах Hadoop), вот выдержка из документа:

Минимальный размер блока. Мы рекомендуем установить минимальный размер блока от 8 КБ до 1 МБ для общего использования. Больший размер блока предпочтителен, если файлы в основном предназначены для последовательного доступа. Однако это привело бы к неэффективному произвольному доступу (поскольку нужно распаковать больше данных). Блоки меньшего размера хороши для произвольного доступа, но требуют больше памяти для хранения индекса блока и могут создаваться медленнее (поскольку мы должны очищать поток компрессора в конце каждого блока данных, что приводит к сбросу ввода-вывода FS). . Кроме того, из-за внутреннего кэширования в кодеке сжатия наименьший возможный размер блока будет составлять около 20–30 КБ.

независимо от размера блока вы можете захотеть установить семейства столбцов таблиц в памяти, что заставляет hbase сохранять их в кеше.

Наконец, ваша ситуация кажется более подходящей для кеша, такого как redis/memcache, чем для Hbase, но, возможно, мне не хватает контекста.

person Arnon Rotem-Gal-Oz    schedule 14.12.2011
comment
Фантастический! Спасибо за ответ. В конечном итоге таблицы будут значительно больше, миллионы строк и должны быть сохранены. Можно ли использовать Redis/memcache в этом сценарии? - person user1098798; 15.12.2011
comment
см. groups.google.com/group/redis-db/browse_thread/thread / для ограничения размера Redis. Опять же, я недостаточно знаю о ваших требованиях. поэтому другие связанные технологии, которые вы, возможно, захотите рассмотреть, включают решения для сетей данных, такие как Gridgain, Hazelcast, Gigaspaces или Infinispan. - person Arnon Rotem-Gal-Oz; 15.12.2011
comment
Имейте в виду, что размер блока HDFS и размер блока HBase — это разные вещи. - person Dave L.; 13.03.2013

arrow_upward
0
arrow_downward

если размер вашего блока слишком мал, вам нужно больше памяти для хранения индексов блоков. если размер блока слишком велик, HBase должен сканировать дополнительную строку, чтобы определить, существует ли искомый ключ в блоке HBase или нет. Если ваша пара KV составляет 100 байт, то 640 KV помещаются в блок, что является хорошим значением.

person ozhang    schedule 04.08.2014