分区键与排序键
PK/SK 设计、热点分区避免。
35 分钟
分区键与排序键
DynamoDB 的 Partition Key(PK) 决定数据落在哪个分区;可选 Sort Key(SK) 在同分区内排序与范围查询。键设计 = 性能与成本的核心。
学习目标
- 理解 PK/SK 与物理分区的关系
- 掌握复合键、前缀建模常见模式
- 识别并避免热点分区
核心内容
主键类型
| 类型 | 结构 | 典型场景 |
|---|---|---|
| 简单主键 | 仅 PK | 用户会话、配置项 |
| 复合主键 | PK + SK | 一对多、时序、单表多实体 |
# 创建复合主键表
aws dynamodb create-table \
--table-name UserProgress \
--attribute-definitions \
AttributeName=PK,AttributeType=S \
AttributeName=SK,AttributeType=S \
--key-schema \
AttributeName=PK,KeyType=HASH \
AttributeName=SK,KeyType=RANGE \
--billing-mode PAY_PER_REQUEST
建模示例:用户课时进度
PK = USER#u_1001
SK = LESSON#mongo-crud → 一条进度记录
SK = LESSON#ddb-intro → 另一条
Query PK = USER#u_1001 即可列出该用户全部进度——等价 MySQL WHERE user_id = ?,但 不能 随意 WHERE lesson_slug = ? 除非加 GSI(ddb-gsi)。
热点分区
反模式:所有写入用同一 PK(如 PK=GLOBAL#counter)→ 单分区 1000 WCU 上限。
改进:
- 计数器:分散到
SHARD#0…SHARD#9,读取时聚合 - 时序:PK 加日期桶
DEVICE#d1#2026-03-01 - 高基数 PK:用户 ID、订单 ID 天然分散
对照 sql-essentials:MySQL 靠索引而非分区键约束访问;postgresql-essentials 分区表是 DBA 主动拆分。
练习
- 为
cf_track实验镜像设计 PK/SK(提示:TRACK#slug + META) - 说明为何
PK=TRACK#all存全部课程是反模式 - 画出 UserProgress 表 Query 路径(仅 PK 条件)
小结
PK 决定分区与扩展性,SK 决定同分区内的查询粒度;先画访问模式再定键。 下一课 CRUD 与条件写。
加载本节练习…