Хранение данных временных рядов разного разрешения в DynamoDB

Question

Мне интересно, знает ли кто-нибудь хороший способ хранения данных временных рядов с разным разрешением времени в DynamoDB.

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

Я хочу агрегировать эти данные за различные временные шаги (30 минут, 1 час, 1 день и т. Д.), Используя лямбду, и также сохранять агрегаты в DynamoDB. Затем я хочу иметь возможность получать любые данные разрешения за любой конкретный интервал времени, например, 48 30-минутных агрегатов за последние 24 часа или каждую ежедневную статистику за этот месяц прошлого года.

Я не уверен, должно ли каждое новое разрешение иметь свои собственные таблицы, data_30min, data_1hr и т. Д., Или если лучший подход был бы чем-то вроде создания составного ключа хеш-функции путем объединения разрешения с идентификатором устройства и сохранения всей совокупности данные в одной таблице.

Например, если идентификатор устройства равен abc123, все 30-минутные данные могут быть сохранены с помощью хэш-ключа abc123_30m, а данные за 1 час могут быть сохранены с помощью HK abc123_1h, и каждый из них будет по-прежнему использовать временную метку в качестве диапазона ключ.

Каковы некоторые плюсы и минусы каждого из этих подходов, и есть ли решение, о котором я не думаю, которое было бы полезно в этой ситуации?

Заранее спасибо.

Answer 1

Я не уверен, что вы видели эту страницу из технических документов, касающихся Be st Практики для хранения данных временных рядов в DynamoDB . В нем говорится о разделении ваших данных на периоды времени, так что у вас есть только одна «горячая» таблица, в которую вы пишете, и много «холодных» таблиц, из которых вы только читаете.

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

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

Вы также можете рассмотреть реляционную базу данных для «горячих» данных (т. Е. Последние 7 дней или любой другой период, который имеет смысл), а затем запустить пакетный процесс для предварительной агрегации и перемещения данных в холодные, доступные только для чтения Таблицы DynamoDB, с DAX и т. Д.