DynamoDB: Как распределить рабочую нагрузку за месяц?

TL; DR

У меня есть таблица с около 2 миллионами WRITEs через месяц и 0 READ. Каждый 1-й день месяца мне нужно прочитать все строки, написанные в предыдущем месяце, и генерировать статистику CSV +.

Как работать с DynamoDB в этом сценарии? Как выбрать пропускную способность READ?

Длинное описание

У меня есть приложение, которое регистрирует запросы клиентов. В нем около 200 клиентов. Клиенты должны получать каждый 1-й день месяца CSV со всеми запросами, которые они сделали. Они также должны быть выставлены на счет, и для этого нам нужно рассчитать некоторую статистику с запросами, которые они сделали, группируя по типу запроса.

Итак, в конце месяца клиент получает отчет, например:

Я уже пришел к двум решениям, но я все еще не убежден ни в одном из них.

1-е решение: нормально, каждый последний день месяца я увеличиваю пропускную способность READ, а затем запускаю работу по сокращению карты. Когда работа выполнена, я уменьшаю емкость до исходного значения.

Против: не полностью автоматизирован, риск того, что емкость DynamoDB недоступна при запуске задания.

2-е решение: Я могу разбить генерацию CSV + статистики на небольшие задания в ежедневной или почасовой рутине. Я мог хранить частичные CSV на S3, и каждый 1-й день месяца я мог бы присоединиться к этим файлам и создать новый. Статистика будет намного проще генерировать, просто некоторые вычисления производятся из ежедневной/часовой статистики.

Против. Я чувствую, что превращаю что-то просто в нечто сложное.

У вас есть лучшее решение? Если нет, какое решение вы бы выбрали? Почему?

Ответ 1

Будучи в подобном месте раньше, я использовал и теперь рекомендую вам обработать необработанные данные:

так часто, как вы разумно можете (начинайте с ежедневного)
в формат как можно ближе к желаемому выходному отчету
с максимально возможной вычислительной нагрузкой/интенсивной работой процессора

оставляя как можно меньше времени отчета.

Этот подход полностью масштабируется - инкрементная частота может быть:

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

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

В моем примере я ежедневно отправлял денормализованные, предварительно обработанные (финансовые расчеты) данные в хранилище данных, а затем сообщал, что речь шла о очень базовом (и быстром) SQL-запросе.

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

Ответ 2

Я бы использовал сервис kinesis для ежедневного и почти реального выставления счетов. для этой цели я бы создал специальную таблицу DynamoDB только для рассчитанных данных. (другой вариант - запустить его на плоских файлах) то я бы добавил процесс, который будет отправлять события в службу кинезиса сразу после обновления обычной таблицы DynamoDB.

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

Я надеюсь, что это поможет.

Ответ 3

Взгляните на Динамический DynamoDB. Он будет увеличивать/уменьшать пропускную способность, когда вам это нужно, без ручного вмешательства. Хорошей новостью является то, что вам не нужно будет менять способ выполнения задания на экспорт.