Подтвердить что ты не робот

Конструкция ключа строки HBase для монотонно увеличивающих ключей

У меня есть таблица HBase, где я пишу строки, например:

<prefix>~1
<prefix>~2
<prefix>~3
...
<prefix>~9
<prefix>~10

Сканирование оболочки HBase дает результат:

<prefix>~1
<prefix>~10
<prefix>~2
<prefix>~3
...
<prefix>~9

Как должен быть создан ключ строки так, чтобы строка с ключом <prefix>~10 была последней? Я ищу некоторые рекомендуемые способы или способы, которые более популярны для разработки ключей строки HBase.

4b9b3361

Ответ 1

Как должен быть сконструирован ключ строки так, чтобы строка с ключом ~ 10 была последней?

Вы видите результат сканирования таким образом, потому что rowkeys в HBase сортируются лексикографически, независимо от порядка вставки. Это означает, что они сортируются на основе их строковых представлений. Помните, что rowkeys в HBase рассматриваются как массив байтов, имеющих строковое представление. Строка row самого низкого порядка появляется сначала в таблице. Вот почему 10 появляется до 2 и так далее. См. Разделы Строки на этой странице , чтобы узнать больше об этом.

Когда вы оставили пэд, целые числа с нулями, их естественное упорядочение остается неизменным при сортировке лексикографически и поэтому вы видите порядок сканирования, такой же, как и порядок, в который вы вставили данные. Для этого вы можете создавать свои строковые ключи, как было предложено @shutty.

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

Для разработки хорошего дизайна есть несколько общих рекомендаций:

  • Держите клавишу row как можно меньше.
  • Избегайте использования монотонно увеличивающихся строк, таких как временная метка и т.д. Это плохой дизайн для shecma и приводит к горячей точке RegionServer. Если вы не можете избежать такого использования, как хеширование или соление, чтобы избежать горячих точек.
  • Избегайте использования строк в качестве строк, если это возможно. Строковое представление числа принимает больше байтов по сравнению с его целым или длинным представлением. Например: Длинные 8 байт. Вы можете сохранить беззнаковое число до 18 446 744 073 709 551 615 в этих восьми байтах. Если вы сохранили это число как String - предположив байт на символ, вам нужно почти 3x байта.
  • Используйте некоторый механизм, например хэширование, чтобы получить равномерное распределение строк, если ваши регионы не равномерно загружены. Вы могли бы также создать предварительно разделенные таблицы для достижения этого.

См. ссылку для получения дополнительной информации о дизайне rowkey.

НТН

Ответ 2

HBase хранит строки в лексикографическом порядке, поэтому вы можете попытаться использовать эту схему с фиксированной длиной rowrey:

<prefix>~0001
<prefix>~0002
<prefix>~0003
...
<prefix>~0009
<prefix>~0010

Имейте в виду, что вы также должны использовать случайные префиксы, чтобы избежать локального горячего определения (когда одна область принимает большую часть записей, в то время как другие регионы простаивают).

Ответ 3

монотонно увеличивающиеся ключи не являются хорошей схемой для hbase. Вы можете прочитать больше здесь: http://hbase.apache.org/book/rowkey.design.html

там также есть ссылка на OpenTSDB, которая решает эту проблему.

Ответ 4

Фиксированные ключи длины действительно рекомендуются, если это возможно. Bytes.toBytes(Long value) можно использовать для получения байтового массива из счетчика. Он будет сортировать для положительных длин менее Long.MAX_VALUE.