跳到主要内容

C2-05-数据库与缓存体系

本章目标：承接 C2-04 的存储体系，从“把数据保存下来”和“把数据组织成可查询、可更新的业务数据”之间的区别开始，建立 Database、Relational Database、SQL、NoSQL、Cache、Document Database、Graph Database、Data Warehouse 的基础模型，并系统理解 Amazon RDS、Amazon Aurora、Amazon DynamoDB、Amazon ElastiCache、Amazon DocumentDB、Amazon Neptune 之间的定位和选择方法。

1-本章在整套-AWS-知识体系中的位置​

上一章解决：数据放在哪里？例如：

Object
→ S3

Block
→ EBS

File
→ EFS / FSx

但是业务数据不能只考虑：“有没有保存”；例如 GlobalShop 的订单：

Order
├── order_id
├── user_id
├── amount
├── status
├── created_at
└── items

应用还需要：按 order_id 查订单、按 user_id 查用户订单、更新订单状态、保证付款与订单修改的一致性、建立索引、并发读写、备份、高可用、扩展；这些能力属于：Database；因此：

Storage
        ↓
保存数据
        ↓
Database
        ↓
组织、查询、修改和管理业务数据

2-本章与-719-道题库的关系​

按照本项目统一的粗略“题干 + 全部选项，每题最多计一次”的曝光统计：

服务 / 概念题库粗略曝光
Amazon RDS42
Amazon DynamoDB36
Amazon Aurora25
Amazon Redshift18
Amazon Neptune12
Amazon ElastiCache9
Amazon DocumentDB6

注意：曝光度、≠、正确答案次数；例如：ElastiCache；在这套题里经常作为：“它明明是 Cache，为什么不是 Database 题答案？”；这样的干扰项出现。所以本章重点不是背服务出现次数，而是建立：Data Model、+、Workload、+、Access Pattern、+、Availability、+、Scaling；之间的关系。

3-★★★★★-数据库基础与数据模型​

3.1-Database-是什么？​

Database；=；数据库；最简单地说：

Database
不是单纯“一个装数据的文件”。

它还提供一套规则和能力，
让 Application 能够高效、可靠地组织、查询、修改数据。

例如：

Application
     │
     │ SQL / API
     ▼
Database Engine
     │
     ├── Data Model
     ├── Query
     ├── Index
     ├── Transaction
     ├── Concurrency
     └── Persistence

3.2-Storage-与-Database-到底有什么区别？​

例如：S3；当然可以存：orders.json；但是如果有：10 亿订单然后每秒都需要：SELECT ...、UPDATE ...、按 user_id 查、按 status 查、事务提交；仅仅把 JSON 文件放 S3，并不等于已经获得一个 Online Transaction Database。所以：

Storage
解决：
字节放在哪里

Database
解决：
业务数据如何建模、查询、修改和保证正确性

3.3-Database-Engine-是什么？​

Engine； 中文：引擎；Database Engine；=；数据库引擎；例如：MySQL、PostgreSQL、MariaDB、Oracle Database、Microsoft SQL Server、IBM Db2；这些不是“一个硬盘”。它们是完整数据库软件系统。

3.4-自己在-EC2-上装数据库​

最传统的云上方式：

EC2
 │
 ├── Linux
 ├── MySQL
 └── EBS

也就是：Database on EC2；此时你控制很多东西：OS、DB Installation、Patch、Version、Configuration、Backup、Replication、Failover、Monitoring；优点：控制能力高；缺点：运维责任大；这和前面：EC2 vs Fargate / Lambda；的抽象思路完全一致。

3.5-Managed-Database-为什么出现？​

很多公司其实想要的是：“我要 MySQL / PostgreSQL，、但我不想每天维护数据库服务器。”；于是 Cloud Provider 可以帮你管理：Hardware、OS、Database Installation、Backup、Patching、Failure Detection、Recovery；这就是：Managed Database；AWS 中最重要的代表：Amazon RDS

3.6-★★★★★-Relational-Database-是什么？​

Relational Database；=；关系数据库；核心数据结构通常是：Table、Row、Column；例如：

3.6.1-users​

user_idnameemail
1001Alicea@example.com
1002Bobb@example.com

3.6.2-orders​

order_iduser_idamount
9000110018000
90002100112000

这里：users.user_id；和：orders.user_id；之间就存在业务关系。

3.7-Table、Row、Column​

3.7.1-Table​

表；例如：users、orders、products

3.7.2-Row​

行 / 记录；例如一笔订单。

3.7.3-Column​

列 / 字段；例如：order_id、amount、status

3.8-Primary-Key-与-Foreign-Key​

Primary Key；简称：PK； 中文：主键；用于唯一标识一条记录。例如：

order_id = 90001

Foreign Key；简称：FK； 中文：外键；用于表达表之间的关系。例如：

orders.user_id
→ users.user_id

注意：Database Key；和：KMS Encryption Key；完全不是一个概念。

3.9-★★★★★-SQL-是什么？​

SQL；=；Structured Query Language、结构化查询语言；关系数据库常用 SQL。例如：

SELECT *
FROM orders
WHERE user_id = 1001;

更新：

UPDATE orders
SET status = 'PAID'
WHERE order_id = 90001;

CLF-C02 不要求写复杂 SQL。只需要知道：

SQL
→ Relational Database
→ Table / Row / Column / Relationship

3.10-Transaction-是什么？​

Transaction；=；事务；例如支付过程：

  1. 创建支付记录、2. 扣减库存、3. 修改订单状态、4. 记录账务

