как спроектировать схему Hbase?

StackOverflow https://stackoverflow.com/questions/375194

  •  22-08-2019
  •  | 
  •  

Вопрос

предположим, что у меня есть эта таблица RDBM (Сущность-атрибут-value_model):

col1: entityID
col2: attributeName
col3: value

и я хочу использовать HBase из-за проблем с масштабированием.

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

Проблема в том, что в моем случае я хочу иметь возможность выполнять итерации по всем 3 столбцам.например :

  • для данного EntityId я хочу получить все его атрибуты и значения
  • для присвоения имени атрибута и значения я хочу указать все идентификаторы объектов ...

итак, у меня возникла идея создать одну таблицу Hbase, которая будет содержать данные (данные таблицы с EntityId в качестве основного индекса), и 2 таблицы "index", одну с attributeName в качестве первичного ключа, а другую со значением

каждая таблица индексов будет содержать список указателей (entityIDs) для таблицы ДАННЫХ.

Разумный ли это подход ?или это "злоупотребление" концепциями Hbase ?

В этом Блог в Автор сказать:

HBase позволяет выполнять операции получения по первичному ключу и сканированию (подумайте:курсор) над строкой диапазоны.(Если у вас есть и масштаб, и необходимость во вторичных индексах, не беспокойтесь - Lucene спешит на помощь!Но это уже другой пост.)

Знаете ли вы , как Lucene может помочь ?

-- Йонатан

Это было полезно?

Решение

Вторичные индексы действительно были бы полезны для многих потенциальных приложений HBase, и я полагаю, что разработчики действительно рассматривают это.Оформить покупку http://www.mail-archive.com/hbase-dev@hadoop.apache.org/msg04801.html.

В то же время, однако, если хранилище данных вашего приложения можно смоделировать как звездообразную схему (см. http://en.wikipedia.org/wiki/Star_schema) возможно, вы захотите проверить решение, которое Hypertable предлагает для нужд вторичного индексного типа http://markmail.org/message/rphm4q6cbar2ycgp

Другие советы

Я рекомендую иметь два разных плоских стола:один для поиска атрибутов + значений, заданных EntityId, и один для поиска EntityId, заданных attributes + values.

Таблица 1 будет выглядеть следующим образом:

entityID1 {
  attribute1: value1;
  attribute2: value2;
  ...
}

и Таблица 2:

attribute1_value1 {
  entityID1;
}
attribute2_value2 {
  entityID1;
}
Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top