NoSQL 图谱:KV、文档、宽列与图数据库

kp-027 · 分布式与NoSQL核心约 25 分钟已校对

前置知识点

前置:

相关知识点

相关:

学习进度:

一句话定义

NoSQL 是为特定访问模式与扩展性而放弃部分关系模型保证的数据库家族:KV 存储(Redis)、文档库(MongoDB)、宽列库(Cassandra/HBase)、图库(Neo4j)各有其甜蜜点;NewSQL 则试图用新架构同时拿回 SQL 与水平扩展。

为什么重要

前置知识

kp-021(LSM——多数 NoSQL 的内核)、kp-024(分区——扩展性的手段)。

核心概念

原理与机制

家族差异本质是「为哪种访问模式放弃哪些保证」。KV:放弃查询能力换纳秒级点查与极简语义,所有复杂度转移到键设计(如 user:{id}:cart 命名空间)。文档库:放弃跨文档事务与连接(新版有有限多文档事务,代价大),换取读模型的局部性——把「订单 + 明细」内嵌为一个文档,读一次到位,这正是 kp-008 反范式的极端化。宽列库:把行键范围扫描做到极致(LSM + 分区),放弃二级索引与即时一致性,适合写多读少的日志/消息流。图库:放弃「把关系降级为连接操作」的关系模型,邻接表物理内联,三度好友、路径查找这类多跳查询从 O(连接爆炸) 变为图遍历。NewSQL 的配方 = kp-024 Range 分区 + 每分区 Raft 组(kp-026)+ 全局时钟/混合逻辑时钟的分布式 MVCC + 完整 SQL 栈。

实例或案例

电商多引擎分工:Redis(KV)扛会话与购物车热点读;MongoDB(文档)存商品详情(属性异构、整体读);Cassandra(宽列)接用户行为日志流;Neo4j(图)做「买了又买」多跳推荐;MySQL(关系库)守住订单与资金的主干事务;TiDB(NewSQL)承接拆分后仍要跨库 JOIN 的中台分析。一套业务、六种引擎——每种的选型理由都能回溯到本篇的机制差异。

常见误区

自测题

  1. 文档库「内嵌 vs 引用」的判据是什么? 答:读模式整体性(总是一起读 → 内嵌)与增长无界性(子文档可能无限增长 → 引用,防止大文档搬家与 16MB 上限)。
  2. NewSQL 如何同时做到 SQL 与水平扩展? 答:Range 分区把数据打散,每个分区用 Raft 保证高可用与强一致,全局时钟支撑分布式 MVCC,上层保留完整 SQL 与优化器。

公式或模型

本节不适用:本知识点是家族图谱与机制对照,定量模型分散在各引擎前置知识点(kp-021/kp-024/kp-026)。

图示

KV 存储点查极快 文档库读模型局部性 宽列库写吞吐扫描 图库多跳遍历 NewSQL:分区 + Raft + 分布式 MVCC + SQL 强一致 + 水平扩展的合流方向
NoSQL 四家族各为一类访问模式而生;NewSQL 向「SQL + 扩展 + 强一致」合流

直观类比

把数据库家族比作厨房:KV 是刀(简单锋利,只做一件事);文档库是深锅(一锅端整道菜);宽列库是流水线烤炉(大批量同款生产);图库是神经网络般的全景地图(找关系最快);关系库是主灶(复杂烹饪的核心);NewSQL 是把主灶复制到每个分店还能同步菜谱的新模式。

与其他知识点的关系

kp-001 的三层模式在非关系引擎中的对应物是「访问 API + 存储格式」;kp-021/kp-024/kp-026 是它们的公共底盘;kp-030 把本图谱变成选型决策树;kp-028 提供各家族兴起的历史语境。

延伸阅读