Хранение временных рядов в AWS DynamoDb

Ответ 1

Предполагая, что ваши данные неизменны и заданы размер, вы можете рассмотреть Amazon Redshift; он написан для решений для отчетности размером в петабайт.

В "Динамо" я могу подумать о нескольких жизнеспособных проектах. В первом случае вы можете использовать одну таблицу с составной клавишей хэша/диапазона (обе строки). Хеш-ключ будет именем временного ряда, ключ диапазона будет временной меткой как строка ISO8601 (которая обладает приятным свойством, что алфавитное упорядочение также является хронологическим порядком), и для каждого элемента будет дополнительный атрибут; ценность'. Это дает вам возможность выбрать все из временного ряда (Query on hashKey равенство) и подмножество временного ряда (Query on hashKey равенство и rangeKey BETWEEN). Однако главная проблема - проблема "горячих точек": внутренне Dynamo будет разбивать ваши данные на hashKey и рассеивает вашу ProvisionedReadCapacity по всем вашим разделам. Таким образом, вы можете иметь 1000 Кбайт чтения в секунду, но если у вас есть 100 разделов, то у вас есть только 10 КБ в секунду для каждого раздела, и чтение всех данных из одного временного ряда (один хэш-код) приведет только к одному разделу. Таким образом, вы можете думать, что ваши 1000 Кбайт чтения дают вам 1 МБ в секунду, но если у вас 10 МБ, это может занять гораздо больше времени, чтобы прочитать его, так как ваш один раздел будет более сильно дросселировать вас.

С другой стороны, DynamoDB имеет чрезвычайно высокую, но дорогостоящую верхнюю границу масштабирования; если вы хотите, чтобы вы могли заплатить за 100 000 единиц мощности чтения, а также время ответа на второе место для всех этих данных.

Еще один теоретический проект - хранить каждый временной ряд в отдельной таблице, но я не думаю, что DynamoDB предназначен для масштабирования до миллионов таблиц, поэтому это, вероятно, не-go.

Вы можете попробовать и разложить свои временные ряды на 10 таблицах, где данные "с высокой степенью чтения" приводятся в таблице 1, "почти никогда не читаемые данные" в таблице 10, а все остальные данные находятся где-то посередине. Это позволит вам "играть" в подготовленные правила управления пропускной способностью/разделением, но с высокой степенью сложности в вашем дизайне. В целом, это, вероятно, не стоит; где у вас новые временные ряды? Как вы помните, где они все? Как вы перемещаете временной ряд?

Я думаю, что DynamoDB поддерживает некоторые внутренние "разрывы" на этих типах чтения из моего собственного опыта, и, возможно, мои номера отключены, и вы получите адекватную производительность. Однако мой вердикт - посмотреть Redshift.

Ответ 2

Как насчет того, чтобы капать каждый временной ряд в JSON или аналогичный и хранить в S3. В лучшем случае вам понадобится найти откуда-то вроде Динамо.

Вам все еще может понадобиться красное смещение для обработки ваших входов.

Ответ 3

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

Для второго сервиса в такой настройке у вас есть много вариантов, включая:

• DynamoDB + Клей + S3 + Афина /Redshift
• DynamoDB + Hive/Spark
• DynamoDB + AWS Lambda + Elasticsearch
• DynamoDB + Rockset

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

(Полное раскрытие: я работаю в Rockset.)