HBase: что касается дизайна схемы

Я читал/изучал HBase и пытался создать схему. Я работаю с RDBMS, и это первый раз, когда я пытаюсь использовать nosql db. У меня простой вопрос о дизайне схемы:

Предположим, что есть три таблицы => альбом, фото, комментарий

  • альбом ‹= Создано пользователем

  • photo ‹= Содержит все фотографии, загруженные в альбом

  • комментарии ‹= Содержит комментарии к альбому или фотографии

    Фотография должна быть получена со всеми комментариями под ней. Альбом должен быть загружен со всеми фотографиями в нем, но не с комментариями.

пользователь идентифицируется по электронной почте. Схема, которую я придумал:

tbl_user

email || info: {password : ..., name : ...}

альбом

<email>:album:<timestamp> || info {title:..., cover: photo-row-key}

Фото

<album-row-key>:<timestamp> || info {caption:..., exif: ...}

комментарий

<album-row-key or photo-row-key> || comments {
    comment:<timestamp>: {user: <email>, text:...}
    comment:<timestamp>: {user: <email>, text:...}
    comment:<timestamp>: {user: <email>, text:...}
    ...
}
  • Этот дизайн выглядит нормально? Я просто хочу знать модификации, которые должны/должны быть сделаны и почему.
  • Должен ли ключ строки фото не предваряться ключом строки альбома (может быть, для экономии места)?
  • Что касается таблицы комментариев, следует ли создать ключ строки комментария, например <album-row-key or photo-row-key>:comment:<timestamp>? В соответствии с приведенной выше схемой всякий раз, когда пользователь создает комментарий, мне нужно прочитать столбец комментариев, обновить его новым комментарием и обновить строку с помощью tha. Звучит нормально?

Было бы очень полезно, если бы вы могли поделиться некоторыми ссылками, в которых есть примеры схем, которые больше подходят для СУБД :)


person Mayank    schedule 12.03.2013    source источник


Ответы (1)


Один из вариантов — поместить комментарии, фотографии и альбомы в одну таблицу. Также поместить фотографии и комментарии к фотографиям в одно семейство столбцов, а комментарии к альбомам — в другое семейство столбцов.

  • в строке альбома есть ключ email:album:0:0:timestamp в строке фото есть ключ
  • электронная почта: альбом: фото: 0: временная метка ключ строки комментария к фотографии
  • электронная почта:альбом:фото:комментарий:метка времени ключ строки комментария к альбому
  • электронная почта:альбом:комментарий:отметка времени

Затем вы можете получить данные в одном доступе в зависимости от ваших потребностей. например.:

  • Одно сканирование по префиксу дает вам альбом со всеми фотографиями и всеми их комментариями
  • Одно сканирование по префиксу и последнему ключу даст вам альбом со всеми его фотографиями, но без комментариев
  • Одно сканирование по электронной почте: альбом для второго семейства столбцов даст вам альбом со всеми его комментариями.
  • Одно сканирование по префиксу email:album:photo даст вам фото со всеми его комментариями
  • одно сканирование по электронной почте: альбом со всеми семействами столбцов даст вам все данные
  • сканировать по электронной почте с ключом конца по альбому.max: даст вам все альбомы для пользователя
  • и Т. Д.
person Arnon Rotem-Gal-Oz    schedule 12.03.2013
comment
Спасибо Арнон. Это имеет смысл :). Что, если я добавлю столбец голосов/репутации к каждому из альбомов, фотографий и комментариев? Для этого нужен новый ключ, например email:album:photo:comment:vote:timestamp. Можно ли предоставить такой длинный ключ? - person Mayank; 14.03.2013
comment
И почему подход с несколькими таблицами может быть плохим (или хорошим) по сравнению с одной таблицей с точки зрения производительности? Просто любопытно... - person Mayank; 14.03.2013
comment
Что касается голосов - это действительно зависит от того, как вы хотите их использовать. Интуитивно я бы указал количество голосов как приращение (archive.cloudera.com/cdh4/cdh/4/hbase/apidocs/org/apache/hadoop/), поэтому он содержит общее количество. а сами голоса вынести в отдельную таблицу. Что подводит нас к вашему второму вопросу :). Размещение вещей в таблицах связано с шаблонами доступа. единственная таблица, которую я предложил выше, позволяет вам выполнить одно сканирование и получить всю необходимую информацию. Относительно голосов - подсчет будет в одном вызове, а затем развертка может быть в другой таблице. - person Arnon Rotem-Gal-Oz; 16.03.2013