哪项服务的响应时间较短？ SQS与DynamoDB

Question

好吧，我之前使用AWS Lambda构建了一个无服务器应用程序。我当前的申请流程如下：

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

现在，有一些注意事项：

1. 客户端将向我的API发送请求（1）。
2. API事件附加了一个lambda函数（2），因此它将接收API请求并对其进行处理。
3. 现在，在这里输入问题。处理完请求后，此处理的结果必须插入DynamoDB（5）。目前，我将其发送到SQS（3），并返回客户端发送的HTTP请求的响应。
4. 尽管请求已完成并得到响应，但SQS（3）消息将由另一个lambda函数（4）进行事件拉动，该函数将在DynamoDB（5）上插入已处理的消息。

当我第一次对该流程进行原型设计时，我有一个假设：向SQS发送消息比在DynamoDB上插入消息要快。但是，我从来没有做过真正的基准测试或类似的事情，所以我的假设只是武断。

最后一个问题是：哪个动作更快？将处理后的请求发送SQS还是直接发送到DynamoDB？

考虑到，在两种情况下，都将在lambda函数（2）中执行它，因此，从理论上讲，由于它与AWS本身处于同一上下文中，因此它与请求它的响应时间不会相同来自其他机器。

如果该问题的答案是：

• 直接在DynamoDB上插入会更快
• 直接在DynamoDB上插入并不快，但差异可以忽略不计

我可以同时删除SQS（3）和第二个lambda函数（4），从而使流程更简单，更直接。

但是，如果通过先发送到SQS来增加响应时间，我可以保留此流程。

Answer 1

如果在两次调用之间保持连接打开状态，则我看到DynamoDB响应时间低于10毫秒。我没有有关SQS延迟的数据。

关于成本，您基本上是将lambda成本加倍，并加上任何SQS会增加您的成本。如果您使用按需写入，则SQS的成本比DynamoDB高约33％。

Answer 2

您正在问SQS是否比DynamoDB便宜，但是在您的流程中，您同时使用这两种方法……只做API Gateway (1) → Lambda Function (2) → DynamoDB (3)当然会便宜。

在性能方面，DynamoDB以快速执行小而频繁的写入而著称，因此我对此不必担心。

SQS与DynamoDB响应时间之间的差异应该非常相似，除非未正确配置DynamoDB容量，在这种情况下，您可能会遇到节气门问题。如果您不关心配置的容量，那么我建议您使用Lambda函数内部的计时器（或使用AWS x-ray）测试SQS和DynamoDB，并确定性能差异是否值得添加SQS和额外的Lambda函数

Answer 3

+1对Deiv's和水泥块反应。

让我分享以下其他观点，以帮助您改进建议的设计。

如果您需要严格遵守异步处理，即将请求处理与响应分离，那么请坚持使用基于SQS的解决方案。

如果请求处理延迟是一致的，并且对于API终结点的使用者来说是可接受的，那么我将建议Diev建议的解决方案，用于处理请求，坚持使用DynamoDB并将响应返回给客户端。作为奖励，您将有较低的AWS账单（如上所述）。

DynamoDB旨在提供“一致”的P99（即第99个百分位数）延迟，对于单个项目读取，该延迟为<10毫秒，对于单个项目写入，为<20毫秒。

希望这会有所帮助！