业务通常希望：要么整体成功、要么整体失败 / 回滚；而不是：钱扣了、订单却没更新；这就是 Transaction 思想。

3.11-ACID-是什么？​

ACID 是关系型事务里常见的四个性质：

A = Atomicity
C = Consistency
I = Isolation
D = Durability

中文：Atomicity 原子性、Consistency 一致性、Isolation 隔离性、Durability 持久性；CLF-C02 不要求深入数据库理论，但要知道：订单、支付、财务、库存；这类有明确关系和事务要求的数据，关系数据库通常很自然。

3.12-★★★★★-NoSQL-是什么？​

NoSQL；常被解释为：Not Only SQL；它不是简单等于：“不能查询”；也不是：“没有结构”；更准确的学习方式：不把所有业务都强制建模为传统关系表 + Join。NoSQL 有多种模型：Key-Value、Document、Graph、Wide-column、...；AWS CLF-C02 中最核心：

DynamoDB
→ Key-Value / Document NoSQL

DocumentDB
→ Document Database

Neptune
→ Graph Database

3.13-为什么需要-NoSQL？​

假设 GlobalShop 购物车：

user_id
→ cart data

访问模式很简单：

给我 user_id
→ 返回购物车

而系统可能面对：几千万用户、流量快速变化、大规模并发；如果主要需求并不是复杂 Join，可以考虑：Key-Value / NoSQL；这不是说：NoSQL 一定比 SQL 好；而是：

Workload 不同
→ Data Model 可以不同

3.14-Database-选择的第一原则：Access-Pattern​

Access Pattern；=；访问模式；也就是：Application 到底怎么读写数据？例如：按订单 ID 查、按用户查最近 20 个订单、按商品 ID 读详情、按用户 ID 读购物车、查询人与人的关系、复杂 BI 聚合；不同 Access Pattern 可能对应不同数据库技术。所以：

不是先问：
AWS 哪个 Database 最强？

而是先问：
我的数据是什么，
我要怎么访问？

4-★★★★★-Amazon-RDS关系数据库​

4.1-★★★★★-Amazon-RDS​

[CURRENT-IN-SCOPE]；正式名称：Amazon Relational Database Service；简称：Amazon RDS； 中文：Amazon 关系数据库服务

4.2-为什么叫-RDS？​

Relational；=；关系型；Database；=；数据库；Service；=；服务；所以：

RDS
=
Relational Database Service

名字直接表达：AWS 托管关系数据库

4.3-RDS-到底是什么？​

最简单：AWS 帮你管理关系数据库基础设施和大量日常运维工作。你仍然需要考虑：Schema、Table、Index、Query、Application Data、Database User、Business Logic；AWS 更多负责：底层基础设施、数据库软件部署、备份机制、补丁、故障检测、恢复；这就是 Shared Responsibility 在 Database 中的体现。

4.4-RDS-当前主要数据库引擎​

当前 Amazon RDS（不把 Aurora 混在这张普通 RDS engine 表里）主要支持：IBM Db2、MariaDB、Microsoft SQL Server、MySQL、Oracle、PostgreSQL；而：Amazon Aurora；属于 Amazon RDS 家族中的 AWS 自研兼容型关系数据库体系，AWS 为 Aurora 提供独立 User Guide。

4.5-RDS-DB-Instance-是什么？​

DB Instance；=；数据库实例；可以理解：一个正在运行的 Managed Database Environment；例如：GlobalShop Order DB、Engine: PostgreSQL、Class: ...、Storage: ...；Application 通过：Database Endpoint；连接。

4.6-GlobalShop-为什么订单适合-RDS？​

订单数据通常：User、Order、Order Item、Payment、Inventory；之间存在明确关系。例如：

User
  │
  └── Order
        │
        └── OrderItem
              │
              └── Product

再加：Transaction、Consistency、SQL Query；所以：RDS / Aurora；是非常自然的订单数据库选择。

4.7-RDS-帮你管理什么？​

相对于：MySQL on EC2；RDS 可以帮助处理很多：Provisioning、Database Software、Patch、Automated Backup、Failure Detection、Recovery、Monitoring Integration、Scaling Options；但它不是：“数据库以后完全不需要 DBA / Developer 思考”；你仍需要管理：

Data Model、Query、Index、Access、Security Configuration、Performance Design、Application Logic

4.8-RDS-Backup​

Amazon RDS 提供：Automated Backups、Manual DB Snapshots、Point-in-Time Recovery；等能力。这里先建立概念：

Automated Backup
→ 系统按配置自动保留恢复能力

Manual Snapshot
→ 用户主动创建时间点快照

完整备份治理还可以结合：AWS Backup

4.9-★★★★★-RDS-Multi-AZ​

Multi-AZ；=；Multiple Availability Zones、多可用区；核心目的：High Availability、Failover；经典 RDS Multi-AZ DB Instance 思路：

              Application
                   │
                   ▼
                Endpoint
                   │
             Primary DB
                AZ-A
                   │
        synchronous replication
                   │
                   ▼
              Standby DB
                AZ-B

如果 Primary 出现问题：

Failover
↓
Standby 接管

4.10-Standby-是什么？​

Standby；=；备用、待机；经典 Multi-AZ DB Instance 中：Standby；主要是：HA / Failover；不是为了：给 Application 分担读请求；这是考试非常重要的区别。

4.11-★★★★★-Read-Replica​

Read Replica；=；只读副本 / 读取副本；核心目的：Read Scaling；架构：

              Primary
             /       \
            /         \
           ▼           ▼
    Read Replica  Read Replica

Application 可以把：读流量；分到 Replica。

