MongoDB 与纸舟书店

如果把数据库课程写成一串命令，读者往往能在当天照着输入，却很难在一周后解释自己为什么这样设计。这门课换一种走法：我们从一家叫“纸舟书店”的小型线上书店出发，一边补齐 MongoDB 的历史、概念和取舍，一边把书籍、顾客与订单真正存进去。后面的每一次查询、更新、聚合、备份和扩展，都继续使用同一组数据。

全课以 MongoDB 8.0 主版本为基线。实践部分优先使用 Docker 官方 mongo:8.0 镜像和 mongosh，这样不同操作系统看到的数据库行为尽量一致。8.0 标签会随安全修复更新补丁版本，因此课程只把 8.0 当作稳定边界，不把某个补丁号写成永远不变的前提。

从一张书籍表遇到的问题说起

纸舟书店最初只需要记录书名和价格，一张二维表当然足够。业务继续生长后，每本书有多个标签、多个版本、作者信息、出版社信息，有些书还有试读章节。不同类别的书字段也不完全一样：纸质书关心开本和重量，电子书关心文件格式，套装书还要记录包含哪些册。

关系型数据库可以严谨地表达这些数据。我们可以把书籍、作者、标签、版本拆成多张表，再用主键和外键连接。问题不在于关系模型做不到，而在于应用每次读取“一本书的商品页”时，常常希望一次得到一个完整对象；如果数据天然围绕这个对象一起读取、一起修改，频繁拆表和组装就会增加开发与查询的复杂度。

MongoDB 选择把一条业务记录表示为“文档”。一本文档可以包含标量、数组和嵌套文档：

{
  _id: "book-mongodb",
  title: "MongoDB 从入门到实践",
  category: "数据库",
  price: 89,
  stock: 20,
  tags: ["MongoDB", "后端"],
  publisher: {
    name: "纸舟出版社",
    city: "上海"
  },
  published: true
}

这段结构和应用代码中的对象很接近。tags 不必拆成多行，publisher 也可以跟书籍放在一起。MongoDB 会把它保存为 BSON，而不是直接保存文本 JSON；BSON 为日期、二进制、ObjectId、Decimal128 等类型提供了明确表示。

MongoDB 是怎样走到今天的

MongoDB 的故事始于 2007 年。MongoDB 官方的公司历史记载，Dwight Merriman、Eliot Horowitz 和 Kevin Ryan 创办了 10gen。他们此前参与过大规模在线广告系统，亲历了业务增长时数据平台在扩展和开发效率上的压力。

最初的目标并不是单独做一款数据库，而是构建一套面向云计算的应用平台。团队后来发现，平台里最有价值的部分是那套面向文档、便于横向扩展的数据层，于是在 2009 年发布 MongoDB。名称来自 “humongous”，强调它希望处理很大的数据规模。10gen 后来更名为 MongoDB, Inc.。

理解这段历史有两个好处。

第一，MongoDB 从一开始就面向应用开发者。它的查询语言使用文档结构，驱动程序把数据库结果映射成语言中的对象，开发者可以用相近的结构思考接口数据与持久化数据。

第二，MongoDB 的分布式能力不是后来简单贴上的标签。副本集负责高可用，分片负责把数据和请求分散到多个分片上。课程后半部分会逐步搭建这些能力，但我们不会因为它能分片，就假设每个小项目都应该分片。

MongoDB 经常被归入 NoSQL。这个名字最有用的地方，是提醒我们它不以传统关系表作为核心抽象；最容易误导的地方，是让人以为它“不要结构”“不支持事务”或“与 SQL 数据库只能二选一”。现代 MongoDB 支持校验规则、索引、聚合、多文档事务和分布式部署。真正要比较的是数据模型、访问模式、一致性需求与团队的运维能力。

文档模型的四层结构

学习 MongoDB 时，可以先把结构记成四层：部署、数据库、集合、文档。

集合可以容纳字段不同的文档，但“技术上允许”并不是“业务上合理”。如果 books 中一半是书籍、一半是支付流水，查询、索引和权限都会变得难以理解。我们仍然让一个集合服务一种清楚的业务概念。

文档还有一个很重要的边界：单个文档的写入具有原子性。假设书籍文档同时保存 stock 和 featured，一次更新可以一起修改这两个字段，其他客户端不会看到只改了一半的中间状态。这是后面设计库存操作时的重要依据。

MongoDB 的单个 BSON 文档有大小上限。课程使用的书籍与订单远小于这个边界，但在设计无限增长的评论数组、日志数组或订单明细时，必须意识到“把所有东西塞进一个文档”迟早会失控。

纸舟书店的数据约定

全课固定使用数据库 bookstore 和三个核心集合：

