Как таблица разделов HBase на серверах регионов?
Скажите, пожалуйста, как таблица разделов HBase распределена по регионам-серверам.
Например, допустим, что мои ключи строк - целые числа от 0 до 10 МБ, и у меня есть 10 серверов регионов.
Означает ли это, что на первом сервере регионов будут храниться все строки с ключами со значениями 0–10M, вторые 1M– 2M, третьи 2M – 3M,… десятые 9M – 10M?
Я хотел бы, чтобы мой ключ строки был меткой времени, но В случае, если большинство запросов будет применяться к последним датам, все запросы будут обрабатываться только одним сервером региона, это правда?
Или, может быть, эти данные будут распространяться по-другому?
Или, может быть, я могу каким-то образом создать больше регионов, чем у меня есть серверов регионов, поэтому (согласно данному примеру) сервер 1 будет иметь ключи 0 - 0,5M и 3M - 3,5M, таким образом мои данные будут распределяться более равномерно, возможный?
обновление
Я только что обнаружил, что есть опция hbase.hregion.max.filesize , как вы думаете, это решит мою проблему?
2 ответа
Разделение WRT, вы можете прочитать сообщение в блоге Ларса об архитектуре HBase или статью Google Bigtable, которую HBase «клонирует».
Если ключ строки - это всего лишь временная метка, тогда да, регион с самыми большими ключами всегда будет получать новые запросы (поскольку регион обслуживается только одним сервером региона).
Хотите использовать временные метки для короткого сканирования? Если это так, подумайте о том, чтобы засолить свои ключи (поищите в Google, как Mozilla сделала это с Sorocco).
Можете ли вы использовать в качестве префикса метку времени любой идентификатор? Например, если вы запрашиваете данные только для определенных пользователей, добавьте к ts префикс этого идентификатора пользователя, и это даст вам гораздо лучшее распределение нагрузки.
Если нет, тогда используйте UUID или что-нибудь еще, что будет случайным образом распространять ваши ключи.
О hbase.hregion.maxfilesize
Установка maxfilesize в этой таблице (что вы можете сделать с помощью оболочки) не означает, что размер каждой области равен точно X МБ (где X - это значение, которое вы комплект) большой. Итак, предположим, что все ваши ключи строки являются временными метками, что означает, что каждый новый ключ строки больше, чем предыдущий. Это означает, что он всегда будет вставлен в область с пустым конечным ключом (последним). В какой-то момент один из файлов вырастет больше, чем maxfilesize (за счет сжатия), и эта область будет разделена посередине. Нижние клавиши будут в своем собственном регионе, верхние - в другом. Но поскольку ваш новый ключ строки всегда больше предыдущего, это означает, что вы будете писать только в этот новый регион (и так далее).
tl; dr, даже если у вас более 1000 регионов, с этой схемой область с самыми большими ключами строк всегда будет получать записи, что означает, что сервер региона размещения станет узким местом.
Параметр hbase.hregion.max.filesize , который по умолчанию равен 256 МБ, устанавливает максимальный размер области, после достижения этого предела область разделяется. Это означает, что мои данные будут храниться в нескольких регионах размером 256 МБ и, возможно, на одну меньше.
Итак,
я бы хотел, чтобы в моей строке была метка времени, но я полагаю, что большинство запросов будет применяться к последним датам, все запросы будут обрабатываться только одним региональным сервером, это правда?
Это неверно, потому что последние данные также будут разделены на регионы размером 256 МБ и сохранены на разных региональных серверах.