Справка по схеме HBase

Question

Исходя из опыта работы с SQL Server, я новичок в отношении HBase, но технология, похоже, хорошо подходит для того, что мы делаем, и цена определенно правильная!

Мне нужно вести список записей журнала, которые обычно я создаю в RDBS, как:

создать таблицу журнала ( UserID int, SiteID int, Page varchar (50), Date smalldatetime )

где один пользователь может иметь 0 или 1000 строк в этой простой таблице. Типичные запросы - найти все строки для одного пользователя или все строки для одного пользователя на одном сайте.

Как это переводится в «карту» в HBase, где нет «ключа строки» И то же самое (SiteID, Page) может появляться много раз. Сначала я подумал, что UserID - это ключ строки, но я до сих пор не понимаю «семейства столбцов» и другую терминологию достаточно хорошо, чтобы понять, как настроить таблицу для хранения этих данных, где один UserID может иметь много (SiteID, Page Дата) "строки".

Любое направление ценится!

Answer 1

Я бы предложил указать UserId в качестве Rowkey. Если любое семейство из одного столбца не будет содержать семейство из нескольких столбцов, это только увеличит время поиска и даст siteId | date в качестве квалификатора столбца, чтобы он всегда был уникальным, и значением этого квалификатора будет ваша страница .

RowKey Qualifier                       Value

001    C:site001|25/01/2013:6:17:17    www.example123.com/home
001    C:site001|25/01/2013:6:17:18    www.example123.com/about
001    C:site002|25/01/2013:6:30:17    www.example1123.com/
001    C:site003|25/01/2013:6:32:18    www.example1123.com/contact
002    C:site001|25/01/2013:2:22:17    www.example123.com/home
003    C:site001|25/01/2013:3:12:18    www.example123.com/about
003    C:site003|25/01/2013:5:30:17    www.example1223.com/
003    C:site004|25/01/2013:6:32:18    www.exampleABC.com/contact

`

надеюсь, что это работает!

Answer 2

Изначально просто посмотрите на это как

• RowKey: квалификатор: значение,

для представления - 12_Aug_2013_00: 00 : * - Temp = 24, - Влажность = 15, - FileghtsDelayed = 17

• RowKey: квалификатор: значение,
• 12_Aug_2013_00: 00 : Temp: 24
• 12_Aug_2013_00: 00 : Влажность: 15

---

Теперь посмотрим немного глубже. Что если мы сможем сгруппировать классификаторы в семейство столбцов.

Например:

• позволяет группировать, Tempuration, Humidity, AirPresure as WeatherDetails

• Позволяет группе, группе * No_FileghtsDelayed *, * No_FlightsCancelled *, as eventsConts

• У нас есть WeatherDetails & eventsConts, как семейства столбцов

У нас есть - Date_Hour: WeatherDetails: EventDetails: например, для 12_Auguest_2013 FirstHour записанные данные могут быть представлены как

• 12_Aug_2013_00: 00 : WeatherDetails - Temp = 24, WeatherDetails - Влажность = 15, eventsConts - FileghtsDelayed = 17

Эта группировка предназначена для оптимизации операции выборки.

Answer 3

Один из подходов - сделать составные ключи строк из вашего идентификатора пользователя + siteid

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

Поскольку HBase поддерживает временные метки для каждой ячейки, вам не нужен отдельный столбец для времени доступа.

Таким образом, у вас будет таблица с содержимым, похожим на

Row             Page

user1:site1     www.example.com/index.html@1234567890
                www.example.com/somepage.html@123456800
                www.example.com/someotherpage.html@123456900
                www.example.com/index.html@123457123

user1:site2     blahblah

user2:site1     etc...

Чтобы обработать ваши два примера запросов:

Для поиска всех пользовательских строк вы должны выполнить сканирование (не забудьте установить maxVersion) от userx: 0 до userx + 1: 0, а затем проанализировать идентификаторы сайтов из каждой строки результатов

Чтобы получить все страницы для определенного пользователя / сайта, просто выполните сканирование от userx: sitex до userx: sitex + 1. В последний раз я проверял, что нельзя установить maxVersions для get, так что это не вариант.

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

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

Чтобы лучше понять внутренности HBase, Блог Ларса Джорджа также великолепен.