数据存储的三种形态
大多数数据库分为三个家族。你不需要去背产品——你需要认出哪种形态适合你的问题。
| 类型 | 例子 | 最适合 | 取舍 |
|---|---|---|---|
| 关系型（） | PostgreSQL, MySQL, SQLite | 带关系的结构化数据；任何与金钱或准确性相关的关键场景 | 你必须预先设计 schema；把写入扩展到非常大的规模更难 |
| 文档型 / | MongoDB, Firestore, DynamoDB | 灵活或嵌套的数据、快速迭代、形态各异的记录 | 容易产生不一致的数据；关系和报表处理起来很别扭 |
| 键值型 | Redis, Memcached, Cloudflare KV | 缓存、会话、计数器、按已知键的快速查找 | 无法按内容查询；通常不是你的事实来源 |
这三种形态以确实不同的方式存储数据。把它们并排来看：
关系型 (SQL) 文档型 (NoSQL) 键值
行 + 列 自包含的数据块 一键 → 一值
┌────┬───────┬──────┐ ┌──────────────────┐ ┌─────────┬─────────┐
│ id │ email │ name │ │ { │ │ key │ value │
├────┼───────┼──────┤ │ id, email, │ ├─────────┼─────────┤
│ 1 │ a@... │ Ana │ │ name, │ │ session │ "x9f2" │
│ 2 │ b@... │ Bob │ │ posts: [ ... ] │ │ count │ "42" │
└────┴───────┴──────┘ │ } │ └─────────┴─────────┘
表彼此 └──────────────────┘ 内部无法查询 —
相互引用 一切都嵌套着 只能按键查找
把关系型数据库想象成一组彼此知道如何相互引用的电子表格。你用来跟它对话的语言就是 SQL（Structured Query Language，结构化查询语言）。对 90% 的项目来说一个好的默认选择：从关系型数据库（Postgres）开始。 它成熟、可预测、强制结构化，并能处理真实应用不可避免会长出来的关系。当你的数据确实没有固定形态时，再去考虑文档存储；而键值存储则作为一个辅助层（缓存），而不是你的主存储。
要避免的陷阱是凭感觉选。"NoSQL（不使用 SQL 表的数据库——它存储灵活、自由形态的记录）扩展性更好"只对一小撮大多数应用永远碰不到的问题成立，而即便如此，代价也是放弃那些让数据可信赖的一致性保证。挑选与你的数据相匹配的形态，而不是在系统设计视频里听起来最唬人的那个。拿不准时，关系型是稳妥的选择——缓存或文档存储你以后随时可以加上，但解开一团乱麻的 NoSQL 数据模型却很痛苦。