Моделирование данных hbase для каналов активности / новостей / графика времени - PullRequest
1 голос
/ 11 августа 2011

Я решил использовать HBase в проекте для хранения действий пользователей в социальной сети. Несмотря на то, что HBase имеет простой способ выражения данных (ориентированный на столбцы), я сталкиваюсь с некоторыми трудностями при выборе способа представления данных.

Итак, представьте, что у вас есть миллионы пользователей, и каждый пользователь генерирует активность, когда он, например, комментирует в потоке, публикует что-то, например, голосует и т. Д. Я думал, в основном, в двух подходах с Activity hbase таблица:

  1. Ключом может быть ссылка на пользователя + метка времени создания активности, значение всех метаданных активности (чаще всего фиксированного размера)

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

Я видел примеры для других типов систем (таких как блоги), которые используют 2-й подход. Первый подход (с фиксированными столбцами, меняющимися только при изменении схемы) встречается чаще.

Какое влияние окажет доступ к данным для этих двух подходов?

1 Ответ

2 голосов
/ 12 августа 2011

Как правило, вы спрашиваете, должен ли ваш стол быть широким или длинным. HBase работает с обоими, вплоть до определенного момента. В широких таблицах никогда не должно быть строки, превышающей размер области (по умолчанию 256 МБ), поэтому действительно плодовитый пользователь может привести к сбою системы, если вы сохраните большие куски данных для своих действий. Однако, если вы сохраняете только несколько байтов на одно действие, то размещение всей пользовательской активности в одном ряду позволит вам получить их полную историю за один раз. Однако вы получите всю строку, что может привести к некоторому замедлению для большой истории (10 секунд для> 100 МБ строк).

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

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

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

Еще один пример - OpenTSDB

...