4.12-★★★★★-Multi-AZ-vs-Read-Replica​

这是数据库章节最重要的对比之一。

能力Multi-AZRead Replica
主要目标High AvailabilityRead Scaling
故障切换是核心用途不是主要定义
是否分担读请求经典 Standby 不用于普通读流量是
关键词failover、HAread-heavy、scale reads

最简单：

Multi-AZ
→ 坏了怎么办？

Read Replica
→ 读太多怎么办？

4.13-一个当前-AWS-细节：不要把所有-Multi-AZ-形态混成一个​

[UPDATED]；现在 RDS 不只有最经典的：Multi-AZ DB instance deployment；也存在：Multi-AZ DB cluster；等形态。其中 Reader Instance / Read Replica 的能力比旧教材中的一句：“Multi-AZ 永远不能读”；要复杂。所以本教材在 CLF-C02 基础层统一采用更准确表述：

经典 Multi-AZ DB Instance 的 Standby、主要用于 HA / Failover，、不能拿 Standby 当普通 Read Replica 使用。考试如果明确说：read scaling；应关注：Read Replica；如果明确说：automatic failover / high availability；应关注：Multi-AZ

5-★★★★★-Amazon-Aurora​

5.1-★★★★★-Amazon-Aurora​

[CURRENT-IN-SCOPE]；正式名称：Amazon Aurora；中文一般直接称：Amazon Aurora；Aurora；原本是：极光；这是产品名，不像 RDS 那样是缩写。

5.2-Aurora-到底是什么？​

AWS 当前定义：Fully Managed Relational Database Engine；并且兼容：MySQL、PostgreSQL；所以：

Aurora
不是 NoSQL

Aurora
不是 MongoDB

Aurora
不是 Data Warehouse

它是：Relational Database

5.3-Aurora-与-RDS-的关系​

容易出现两个错误极端。错误 1：Aurora 就是 RDS 的另一个普通第三方 Engine；不够准确。错误 2：Aurora 和 RDS 完全没关系；也不对。更好的理解：

Amazon RDS
关系数据库托管体系
│
├── MySQL
├── PostgreSQL
├── MariaDB
├── Oracle
├── SQL Server
├── Db2
│
└── Amazon Aurora
     ├── MySQL-compatible
     └── PostgreSQL-compatible

Aurora 有自己专门设计的：Distributed Storage Architecture、Cluster、Reader / Writer

5.4-Aurora-Cluster​

Aurora 的一个重要概念：DB Cluster；简化：

                 Aurora Cluster
                       │
          ┌────────────┴────────────┐
          │                         │
          ▼                         ▼
      Writer                     Reader
     Instance                   Instance
          │                         │
          └──────────┬──────────────┘
                     ▼
             Shared Cluster Storage

用户不需要像自己搭 MySQL 集群那样，自己管理底层分布式存储复制。

5.5-Writer-与-Reader​

Writer；=；写入节点；负责：Read / Write；Reader；=；读取节点；用于：Read Scaling；所以 Aurora 同样体现：Write Path、Read Scaling、High Availability

5.6-Aurora-为什么经常出题？​

因为它很容易和：RDS、DynamoDB、Redshift；混淆。题目看到：MySQL-compatible、PostgreSQL-compatible、relational、AWS-managed、high availability；Aurora 可能是重点候选。看到：NoSQL、key-value、serverless at any scale；应该更偏：DynamoDB

5.7-RDS-vs-Aurora​

可以这样理解：

RDS
→ Managed Relational Database Service 家族

Aurora
→ AWS 自研的 MySQL/PostgreSQL-compatible
  Managed Relational Database Engine

如果企业必须使用：Oracle、SQL Server、Db2、MariaDB；Aurora 显然不是对应答案。

6-★★★★★-Amazon-DynamoDB​

6.1-★★★★★-Amazon-DynamoDB​

[CURRENT-IN-SCOPE]；正式名称：Amazon DynamoDB；它不是一个缩写。Dynamo；有：动力机 / 发电机；等含义，这里主要是产品名的一部分。DB；=；Database、数据库

6.2-DynamoDB-到底是什么？​

AWS 当前定义的核心：Serverless、Fully Managed、Distributed、NoSQL Database；并提供：Key-Value、Document；数据模型。核心特征：大规模、低延迟、自动扩展能力强、不需要管理数据库服务器

6.3-DynamoDB-的核心对象​

最基础：Table、Item、Attribute；例如：Cart Table；其中一条 Item：

{
  "user_id": "u-1001",
  "items": [
    {"sku": "p-001", "qty": 2},
    {"sku": "p-009", "qty": 1}
  ],
  "updated_at": "2026-09-05T10:00:00Z"
}

这里：

Item
≈ 一条数据记录

Attribute
≈ 数据属性

6.4-DynamoDB-Primary-Key​

DynamoDB 的关键概念：Primary Key；最基础可能是：Partition Key；或者：Partition Key、+、Sort Key

6.5-Partition-Key-是什么？​

Partition；=；分区；Partition Key；不只是：“业务主键的另一个名字”；它还与 DynamoDB：数据如何分布；密切相关。例如：user_id；可以作为购物车表的 Partition Key。访问：

user_id = u-1001

就能定位相关数据。

6.6-Sort-Key-是什么？​

Sort Key；=；排序键；Composite Primary Key：Partition Key、+、Sort Key；例如：PK: user_id、SK: created_at；可以把：同一个用户的一组数据；按照 Sort Key 组织。CLF-C02 不要求深入 Single-table Design，但要知道：DynamoDB、不是传统 Row / Foreign Key / Join 思维的直接复制。

