Шаблон проектирования таблицы DynamoDB: данные с указанием времени

Question

В настоящее время я проектирую паттерн DynamoDB, я не знаю, нахожусь ли я на правильном пути или нет.

У меня есть следующие данные, которые мне нужно сохранить в таблицу DynamoDB:

• deviceID (число)
• deviceLogType (строка)
• отметка времени (число) // отметка времени указана в утц-секундах
• другие атрибуты misc

Основной запрос для этой таблицы DynamoDB - запрос данных по deviceID и deviceLogType за определенный промежуток времени.

Ключ раздела : deviceLogType_deviceID

Ключ сортировки : timestamp

Мои вопросы:

• Правильно ли приведенный выше дизайн?
• Лучше ли использовать составной ключ для ключа разделения для представления иерархических отношений?

Answer 1

Ваш подход будет работать для описанного вами варианта использования.

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

Я вижу только одну возможную проблему. Если у вас есть несколько записей журнала с одинаковыми deviceLogType_deviceID и timestamp, последняя перезапишет все предыдущие записи с одной и той же отметкой времени. Чтобы избежать этого, вы можете сохранить отметку времени в виде строки ISO 8601 и добавить UUID к концу отметки времени, чтобы предотвратить конфликты первичных ключей.

Answer 2

deviceLogType_deviceID (hash key)
timestamp (sort key)
deviceID (I would keep this separate for future query possibilities)
deviceLogType (I would keep this separate for future query possibilities)
other misc attributes

Используя эту схему, вы можете использовать свой текущий запрос и откроете будущие возможности для запросов только по deviceId или deviceLogType (только добавьте индекс).

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

Но, например, если у нас есть AndroidDeviceLogType> DeviceLogType, рекомендуется хранить это значение в deviceLogType в сериализованной форме (например, JSON в Base64 или просто в формате JSON ...).