Блог

Базы данных NoSQL, такие как DynamoDB, — сложная вещь, потому что они не предлагают те же «шаблоны» запросов, что и традиционные реляционные базы данных.

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

Моим предложением для одного такого решения было бы использовать функцию DynamoDB, называемую потоками DynamoDB.

Короче говоря, потоки DynamoDB будут запускаться каждый раз, когда элемент в вашей таблице создается, изменяется или удаляется. Затем потоки отправят новую (и старую) версию этого элемента указанному вами «получателю». Обычно это будет лямбда-функция.

Решение, которое я бы предложил, — использовать потоки для отправки новых элементов в лямбда. Затем этот лямбда-выражение может считывать атрибуты элемента, которые не являются пустыми, и записывать их в любое хранилище данных, которое вам нравится. Может быть другая таблица DynamoDB, может быть S3 или что угодно еще, что вам нравится. Очевидно, что лямбда-выражение должно обязательно перезаписать предыдущие значения и т.д., Но подробная бизнес-логика зависит от вас.

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

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

Наконец, я хочу упомянуть, что рекомендуется иметь не более двух «получателей» потока таблиц. Это означает, что для производства я бы рекомендовал иметь только один приемник Lambda, а затем позволить этому Lambda создать событие AWS EventBridge (например, «элемент создан», «элемент изменен», «элемент удален»). Это позволит вам иметь намного больше лямбд и т.д. «прослушивание» таких событий и их обработка, смягчение ограничения потоков. Тогда это решение, основанное на событиях. Как и раньше, это добавит задержки.