文档型数据库 MongoDB

MongoDB 很适合保存结构变化较多的数据。

如果 MySQL 更像“表格型存储”，那么 MongoDB 更像“文档型存储”，它和 JSON 的思路非常接近。

本节目标

• 理解 MongoDB 是什么
• 理解数据库、集合、文档三个核心概念
• 理解 MongoDB 和 MySQL 的思维差异
• 理解 MongoDB 适合哪些场景

为什么会有 MongoDB

真实项目里有很多数据并不适合用非常固定的表结构来描述，例如：

• 爬虫抓下来的网页原始信息
• 商品详情字段经常变化的数据
• 结构半固定、半灵活的内容数据

这时如果强行把所有数据都塞进传统关系表里，设计和维护成本可能会比较高。

MongoDB 更适合这种“结构较灵活”的场景。

三个最重要的概念

database

数据库。

collection

集合。

你可以粗略理解成和 MySQL 中“表”有点像。

document

文档。

你可以粗略理解成一条记录，但它的字段结构更灵活。

文档长什么样

一个典型文档可能像这样：

{
  "title": "Python 入门",
  "author": "小王",
  "views": 120,
  "tags": ["python", "基础"]
}

这也是为什么很多人会觉得 MongoDB 很像 JSON。

MongoDB 和 MySQL 的核心区别

MySQL 更强调

• 表结构
• 字段约束
• 表和表之间的关系

MongoDB 更强调

• 一条文档整体存取
• 字段可灵活变化
• 数据结构更像 JSON

所以 MongoDB 不是“更高级的 MySQL”，而是适合不同类型的数据。

MongoDB 适合什么场景

MongoDB 特别适合：

• 半结构化数据
• 字段变化比较频繁的数据
• 层级结构丰富的数据
• 爬虫原始内容和内容型数据

例如：

• 商品详情页抓取结果
• 新闻内容原始文档
• 用户扩展资料

MongoDB 不适合什么

如果你的数据：

• 结构非常稳定
• 关系非常明确
• 需要大量复杂关联查询

那么 MySQL 通常仍然更适合。

为什么 Python 和 MongoDB 很搭

因为：

• Python 里的字典和列表
• 本身就和 JSON、文档结构很接近

这意味着你在保存 MongoDB 数据时，通常会觉得非常自然。

一个最小思维示例

假设你抓取一篇文章，结果可能包含：

• 标题
• 作者
• 浏览量
• 标签
• 评论数量

这些字段可以直接组织成一个字典：

article = {
    "title": "Python 入门",
    "author": "小王",
    "views": 120,
    "tags": ["python", "基础"]
}

这种结构就非常适合保存到 MongoDB。

MongoDB 和爬虫为什么经常一起出现

因为爬虫抓下来的内容往往有这些特点：

• 字段不总是固定
• 页面结构变化大
• 有些文档字段很多，有些很少

这种情况下，MongoDB 往往比严格表结构更自然。

常见错误认识

1. 以为 MongoDB 可以无脑替代 MySQL

不是。它们解决的是不同类型的问题。

2. 只看到“灵活”，忽略了数据设计

灵活不代表可以随便乱存。即使是文档型数据库，也需要有基本的数据组织意识。

3. 只会背概念，不理解适用场景

MongoDB 最重要的不是定义，而是你知道什么时候该考虑它。

练习题

练习 1

用自己的话解释：

• 数据库
• 集合
• 文档

分别是什么。

练习 2

自己写一个适合保存到 MongoDB 的文档示例。

练习 3

思考：为什么爬虫原始数据经常适合 MongoDB？

练习 4

比较 MySQL 和 MongoDB 的思维差异。

本节小结

MongoDB 的核心价值，是为结构较灵活的数据提供更自然的存储方式。

你最重要的收获应该是：

• 理解文档型数据库和关系型数据库的差异
• 知道 database / collection / document 这三个基本概念
• 知道 MongoDB 为什么常出现在爬虫和内容型项目中

只要这一层认知建立起来，后面你再用 Python 操作 MongoDB 时，就不会只是在机械记 API。