Когда я должен использовать автоматическое масштабирование и когда использовать SQS? - PullRequest
0 голосов
/ 16 октября 2019

Я изучал DynamoDb, где застрял в вопросе, для которого я не могу найти какое-либо общее решение.

Мой вопрос: если у меня есть приложение с динамодабом в качестве базы данных с начальной емкостью записи 100 записей в секунду и большой нагрузкой в ​​часы пик, предположим, 300 записей в секунду. Для того, чтобы уменьшить нагрузку на БД, какой сервис я должен использовать?

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

Ответы [ 2 ]

3 голосов
/ 17 октября 2019

В прежние времена, до автоматического масштабирования DynamoDB, шаблон обычного использования был:

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

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

В настоящее время DynamoDB может использовать адаптивную емкость и пакетную емкость для обработки временных изменений. Для более крупных изменений вы можете реализовать DynamoDB Auto Scaling , что, вероятно, проще в реализации, чем метод SQS.

0 голосов
/ 17 октября 2019

Лучшее решение зависит от характеристик вашего приложения. Может ли он терпеть асинхронные записи в базу данных? Может ли он выдержать любое удушение при записи в базу данных?

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

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

Если у вас должны быть синхронные записи, и вы не можете допустить никакого регулирования от DynamoDB, вы должны использовать режим DynamoDB по требованию. (Тем не менее, обратите внимание, что может возникнуть ограничение, если вы превысите 1 КБ или 3 КБ для одного ключа раздела.)

Конечно, стоимость также учитывается. Использование DynamoDB с автоматическим масштабированием будет наиболее экономически эффективным методом. Я не уверен, как On Demand сравнивается со стоимостью использования SQS.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...