数据存储的三种形态
大多数数据库分为三个家族。你不需要去背产品——你需要认出哪种形态适合你的问题。
| 类型 | 例子 | 最适合 | 取舍 |
|---|---|---|---|
| 关系型（SQL） | PostgreSQL, MySQL, SQLite | 带关系的结构化数据；任何与金钱或准确性相关的关键场景 | 你必须预先设计 schema；把写入扩展到非常大的规模更难 |
| 文档型 / NoSQL | MongoDB, Firestore, DynamoDB | 灵活或嵌套的数据、快速迭代、形态各异的记录 | 容易产生不一致的数据；关系和报表处理起来很别扭 |
| 键值型 | Redis, Memcached, Cloudflare KV | 缓存、会话、计数器、按已知键的快速查找 | 无法按内容查询；通常不是你的事实来源 |
对 90% 的项目来说一个好的默认选择：从关系型数据库（Postgres）开始。 它成熟、可预测、强制结构化，并能处理真实应用不可避免会长出来的关系。当你的数据确实没有固定形态时，再去考虑文档存储；而键值存储则作为一个辅助层（缓存），而不是你的主存储。
要避免的陷阱是凭感觉选。"NoSQL 扩展性更好"只对一小撮大多数应用永远碰不到的问题成立，而即便如此，代价也是放弃那些让数据可信赖的一致性保证。挑选与你的数据相匹配的形态，而不是在系统设计视频里听起来最唬人的那个。拿不准时，关系型是稳妥的选择——缓存或文档存储你以后随时可以加上，但解开一团乱麻的 NoSQL 数据模型却很痛苦。