Как масштабировать обработку записей DynamoDB? - PullRequest
Новая
       13

Как масштабировать обработку записей DynamoDB?

3 голосов
/ 30 апреля 2020

Я создаю веб-сервис CRON, используя DynamoDB и Lambda. Хотя в настоящее время у меня нет следующей проблемы, мне интересно, как бы я мог ее решить, если она возникнет.

Архитектура работает следующим образом:

  1. Lambda A - запрос для всех задач, которые должны произойти в текущую минуту
  2. Лямбда A - для каждой задачи увеличьте счетчик в документе
  3. Лямбда B - прослушайте потоковое событие для каждого документа и выполните фактическое Задача CRON

Насколько я могу судить, Lambda B должна быть масштабируемой - AWS должно запускать столько экземпляров, сколько необходимо для обработки всех событий потока (я думаю).

Но для Lambda A, скажем, у меня есть 1 миллиард документов, которые нужно обрабатывать каждую минуту.

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

Как мне спроектировать систему так, чтобы все документы обрабатывались за <60 секунд? </p>

Ответы [ 2 ]

2 голосов
/ 05 мая 2020

Вы правы, Lambda A должен был бы выполнить сканирование / запрос монстров, который не масштабировался бы.

Один из способов сделать это, чтобы разделить элементы cron так, чтобы вы могли может вызывать несколько лямбд параллельно (то есть разветвлять работу) вместо одной (лямбда-А), чтобы каждый обрабатывал раздел (или набор разделов) вместо всего.

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

cronID | rangeKey               | jobInfo | counter
1001   | 72_2020-05-05T13:58:00 | foo     | 4
1002   | 99_2020-05-05T14:05:00 | bar     | 42
1003   | 01_2020-05-05T14:05:00 | baz     | 0
1004   | 13_2020-05-05T14:10:00 | blah    | 2
1005   | 42_2020-05-05T13:25:00 | 42      | 99

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

В этом примере вы можете вызывать 100 лямбда-сообщений каждую минуту (типы «лямбда-А»), каждый из которых обрабатывает один набор префиксов. Или вы могли бы сказать, 5 лямбда, каждый из которых обрабатывает диапазон 20 префиксов. Вы можете даже динамически масштабировать количество лямбда-вызовов вверх и вниз в зависимости от нагрузки, без необходимости обновлять префиксы в ваших данных в таблице.

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

РЕДАКТИРОВАТЬ

Повторное ограничение страницы в 1 МБ в вашем комментарии, вы получите LastEvaluatedKey назад, если ваш запрос был ограничен. Ваша лямбда может выполнять запросы в al oop, передавая значение LastEvaluatedKey обратно как ExclusiveStartKey до тех пор, пока вы не получите все страницы результатов.

Вы все равно должны быть осторожны во время выполнения ( и перехват ошибок для повторения, так как это не атомы c), но раздувание ваших лямбд, как указано выше, будет влиять на время работы, если вы размахиваете достаточно широко.

0 голосов
/ 04 мая 2020

Я не уверен в вашем проекте, но похоже, что то, что вы спрашиваете, уже есть в документации AWS DynamoDb , читайте здесь:

Когда вы создаете Новая подготовленная таблица в Amazon DynamoDB, вы должны указать ее подготовленную пропускную способность. Это количество операций чтения и записи, которые может поддерживать таблица. DynamoDB использует эту информацию для резервирования достаточных системных ресурсов для удовлетворения ваших требований к пропускной способности.

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

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

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

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

Надеюсь, это поможет вам усомниться.

...