DynamoDB - Дизайн 1 ко многим

Question

Я новичок в технологиях DynamoDB, но не в NoSQL (я уже сделал какой-то проект с использованием Firebase).

Прочитайте, что лучшая практика DynamoDB - это одна таблица на приложение. У меня были трудности с тем, как спроектировать мои отношения от 1 до N.

У меня есть эта сущность (псевдо-JSON):

{
   machineId: 'HASH_ID'
   machineConfig: /* a lot of fields */
}

A machineConfig уникален для каждой машины и может изменяться редко и только администрацией (здесь нет проблем согласованности).

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

{
  machineId: 'HASH_ID',
  sensorsData: [
    /* Huge list of: */
    { timestamp: ..., data: /* lot of fields */ },
    ...
  ]
}

Я хочу держать свой machineConfig в одном месте. Невозможно вставить список журнала в объект машины, потому что это непрерывный поток данных, взятых с течением времени.

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

Как спроектировать эту взаимосвязь с учетом потенциальных измерений данных?

Answer 1

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

Для хранения machineConfig вы должны вставить элемент с первичным ключом (machineId, "CONFIG"). Атрибут sortKey будет иметь постоянное значение CONFIG.

Для хранения sensorsData вы можете использовать timestamp в качестве значения sortKey. Вы должны вставить новый элемент для каждого элемента данных датчика. Вы должны хранить timestamp в виде строки (как время с начала эпохи, ISO8601 и т. Д.)

Затем, чтобы запросить все о машине, вы должны выполнить запрос Dynamo, указав только ключ раздела machineId - это вернет много элементов, включая machineConfig и данные датчика.

Чтобы запросить только machineConfig, вы должны выполнить запрос Dynamo, указав ключ machineId и константу CONFIG в качестве значения sortKey

Для запроса данных датчика вы можете указать точную метку времени или диапазон меток времени для sortKey. Если вам нужно запросить данные датчика по другим значениям, этот дизайн может не сработать.

Редактирование для ответа на следующий вопрос:

Вам придется прибегнуть к сканированию с фильтром, чтобы вернуть все машины с их machineId и machineConfig. Если вы в конечном итоге вставите много данных с датчиков, то это будет очень дорогая операция, так как «Динамо» будет смотреть на каждый элемент в таблице. Если вам нужно сделать это, у вас есть несколько вариантов.

Если машин не так много, вы можете вставить элемент с первичным ключом, таким как ("MACHINES", "ALL") и список всех machineIds. Вы запросили бы этот ключ, чтобы получить список machineIds, а затем выполнили бы кучу запросов (или пакетное получение), чтобы получить все связанные machineConfigs. Однако, поскольку максимальный размер предмета «Динамо» составляет 400 КБ, вы не сможете вместить их всех

Если в одном элементе слишком много машин, вы можете немного изменить вышеприведенный подход и иметь ("MACHINES", $machineIdSubstring) в качестве первичного ключа и хранить фрагменты machineIds под каждым ключом сортировки. Например, все machineIds, начинающиеся с 0, входят в ("MACHINES", "0"). Затем вы будете запрашивать по каждому первичному ключу 0-9, составлять список всех machineIds и запрашивать каждую машину, как указано выше.

В качестве альтернативы, вам не нужно помещать все в 1 таблицу - это просто руководство, которое подходит для многих случаев использования. Если существует слишком много машин, чтобы уместить их менее 400 КБ, но их нет десятков тысяч, и вы не пытаетесь все время запрашивать их все, у вас может быть отдельная таблица machineId и machineConfig, которая Вы прибегаете к сканированию при необходимости.