Агрегирование данных в DynamoDB, которое соответствует нашему шаблону доступа - PullRequest
0 голосов
/ 11 февраля 2019

В настоящее время я пытаюсь объединить данные акселерометра, когда они загружаются в нашу таблицу динамо.Я хотел бы агрегировать в 5-минутных временных окнах для каждого пользователя и вставлять результат агрегирования в другую таблицу динамо.Поскольку я не очень хорошо разбираюсь в «Динамо» или «Лямбде», я надеюсь, что кто-то может направить меня в другом направлении, если я пропущу лучшие решения.

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

Итак, моя идея состоит в том, чтобы обрабатывать поток внутри лямбды, который запускается каждые 1000 записей, и делать так, чтобы он сохранял запись в новой таблице для каждого пользователя в течение каждого 5-минутного временного окна в течение дня,начиная с полуночи как времени 0. Запись будет вставлена, если для этого временного окна для пользователя не существует ни одной записи.Если запись существует, она будет обновлять агрегацию условно.

Таблица будет состоять из идентификатора пользователя, который является ключом раздела, в формате <\ company id> | <\ user id>, окнавремя начала (<\ date> 00:00, 00:05, 00:10 и т. д.), которое будет ключом сортировки, суммой данных, которые я собираю, и количеством записей, используемых для вычисления этогосумма и среднее значение.

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

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

Спасибо!

1 Ответ

0 голосов
/ 12 февраля 2019

Здесь есть несколько вещей, на которые стоит обратить внимание.

Я предполагаю, что это существенно сократит нашу емкость чтения и приведет к увеличению времени выполнения Lambda. Поток Dynamodb состоит из обоихстарые и новые данные, следовательно, вы не пойдете в dyanamodb для получения данных.Следовательно, нет необходимости в дополнительном потреблении емкости.

Для вышеуказанной проблемы у вас есть схема базы данных, подобная этой

|PK       |  SK             | timesegment    |
|mike     | event#12334     | 12330#12330    | some metadata about this event.
|mike     | event#12336     | 12335#12340    | some metadata about this event.
|mike     | metadata        |                | some metadata about mike completely optional
|tim      | event#12339     | 12335#12340    | some metadata about this event.

Где PK - идентификатор пользователя, SK - информация о строке.

СейчасЕсть две проблемы под рукой

  1. Где хранить агрегацию?

    Вы можете выбрать либо DynamoDB, либо CloudWatch в зависимости от того, что вам больше подходит.

  2. Как рассчитать агрегацию?

    Для запуска агрегации вам потребуется следующее

    1. Что изменили все пользователи за последние 5 минут (потому что, очевидно, мы несобираюсь сделать сканирование таблицы.)

      Есть несколько способов ответить на этот вопрос,

      a.Проведите GSI в 5-минутное время.Получить все PK из этой таблицы GSI, чтобы знать, что изменились все пользователи.Теперь вы можете перебирать всех пользователей для агрегирования их данных.

      Плюсы

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

      Минусы

      • GSI будет очень горячим, так как в течение 5-минутного интервала времени все записи будут идти только в один раздел.

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

      Pros

      • Не будет никакого горячего раздела.

      Минусы

      • Функцию воспроизведения будет нелегко реализовать.
  3. Какдля запуска агрегации

    Вместо того, чтобы иметь динамический поток, у вас может быть событие cloudwatch, запускающее лямбда-функцию, которая выполняет агрегацию, если вы видите, что лямбда-тайм-аут (агрегация занимает более 15 минут), вы можетесоздайте одну родительскую лямбда-функцию, которая просто вычисляет измененные PK и переводит их в SQS.затем есть лямбда-функция, подписанная на SQS, которая выполняет вычисления для каждого идентификатора пользователя

...