aws-doc/课程/第二阶段-核心服务/第15天-DynamoDB数据库.md
2026-05-08 10:24:39 +08:00

6.1 KiB
Raw Blame History

第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 加钱必须同时成功) RDSDynamoDB 也支持,但有限制)
需要灵活的 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 的"分区键 + 排序键"是什么意思?举一个例子。

延伸阅读


明天预告

明天学习 VPC虚拟私有云——AWS 的网络基础。理解子网、路由、网关这些概念,搞清楚你的服务器是怎么连上网的,以及怎么保护它们不被外界随意访问。