Схема умного дома AWS Dynamo (расположение / комнаты)

Question

Я пытаюсь создать масштабируемую инфраструктуру умного дома на AWS, используя iot core, lambda и DynamodB, а также серверную инфраструктуру и последующее приложение для Android / iOS.

Я реализую локации и комнаты в динамод. Пользователь может иметь много местоположений, а местоположения могут иметь много комнат. Я привык использовать Firebase Firestore, поэтому использование ключей разделения и ключей сортировки (хэш и диапазон?) И комбинация запроса немного сбивают с толку. Я реализовал свой собственный хеш для использования в качестве основного (раздел? Хэш?) Идентификатора. Вот структура, о которой я думаю:

Местоположение

• ID
• имя
• имя пользователя

Я также добавил дополнительный индекс в username, чтобы пользователь мог запрашивать все свои местоположения.

номер

• ID
• имя
• locationId

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

Вот код, в котором я создаю идентификаторы:

// need a unique hash for the id
let hash = event.name + event.username + new Date().getTime();

let id = crypto.createHash('md5').update(hash).digest('hex');
let location = {
    id: id,
    name: event.name,
    username: event.username
};

А для комнат:

// need a unique hash for the id
let hash = event.name + event.locationId + new Date().getTime();

Так как я довольно новичок в Dynamo / AWS, мне интересно, является ли это приемлемым решением. Очевидно, я бы остановился на этом, добавив несколько устройств под комнатами, связавшись через roomId. Я также хотел бы иметь возможность обмениваться устройствами, так что я не совсем уверен, как это будет работать, поскольку связь для пользователя на месте - поэтому я предполагаю, что мне придется поделиться местоположением, комнатой (комнатами) и устройством (с) (как я думаю, как это делает Google Home)

Любые предложения будут с благодарностью!

EDIT Вопросы, которые я могу придумать, будут такими:

• Получить местоположение по Id
• Получить все местоположения по пользователю
• Получить номер по Id
• Получить все номера по расположению

Однако, поскольку приложение будет расширяться в будущем, я бы хотел, чтобы эти запросы были гибкими (делиться местоположением, получать общие местоположения и т. Д.)

Answer 1

Я бы хотел, чтобы эти запросы были гибкими

Тогда noSQL в целом и Dynamo, в частности, могут быть неправильным выбором.

Как намекает @varnit, базы данных noSQL очень гибки в том, что вы храните, но очень гибки в том, как вы можете запрашивать эти данные.

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

Я не понимаю, что влечет за собой «общее местоположение».

Но с несколькими принципами в Динамо (каждый пользователь только смотрит на свои данные) проще было бы использовать userID в качестве ключа раздела (PK).

Я бы использовал составной ключ сортировки местоположения # комната

• Получить местоположение по идентификатору -> GetItem (PK = пользователь, SK = местоположение)
• Получить все местоположения по пользователю -> Запрос (PK = Пользователь)
• Получить все комнаты по местоположению -> Запрос (PK = Пользователь, SK начинается с Местоположения)

Этот немного хитрее ... - Получить номер по Id ->

Если вам действительно нужно получить комнату без местоположения, то вам нужно иметь комнату как отдельный атрибут в дополнение к тому, что она является частью ключа сортировки. Затем вы можете создать по нему локальный вторичный индекс и выполнить запрос (PK = Пользователь, Индекс SK = Комната)

Я подозреваю, что поиск комнаты через GetItem (PK = User, SK = location # room) может сработать вместо вас.

Ключевой момент, сравнение ключей разделения равно всегда равно. Там нет начала с, заканчивается или содержит для сравнения ключа раздела.

Если вы их не видели, посмотрите следующие видео
AWS re: Invent 2018: Сборка с базами данных AWS: сопоставьте рабочую нагрузку с нужной базой данных (DAT301)
AWS re: Invent 2018: глубокое погружение Amazon DynamoDB: расширенные шаблоны проектирования для DynamoDB (DAT401)

Также обязательно прочитайте Стратегии хранения SaaS - Построение модели хранения с несколькими арендаторами на техническом документе AWS .

EDIT
«местоположение» и «комната» могут быть самыми важными для вашего приложения. GUID или естественный ключ, такой как «Домой». В базе данных noSQL GUID полезны, когда записи добавляются несколькими узлами. Но естественный ключ хорош тогда, когда пользователю приложения будет удобно. Так как вы не хотите искать путеводитель по естественному ключу. Практики РСУБД не применяются к БД noSQL.

Так что да, я бы использовал "Дом" в качестве местоположения, а это означает, что пользователь не сможет иметь несколько "Дом". Но я не вижу в этом большого смысла, я бы использовал «Дом» и «Дом отдыха» в реальной жизни.

EDIT2
Динамо не волнует, если это GUID или естественный ключ. Он внутренне хэширует любое значение, которое вы используете для ключа раздела. Все, что имеет значение, это количество различных ценностей. Distinct отличается, не имеет значения, является ли значение '0ae4ad25-5551-46a7-8e39-64619645bd58' или 'charles.wilt@mydomain.com'. Если ваш процесс авторизации возвращает GUID, используйте его. В противном случае используйте имя пользователя.