键值数据库入门：Redis 与 DynamoDB

一个视频，讲透键值数据库，不用学几个月。

第一章 - 键值数据库是什么

这一个视频把键值数据库这一类讲完，重点对比两个代表：{{Redis}} 和 {{DynamoDB}}。

一句话：键值数据库存的是{{键值对}}——给我 key，马上给你 value。没有表、没有关系，就是最快的那条直通路。

对比关系型

关系型 SQL          键值数据库
表（多列多行）        key -> value（一个键一个值）
SELECT 条件查询      GET key 直达

这一类数据库的共同点

• 按 key 精确访问，O(1) 级快。
• 没有复杂 JOIN，牺牲了关系换来极速。
• 适合缓存、会话、状态、点查。

本章小结

键值数据库是"最直接的存储"：key 直达 value。Redis 放内存快，DynamoDB 云托管无限扩展。

第二章 - Redis：内存里的五种数据结构

为什么快

{{内存}} + {{单线程}}事件循环：数据在 RAM 没有磁盘延迟，单线程没有锁竞争。

五种类型

SET user:1 "Ada"              # String：字符串
HSET user:1 name "Ada" age 28 # Hash：对象
LPUSH queue "task1"           # List：队列
SADD tags:1 "python"          # Set：去重
ZADD rank 100 "Ada"           # Sorted Set：排行榜

GET user:1
HGETALL user:1
LRANGE queue 0 -1
SINTER tags:1 tags:2
ZREVRANGE rank 0 9 WITHSCORES

本章小结

String 存值、Hash 存对象、List 当队列、Set 去重、ZSet 排行——五种结构覆盖绝大多数场景。

第三章 - Redis：过期、持久化、高可用

过期与缓存

SETEX session:1 300 "token"   # 300 秒过期
TTL session:1

缓存三坑：{{穿透}}（查不存在的 key 打库）、{{击穿}}（热点 key 过期瞬间打库）、{{雪崩}}（一批 key 同时过期）。

持久化：RDB 快照 + AOF 日志

CONFIG SET appendonly yes    # AOF：追加每条写命令，丢得少
SAVE                         # RDB：整内存快照，恢复快

高可用：主从、哨兵、集群

主从: [主] -> [从] [从]（读写分离）
哨兵: 主挂了自动提升从为主
集群: key 按哈希槽分到多节点（水平扩展）

本章小结

过期做缓存、RDB/AOF 持久化、主从哨兵集群保高可用——Redis 三件套。

第四章 - Redis：经典场景

缓存、会话、排行榜、限流、队列

SET product:1 '{"name":"Book","price":19.99}' EX 300   # 缓存
SETEX session:token 1800 '{"uid":1}'                   # 会话
ZINCRBY leaderboard 1 "Ada"                            # 排行榜
INCR rate:user1                                        # 限流计数
LPUSH queue "order1"                                   # 消息队列

本章小结

Redis 几乎撑起了后端高性能"基础设施"：热点放 Redis，冷数据放磁盘库。

第五章 - DynamoDB：数据模型与主键

AWS 托管的键值库

{{DynamoDB}} 是 AWS 的全托管 NoSQL，不用管服务器，自动扩容，按用量付费。它存的是表（Table），但表里是条目（Item）和属性（Attribute）。

Table: users
├─ 主键 = 分区键 user_id + 排序键 created_at
└─ Item = { user_id: "u1", name: "Ada", age: 28 }

主键设计是关键

• {{分区键 Partition Key}}（Hash Key）：决定数据落在哪个物理分区。
• {{排序键 Sort Key}}（Range Key，可选）：同一分区键内的数据按它排序。

分区键 user_id（哈希分散到不同分区）
排序键 created_at（同一用户的数据按时间排）

主键一旦定下就难改，是 DynamoDB 设计里最重要的一步。

本章小结

DynamoDB 是云托管键值库，Table 装 Item，主键 = 分区键 + 可选排序键，决定一切。

第六章 - DynamoDB：CRUD 与二级索引

基本操作

import boto3
db = boto3.resource("dynamodb", region_name="us-east-1")
table = db.Table("users")

