波仔
🗄️ 第二章 数据的存储方式-关系型数据库的特征
📄 一句话概括

NoSQL 后两族：面向文档型＝一条数据一个袋子，袋子里的字段可以随手长（MongoDB）；图型＝节点加边专治复杂关系（Neo4j）——一个治【结构不齐】，一个治【关系太密】。

📝 本节和前面几节的关系

2-6 看了键值型（快）和面向列型（省）；本节收掉家族后两族，并把全章串起来——图型正是 2-1 里【网状模型】思想的现代复活，本章就此闭环。

一、面向文档型：袋子模型

面向文档型（Document-Oriented）：每条数据是一个文档——通常长成 JSON 的样子：

{
  "id": 1001,
  "name": "张三",
  "tags": ["VIP", "宜昌"],
  "address": { "city": "宜昌", "street": "西陵一路" }
}

看三个特点：

  1. 一个文档一个袋子：这位顾客的全部信息装在一个文档里，取的时候整袋拿走——不像关系型要把【用户表】【地址表】拆开再连接
  2. 袋子里的字段随手长：张三有 tags 字段，李四可以没有；今天想加【会员等级】字段，新文档直接写，老文档不用动
  3. 嵌套：字段里还能再套结构（address 里套城市和街道）——1-1 那种【树】装在了一个文档里

生活原型：档案袋——每个人一个袋子，袋里装什么、装几页，各人各不一样；办事时整袋调出，不用跑三个科室各抄一张表。

代表产品：MongoDB——NoSQL 里知名度最高的一个，Web 后端大量使用。

二、文档型强在哪、弱在哪

强：结构灵活、读写顺手。

弱：跨文档的复杂关联弱。

三、图型：节点加边

图型（Graph）：数据 = 节点（Vertex）＋ 边（Edge）＋ 属性。

（张三）──朋友──（李四）
   │                │
 关注            点赞
   │                │
（王五）──同事──（赵六）

生活原型：地铁线路图——站是节点、线路是边；【两站之间怎么换乘最少】这种问题，天然要在图上找路径。

代表产品：Neo4j——社交网络、推荐系统、风控（【你的好友的好友骗过人】）的主力。

四、图型强在哪、弱在哪

强：关系查询一步到位。

弱：批量统计不是它的菜。

首尾呼应：2-1 里网状模型的死穴是【线乱难维护】；图型数据库用专门的存储和查询引擎把【线】管好了——网状思想没有死，换了个地方活得很好。

五、NoSQL 四族总表（本节收拢全家族）

类型 组织方式 代表 最强场景 生活原型
键值型 键 → 值 Redis 缓存、计数 储物柜
面向列型 按列打包 HBase 海量批量分析 图书馆按类分区
面向文档型 JSON 文档 MongoDB 结构灵活的对象 档案袋
图型 节点＋边 Neo4j 深层关系 地铁线路图

选型口诀：键值求快、列存求省、文档求灵活、图求关系。

六、动手 Demo：给四个数据挑模型

数据：① 用户登录状态（几分钟就过期）② 全网商品描述（字段五花八门还常变）③ 全城公交线网【任意两站换乘方案】④ 十亿条阅读记录的月度统计。

  1. ① → 键值型（Redis）：按键（用户ID）取状态，快、过期自动删
  2. ② → 面向文档型（MongoDB）：字段不齐、常变，袋子最合适
  3. ③ → 图型（Neo4j）：站点＋线路就是节点＋边，路径是图的本行
  4. ④ → 面向列型（HBase/Cassandra）：海量聚合，只扫需要的列

看到什么算成功：四个选择都能用【选型口诀】各说回一句理由。

七、30 秒实验

打开微信 →【看一看】或任何【猜你喜欢】：

八、常见误区

  1. "文档型里的文档＝Word 文档" —— 不是。这里是结构化数据记录（JSON 那种），【文档】指【一条自带结构的完整数据】。
  2. "图型数据库是画图的工具" —— 与画图无关：【图】是数学里的 graph（节点＋边），管的是关系的存储与查询。
  3. "MongoDB 没有【表】所以更先进" —— 没有强制表结构是取舍不是先进：结构松了，强一致和复杂连接就弱了（2-5 的账在这里同样成立）。
自测三问（点开对答案） 1. 文档型的数据长什么样？三个特点？ **JSON 式文档；一对象一袋整存、字段可各不相同、支持嵌套**。 2. 图型的两个基本零件是什么？最强的查询是什么？ **节点＋边；顺边走的多层关系查询（朋友的朋友）**。 3. 四族选型口诀？ **键值求快、列存求省、文档求灵活、图求关系**。

相关笔记