6.7-DynamoDB-为什么适合购物车？​

GlobalShop：

User
 │
 ▼
user_id
 │
 ▼
Shopping Cart

需求：按 user_id 快速读写、流量可能非常大、双十一瞬时增长、不需要复杂多表 Join；于是：DynamoDB；非常自然。

6.8-DynamoDB-Serverless-的含义​

Serverless；不是：AWS 没有服务器；而是：用户不管理数据库服务器实例。你更关注：Table、Key、Item、Capacity Mode、Access Pattern；而不是：哪个 EC2、哪个 OS、数据库软件怎么安装

6.9-DynamoDB-Capacity-Mode​

最重要的两种思路：On-Demand、Provisioned

6.9.1-On-Demand​

按请求使用、适合流量不可预测、自动适应读写需求

6.9.2-Provisioned​

事先配置读写 Capacity、适合可预测工作负载；CLF-C02 重点：variable traffic、unknown traffic、automatic scaling / serverless simplicity；经常与 DynamoDB On-Demand 思路相关。

6.10-★★★-DynamoDB-Global-Tables​

Global Tables；=；全局表；用于：Multi-Region、多区域复制；例如 GlobalShop：

Tokyo
DynamoDB
   │
   ├──────────────┐
   ▼              ▼
Virginia       Frankfurt
DynamoDB       DynamoDB

适合：全球低延迟访问、Multi-Region resilience；完整 Multi-Region 架构会在后面章节再深入。

6.11-★★★-DynamoDB-Streams​

Streams；=；变更数据流；当 DynamoDB Item：Insert、Update、Delete；时，可以产生变化记录。典型：

DynamoDB
   │
   │ change
   ▼
DynamoDB Streams
   │
   ▼
Lambda

例如：

订单状态变化
↓
触发后续异步处理

完整 Event-driven Architecture 会在 C2-11 继续讲。

6.12-★★-DynamoDB-TTL​

TTL；=；Time To Live、生存时间；可以为数据设置：到期时间；适合：临时 Session、临时 Token 记录、过期业务数据；但不要把：TTL；理解成：Backup

6.13-★★★★★-RDS-vs-DynamoDB​

维度RDS / AuroraDynamoDB
类型RelationalNoSQL
数据模型Table / RelationKey-Value / Document
SQL / Join核心能力不是传统关系 Join 模型
Server 管理AWS 托管，但有 DB Instance 概念Serverless
典型订单、财务、关系数据购物车、Session、大规模 Key-Value
Scaling 思维Instance / Replica / StoragePartition / Capacity / Serverless Scaling

最重要：

有关系、事务、SQL
→ RDS / Aurora

Key-Value、大规模、简单访问模式
→ DynamoDB

不是绝对规则，但这是 CLF 层最重要的判断框架。

7-★★★★★-Amazon-ElastiCache​

7.1-★★★★-Amazon-ElastiCache​

[CURRENT-IN-SCOPE]；正式名称：Amazon ElastiCache；名称可以拆成：Elastic、+、Cache； 中文：弹性缓存

7.2-★★★★★-Cache-是什么？​

Cache；=；缓存；缓存的核心：把“经常使用、读取成本较高”的数据、放到更快的位置，、减少对后端系统的访问。例如：

Application
    │
    ▼
ElastiCache
    │
    │ cache miss
    ▼
RDS

7.3-为什么-Database-前面还需要-Cache？​

假设商品详情：

product_id = 12345

一秒被请求：100,000 次如果每一次都：

Application
↓
RDS
↓
复杂 Query

数据库压力会很大。可以：

第一次：
Application
↓
RDS
↓
结果放 Cache

以后：
Application
↓
Cache
↓
快速返回

7.4-Cache-Hit-与-Cache-Miss​

Cache Hit；=；缓存命中；即：需要的数据在 Cache 里；Cache Miss；=；缓存未命中；即：

Cache 没有
↓
去 Database / Backend 读取

这两个词以后会经常出现。

7.5-Cache-Aside-Pattern​

一个非常常见的缓存模式：

Application
     │
     ▼
Check Cache
     │
     ├── Hit
     │    └── Return
     │
     └── Miss
          │
          ▼
        Database
          │
          ▼
      Put Cache
          │
          ▼
        Return

叫：Cache-Aside；CLF 不要求实现代码，但这个图能解释：为什么 ElastiCache 能降低 Database Load

7.6-ElastiCache-当前支持的引擎​

当前 AWS ElastiCache 支持：Valkey、Memcached、Redis OSS；并提供：Serverless Cache、Node-based Cluster；两类运行方式。这也是一个当前状态需要注意的点：旧资料经常只写：Redis / Memcached；现在官方已经把：Valkey；列为重要引擎选项。

7.7-Redis-/-Valkey-风格与-Memcached-的基础区别​

CLF-C02 不需要深挖底层协议。最基础：

7.7.1-Valkey-/-Redis-OSS​

通常具备更丰富的数据结构与能力，常用于：Cache、Session、Counter、Leaderboard、Pub/Sub 等

7.7.2-Memcached​

模型更简单，主要是：distributed memory cache；考试如果只是问：managed in-memory cache；服务层答案通常先看：ElastiCache；而不是强行要求选择具体 Engine。

7.8-ElastiCache-最大的理解误区​

错误：

ElastiCache
=
“更快的 RDS”

不对。ElastiCache 是：In-Memory Data Store / Cache；典型架构：

Application
   │
   ├── Cache
   │     └── ElastiCache
   │
   └── Source of Truth Database
         └── RDS / Aurora / DynamoDB 等

