Ключ строки дизайна HBase

У меня = ~ 20 миллиардов событий. Событие состоит из: одного ключа (SSN), одной даты и информации о событии. У меня есть 5 типов событий.

Шаблон чтения: мне нужно получить все события с одного ключа до определенной даты.

Шаблон записи: всего одна массовая загрузка один раз в день.

Представьте себе базу данных:

SSN;date(yyyymmdd);info
1;20140101;A
1;20140105;B
2;20140106;A
1;20140103;C

Итак, если мой запрос: (SSN = "1" и date = "20140104"), мне нужно получить:

1;20140101;A
1;20140103;C

Мой первый подход:

  • Ключ строки = SSN + дата.
  • Одна семья с множеством столбцов для хранения информации. (информация: cep, информация: имя, ...)

Кто-нибудь видит в этом подходе проблемы с производительностью? хотя мой ключ состоит из даты, я не думаю, что это вызывает «монотонно увеличивающиеся значения», потому что сначала у меня есть SSN.


nosql row hbase
person p.magalhaes    schedule 26.03.2015    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Это прекрасный дизайн. Для сканирования чтения вы должны использовать startKey = sss + 0 и endKey = ssn + date. Вам нужно будет выделить фиксированное количество символов для поля идентификатора пользователя (SSN - 9). Ключи строк отсортированы лексикографически. 20 млрд / 420 общих SSN в обращении = 47 событий на SSN, при условии равномерного распределения. Это немного, но я бы подумал о размере индекса и любых необходимых оптимизациях.

События представляют собой временные ряды. Возможно, вас заинтересует следующее резюме. Он имеет 3 варианта использования: https://cloud.google.com/bigtable/pdf/CloudBigtableTimeSeries.pdf

person Sergei Rodionov    schedule 08.05.2015

arrow_upward
0
arrow_downward

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

У вас есть монотонно увеличивающиеся ключи (с учетом SSN), но это не имеет значения по двум причинам:

  • Ведущая часть ключа - это SSN, и его мощность (~ 450MM) намного больше, чем количество узлов / серверов региона.
  • Самое главное, вы пишете только раз в день! Монотонно увеличивающиеся ключи могут вызвать «горячие точки» в зависимости от распределения данных и шаблонов записи. Выполнение массовой загрузки означает создание предварительно разделенной таблицы, генерирующей файлы HFiles ' offline 'и загружая их все сразу, не проходя через конвейер записи HBase (WAL, Memstore, Minor / Major Compactions). Не может быть точки доступа во время записи.

Небольшой совет:

  • Используйте односимвольные имена семейств столбцов: info -> d (как в 'data')
person Marsellus Wallace    schedule 30.09.2016