决策：SQL 还是 NoSQL（哪个数据库家族）？

选择正确的数据库家族取决于数据模型的形态、一致性与扩展性的优先级，以及查询复杂度。“NoSQL 更现代”之类的概括具有误导性；每个家族都是为特定访问模式设计的。这棵决策树从数据结构出发，引导你在关系型、文档型、键值和搜索引擎中选择合适的工具，并在需要时提醒你采用多语言持久化（polyglot）方式。

数据的性质和主要访问模式是什么？

从最具决定性的问题开始：数据是具有强关联的结构化记录、具有灵活/可变模式的文档、简单的键值查找，还是文本搜索等特殊需求？数据的形态和查询方式在很大程度上决定了家族。

• 关系型、结构化记录和复杂查询
• 具有灵活/可变模式的嵌套文档
• 简单键值、极低延迟/缓存
• 全文 / 分面搜索、日志分析

优先考虑强一致性（ACID）还是水平扩展？

数据看起来是关系型的；但你的优先级是什么？多表连接、事务完整性和强一致性（ACID）是必需的，还是要水平扩展单个节点容纳不下的海量数据？关系模型是大多数负载的正确默认选择；只有当规模确实超出单个节点时才会吃力。

• ACID、连接和复杂查询的完整性优先
• 规模高于一切，关系/连接较弱

建议：关系型数据库（RDBMS）

对于数据结构化、关联性强且需要事务完整性的负载，这是正确的默认选择。ACID 保证、成熟的 SQL 查询引擎和连接能力，使其能够可靠地回答复杂问题。

建议：文档数据库

以自然形式（类 JSON 文档）存储模式频繁变化的灵活嵌套数据。适合主要通过单个文档读写、连接需求少且需要水平扩展的应用。

建议：键值存储 / 缓存

专为需要按键进行极快读写且无需复杂查询的负载而设计。通常运行在内存中，提供微秒/毫秒级延迟；非常适合缓存、会话和计数器等任务。

建议：搜索 / 分析引擎

基于倒排索引的引擎，专门用于全文搜索、相关性排序、分面过滤和大规模日志/文本分析。它能提供关系型 LIKE 查询无法实现的搜索体验。