很多场景下：Cache、不是唯一的永久业务事实来源

7.9-Cache-Invalidation-为什么重要？​

Invalidation；=；失效 / 使缓存无效；例如：商品价格：、1000 円；数据库改成：800 円但 Cache 还是：1000 円用户就可能看到旧数据。所以 Cache 不是：“加上以后系统一定更简单”；它会引入：Expiration、Invalidation、Consistency；等问题。CLF 不要求设计完整一致性方案，但需要知道：Cache、是性能优化层，、不是免费的魔法。

7.10-GlobalShop：RDS-+-ElastiCache​

User
 │
 ▼
Application
 │
 ├─────► ElastiCache
 │          │
 │          │ Miss
 │          ▼
 └─────► Aurora / RDS

例如：商品详情、店铺配置、热门数据、Session；可以利用 Cache。

7.11-DynamoDB-与-Cache​

DynamoDB 本身已经以：低延迟、大规模；为目标设计。但一些场景还可以有：DAX、DynamoDB Accelerator；作为 DynamoDB 专用的 In-Memory Acceleration。不过在这套 719 题中它并不是高频核心考点，CLF-C02 当前复习优先级明显低于：DynamoDB、ElastiCache；因此只建立概念，不深入。

8-★★★★★-DocumentDB与Neptune​

8.1-★★★-Amazon-DocumentDB​

[CURRENT-IN-SCOPE]；正式名称：Amazon DocumentDB、(with MongoDB compatibility)； 中文：Amazon 文档数据库

8.2-Document-Database-是什么？​

Document；=；文档；这里不是 Word / PDF 文档。而是类似：

{
  "product_id": "p-1001",
  "name": "Camera",
  "attributes": {
    "color": "black",
    "sensor": "full-frame"
  },
  "tags": ["camera", "pro"]
}

这种：JSON-like Document；数据模型。

8.3-为什么需要-Document-Database？​

某些业务数据结构变化频繁。例如不同商品：

手机：
CPU
Memory
Screen

衣服：
Color
Size
Material

相机：
Sensor
Lens Mount
Resolution

如果所有属性都强制放进固定关系表，Schema 设计可能很复杂。Document Model 可以更加灵活。

8.4-Amazon-DocumentDB-与-MongoDB​

Amazon DocumentDB 的完整产品名强调：with MongoDB compatibility；核心意思：很多 MongoDB Application Code、Driver、Tool；可以较容易迁移 / 适配。但是：MongoDB compatibility、≠、Amazon DocumentDB 就是 MongoDB Server 原封不动托管版；AWS 官方也单独维护：Compatibility、Functional Differences；文档。

所以考试层级应该记：

MongoDB-compatible；document database
→ Amazon DocumentDB

不要推导成：100% 完全相同实现

8.5-DocumentDB-vs-DynamoDB​

两者都不是传统关系数据库，但定位不同。

8.5.1-DynamoDB​

Serverless distributed NoSQL、Key-Value / Document、大规模 operational workload

8.5.2-DocumentDB​

Managed Document Database、MongoDB compatibility、Document-oriented application；题目出现：MongoDB-compatible；是 DocumentDB 非常强的识别词。

8.6-★★★-Amazon-Neptune​

[CURRENT-IN-SCOPE]；正式名称：Amazon Neptune；Neptune；=；海王星；同样是产品名，不是缩写。

8.7-Graph-Database-是什么？​

Graph；=；图；Graph Database；=；图数据库；它特别适合：实体之间存在大量关系、并且查询重点是“沿着关系走”；例如：

User A
  │ follows
  ▼
User B
  │ bought
  ▼
Product X
  │ belongs_to
  ▼
Category Camera

8.8-Graph-中的-Node-与-Edge​

最基础：

Node
→ 节点 / 实体

Edge
→ 边 / 关系

例如：

Alice ──FRIEND──► Bob
Bob   ──BOUGHT──► Camera

注意：这里的：Edge；和：AWS Edge Location；不是同一个概念。

8.9-Neptune-适合什么？​

AWS 官方典型场景包括：Recommendation、Fraud Detection、Knowledge Graph、Network Security、Highly Connected Data；GlobalShop 可以用于：

User
  ├── viewed
  ├── bought
  ├── follows
  └── similar_to
       │
       ▼
     Product

如果要分析：A 用户购买了什么、A 的朋友又购买了什么、哪些商品共同被相似用户购买；Graph Model 很自然。

8.10-Neptune-vs-RDS​

RDS：关系表、SQL、Join、Transaction；Neptune：Graph、Node、Edge、Relationship Traversal；关系数据库当然也能保存：relationship；但如果核心工作负载是：高连接图关系查询；Graph Database 更合适。

8.11-Neptune-vs-DocumentDB-vs-DynamoDB​

DynamoDB
→ Key-Value / Document NoSQL
→ 大规模 operational access

DocumentDB
→ Document
→ MongoDB compatibility

Neptune
→ Graph
→ Highly connected relationships

这是 CLF-C02 需要建立的服务地图。

9-★★★★★-Redshift与分析型数据库​

9.1-★★★★-Amazon-Redshift​

[CURRENT-IN-SCOPE]；Amazon Redshift；是：Fully Managed Data Warehouse；当前 AWS 还提供：Redshift Serverless；但是：Redshift；的完整深入内容属于：C2-12-数据分析与大数据.md；这里仅建立数据库体系中的位置。

9.2-OLTP-与-OLAP​

理解 Redshift 最有用的两个词：

9.2.1-OLTP​

Online Transaction Processing、在线事务处理；例如：创建订单、修改订单、付款、库存扣减；典型：RDS / Aurora