bookstore
├── books       书籍目录、价格、库存、标签与上架状态
├── customers   顾客资料与收货地址
└── orders      订单状态、顾客引用与下单时的商品快照

我们会有意采用可读的字符串 _id，例如 book-mongodb、customer-lin 和 order-1001。MongoDB 完全支持自动生成的 ObjectId，真实项目也经常使用 ObjectId；课程使用固定字符串，是为了让每条命令都能复制，并让查询结果不受随机标识影响。

三类文档承担不同的建模任务：

• books 让我们学习 BSON、CRUD、查询、数组、嵌套字段、索引和聚合。
• customers 把收货地址嵌入顾客文档，展示“一起读取、一起维护”的数据为何适合嵌入。
• orders 使用 customerId 和 bookId 引用其他文档，同时保存下单时的书名与单价快照。即使书籍以后改名或调价，历史订单仍然能说明当时卖了什么、卖多少钱。

这里已经出现 MongoDB 建模最重要的判断：引用负责指向一个独立实体，快照负责保存历史事实。二者可以同时存在，不必强行只选一种。

MongoDB 适合解决什么

MongoDB 通常适合以下问题：

• 应用主要围绕对象或聚合根读取数据，例如商品详情、内容页面、用户档案。
• 同类记录允许少量字段差异，模式会随产品迭代逐步演进。
• 数据中自然包含数组和嵌套结构，希望减少反复拆分与组装。
• 需要丰富查询、二级索引和聚合，同时希望保留文档模型。
• 数据量或请求量可能增长，需要副本集与水平扩展路线。

纸舟书店符合其中几项：书籍标签和订单明细天然是数组，商品详情适合按整本文档读取，订单需要保留当时的商品快照。它足够真实，又不会用庞大业务细节掩盖数据库知识。

MongoDB 并不只适合“没有规则的数据”。恰恰相反，一个可靠的 MongoDB 项目需要清楚的字段含义、校验规则、索引策略和迁移方案。灵活模式的价值在于允许受控演进，而不是允许字段名随意变化。

哪些情况应当谨慎选择

如果业务核心是大量复杂的跨实体关联、强约束和成熟的关系分析，关系型数据库可能更直接。例如总账系统依赖严格科目关系和复杂报表，使用关系模型往往能更自然地表达约束与连接。

如果团队需要对任意维度做即席分析，数据仓库或列式分析系统可能比业务数据库合适。MongoDB 的聚合框架很强，但业务查询与大规模分析并不是同一种负载。

如果数据几乎没有查询需求，只需要廉价保存大对象，对象存储会比把文件直接塞进数据库更简单。MongoDB 提供 GridFS，但“存在这个功能”不代表所有文件都应该这样存。

还要警惕三个常见误区：

1. 为了灵活而拒绝校验。 没有规则的字段最终会把复杂度推给每一段读取代码。
2. 为了少查一次而无限嵌套。 无界数组会持续增长，热点文档会承受越来越多写入竞争。
3. 为了可扩展而过早分片。 分片引入路由、均衡、分片键和更多故障面；单节点或副本集能满足需求时，不必先支付这笔复杂度成本。

从零到交付会经历什么

接下来的课程会沿着同一条项目线推进：

1. 建立可重复启动的 MongoDB 8.0 服务，并用 mongosh 完成版本体检。
2. 导入纸舟书店的固定种子数据，认识 BSON、集合和校验规则。
3. 完成 CRUD、条件查询、稳定分页、原子更新和批量写入。
4. 为真实查询设计索引，用 explain 比较扫描文档数，而不是凭感觉谈性能。
5. 用聚合管道生成销量报表，再通过官方驱动把数据库接入应用。
6. 处理事务、副本集、安全、备份、监控和分片，最终完成恢复与验收。

每个实践段落都遵守同一顺序：先解释知识点，再执行操作，然后展示并解读结果。动态生成的容器 ID、时间戳和补丁版本会明确标注，不会被包装成固定答案。

做一次选择判断

一家内容平台的文章包含标题、正文、作者摘要、若干标签和不同类型的扩展区块。页面访问时通常整篇读取，字段还会随着编辑器能力演进。仅根据这些信息，文档模型是一个值得验证的候选方案。

进入实践前的检查点

读完这一节，你应该能说清楚四件事：MongoDB 为什么从 10gen 的平台项目中独立出来；数据库、集合和文档之间是什么关系；嵌入与引用分别在解决什么问题；哪些场景下不应只因为“数据像 JSON”就选择 MongoDB。

下一节会准备 Docker，启动 mongo:8.0，初始化一个单节点副本集，并通过 ping、db.version() 和 db.hello() 完成第一次体检。纸舟书店从那一步开始真正拥有可查询的数据空间。