171 lines
6.1 KiB
Markdown
171 lines
6.1 KiB
Markdown
# 第15天：DynamoDB——NoSQL 数据库
|
||
|
||
## 今天你将学到什么
|
||
|
||
今天学习一种和 RDS 完全不同的数据库：DynamoDB。它是 AWS 的 NoSQL 数据库，专为超大规模和超低延迟设计。
|
||
|
||
---
|
||
|
||
## 先搞清楚：什么是 NoSQL
|
||
|
||
**SQL 数据库（关系型，如 MySQL）**：
|
||
- 数据存在"表"里，有固定的列（像 Excel 表格）
|
||
- 用 SQL 语言查询
|
||
- 擅长复杂查询（多表关联、聚合统计）
|
||
- 扩展有上限（一台机器的 CPU/内存是有限的）
|
||
|
||
**NoSQL 数据库（如 DynamoDB）**：
|
||
- 数据结构灵活（每条记录可以有不同的字段）
|
||
- 不用 SQL，用 API 查询
|
||
- 查询方式受限（主要通过"键"来查）
|
||
- 可以无限水平扩展（加机器就能扩容）
|
||
|
||
**生活类比**：
|
||
|
||
- SQL 数据库像**图书馆的目录卡片柜**：每张卡片格式统一（书名、作者、出版社、ISBN），可以按任意字段检索，但柜子大小有限。
|
||
- NoSQL 数据库像**快递柜**：每个格子有一个编号（键），你用编号就能极快地取到东西。但你不能说"帮我找出所有重量超过 5 公斤的包裹"——它不支持这种查询。
|
||
|
||
---
|
||
|
||
## DynamoDB 的特点
|
||
|
||
- **完全托管**：不需要装软件、不需要管服务器、不需要做备份
|
||
- **无限扩展**：从每秒几个请求到每秒数百万个请求，自动扩展
|
||
- **稳定延迟**：无论数据量是 1GB 还是 100TB，读写延迟都是个位数毫秒
|
||
- **高可用**：数据自动复制到 3 个可用区
|
||
- **按量付费**：可以选择按请求次数付费，不用不花钱
|
||
|
||
---
|
||
|
||
## 核心概念——用通讯录来理解
|
||
|
||
想象你有一个手机通讯录：
|
||
|
||
### 表（Table）
|
||
|
||
通讯录本身就是一张"表"。
|
||
|
||
### 项目（Item）
|
||
|
||
通讯录里的每个联系人就是一个"项目"（相当于 SQL 里的一行）。
|
||
|
||
### 属性（Attribute）
|
||
|
||
每个联系人的信息（姓名、电话、地址）就是"属性"（相当于 SQL 里的列）。
|
||
|
||
**但和 SQL 不同的是**：DynamoDB 的每个项目可以有不同的属性。
|
||
|
||
比如：
|
||
- 张三：{姓名, 手机, 邮箱, 公司}
|
||
- 李四：{姓名, 手机, 微信号}（没有邮箱和公司）
|
||
- 王五：{姓名, 座机, 地址, 生日}（没有手机）
|
||
|
||
在 MySQL 里，你必须预先定义好所有列。在 DynamoDB 里，每条记录想有什么字段就有什么字段。
|
||
|
||
### 主键（Primary Key）
|
||
|
||
主键是查找数据的"入口"，是你必须定义的唯一结构。
|
||
|
||
**两种主键类型**：
|
||
|
||
**类型一：分区键（Partition Key）**
|
||
- 单个属性作为主键
|
||
- 必须唯一标识每个项目
|
||
- 例：用户 ID、订单号
|
||
|
||
**类型二：分区键 + 排序键（Partition Key + Sort Key）**
|
||
- 两个属性组合作为主键
|
||
- 分区键相同的项目存在一起，按排序键排序
|
||
- 例：用户 ID（分区键）+ 订单时间（排序键）
|
||
|
||
**举个例子**：电商的订单表
|
||
|
||
| 用户ID（分区键） | 下单时间（排序键） | 商品 | 金额 |
|
||
|-----------------|-------------------|------|------|
|
||
| user-001 | 2024-01-15 10:30 | iPhone | 6999 |
|
||
| user-001 | 2024-02-20 14:15 | 耳机 | 299 |
|
||
| user-001 | 2024-03-05 09:00 | 充电器 | 89 |
|
||
| user-002 | 2024-01-18 11:00 | iPad | 3999 |
|
||
|
||
这样设计后，你可以高效地查询：
|
||
- "user-001 的所有订单"（按分区键查）
|
||
- "user-001 在 2024 年 2 月之后的订单"（分区键 + 排序键范围查询）
|
||
|
||
但你**不能**高效地查询：
|
||
- "所有金额超过 5000 的订单"（需要扫描全表，很慢）
|
||
- "买了 iPhone 的所有用户"（金额和商品不是键）
|
||
|
||
---
|
||
|
||
## DynamoDB vs RDS：什么时候用哪个
|
||
|
||
| 我的需求是... | 选择 |
|
||
|--------------|------|
|
||
| 需要复杂的多表关联查询 | RDS |
|
||
| 需要事务（转账：A 减钱 B 加钱必须同时成功） | RDS（DynamoDB 也支持，但有限制） |
|
||
| 需要灵活的 SQL 查询 | RDS |
|
||
| 需要处理每秒数万甚至数百万次简单读写 | DynamoDB |
|
||
| 数据结构不固定，经常变化 | DynamoDB |
|
||
| 需要个位数毫秒的稳定延迟 | DynamoDB |
|
||
| 不想管任何数据库运维 | DynamoDB |
|
||
|
||
**典型选择**：
|
||
- 用户信息、订单详情、财务数据 → RDS
|
||
- 用户会话、购物车、游戏排行榜、IoT 设备数据、实时计数器 → DynamoDB
|
||
|
||
**很多项目两者都用**：核心业务数据放 RDS，高并发的热点数据放 DynamoDB。
|
||
|
||
---
|
||
|
||
## DynamoDB 的计费模式
|
||
|
||
### 按需模式（On-Demand）
|
||
|
||
- 按实际读写次数付费
|
||
- 不需要预估容量
|
||
- 适合：流量不可预测、新应用、开发环境
|
||
- 价格：约 $1.25/百万次写入，$0.25/百万次读取
|
||
|
||
### 预置模式（Provisioned）
|
||
|
||
- 预先设定每秒的读写能力
|
||
- 可以配合 Auto Scaling 自动调整
|
||
- 适合：流量稳定可预测的生产环境
|
||
- 更便宜（大流量时）
|
||
|
||
**学习阶段用按需模式**，不用的时候一分钱不花。
|
||
|
||
---
|
||
|
||
## DynamoDB 的设计思维转变
|
||
|
||
如果你有 SQL 数据库的经验，用 DynamoDB 需要转变思维：
|
||
|
||
**SQL 思维**：先设计好表结构（范式化），再想怎么查询。
|
||
**DynamoDB 思维**：先想清楚要怎么查询，再设计表结构。
|
||
|
||
这是因为 DynamoDB 的查询能力有限——你只能通过主键高效查询。所以必须先知道"我要查什么"，然后把主键设计成支持这种查询的方式。
|
||
|
||
---
|
||
|
||
## 今天的小测验
|
||
|
||
1. DynamoDB 和 RDS 最本质的区别是什么？
|
||
2. 为什么 DynamoDB 能做到"无论数据量多大，延迟都是个位数毫秒"？
|
||
3. 如果你要存储一个游戏的实时排行榜（每秒更新几万次），应该用 RDS 还是 DynamoDB？
|
||
4. DynamoDB 的"分区键 + 排序键"是什么意思？举一个例子。
|
||
|
||
---
|
||
|
||
## 延伸阅读
|
||
|
||
- [DynamoDB 开发者指南](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/)
|
||
- [DynamoDB 免费套餐](https://aws.amazon.com/dynamodb/pricing/)（永久免费 25GB + 每月 2 亿次请求）
|
||
- [DynamoDB 设计最佳实践](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html)
|
||
|
||
---
|
||
|
||
## 明天预告
|
||
|
||
明天学习 VPC（虚拟私有云）——AWS 的网络基础。理解子网、路由、网关这些概念，搞清楚你的服务器是怎么连上网的，以及怎么保护它们不被外界随意访问。
|