9.2.2-OLAP​

Online Analytical Processing、在线分析处理；例如：过去三年每个国家销售额、每个品类利润率、数十亿订单聚合分析；典型：Data Warehouse、Redshift

9.3-★★★★★-RDS-vs-Redshift​

这也是高频混淆。RDS：Operational Relational Database、OLTP、业务实时读写；Redshift：Data Warehouse、Analytics、大规模聚合分析；如果题目说：petabyte-scale data warehouse、BI、analytics、complex aggregation；重点考虑：Redshift；而不是：RDS

9.4-题库典型：Petabyte-scale-Data-Warehouse​

题库中有典型题：petabyte-scale data warehouse、analyze its data、fully managed、no manual hardware/software management；选项包括：DocumentDB、Redshift、Neptune、ElastiCache；本质是判断：Document、Graph、Cache、Data Warehouse；不是比较谁“更高级”。需求：Data Warehouse；直接定位：Redshift

10-★★★★★-GlobalShop数据架构与扩展​

10.1-Database-与-Cache-完整分层​

GlobalShop 可以这样理解：

                  Application
                      │
                      ▼
                  ElastiCache
                      │
                  Cache Miss
                      │
          ┌───────────┼───────────┐
          │           │           │
          ▼           ▼           ▼
     RDS/Aurora    DynamoDB    DocumentDB
       Orders       Cart        Flexible Docs
          │
          └──────────────┐
                         │
                         ▼
                    Analytics ETL
                         │
                         ▼
                      Redshift

关系数据：RDS / Aurora；Key-Value：DynamoDB；Document：DocumentDB；关系网络：Neptune；Cache：ElastiCache；分析仓库：Redshift

10.2-GlobalShop-数据库业务映射​

一种教学性的简化映射：

GlobalShop 业务可考虑的 AWS 服务
订单 / 支付 / 核心交易RDS / Aurora
购物车DynamoDB
大规模 Session / Key-ValueDynamoDB
热门商品 CacheElastiCache
灵活 JSON DocumentDocumentDB
推荐关系 / 欺诈关系Neptune
BI / 历史分析Redshift

注意：这是教学架构，、不是说真实电商平台只能这样设计。真实架构会根据：规模、团队、访问模式、一致性、成本、现有技术栈；变化。

10.3-Polyglot-Persistence​

Polyglot；=；多种语言 / 多种技术并存；Polyglot Persistence；可以理解：一个系统不强迫所有数据都放同一种 Database，、而是不同 Workload 使用更合适的数据存储技术。GlobalShop：

Order
→ Aurora

Cart
→ DynamoDB

Cache
→ ElastiCache

Graph
→ Neptune

Analytics
→ Redshift

现代大型系统经常是这种思路。

10.4-但不要为了“技术多”而多数据库​

Polyglot Persistence 不是：服务越多越高级；每增加一种数据库，都会增加：开发成本、监控、权限、备份、一致性、数据同步、团队学习成本、故障排查复杂度；所以真实工程中还要考虑：是否真的需要；CLF-C02 主要训练：在明确需求下选择匹配服务

10.5-Scaling-Database-的几种思路​

Database Scaling 可以粗略分：Vertical Scaling、Horizontal Read Scaling、Partitioning / Distributed Scaling、Caching

10.6-Vertical-Scaling​

Vertical Scaling；=；纵向扩展；例如：

DB Instance
4 vCPU / 16 GB
↓
16 vCPU / 64 GB

RDS / Aurora 仍然存在：DB Instance Size；概念。

10.7-Read-Scaling​

Read Scaling；=；读取扩展；例如：

Primary
   │
   ├── Read Replica 1
   ├── Read Replica 2
   └── Read Replica 3

把读请求分出去。RDS Read Replica、Aurora Reader 都属于这一类思路。

10.8-Distributed-/-Partition-Scaling​

DynamoDB 更强调：Distributed、Partitioned、Serverless；数据根据 Key 分布，AWS 帮你管理底层大量扩展复杂度。所以：RDS；和：DynamoDB；的扩展思维并不相同。

10.9-Caching​

第四个方向：不要每次都让 Database 做同样查询。于是：Database、+、ElastiCache；可以降低：Read Load、Latency

11-★★★★★-高可用安全与迁移​

11.1-High-Availability-与-Database​

对于数据库：High Availability；不等于：Backup；例如 RDS：

Multi-AZ
→ HA / Failover

而：

Automated Backup / Snapshot
→ Recovery

两者都重要。

11.2-Database-Backup-与-Read-Replica-不一样​

Read Replica：数据持续复制、主要用于读扩展；Backup：保留可恢复历史状态；如果 Application 发出错误：

DELETE FROM orders;

Read Replica 可能也复制这个变化。Backup 可能让你：恢复到删除之前；所以：Replica、≠、Backup

11.3-RDS-Shared-Responsibility​

AWS 负责很多：Physical Infrastructure、Host、Managed OS Layer、Database Installation、部分 Patch / Backup Infrastructure；客户仍负责：Database Account、Data、Schema、Query、Index、Encryption / Access Configuration、Application Security；Managed Service：

减少运维责任、≠、消灭客户责任

11.4-DynamoDB-Shared-Responsibility​

DynamoDB 更 Serverless：你不管理：DB Server、OS、Cluster Node；但是仍然需要管理：Table Design、Key Design、IAM、Data、Capacity Mode / Limits、Application Access、Backup / PITR Configuration；抽象越高，客户管理的基础设施越少，但业务数据责任仍然存在。

11.5-Database-Security-在哪里继续深入？​

