AWS DynamoDB
Amazon DynamoDB
第一章：核心定义与本质
Amazon DynamoDB 是一种完全托管的 NoSQL 数据库服务，提供快速、可预测的性能和无缝的扩展性。
- 无服务器 (Serverless)： 你无需管理服务器、安装补丁或维护底层基础设施。
- 高可用性： 数据自动在区域内的多个可用区（AZ）之间进行同步复制。
- 性能： 无论数据规模如何，都能提供稳定、个位数毫秒级的响应延迟。
- 安全性： 提供默认的静态加密（Encryption at Rest），并与 IAM 集成进行细粒度的访问控制。
第二章：数据模型与核心组件
1. 基础结构
- 表 (Tables)： 数据的集合。DynamoDB 的表是无模式（Schema-less）的，除了主键外，不需要预先定义属性。
- 项目 (Items)： 表中的单条记录（类似于行）。每个项目的大小上限为 400 KB。
- 属性 (Attributes)： 项目中的基本数据元素（类似于列）。支持标量、集合及嵌套的文档类型（List 和 Map），嵌套深度可达 32 层。
2. 主键 (Primary Key)
主键必须在创建表时定义，且必须是标量类型（String, Number, Binary）。
- 分区键 (Partition Key/Hash Key)： 决定数据存储在哪个物理分区。
- 排序键 (Sort Key/Range Key)： 可选。与分区键结合形成“复合主键”，允许在相同分区键下进行范围查询和排序。
第三章：二级索引 (Secondary Indexes)
当主键无法满足查询需求时，使用二级索引来提供查询灵活性。
| 特性 | 本地二级索引 (LSI) | 全局二级索引 (GSI) |
|---|---|---|
| 分区键 (PK) | 必须与原表的分区键相同 | 可以与原表不同 |
| 排序键 (SK) | 必须与原表不同 | 可以与原表不同 |
| 创建时机 | 仅限在建表时创建 | 可以在建表后随时创建、修改或删除 |
| 范围限制 | 仅限于单个分区键值内（本地） | 跨越表的所有分区（全局） |
| 读一致性 | 支持强一致性或最终一致性 | 仅支持最终一致性 |
第四章：读一致性与容量单位
1. 读一致性模型
- 最终一致性 (Eventually Consistent)： 默认模式，性能最高。响应可能包含过时数据，但通常在 1 秒内达到一致。
- 强一致性 (Strongly Consistent)： 返回最准确的数据。但在网络延迟或故障时可用性略低，且不支持跨区域读取。
2. 吞吐量单位计算
- 写入 (WCU)： 1 个 WCU = 每秒 1 次写入（项大小不超过 1 KB）。
- 读取 (RCU)： 1 个 RCU = 每秒 1 次强一致性读取，或每秒 2 次最终一致性读取（项大小不超过 4 KB）。
第五章：容量管理模式
预置模式 (Provisioned)： 你指定固定的 RCU 和 WCU。适合流量平稳、可预测的场景。
Auto Scaling： 开启后，DynamoDB 会根据实际流量自动调整预置的容量，防止因请求超限导致的 Throttling（节流）。
按需模式 (On-Demand)： 按请求付费，无需容量规划。适合流量不可预测或有突发尖峰的负载。
第六章：查询操作 (Query vs Scan)
Query (查询)： 基于主键值定位。必须指定分区键的等值条件。性能极高且消耗吞吐量低。
Scan (扫描)： 读取表或索引中的所有项目，然后进行过滤。
注意： 对于大表，Scan 非常慢且非常昂贵，因为它会消耗大量的 RCU。
优化： 尽可能使用 Query；如必须 Scan，可尝试“并行扫描 (Parallel Scan)”。
数据限制： 单次 Query 或 Scan 操作返回的数据上限为 1 MB。
第七章：高级特性与集成
1. DynamoDB Streams
捕获表的增删改操作。
- 记录保留 24 小时。
- 常用于触发 AWS Lambda，实现数据同步、实时分析或跨区域复制。
2. DAX (DynamoDB Accelerator)
专为 DynamoDB 设计的内存中缓存集群。
- 提供微秒级的响应速度。
- 主要针对频繁读取、重复读取的场景，但不适合需要强一致性读的应用。
3. 全球表 (Global Tables)
提供全托管、多区域、多活跃（Multi-active）的复制方案。
- 允许在多个 AWS 区域提供极低延迟的读写。
- 依赖 DynamoDB Streams 实现。
4. 其他核心特性
- TTL (生存时间)： 自动删除过期项目。系统自动执行，不消耗吞吐量。
- Transactions (事务)： 提供原子性、一致性、隔离性和持久性（ACID）。单次事务最多处理 25 个项目（4 MB）。
第八章：架构设计最佳实践 (解决热点问题)
1. 热点分区 (Hot Partitions)
- 原因： 如果大量请求集中在同一个分区键（例如热门产品 ID），会导致该物理分区达到 RCU/WCU 上限，产生节流错误。
- 对策：
- 高基数键： 选择具有大量唯一值的分区键（如 UserID 而非 Gender）。
- 写入分片 (Write Sharding)： 在分区键末尾添加随机后缀，将压力分散到多个分区。
- 利用缓存： 使用 DAX 处理读取热点。
2. 节流处理 (Throttling)
- 当请求被节流时，客户端会收到 HTTP 400 (ProvisionedThroughputExceededException) 错误。
- 解决方案： 增加预置容量、开启 Auto Scaling 或切换到按需模式。
第九章：架构师对比 (什么时候选 DynamoDB？)
| 需求 | 推荐方案 |
|---|---|
| 关系型数据、多表 Join、复杂 SQL | 选择 RDS 或 Aurora |
| 超高性能、毫秒级响应、键值对存储 | 选择 DynamoDB |
| 微秒级读取延迟 | 在 DynamoDB 前端部署 DAX |
| 事件驱动、数据库变动触发逻辑 | 使用 DynamoDB Streams + Lambda |
| 存储大文件（如图片） | 将文件存入 S3，仅在 DynamoDB 存入 URL |