无服务器数据库 - 用 DynamoDB 实现可扩展的数据管理
以 DynamoDB 按需模式为核心，构建根据流量自动扩展的数据库。包括与 Aurora Serverless 的比较在内，解析根据工作负载特性选择无服务器数据库的标准。
无服务器数据库的概念与 DynamoDB 的定位
无服务器数据库消除了容量规划和服务器管理的需要，让开发者专注于应用开发。Amazon DynamoDB 自 2012 年发布以来一直是 AWS 无服务器数据库的核心，是能以个位数毫秒延迟处理每秒数百万请求的全托管 NoSQL 数据库。在本地运行同等的 NoSQL 数据库 (MongoDB、Cassandra 等) 时，需要集群构建、分片设计、复制管理、补丁应用等大量运维任务。DynamoDB 由 AWS 管理所有这些，开发者可专注于表设计和查询优化。选择按需容量模式后，甚至无需预先设置容量，根据流量自动扩展。
DynamoDB 的主要功能
DynamoDB 提供按需模式和预置模式 2 种容量模式。按需模式按请求单位计费，最适合流量难以预测的工作负载。预置模式结合 Auto Scaling 可实现高性价比运维。DynamoDB Streams 可将表的变更实时触发 Lambda 函数，用几行代码实现变更数据捕获（CDC）模式。全局表提供多区域复制，在全局表配置下适用 99.999% 的可用性 SLA。默认情况下，区域间的复制为最终一致性；需要跨区域的强一致性时，应选择多区域强一致性（MRSC）模式。官方文档（截至 2026 年 8 月）规定，MRSC 必须为恰好 3 个区域的配置（3 个副本，或 2 个副本 + 1 个 witness）。MRSC 只能在 US、EU、AP 各区域集内配置，不能跨越区域集。以下是用按需模式创建 DynamoDB 表的 CLI 命令示例。 aws dynamodb create-table \ --table-name Orders \ --attribute-definitions AttributeName=CustomerId,AttributeType=S AttributeName=OrderId,AttributeType=S \ --key-schema AttributeName=CustomerId,KeyType=HASH AttributeName=OrderId,KeyType=RANGE \ --billing-mode PAY_PER_REQUEST
Lambda 集成的无服务器架构
DynamoDB 与 Lambda 的组合是 AWS 无服务器架构的黄金模式。从 API Gateway 接收请求用 Lambda 处理、将数据持久化到 DynamoDB 的架构，无需服务器配置即可构建支持数百万用户规模的应用。DynamoDB Streams 与 Lambda 集成可实现以数据变更为触发器的异步处理。如以订单数据插入为触发器自动执行库存更新或通知发送，构建事件驱动的数据管道。使用 PartiQL 可用类 SQL 语法操作 DynamoDB，降低习惯 RDB 的开发者的学习成本。DAX (DynamoDB Accelerator) 作为内存缓存，将读取延迟缩短到微秒级。在本地构建同等缓存层需要另外运维 Redis 或 Memcached，而 DAX 是与 DynamoDB 完全集成的托管服务。
成本效率与可扩展性优势
DynamoDB 的按需模式按请求单位计费，流量为零的时段仅产生存储费用（截至 2026 年 8 月，弗吉尼亚北部 / 东京）。读取每 100 万请求单位在弗吉尼亚北部为 0.125 美元、东京为 0.1425 美元，写入同样每 100 万请求单位在弗吉尼亚北部为 0.625 美元、东京为 0.715 美元。常时免费额度为 25 GB 存储和 25 个预置 WCU、25 个预置 RCU，官方文档将其说明为每月可处理 2 亿次请求的规模。不过，该额度针对的是预置容量，因此不适用于按需模式的请求费用。如果想在免费额度内运行小规模应用，选择预置模式与 Auto Scaling 的组合是常规做法。在预置模式下，仅 Standard 表类别可购买预留容量，相对于标准价格，1 年合约最多可享 54% 的折扣，3 年合约最多可享 77% 的折扣。（3 年合约仅限部分区域；购买单位为 100 RCU 或 100 WCU；按需模式和 Standard-IA 表类别不在适用范围内。）在可扩展性方面，每张表的默认配额为每秒 40,000 个读取请求单位和 40,000 个写入请求单位，如需超出该规模，应通过 Service Quotas 申请提高。（预置模式另有账户级别 80,000 RCU / 80,000 WCU 的默认额度。）存储无需事先预留容量，即使表大小达到数百 TB，也能保持一致的性能。
数据建模与访问模式设计
有效使用 DynamoDB 的关键，在于理解与关系型数据库不同的设计思路。需先梳理应用的访问模式，即以什么条件读写数据，再据此设计表和键。选择左右数据分散与获取的分区键时，应避免访问出现偏斜，这一点很重要。如果将设计做到能高效地一并获取相关数据，就能发挥高速而稳定的性能。由于不擅长事后以自由条件进行检索，事先掌握所需的检索模式是可扩展数据设计的前提。
与 Aurora Serverless 的比较与选择标准
无服务器数据库的选择并不只有 DynamoDB。需要关系模型时，Aurora 的无服务器配置是与之相对的选择（官方文档中的名称为 Aurora Serverless。AWS 已告知于 2026 年 4 月由 Aurora Serverless v2 改称）。Aurora Serverless 以 ACU（Aurora Capacity Unit）为单位自动调整容量，1 ACU 相当于约 2 GiB 内存以及相应的 CPU 和网络性能。容量范围可指定为最小 0.5 ACU 到最大 256 ACU，以 0.5 ACU 为步长进行细致的增减来跟随工作负载。截至 2026 年 10 月，Aurora PostgreSQL 的受支持引擎版本可将上限设为 384 ACU。如果希望在一定时间内没有用户操作产生的连接时自动停止，可将最小容量设置为 0 ACU。费用由 ACU 使用量加上存储和 I/O 构成，单价因区域和配置而异，因此请通过 Aurora 的官方价格表确认实际金额。 选择标准可从「能否在设计时确定访问模式」和「是否需要 SQL 的灵活性」2 个维度来整理。如果以指定键的高速读写为主，且能在设计时梳理出所需的访问模式，则 DynamoDB 具有优势。个位数毫秒的延迟和按请求计费能发挥作用，空闲时的成本仅为存储费用。反之，如果业务要求包含汇总、联接、事后更改条件的临时检索，或者需要迁移现有的 PostgreSQL、MySQL 资产，则应选择 Aurora Serverless。由于需确保最小 ACU，空闲时也会持续计费（使用 0 ACU 自动停止的情况除外），但可获得关系模型的表达能力以及处理跨多表事务的便利性。两者并不互斥。将作为业务事务基准的数据放在 Aurora Serverless 中，由 DynamoDB 承接查询类的高吞吐量部分，这种组合使用也是一种设计选择。
总结 - 无服务器数据库的选择标准
DynamoDB 是无服务器架构中数据持久化的主力选择。按需模式的从零扩展和按需计费，从初创企业到大型企业广泛适用。DynamoDB Streams 的事件驱动处理、全局表的多区域部署（全局表配置下 99.999% 的可用性 SLA）、DAX 的微秒级缓存等，全面提供了数据管理所需的功能。在选择顺序上，如果能在设计时固定访问模式，就先考虑 DynamoDB；如果需求中包含汇总、临时检索、现有关系型资产的迁移，则选择 Aurora Serverless。这样整理，判断就不会摇摆。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。