Как реализовать простую таблицу DynamodB с ежедневным значением

Question

Я изучаю AWS API Gateway + Lambda + Dynamodb, создав очень простой API-проект.

У меня ежедневная стоимость, начиная с 2013-01-01, и я постоянно обновляюсь, так что в основном это нечтокак:

[
    {
        "value": 1776.09,
        "date": "2013-01-01"
    },
    {
        "value": 1779.25,
        "date": "2013-01-02"
    },
    // ...
    {
        "value": 2697.32,
        "date": "2018-11-22"
    }
]

В API я хочу получить данные за определенный день и за диапазон (dateFrom - dateTo), и я читал о Dynamodb и планирую иметь date какключ разделения в формате YYYY-MM-DD и без ключа сортировки, но не уверен, что это правильный подход для этого типа данных и запроса диапазона, который я собираюсь выполнить, поскольку я предполагаю, что мне придется выполнить полныйСканирование таблицы для запроса диапазона, хотя это небольшой набор данных.

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

Answer 1

Копирование моего ответа из этого поста

Несколько концепций записи NOSQLdb

1. должны быть одинаково распределены по первичным ключам.
2. чтение должно быть в равной степени распределено по первичным ключам.

Очевидная вещь, которая приходит на ум при рассмотрении данной проблемы и схемы dyanamodb:

имеет ключ logs в качестве первичного ключа и timestamp как вторичный ключ.Для агрегации используйте

select * where pk=logs and sk is_between x and y

, но это нарушит обе концепции.Мы всегда пишем на одном ПК и всегда читаем с одного и того же.

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

нам нужно будет сделать некоторые предположения о приложении при разработке ключей.скажем, мы решили, что мы будем обновлять каждый час.следовательно, может иметь 7 января 2018-17 в качестве ключа.где 17 означает 17-й час.этот ключ является детерминированным, но он не является достаточно случайным.и каждое обновление или чтение 7 января будет происходить в основном в одном разделе.Чтобы сделать ключ случайным, мы можем вычислить его хеш, используя алгоритм хеширования, такой как md5.скажем, после взятия хэша наш ключ становится 1sdc23sjdnsd.Это не имеет никакого смысла, если вы смотрите на данные таблицы.Но если вы хотите узнать количество событий 7 января 2018-17 гг., Вы просто хешируете время и извлекаете данные из DynamodB с помощью хеш-ключа.если вы хотите знать все события 7 января 2018 года, вы можете повторить 24 получения и агрегировать счет.

Теперь у схем такого типа будут проблемы, при которых

1. Если вы решите переходить с почасовой на минутную ставку.

2. Если большинство ваших запросов выполняются во время выполнения, как, пожалуйста, получите все данные за последние 2,4,6 дня.Это будет означать слишком много поездок туда и обратно в БД.И это будет не только по времени, но и по затратам.

Эмпирическое правило равно , если шаблоны запросов четко определены, используйте NOSQL и сохраняйте результаты по соображениям производительности.Если вы пытаетесь выполнить запросы на объединение или агрегацию в nosql, это принудительно подгоняет ваш вариант использования на основе вашего выбора технологии.

Вы также можете посмотреть aws рекомендацию храненияданные временного ряда.

Answer 2

То, что вы предлагаете, будет работать.

Однако, если вы хотите повысить эффективность проекта, вы можете использовать ключ раздела YYYY, и тогда ваш ключ сортировки может быть MM-DD.Таким образом, вы можете использовать операцию запроса, чтобы ограничить результаты (или вы все равно можете использовать сканирование).

Вы можете даже использовать одно постоянное значение для ключа раздела и date в качестве ключа сортировки, но использование одного и того же ключа разделения для каждого элемента обычно не рекомендуется.

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