本章只建立：Database 本身是什么；下面这些会在其他章节继续：

VPC
Security Group
Subnet
→ C2-06

IAM
→ C2-08

KMS / Encryption / Secrets Manager
→ C2-09

Monitoring
→ C2-10

不要把一章写成所有 AWS 服务的重复大全。

11.6-Database-Migration-在哪里？​

题库里会出现：AWS Database Migration Service、AWS DMS；DMS；=；Database Migration Service、数据库迁移服务；它解决：数据库怎么迁移；而不是：业务数据库最终是什么；所以完整内容放：C2-14-迁移数据传输与混合云；这里只记：

RDS / Aurora / DynamoDB
→ Database Target / Platform

DMS
→ Migration

12-★★★★★-选型决策与高频错误​

12.1-最重要的数据库选择树​

需要 Database
   │
   ├── 传统关系数据 / SQL / Transaction？
   │      │
   │      ├── 普通 Managed Relational Engines
   │      │      └── RDS
   │      │
   │      └── MySQL/PostgreSQL-compatible AWS Engine
   │             └── Aurora
   │
   ├── Key-Value / Document NoSQL、大规模 Serverless？
   │      │
   │      └── DynamoDB
   │
   ├── MongoDB-compatible Document Database？
   │      │
   │      └── DocumentDB
   │
   ├── Highly Connected Graph？
   │      │
   │      └── Neptune
   │
   ├── In-Memory Cache？
   │      │
   │      └── ElastiCache
   │
   └── Data Warehouse / BI / Analytics？
          │
          └── Redshift

12.2-高频关键词映射​

relational
SQL
managed relational database
→ RDS

MySQL-compatible / PostgreSQL-compatible AWS relational engine
→ Aurora

NoSQL
key-value
serverless database
massive scale
→ DynamoDB

in-memory cache
reduce database load
low latency cache
→ ElastiCache

MongoDB-compatible
document database
→ DocumentDB

graph
highly connected data
recommendation relationship
fraud graph
→ Neptune

data warehouse
petabyte-scale analytics
BI
→ Redshift

12.3-常见错误-1：NoSQL-=-没有-Schema​

不准确。NoSQL 不代表：数据随便乱写、没有设计；DynamoDB 仍然需要非常认真设计：Partition Key、Sort Key、Access Pattern、Index；DocumentDB 也有：Document Structure、Index、Query Pattern；区别是：数据模型、不是传统关系表设计的简单复制

12.4-常见错误-2：DynamoDB-=-Managed-MongoDB​

错误。

DynamoDB
→ AWS serverless distributed NoSQL
  Key-Value / Document

DocumentDB
→ MongoDB-compatible Document Database

看到：MongoDB；优先想到：DocumentDB

12.5-常见错误-3：Aurora-=-NoSQL​

错误。Aurora 是：Relational、MySQL-compatible、PostgreSQL-compatible

12.6-常见错误-4：ElastiCache-=-永久数据库替代品​

不应该这样理解。ElastiCache 的核心定位：In-Memory Cache / Data Store；典型用于：降低数据库压力、减少 Latency、保存 Session / Hot Data；很多业务仍需要：Durable Source of Truth

12.7-常见错误-5：Multi-AZ-=-Read-Scaling​

经典 Multi-AZ DB Instance：主要解决 HA；Read Replica：主要解决 Read Scaling；这是考试中非常容易反着选的点。

12.8-常见错误-6：Read-Replica-=-Backup​

错误。

Read Replica
→ 当前数据副本 / Read Scaling

Backup / Snapshot
→ 历史恢复点

12.9-常见错误-7：Redshift-=-更大的-RDS​

Redshift 是：Data Warehouse / Analytics；而不是单纯：“RDS 容量不够了，、换一个超大 RDS。”；工作负载不同：OLTP、vs、OLAP

12.10-常见错误-8：RDS-管理一切，所以客户不用管安全​

不对。Managed Database 仍有：Shared Responsibility；客户仍管理：Data、Identity、Access、Schema、Application、Configuration

13-★★★★★-GlobalShop链路与本章总结​

13.1-GlobalShop-最终-Database-+-Cache-架构​

                           Global Users
                                │
                                ▼
                         Application Layer
                                │
          ┌─────────────────────┼─────────────────────┐
          │                     │                     │
          ▼                     ▼                     ▼
     ElastiCache            DynamoDB             Aurora / RDS
   Hot Data / Cache        Cart / KV           Order / Payment
          │                                           │
          │                                           │
          └────────── cache miss ─────────────────────┘
                                │
             ┌──────────────────┼───────────────────┐
             │                  │                   │
             ▼                  ▼                   ▼
        DocumentDB           Neptune             Redshift
        Documents            Graph              Analytics

横向还有：IAM、KMS、Secrets Manager、CloudWatch、AWS Backup；后面章节继续补全。

13.2-用户访问商品页面时-Database-如何参与？​

例如：GET /products/12345；可能：

Application
    │
    ▼
ElastiCache
    │
    ├── Hit
    │     └── Return Product
    │
    └── Miss
          │
          ▼
      DynamoDB / RDS / DocumentDB
          │
          ▼
       Cache Result
          │
          ▼
        Return

这里：Cache、Database；是两个不同层。

13.3-用户下订单时-Database-如何参与？​

User
 │
 ▼
Order API
 │
 ▼
Aurora / RDS
 │
 ├── Create Order
 ├── Create Order Items
 ├── Transaction
 └── Commit

成功后可以：

Event
↓
SQS / EventBridge
↓
其他服务

消息体系放在 C2-11。

