NoSQL 是 “Not Only SQL”——不是不要 SQL，而是为特定数据模型与扩展方式做取舍。看懂四类 NoSQL 各自的定位，以及背后的 CAP 动机，选型就不再是追热点。

四类 NoSQL 的定位对比

类型 代表产品 数据模型 强项 典型场景
键值（KV） Redis、DynamoDB Key → Value，结构极简 内存级读写、结构体丰富、延迟极低 缓存、会话、计数器、分布式锁
文档 MongoDB、CouchDB BSON/JSON 文档，可嵌套 schema 灵活、单对象内聚、查询能力较强 内容管理、商品目录、日志、用户画像
列族（宽列） Cassandra、HBase 按列族组织的稀疏大表 海量数据写入吞吐、范围扫描、水平扩展 时序数据、监控指标、消息存储
图 Neo4j、Neptune 节点 + 边 多跳关系遍历天然高效 社交关系、推荐、风控关联分析、知识图谱

记忆要点：KV 管「快」，文档管「灵活」，列族管「大」，图管「关系」。一个常见误解是 NoSQL 不能存关系型数据——能存，只是表达关系的方式不同：文档靠内嵌，图靠显式的边，列族靠行键设计。

SQL 与 NoSQL 的关键差异

维度 关系型 NoSQL
数据模型 固定表结构，先定义后写入 灵活 schema，结构随数据演进
扩展方式 垂直扩展为主，加分库分表 原生分片，横向加机器
事务 成熟的 ACID 多数最终一致，部分支持有限事务
查询 标准 SQL API 与查询语言因产品而异
适用 强一致、复杂关联、通用业务 海量、高并发、访问模式明确的场景

CAP 视角的选型动机

CAP 定理说，分布式系统在网络分区（P）发生时，只能在一致性（C）与可用性（A）之间二选一。而网络分区在分布式环境里迟早发生，所以真实的选择题是：分区来了，你要 C 还是 A？

  • 选 CP：宁可拒绝服务也不返回旧数据。HBase、MongoDB（默认主节点读写）走这条路——适合订单、库存这类读错就出事的场景。
  • 选 AP：宁可返回旧数据也要响应。Cassandra、DynamoDB、Redis Cluster 走这条路——适合 feeds、浏览计数这类「旧几秒无所谓」的场景。

业务上要把「可接受多旧」写成明确答案：购物车缓存旧几分钟可以，账户余额不行。CAP 不是背概念，而是把这个权衡从隐式变成显式。

什么时候不该用 NoSQL

这是比「什么时候用」更重要的问题：

  1. 强跨实体事务：转账、清结算这类必须 ACID 的链路，NoSQL 的最终一致或有限事务撑不住，关系库仍是主力。
  2. 复杂关联与即席分析：JOIN 密集、查询模式不确定的报表分析，是关系模型与 OLAP 的主场；拿 MongoDB 做复杂报表，等于把 JOIN 搬到应用层重写。
  3. 团队运维能力不足：分片、副本、扩容、备份的运维复杂度是隐性成本，数据量没到量级时，单机关系库加分表往往更经济。
  4. 把 NoSQL 当银弹：「关系库慢所以换 NoSQL」是伪命题——多数慢查询是索引和 SQL 的问题，不是模型的问题。

务实的路径是：先用关系库把业务跑顺，出现明确瓶颈（单机容量、写入吞吐、特定访问延迟）再引入对应的 NoSQL，跨存储一致性用 Outbox、CDC 或补偿任务兜底，而不是幻想双写一致。

小结

  • 四类 NoSQL：KV 求快、文档求灵活、列族求海量、图求关系遍历。
  • CAP 的意义是在分区发生时明确选 C 还是选 A，并让业务方认可这个取舍。
  • 强事务、复杂关联、团队储备不足，这三种情况请留在关系型世界。