数据库：DynamoDB
本节课将讨论DynamoDB的特性、DynamoDB索引的优缺点，以及在什么情况下它是一个优秀的数据库默认选择。最后，我们将列出关于使用DynamoDB索引的建议。
## 云中的数据结构
亚马逊将 DynamoDB 描述为一种数据库，但更准确地说，它应被视为一种高持久性的云中数据结构。具体来说，它是一种分区的 B 树数据结构。
DynamoDB 与 **Redis** 的相似性远高于与 **MySQL**。但与 **Redis** 不同的是，DynamoDB 具有立即一致性和高持久性，其核心围绕单一数据结构构建。当你向 DynamoDB 写入数据后，可以立即读取回来，并且在实际应用中，你可以认为写入的数据永远不会丢失。
确实，DynamoDB 可以替代关系型数据库，但前提是你要能接受将所有数据存储在一个简单的 B 树结构中。如果符合这一前提，那么 DynamoDB 就是一个极佳的默认数据库选择。
DynamoDB 与关系型数据库对比
下表展示了 DynamoDB 与关系型数据库之间的一些高层次差异：
查询处理
大多数查询处理需要在应用端完成，这不仅不方便，还会带来性能影响。关系型数据库会尽可能靠近数据执行查询，因此如果你要计算每个客户的订单总金额，汇总操作会在读取数据时完成，最终只需通过网络传输每客户一行的汇总结果。然而，若使用 DynamoDB，你必须获取所有客户订单（每条订单一行），这意味着传输大量数据，然后在远离数据的应用端完成汇总。这一特性将成为判断 DynamoDB 是否适合你需求的关键因素之一。
存储成本
另一个需要考虑的因素是成本。如下表所示，将 1 TB 数据存储在 DynamoDB 中的成本高于存储在 S3 中。
| 1 TB 在 DynamoDB | 1 TB 在 S3 |
|---|---|
| $256/月 | $23.55/月 |
此外，S3 对数据的压缩效率更高，这可能进一步拉大两者之间的成本差距。
然而，存储成本通常不是决定是否选用 DynamoDB 的主要因素。真正关键的是请求定价。
请求定价
按需模式
默认情况下，你应该从 DynamoDB 的按需定价开始，只有在进行成本优化时才考虑预留容量。按需模式下，每百万次写入收费 0.25。由于 DynamoDB 的数据结构非常简单，通常不难估算所需的请求数量。你很可能能够通过分析应用逻辑，将每个操作映射到具体的 DynamoDB 请求数。例如，你可能会发现，加载一个网页需要 4 次 DynamoDB 读取请求。因此，如果每天预计服务一百万个页面，仅此操作的 DynamoDB 请求成本就约为 $1/天。
来个小练习： 使用下方工具，当每百万次读取成本为 $0.25 时，计算按需成本。只需在第一个单元格中输入每页所需 读取 请求数量（以百万为单位），系统将自动在下一个单元格中生成成本。
再来一个活动： 使用下方工具，当每百万次写入成本为 $1.25 时，计算按需成本。只需在第一个单元格中输入每页所需 写入 请求数量（以百万为单位），系统将自动在下一个单元格中生成成本。
预留容量
如果 DynamoDB 的性能特征与你的应用兼容，且按需定价在可接受范围内，可以考虑切换到预留容量模式。理论上，原本每天花费 0.14/天，看起来成本大幅降低。但这个计算假设了以下两点：
- 请求在一天内均匀分布；
- 完全没有容量冗余（一旦出现第 1,000,001 次请求，就会被限流）。
显然，这两个假设都不现实。实际上，你必须预留充足的冗余容量以应对峰值请求率，以及应对需求波动带来的不确定性。使用预留容量意味着你需要持续监控资源利用率，并主动调整容量配置。
来个小练习： 使用下方工具，当每小时每读取容量单位（RCU）成本为 $0.00013 时，计算预留容量成本。只需在第一个单元格中输入每小时服务一页所需的 读取 请求数量，系统将自动在下一个单元格中生成成本。
再来一个活动： 使用下方工具，当每小时每写入容量单位（WCU）成本为 $0.00065 时，计算预留容量成本。只需在第一个单元格中输入每小时服务一页所需的 写入 请求数量，系统将自动在下一个单元格中生成成本。
总体而言：
- 你几乎总是应该从按需定价开始（无需管理容量负担）。
- 当使用量显著增长时，几乎总是应考虑转向预留容量（实现显著的成本节约）。
但如果你觉得按需定价过高，那么即使采用预留容量，DynamoDB 也可能仍然过于昂贵。在这种情况下，你可能需要考虑使用关系型数据库，它具有与 DynamoDB 完全不同的成本特性。
需要特别注意的是：
- 按需定价并非完全意义上的“即时按需”。背后，DynamoDB 会动态调整每秒读写次数的限制，这些限制会根据你的使用情况变化。但由于该过程不透明，若希望确保在使用量剧烈波动时仍能保留足够容量，建议使用预留容量以获得安心。
注意： 上述价格仅用于帮助理解成本对比，实际价格可能随时由 AWS 调整。因此，最终决策时请参考最新的官方定价信息。
DynamoDB 索引
DynamoDB 索引分为两种类型：
- 局部索引
- 全局索引
局部索引最早于 2013 年初推出，全局索引则在数月后加入。
局部索引
局部索引唯一的优点是立即一致性，但它有一个非常隐蔽的严重缺点。一旦在表上创建局部索引，该表无限增长的能力就会消失。局部索引要求共享相同分区键的所有记录必须能容纳在 10 GB 以内。一旦达到此上限，所有使用该分区键的写入操作都将失败。
全局索引
相比之下，全局索引不会对表大小施加任何限制，但读取操作是最终一致的（尽管延迟通常几乎不可察觉）。全局索引也有一个潜在问题，但在大多数场景下，其影响远小于局部索引的问题。
DynamoDB 在主表与全局索引之间维护一个类似队列的内部机制，该队列具有固定但不透明的大小。因此，如果全局索引的预留吞吐量不足以跟上主表的更新速度，该队列可能被填满。一旦发生这种情况，灾难性后果随之而来：
- 主表的所有写入操作都会失败。
最棘手的是，无法监控该内部队列的状态。因此，唯一预防方法是：
- 监控所有全局索引的限流请求数量，并在出现限流时迅速响应，为受影响的索引增加容量。
尽管如此，这种情况通常只发生在极高活跃度的表上，短暂的限流很少引发此类问题。全局索引仍然非常有用，但请记住它们是最终一致的，且如果配置不足，可能间接对主表造成严重影响。
在下一课中，我们将探讨何时应使用 S3。
Quiz
DynamoDB与关系型数据库的一个主要区别在于，DynamoDB中的数据聚合是在数据附近完成的，而关系型数据库则不是这样。