13.4-双十一时-Database-层怎么思考？​

不是只说：“加服务器”；要分别考虑：

Application Compute
→ Auto Scaling / ECS / Fargate

Hot Read
→ ElastiCache

Relational Read
→ Read Replica / Aurora Reader

Key-Value Traffic
→ DynamoDB Scaling / On-Demand

Analytics
→ Redshift

也就是：不同层分别扩展

13.5-本章最重要的服务表​

服务类型最核心用途
RDSManaged Relational DB托管 MySQL/PostgreSQL/Oracle/SQL Server/MariaDB/Db2 等
AuroraRelational DBAWS MySQL/PostgreSQL-compatible relational engine
DynamoDBServerless NoSQLKey-Value / Document，大规模低延迟
ElastiCacheIn-Memory Cache降低后端数据库压力、低延迟
DocumentDBDocument DBMongoDB-compatible document workloads
NeptuneGraph DBHighly connected data
RedshiftData WarehouseAnalytics / BI / OLAP

13.6-本章重要英文词汇​

13.6.1-Database​

数据库

13.6.2-Relational-Database​

关系数据库

13.6.3-Database-Engine​

数据库引擎

13.6.4-SQL​

Structured Query Language、结构化查询语言

13.6.5-NoSQL​

非传统关系型数据库体系 / Not Only SQL

13.6.6-Table​

表

13.6.7-Row​

行 / 记录

13.6.8-Column​

列 / 字段

13.6.9-Primary-Key​

主键

13.6.10-Foreign-Key​

外键

13.6.11-Transaction​

事务

13.6.12-Read-Replica​

只读副本

13.6.13-Standby​

备用实例 / 待机

13.6.14-Failover​

故障切换

13.6.15-Partition-Key​

分区键

13.6.16-Sort-Key​

排序键

13.6.17-Cache​

缓存

13.6.18-Cache-Hit​

缓存命中

13.6.19-Cache-Miss​

缓存未命中

13.6.20-In-Memory​

内存中

13.6.21-Document-Database​

文档数据库

13.6.22-Graph-Database​

图数据库

13.6.23-Data-Warehouse​

数据仓库

13.6.24-OLTP​

Online Transaction Processing、在线事务处理

13.6.25-OLAP​

Online Analytical Processing、在线分析处理

13.7-CLF-C02-层级真正应该掌握什么？​

不需要深入：B-Tree 内部实现、MVCC 算法、Redo Log、WAL、数据库锁算法、DynamoDB 内部分区实现、Redis 源代码、Query Optimizer；但一定要会：

RDS 是什么
Aurora 是什么
DynamoDB 是什么
ElastiCache 是什么
DocumentDB 是什么
Neptune 是什么
Redshift 是什么

Multi-AZ vs Read Replica
SQL vs NoSQL
Database vs Cache
OLTP vs OLAP

13.8-本章压缩成一张图​

                          AWS Data Layer
                               │
      ┌────────────┬───────────┼───────────┬────────────┐
      │            │           │           │            │
      ▼            ▼           ▼           ▼            ▼
 Relational      NoSQL       Cache       Document      Graph
      │            │           │           │            │
      ▼            ▼           ▼           ▼            ▼
 RDS/Aurora     DynamoDB   ElastiCache  DocumentDB    Neptune

                               │
                               ▼
                          Analytics
                               │
                               ▼
                            Redshift

13.9-最重要的八句话​

1. RDS = Managed Relational Database Service。
2. Aurora = MySQL/PostgreSQL-compatible AWS relational database engine。
3. Multi-AZ 的核心是 High Availability / Failover。
4. Read Replica 的核心是 Read Scaling。
5. DynamoDB = Serverless Fully Managed NoSQL，核心是 Key-Value / Document。
6. ElastiCache = In-Memory Cache，用来降低 Latency 和 Database Load。
7. DocumentDB = MongoDB-compatible Document Database；Neptune = Graph Database。
8. Redshift = Data Warehouse，不是普通 OLTP RDS。

13.10-AWS-官方资料​

Amazon RDS：AWS 官方文档：What is Amazon RDS?；RDS Multi-AZ：

AWS 官方文档：Configuring and managing a Multi-AZ deployment；RDS Read Replicas：

AWS 官方文档：Working with DB instance read replicas；Amazon Aurora：

AWS 官方文档：What is Amazon Aurora?；Amazon DynamoDB：

AWS 官方文档：What is Amazon DynamoDB?；DynamoDB Core Components：

AWS 官方文档：Core components of Amazon DynamoDB；Amazon ElastiCache：

AWS 官方文档：What is Amazon ElastiCache?；Amazon DocumentDB：AWS 官方文档：What is Amazon DocumentDB?

Amazon DocumentDB MongoDB Compatibility：AWS 官方文档：Amazon DocumentDB compatibility with MongoDB；Amazon Neptune：

AWS 官方文档：What is Amazon Neptune?；Amazon Redshift：AWS 官方文档：What is Amazon Redshift?

13.11-下一章​

到这里：Compute、Storage、Database；已经建立。但是所有这些资源都不能悬浮在空气里。还需要解决：EC2 放在哪个网络？、Subnet 是什么？、Public / Private 是什么？、Internet 怎么进来？、Database 为什么通常不直接暴露公网？、Security Group 在哪里生效？、Route Table 怎么决定流量去哪？于是下一章正式进入：C2-06-VPC与基础网络.md；核心主线：

Network
│
├── Amazon VPC
├── CIDR
├── Subnet
├── Route Table
├── Internet Gateway
├── NAT Gateway
├── Security Group
└── Network ACL