如何设计键值存储 schema

设计键值存储（Key-Value Store）的 schema，核心思路是：用“键”表达访问路径，用“值”承载数据，并兼顾查询模式、性能与扩展性。下面从原则、常见模式、反模式到示例逐步说明。

一、设计前先明确几点

1. 查询模式：主要按什么查？单 key 查、前缀查、范围查？
2. 读写比例：读多写多？是否要高频更新？
3. 数据规模：是否会无限增长？是否需要 TTL？
4. 一致性要求：最终一致可否？是否需要原子操作？
5. 存储引擎特性：Redis / RocksDB / DynamoDB / TiKV 差异很大

二、Key 的设计原则

1. 层次化但扁平

用分隔符构造“逻辑层次”，但底层仍是扁平 key：

user:1001:profile
user:1001:orders:202401

常用分隔符：: / #（避免空格）

2. Key 要短且稳定

• 短：节省内存与 IO
• 稳定：避免业务字段变更导致 key 大规模失效

3. 把“查询条件”放 key 里

KV 没有二级索引，查询条件必须在 key 中体现：

device:temperature:room1:20240101

三、常见 Key Schema 模式

模式 1：实体 + ID

user:{userId}
order:{orderId}

值：JSON / Protocol Buffers

模式2：复合键（多维查询）

{entity}:{partition}:{sortKey}
例：
message:user1001:1700000000

• partition：用于分片
• sortKey：用于范围/时间排序

模式 3：前缀扫描（时间序列）

metric:cpu:host1:20240101:10
metric:cpu:host1:20240101:11

用 metric:cpu:host1:20240101: 做前缀扫描

模式 4：标签 / 倒排（手动索引）

user:tag:VIP:1001 -> 1
user:tag:VIP:1002 -> 1

再扫 user:tag:VIP: 得用户列表

模式 5：计数器

stats:page:home:views -> 12345

用原子 incr

四、Value 的设计

• 简单值：数字、字符串
• 结构化：JSON（易调试）、PB / Avro（省空间）
• 大对象：存对象存储，KV 只存指针
• 版本化：value 内含 version 字段

五、典型反模式

❌ 把 SQL 思维搬过来（join、like） ❌ key 过长（user_profile_data_of_xxx） ❌ 用随机 UUID 做纯 key（无法范围查） ❌ 单 key 存超大 value（影响性能）

六、示例：电商用户系统

user:1001:base        -> {"name":"A","age":20}
user:1001:orders      -> ["o1","o2"]
order:o1              -> {...}
user:1001:cart        -> {...}
idx:user:email:a@x.com -> 1001

七、一句话总结

KV schema = 把“怎么查”写进 key，把“是什么”放进 value。

如果你有具体场景（如 Redis / DynamoDB / 自研引擎），我可以给更针对性的 schema 设计。