Какой сервис имеет меньшее время отклика? SQS против DynamoDB

Question

Ну, я недавно создал безсерверное приложение, используя AWS Lambda.Мой текущий поток приложений выглядит следующим образом:

API Gateway (1) → Lambda Function (2) → SQS (3) → Lambda Function (4) → DynamoDB (5)

Теперь есть несколько соображений:

1. Клиент собирается отправить запрос в мой API(1).
2. К событию API прикреплена лямбда-функция (2), поэтому она будет получать запрос API и обрабатывать его.
3. Теперь вот, где вопрос входит.После обработки запроса результат этой обработки ДОЛЖЕН быть вставлен в DynamoDB (5).В настоящее время я отправляю его в SQS (3) и возвращаю ответ на HTTP-запрос, отправленный клиентом.
4. Хотя запрос завершен и получен ответ, сообщения SQS (3) будут извлечены по событиюдругой лямбда-функцией (4), которая собирается вставить обработанное сообщение в DynamoDB (5).

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

Наконец, вопрос: , какое из действий быстрее?Отправка обработанного запроса в SQS или непосредственно в DynamoDB?

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

Если ответ на этот вопрос:

• Вставка непосредственно в DynamoDB происходит быстрее
• Вставка непосредственно в DynamoDB не быстрее, но разница незначительна

Я могу удалить как SQS (3), так и вторую лямбда-функцию (4), что приведет к более простой и более сложнойпрямой поток.

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

Answer 1

Вы спрашиваете, дешевле ли SQS, чем DynamoDB, но в своем потоке вы используете оба ... конечно, дешевле будет просто сделать API Gateway (1) → Lambda Function (2) → DynamoDB (3).

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

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

Answer 2

+ 1 к ответам Дейва и цементного блока.

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

Если вам необходимо строго соблюдать асинхронную обработку, т. Е. Отделить обработку запроса от ответа, тогда придерживайтесь своего решения на основе SQS.

Если задержка обработки запроса является постоянной и приемлемой для потребителей конечной точки API, то я бы порекомендовал решение, которое Diev рекомендовал обработать запрос, сохранить в DynamoDB и вернуть ответ клиенту. В качестве бонуса вы получите меньший счет AWS (как указано выше).

DynamoDB предназначен для обеспечения "согласованной" задержки P99 (то есть, 99-го процентиля) <10 мс для операций чтения одного элемента и <20 мс для записи одного элемента. </p>

Надеюсь, это поможет!

Answer 3

Если вы сохраняете соединение открытым между вызовами, я видел время отклика DynamoDB ниже 10 мс.У меня нет данных о задержке SQS.

Что касается стоимости, вы, по сути, удваиваете свою стоимость лямбды и добавляете любую стоимость SQS.SQS стоит примерно на 33% дороже, чем DynamoDB, если вы используете записи по требованию.