文档数据库的应用 - 借助 Amazon DocumentDB 和 DynamoDB 实现灵活的数据建模
讲解利用 Amazon DocumentDB 和 DynamoDB 的文档数据库设计 / 运维方法。
文档数据库的基本概念与 AWS 服务的选项
文档数据库是为存储 / 检索 JSON 或 BSON 格式的灵活数据结构而设计的 NoSQL 数据库。它不需要像关系数据库那样事先严格定义架构，可以随着应用程序的演进灵活地变更数据结构。在 AWS 中，Amazon DocumentDB 和 Amazon DynamoDB 这 2 项服务适用于文档数据库的用例。DocumentDB 提供与 MongoDB 兼容的 API。因此，只要在所支持版本的范围内，仅变更连接字符串和驱动程序的设置，就可以运行现有的 MongoDB 应用程序。不过，这种兼容性并非 MongoDB 本体的移植，而是 API 层面的兼容，部分运算符和管理命令不受支持。迁移前确认正在使用的功能是否包含在支持范围内，并使用 AWS Database Migration Service 迁移数据，这是实务上的步骤。另一方面，DynamoDB 是同时支持键值型和文档型的完全托管服务，实现毫秒级的一致延迟。在本地运行 MongoDB 集群时，会产生副本集的配置、分片的设计、备份的自动化、安全补丁的应用等大量运维负担，而 AWS 的托管服务会将这些全部自动化。
Amazon DocumentDB 的特性
Amazon DocumentDB 是与 MongoDB 兼容的托管数据库服务。截至 2026 年 8 月，可以新选择的引擎版本为 4.0、5.0、8.0（已结束标准支持的版本，也仅限已在使用该版本集群的账户可以新建）。于 2025 年 11 月发布的 8.0 提供与 MongoDB 8.0 的兼容性。最初一代的 3.6 已于 2026 年 3 月 30 日结束标准支持。此后它纳入付费 Extended Support（提供针对重大 CVE 的安全更新 / 严重缺陷的修复 / 支持案例的处理 / 最长 3 年）的范围。因此，新建时基本上选择 8.0。存储会根据使用量以 10 GiB 为单位自动扩展，上限为引擎版本 8.0 起 256 TiB，更早的版本为 128 TiB。在通过分片进行横向扩展的 Elastic Clusters 中，每个集群可以扩展到 4 PiB。数据以 6 个副本跨 3 个可用区保存，因此实现高持久性和高可用性。最多可以添加 15 个只读副本，便于分散读取负载。DocumentDB 采用计算与存储分离的构成，数据保存在分布于多个可用区并自动扩展的集群卷中。它采用基于仲裁的复制，写入在 6 个副本中的 4 个确认后即完成。使用全局集群功能，可以为 1 个主区域添加最多 10 个辅助区域，同时实现灾难恢复和全局读取性能。不过，每添加 1 个辅助区域，主集群中可以创建的只读副本上限就会减少 1 个（辅助区域为 10 个时，主集群为 5 个）。因此，区域部署与区域内的读取扩展之间存在权衡关系。另外，全局集群在引擎版本 3.6 以及 db.t3、db.t4g 等部分实例类中无法使用。以下是创建 DocumentDB 集群的 CLI 命令示例。 aws docdb create-db-cluster \ --db-cluster-identifier my-docdb-cluster \ --engine docdb \ --engine-version 8.0.0 \ --master-username admin \ --master-user-password MySecurePassword123 \ --storage-encrypted
DynamoDB 的文档模型与用例
DynamoDB 在存储文档型数据方面也发挥出色的能力。每个项目可以拥有最大 400 KB 的嵌套 JSON 结构，可以自由组合映射型和列表型属性来表示文档。使用名为 PartiQL 的 SQL 兼容查询语言，也可以直观地编写针对嵌套文档内特定字段的检索和更新。在 DynamoDB 的按需容量模式下，会根据流量自动扩展，没有请求的时段的成本几乎为零。它最适合游戏的玩家档案、电商网站的商品目录、IoT 设备的遥测数据等访问模式明确且要求可扩展性的用例。通过组合 DynamoDB Streams 和 Lambda，还可以构建实时检测文档变更并传播到下游系统的事件驱动架构。借助全局表功能，也可以实现多个区域的主动-主动配置。
DocumentDB 与 DynamoDB 如何选择
DocumentDB 和 DynamoDB 都可以处理文档数据，但最适合的用例不同。DocumentDB 适合需要复杂查询模式的情况。可以直接利用临时查询、聚合管道、文本搜索、地理空间查询等 MongoDB 丰富的查询功能。它作为现有 MongoDB 应用程序的迁移目标也最为合适。另一方面，DynamoDB 适合能够事先定义访问模式、要求毫秒级一致延迟的工作负载。在会话管理、购物车、实时竞价系统等高吞吐量和低延迟很重要的用例中，它发挥出真正的价值。从本地的 MongoDB 迁移时根据查询模式的复杂程度选择 DocumentDB，在新开发中最优先考虑可扩展性时选择 DynamoDB，这是一般的判断标准。两项服务都支持加密、VPC 集成和 IAM 认证，满足企业级的安全要求。
DocumentDB 与 DynamoDB 的费用对比
即使同为“文档数据库”，计费的思路也有根本的不同，因此需要套用到预想的工作负载上进行比较（截至 2026 年 8 月 / 弗吉尼亚北部 / 东京）。DocumentDB 的实例费用为按需的 db.r6g.large 每小时 0.26315 美元（弗吉尼亚北部）/ 0.3173 美元（东京）。按 730 小时换算，每月约 192 美元 / 约 232 美元。存储为每 1 GB 每月 0.10 美元（弗吉尼亚北部）/ 0.12 美元（东京），此外还要加上 I/O 和备份的费用。另一方面，DynamoDB 的按需模式为读取每 100 万个请求单位 0.125 美元（弗吉尼亚北部）/ 0.1425 美元（东京）。写入为每 100 万个请求单位 0.625 美元（弗吉尼亚北部）/ 0.715 美元（东京）。DynamoDB 是无服务器的，最低成本接近零，而 DocumentDB 即使没有请求也会产生实例的固定成本。反之，在读写量大且稳定的工作负载中，DocumentDB 的固定成本有时会比请求计费不断累积的 DynamoDB 更便宜。访问模式简单且高吞吐量时选择 DynamoDB，需要复杂查询或聚合时选择 DocumentDB，最新的单价请务必在官方价格页面确认。
总结 - 文档数据库策略的优化
DocumentDB 具备与 MongoDB 兼容的查询功能和自动扩展的集群卷，作为希望继续使用临时查询和聚合管道的现有工作负载的迁移目标，是有力的选择。DynamoDB 提供无服务器的可扩展性和一致的低延迟，借助与 Lambda 的原生集成，易于构建事件驱动架构。根据工作负载的特性分别使用这两项服务，可以兼顾灵活的数据建模和高性能。选择文档数据库时，从查询模式的复杂程度、可扩展性要求、现有资产的利用这 3 个维度进行判断很重要。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。