Конструкция ключа таблицы HBase в отношении дубликатов и точек доступа сервера региона

У меня есть требование для хранения событий, сгенерированных пользователем, идентифицированным userId. Каждый пользователь принадлежит компании, которая идентифицируется по companyId. Я придумал дизайн для таблицы в HBase следующим образом:

rowkey: < companyId>< userId>< timestamp>

column-family: info (инкапсулирует набор атрибутов события, как показано ниже)

столбцы: < attr1>, < attr2>....< attrn>

Я знаю, что этот дизайн ключа облегчит запрос данных позже по companyId и / или userId с помощью частичного сканирования ключей. Сказав это, у меня есть несколько вопросов и проблем, и я хотел бы получить некоторые идеи.

1- Если у нас есть сценарий использования для чтения, который считывает все данные в заданном диапазоне времени, то с этим текущим дизайном мы не сможем использовать rowKey. Вместо этого нам нужно будет выполнить полное сканирование и отфильтровать строки в поле отметки времени (поддерживается отдельно как один из столбцов attr).

2- Как обрабатывать дубликаты? Я знаю, что в этом случае HBase создаст новую версию строки, но разрешит ли она чтение позже в соответствии с вариантом чтения-использования, упомянутым в 1? Я знаю, что вы можете контролировать версии при запросе, но будет ли это хороший дизайн или неправильная перегрузка нативных функций?

3- Это касается точки доступа сервера региона. У нас нет монолитных ключей, но мы все еще можем столкнуться с этой проблемой, если, скажем, одна конкретная компания или пользователь очень активны. Хеширование и разбивка на основе количества серверов будут работать не в этом случае? Может быть, если мы хешируем поле timestamp и добавляем его к rowKey, а не к исходному значению? Но тогда проблема заключается в том, что сканирование по метке времени компонента ключа будет невозможно. Нам понадобится отдельный столбец (attr), чтобы захватить это. Какие-либо предложения?

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

Источник

1 ответ

1: чтение варианта использования

Это зависит от вашего варианта использования:

  • Если вы хотите получить данные каждого пользователя для организации за определенный промежуток времени, то то, что у вас есть, мне кажется правильным, и вам придется выполнить сканирование всех данных организации.

  • Если вы хотите прочитать все данные для данного вашего текущего дизайна ключа, кажется, хорошо. Хотя я бы перевернул позицию org и user id для создания нового ключа (rowkey: userId-companyId-timestamp). Это произойдет, поскольку данные независимых пользователей не пересекаются, и теперь их не нужно объединять.

  • Если вы нажмете отметку времени вверху (rowkey: timestamp-companyId-userId), вы сможете запустить сканирование всех данных orgs / all пользователей, заканчивающихся в месте, определенном диапазоном времени (пропуская полное сканирование таблицы)

2: Дублирование

ВНИМАНИЕ: Hbase по умолчанию записывает до 3-х версий ячейки (также не путайте эти временные метки версии с временными метками на вашем ключе). Вы можете увеличить этот лимит и получать результаты из разных версий, однако не рекомендуется, чтобы это количество версий было большим.

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

3: Горячие регионы

  • Если компания очень активна, вы можете добавить хеш companyId-userId к вашей строке. Это распределит записи по любой организации.

  • Если пользователь очень активен, и есть сценарий использования для извлечения всех его данных оптимальным способом, то я не уверен, что хеширование по ключу или метке времени является хорошим решением. Вы определенно хотели бы сохранить данные для пользователя вместе, и я не уверен, что будет лучшим решением здесь.

Исходя из того, как я понимаю вашу проблему, я, вероятно, разработал бы ROWKEY как HASH(companyId-UserId)-companyId-UserId-Timestamp

Источник
Другие вопросы по тегам