RDBMS 与 DynamoDB 和无服务器与非无服务器

Question

关于计划应用程序的设计，我有一点问题，尤其是数据库引擎和无服务器/非无服务器。 目标是一个通过 Rest API 与数据库对话的 Web 应用程序。 Rest API 本身实际上只是 CRUD 操作，因此我认为无服务器方法（AWS Lambda）非常适合。为此，可供选择的最高效数据库可能是 DynamoDB (NoSQL)。

我熟悉 RDBMS，对 NoSQL 数据库知之甚少。

应用程序的 Schema 还没有完成，应该可以在以后扩展，因为可能会有新的特性要实现等等。因此，我宁愿使用 RDBMS 而不是 NoSQL 数据库，因为它们在以后编辑模式方面不能很好地扩展。 （至少这是我最近几个小时读到的）

选择例如 Amazon RDS MySQL 数据库会贵得多，而且我不知道他们在使用 Rest API 的无服务器方法方面做得如何。

所以我站在一个地方，我真的不知道在这里使用什么服务。我还能使用 DynamoDB 吗？该模式可能是非常相关的。

Answer 1

DynamoDB 没有任何架构的概念，所以关于编辑的整个事情都与 DynamoDB 无关。如果通过模式表示具有某些属性的对象，那么它取决于用例。如果您可以在表中拥有不共享相同“模式”的对象，那么它非常简单，因为默认情况下允许这样做。另一方面，如果您需要所有对象共享同一组属性并且您要经常更改它们，那么与 RDS 相比，这确实没有那么简单和直接。

接下来，如果您有一个关系模式 - 表 - 并且计划对它们进行一些 JOIN，那么 DynamoDB 确实不是一个好的解决方案。 DynamoDB 适用于特定类型的用例，例如存储会话或具有类似（低）复杂性的东西。在 DynamoDB 中编写更复杂的查询会变得非常乏味和痛苦。

考虑价格。好吧，我真的不会说 DynamoDB 有那么便宜。乍一看似乎是这样，但如果你深入研究它，你会发现它实际上非常昂贵，主要是从写入的角度来看。您需要提供读写容量和更大的吞吐量，您需要的成本就越高（您可以对突发流量进行自动缩放，但在流量一致的情况下，这对您没有太大帮助）。在更大的规模上，RDS（不是 Aurora）的成本只是 DynamoDB 成本的一小部分（假设我们谈论的是 RDS 可以处理的用例）。

如果您担心 RDS 与 Lambda 的集成，那么与 DynamoDB 相比，复杂性并没有那么大。需要考虑一些因素，例如 lambda 执行时间硬限制（当前为 15 分钟）和 RDS 响应速度可能较慢（与 DynamoDB 相比），但如果您的查询花费了那么长时间，那么您要么在做出现问题或滥用这些工具。

总而言之，如果您对使用 RDS 感到满意，并且不需要 DynamoDB 提供的毫秒级延迟（如果也使用 DAX，则甚至是微秒级延迟），那么在您的情况下，我肯定会选择 RDS 而不是 DynamoDB。同样，DynamoDB 并不是针对所有与数据相关的问题的通用解决方案，而且我经常看到它被严重滥用于 RDS 可以轻松处理的东西。