Подходящая модель таблицы HBase

Question

Мне сложно найти таблицу HBase для следующего требования.

У меня есть стол «Магазин», где хранятся детали магазина (Pizza Hut).

У меня есть таблица «Заказ», в которой содержится сводка транзакции (общая сумма транзакции и т. Д.).

У меня есть еще один стол «Order_Item», где каждый упорядоченный элемент в транзакции хранится (Это имеет идентификатор товара, наименование товара, количество элементов, налог и т.д ..)

1. Это требование, учитывая временной диапазон вычисляет общий доход по определенной позиции заказа из определенного Магазина.

Пример: Диапазон дат - Последняя неделя, магазин - Pizza A, Предмет - A, Общий доход - 120 $

1. Другим требованием является, учитывая время диапазон расчета процента от общего дохода по определенный предмет заказа из магазина.

Пример: Диапазон дат - Последняя неделя, магазин - Pizza A, Предмет - A,% Доля доходов - 23%

Я действительно застрял на том, как смоделировать таблицы Hbase и срок делает меня напряглись ,

Пожалуйста, помогите мне в этом.

Answer 1

В HBase вы хотите быть уверены, что вы проектируете свои таблицы вокруг своих типичных запросов. Если вы создаете свои таблицы на основе каких-то произвольных «то, что имеет смысл», вы увидите плохую производительность.

Поскольку основным требованием является запрос по диапазону дат/хранению/элементу, вы хотите, чтобы это было вашим ключом. Если это ваш ключ, ваши запросы будут быстрыми.

Я предлагаю вам сделать ваш ключ конкатенации диапазона дат + магазин + пункт вместе с некоторым разделителем, например:

20110103-PIZZAHUT-MEATLOVERS 
20110103-PIZZAHUT-VEGETABLE 
20110104-PIZZAHUT-MEATLOVERS 
20110105-DOMINOS-HAWAIIAN 

Затем хранить каждую проданную деталь в первой семью столбца в качестве (ID: прибыль) , ID здесь - это что-то вроде уникальной метки времени, UUID, идентификатора квитанции или чего-то еще.

Для первого запроса все, что вы делаете, это поиск ключевых слов в DATE-STORE-ITEM, а затем суммирование всех значений, которые вы извлекаете.

Для второго запроса выполните сканирование диапазона от 20110107-PIZZAHUT-! до 20110206-PIZZAHUT-~. Суммируйте предметы, которые вы ищете, и все предметы, которые вы не являетесь. В конце вычислите процент.

Answer 2

Подход, предложенный orangeoctopus, хранит одну строку в день, за каждое хранилище, за столбец для каждой транзакции. Этот подходит; другой подход заключается в том, чтобы хранить каждую транзакцию в своей собственной строке с теми же ключевыми полями плюс уникальный идентификатор как часть ключа. Затем в одном столбце есть один столбец для суммы.

20110103-PIZZAHUT-MEATLOVERS-857283394 
20110103-PIZZAHUT-MEATLOVERS-857283395 
20110103-PIZZAHUT-MEATLOVERS-857283396 
20110103-PIZZAHUT-VEGETABLE-859238494 
20110103-PIZZAHUT-VEGETABLE-859238494 

и т.д.

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

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

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