AWS DynamoDB 与 RDS for Lambda 无服务器架构
AWS DynamoDB vs RDS for Lambda serverless architecture
我所在的团队目前正在为政府办公室和 public 之间的通信服务开发概念验证 architecture/application（目前缩小到 health-sector）。客户特别要求通过 AWS 服务采用主要无服务器的方法，我需要有关如何设置此架构的建议，即 Lambda 与数据库的关系。
粗略地说，该架构将使用 API 网关来处理请求，这将调用不同的 Lambda，如 micro-services，以访问数据库。
下图描述了一个快速关系架构。基本上，患者输入其状况的描述，这构成了案例的基础。该病例由一名或多名护士在一个或多个会议期间处理，这些护士记录与病例相关的笔记。 DB Schema (not enough reputation)
根据我的研究，我发现在 RDS 的情况下，安全性之间存在 trade-off（将 Lambdas 置于包含 RDS 实例的 public VPC 之外，放弃安全性best-practices，public 扇区的 no-no）和性能（将 Lambda 放在具有 RDS 实例的私有 VPC 中，并且由于提供 ENI 而导致大量 cold-start 次).然而，cold-start 时间可以通过使用 CloudWatch 对它们执行 ping 操作来取消，这可能是也可能不是最佳的。
在 DynamoDB 方面，我个人非常缺乏经验（比 MySQL 更缺乏经验）并且不确定数据是否适用于 NoSQL 模型。如果是，DynamoDB 似乎是更好的方法。不过根据我的理解，NoSQL 对涉及 JOIN 等的复杂查询的支持较少，这可能会将其作为一个选项消除。
感觉 SQL/RDS 比 data/relations 更合适，但如果找到合适的数据模型，DynamoDB 对 Lambda/AWS 服务的问题会更少。所以我的问题是，是否最好选择私有 RDS 实例并尝试通过预热最关键的 Lambda 来否定 cold-starts，或者是否有一个 NoSQL 模型不会引起复杂查询的麻烦， 除其他事项外？我是否遗漏了任何可以扭转局面的关键方面？
让我们首先澄清您的一些相当严重的误解：
From my research, I've gathered that in the case of RDS, there is a trade-off between security (keeping the Lambdas outside of a public RDS instance, foregoing security best-practices, a no-no for public sector) and performance (putting the Lambda in a private RDS instance, and incurring heavy cold-start times). The cold-start times can however be negated by pinging them with CloudWatch, which may or may not be optimal
- RDS 是一个数据库服务器。您不 运行 里面或外面的任何东西。
- 您可能会想到 VPC，即虚拟私有云。这是一个隔离网络，您可以在其中 运行 您的 RDS 实例和 Lambda。
- 运行 VPC 内部或外部对冷启动时间没有影响。当 AWS 必须为 运行 您的 Lambda 启动一个新容器时，您需要支付冷启动罚款。发生这种情况可能是因为它最近没有 运行ning，或者因为它需要扩展以满足并发请求。实际的冷启动时间将取决于您的语言：Java 比 Python 慢得多，例如，因为它需要在执行任何操作之前启动 JVM 并加载 类。
现在回答你的实际问题
Basically, a Patient inputs a description of his Condition which forms the basis for a Case. That Case is handled during one or many Sessions by one or many Nurses that take Notes related to the Case.
这可以在 NoSQL 数据库（例如 DynamoDB）中实现。如果没有更多信息，我可能会将会话作为基本文档，使用案例 ID 作为分区键，使用会话 ID 作为排序键。如果您不理解这些术语的含义，以及您将如何基于该键构建文档，那么您可能不应该使用 DynamoDB。
不使用 DynamoDB 的一个更大原因与访问模式有关。您是否想查找给定护士处理的所有病例？或者与特定患者有关？这些类型的查询是关系数据库的设计目的。
the case of DynamoDB, I am personally very inexperienced (more so than in MySQL)
您的团队中是否有人熟悉 NoSQL 数据库？如果不是，那么我认为您应该坚持使用 MySQL。学习如何使用 Lambda 将面临足够多的挑战。
我所在的团队目前正在为政府办公室和 public 之间的通信服务开发概念验证 architecture/application（目前缩小到 health-sector）。客户特别要求通过 AWS 服务采用主要无服务器的方法，我需要有关如何设置此架构的建议，即 Lambda 与数据库的关系。
粗略地说，该架构将使用 API 网关来处理请求，这将调用不同的 Lambda，如 micro-services，以访问数据库。
下图描述了一个快速关系架构。基本上，患者输入其状况的描述，这构成了案例的基础。该病例由一名或多名护士在一个或多个会议期间处理，这些护士记录与病例相关的笔记。 DB Schema (not enough reputation)
根据我的研究，我发现在 RDS 的情况下，安全性之间存在 trade-off（将 Lambdas 置于包含 RDS 实例的 public VPC 之外，放弃安全性best-practices，public 扇区的 no-no）和性能（将 Lambda 放在具有 RDS 实例的私有 VPC 中，并且由于提供 ENI 而导致大量 cold-start 次).然而，cold-start 时间可以通过使用 CloudWatch 对它们执行 ping 操作来取消，这可能是也可能不是最佳的。
在 DynamoDB 方面，我个人非常缺乏经验（比 MySQL 更缺乏经验）并且不确定数据是否适用于 NoSQL 模型。如果是，DynamoDB 似乎是更好的方法。不过根据我的理解，NoSQL 对涉及 JOIN 等的复杂查询的支持较少，这可能会将其作为一个选项消除。
感觉 SQL/RDS 比 data/relations 更合适，但如果找到合适的数据模型，DynamoDB 对 Lambda/AWS 服务的问题会更少。所以我的问题是，是否最好选择私有 RDS 实例并尝试通过预热最关键的 Lambda 来否定 cold-starts，或者是否有一个 NoSQL 模型不会引起复杂查询的麻烦， 除其他事项外？我是否遗漏了任何可以扭转局面的关键方面？
让我们首先澄清您的一些相当严重的误解：
From my research, I've gathered that in the case of RDS, there is a trade-off between security (keeping the Lambdas outside of a public RDS instance, foregoing security best-practices, a no-no for public sector) and performance (putting the Lambda in a private RDS instance, and incurring heavy cold-start times). The cold-start times can however be negated by pinging them with CloudWatch, which may or may not be optimal
- RDS 是一个数据库服务器。您不 运行 里面或外面的任何东西。
- 您可能会想到 VPC，即虚拟私有云。这是一个隔离网络，您可以在其中 运行 您的 RDS 实例和 Lambda。
- 运行 VPC 内部或外部对冷启动时间没有影响。当 AWS 必须为 运行 您的 Lambda 启动一个新容器时，您需要支付冷启动罚款。发生这种情况可能是因为它最近没有 运行ning，或者因为它需要扩展以满足并发请求。实际的冷启动时间将取决于您的语言：Java 比 Python 慢得多，例如，因为它需要在执行任何操作之前启动 JVM 并加载 类。
现在回答你的实际问题
Basically, a Patient inputs a description of his Condition which forms the basis for a Case. That Case is handled during one or many Sessions by one or many Nurses that take Notes related to the Case.
这可以在 NoSQL 数据库（例如 DynamoDB）中实现。如果没有更多信息，我可能会将会话作为基本文档，使用案例 ID 作为分区键，使用会话 ID 作为排序键。如果您不理解这些术语的含义，以及您将如何基于该键构建文档，那么您可能不应该使用 DynamoDB。
不使用 DynamoDB 的一个更大原因与访问模式有关。您是否想查找给定护士处理的所有病例？或者与特定患者有关？这些类型的查询是关系数据库的设计目的。
the case of DynamoDB, I am personally very inexperienced (more so than in MySQL)
您的团队中是否有人熟悉 NoSQL 数据库？如果不是，那么我认为您应该坚持使用 MySQL。学习如何使用 Lambda 将面临足够多的挑战。