table.put_item(Item={"user_id": "u1", "name": "Ada", "age": 28})   # 写
item = table.get_item(Key={"user_id": "u1"})["Item"]               # 按主键读
table.update_item(Key={"user_id": "u1"},
                  UpdateExpression="SET age = :a",
                  ExpressionAttributeValues={":a": 29})             # 改
table.delete_item(Key={"user_id": "u1"})                           # 删

Query 与 Scan

# Query：只查某个分区键（高效，推荐）
resp = table.query(KeyConditionExpression="user_id = :uid",
                   ExpressionAttributeValues={":uid": "u1"})

# Scan：扫全表（慢，避免）
resp = table.scan()

{{Query}} 走主键、高效；{{Scan}} 全表扫描、又慢又费钱，尽量避免。

二级索引：GSI 和 LSI

• {{GSI 全局二级索引}}：换一个分区键/排序键，跨全表查。
• {{LSI 本地二级索引}}：同一个分区键，换排序键。

GSI：按 email 查用户（email 作为新的分区键）
LSI：同一 user_id，按 update_at 而不是 created_at 排序

本章小结

主键读写用 get/put，查询用 Query 别用 Scan，要按别的字段查就建 GSI/LSI。

第七章 - DynamoDB：容量、一致性、单表设计

容量模式

• {{按需 on-demand}}：按请求付费，适合不可预测流量。
• {{预置 provisioned}}：事先买 RCU（读）/ WCU（写），适合稳定流量。

一致性

• 默认{{最终一致}}读：快，但可能读到旧值。
• {{强一致}}读：保证读到最新，稍慢稍贵。

单表设计 Single Table Design

DynamoDB 没有 JOIN，传统做法是把多类实体塞进{{一张表}}，靠主键前缀区分：

Table: app
├─ USER#u1      -> { name: "Ada" }
├─ ORDER#o1     -> { user_id: "u1", amount: 19.99 }
└─ USER#u1#ORDER#o1 -> { ... }

本章小结

按需/预置选容量，最终/强一致选读取，单表设计是 DynamoDB 的进阶建模法。

第八章 - Redis vs DynamoDB 对比

一句话选型

要极致低延迟的{{缓存/会话}}选 {{Redis}}；要云上{{海量持久化}}、免运维选 {{DynamoDB}}。

本章小结

Redis 是内存加速层，DynamoDB 是云上持久化键值库——一个求快，一个求省心。

第九章 - 用 Python 连接两者

Redis：redis-py

import redis
pool = redis.ConnectionPool(host="localhost", port=6379, max_connections=20)
r = redis.Redis(connection_pool=pool)
r.set("user:1", "Ada")
print(r.get("user:1"))

DynamoDB：boto3

import boto3
db = boto3.resource("dynamodb", region_name="us-east-1")
table = db.Table("users")
table.put_item(Item={"user_id": "u1", "name": "Ada"})
print(table.get_item(Key={"user_id": "u1"})["Item"])

本章小结

redis-py 连 Redis、boto3 连 DynamoDB——都用连接池/客户端，都是"连 -> 写 -> 读"。

第十章 - 什么时候用键值数据库

适合

• 按 key 精确点查、要极快（缓存、会话、排行榜）。
• 海量持久化点查、要免运维（DynamoDB）。

不适合

• 复杂条件查询、JOIN、聚合 -> 关系型或文档型。
• 需要强事务一致性 -> 关系型。

本章小结

键值数据库赢在"点查极快"；要复杂查询就换 SQL，要灵活文档就换 MongoDB。

总结

• 核心回顾：键值数据库 key 直达 value；Redis 内存 + 五种数据结构做缓存/会话/排行榜，RDB/AOF 持久化、主从哨兵集群保高可用；DynamoDB 云托管，主键 = 分区键 + 排序键，Query 高效 Scan 慢，GSI/LSI 扩展查询，单表设计做进阶建模。
• 学习路线：先 redis-cli 练五种类型 -> 再用 Docker 起 DynamoDB Local 练主键和 Query -> 最后各写一个 Python 脚本。
• 推荐练习：① 用 Redis ZSet 做实时排行榜；② 用 DynamoDB Local 建一张带分区键+排序键的表，跑 Query 和 GSI；③ 对比同一个"用户点查"场景，Redis 和 DynamoDB 各自的写法和延迟。