MongoDB 入门

1. 一句话简介

MongoDB 是一种基于分布式文件存储的开源文档数据库，属于 NoSQL 阵营。它不再以「表 + 行 + 列」为模型，而是把数据存储为灵活的 BSON 文档（可理解为增强版 JSON），一个集合（collection）内的文档不必拥有完全相同的字段结构，实现了真正的 schema-free。

以本 demo（demo-mongodb）为例，一条帖子（帖子人）就是一篇独立的 Article 文档，字段（id、title、content、createTime、thumbUp、visits 等）直接内嵌在文档里，随业务扩展即增即用，无需先建表、无需迁移。它主要解决：数据模型多变、字段层级嵌套、高并发读写、海量数据水平扩展这些关系型数据库处理起来很吃力的问题。Spring Boot 通过 spring-boot-starter-data-mongodb 自动配置好连接、MongoTemplate 和 Repoitory，可像 JPA 一样零 SQL 实现 CRUD。

2. 什么时候使用

✅ 适用场景

• 数据结构多变、字段不固定：业务字段经常增删、同一个集合里不同文档字段差异很大时，MongoDB 无需 DDL 迁移即可随写随存。
• 文档型 / 嵌套型数据：如帖子与点赞、评论、标签等天然是「一个整体、可内嵌」的关联，直接嵌套存储，避免大量 JOIN。
• 高并发读写、需要水平扩展：原生支持分片（sharding）和副本集（replica set），水平扩展能力强，适合读写量大的业务。
• 快速迭代、追求开发效率：Json 风格的文档与 Java 对象的映射直观，Spring Data 的 Repoitory 方法名查询（如本 demo 的 findByTitleLike）可自动生成查询。
• 频繁的计数类原子更新：本 demo 中点赞/访客数用 MongoTemplate 的 $inc 原子递增，无需先查后改，天然支持并发场景下安全的计数器更新。

❌ 不适用 / 需谨慎

• 强事务、强一致业务：核心金融、账务、订单这类需要 ACID 多文档强一致性的场景不建议主用，虽然后期版本引入多文档事务，但复杂度与性能代价高。
• 复杂多表关联查询：没有 JOIN，习惯 SQL 联表 + 聚合函数的地方，用 MongoDB 需要靠冗余或多次查询，反而别扭。
• 数据之间强依赖、关系固定的领域建模：如 ERP、进销存、人事这类关系稳定、报表维度多的系统，关系型数据库 + SQL 更合适。
• 需要复杂 SQL 报表分析、行列精准约束：SQL 的丰富聚合、窗口函数、精确约束，MongoDB 的聚合管道表达起来较重。
• 团队无 NoSQL 运维经验：相比单机 MySQL，MongoDB 的副本集、分片、索引、备份恢复运维门槛更高。

3. 常见业务场景

内容创作与文档型数据（帖子 / 文章）：本 demo 中的 Article 文档是典型代表。一篇文章从标题、正文、附件到浏览/点赞统计，都可以作为一个完整文档内嵌，按 id 一次读回，无 JOIN；点赞、访客数这类高频累计用 $inc 原子更新，分页排序用 PageRequest + Sort 轻松实现「按点赞数、更新时间降序拉取热门文章」。

评论、标签、动态等嵌套关联内容：用户发表的评论、动态下的点赞列表、文章的标签集合，本质是依附于某条主体的子数据，用数组或内嵌子文档直接存在同一条文档里，读一次即可拿到全部，避免频繁关联查询。

操作日志 / 行为埋点 / 事件流：数据量大、写入频繁、结构不固定（不同事件字段差异大）、只追加少修改，正好匹配文档数据库的优势；配合 TTL（存活时间）索引还能自动清理过期日志。

高并发计数类应用（点赞、浏览、转发）：借助 $inc 完成数据库层的原子自增，天然规避「先查后改再写回」产生的并发覆盖问题，适合秒杀、热榜、统计这类对写入吞吐要求高的场景。

内容系统 + 轻量全文检索：文档型内容可直接按标题/正文建立文本索引做模糊搜索（本 demo 的 findByTitleLike 即编译为正则匹配），适合中小规模的「文章/商品搜索」，省去额外引入 ES 的成本。

4. 同类技术对比

维度	MongoDB	MySQL（关系型）	Elasticsearch	Redis
数据模型	文档（BSON），schema-free	表、行、列，强 schema	倒排索引 + JSON 文档	键值对 + 多种数据结构
适合查询	文档内嵌套查询、模糊/文本搜索	复杂 JOIN、聚合报表、精准约束	全文检索、模糊查询、聚合分析	简单键值读写、缓存
事务与一致性	单文档强一致，多文档事务较新/代价高	完整 ACID 事务，成熟	近实时（NRT），最终一致	弱一致为主
性能特点	高并发读写、水平扩展强	单机性能优异、强一致	海量数据下搜索性能强	极低延迟、高吞吐缓存
水平扩展	原生分片 + 副本集，扩展强	主从/分库分表，运维较复杂	分布式原生，扩展强	集群/哨兵，扩展中等
学习与运维成本	中偏高（副本集/分片/索引）	低，生态成熟 DBA 多	高（集群管理、映射与分词）	低（结构简单）
适用规模	海量 + 高并发 + 多变结构	中小规模、关系复杂数据	海量文本搜索与分析	缓存、热数据、计数

选型建议：数据关系紧密、需要多表 JOIN、强 ACID 和多样报表的「核心交易型业务」，选 MySQL。数据是文档型、字段多变、需要内嵌和水平扩展、追求快速迭代的「内容/日志/计数型业务」，选 MongoDB。需要海量文本搜索与聚合分析的内容检索场景，选 Elasticsearch（也可与 MongoDB 搭配，MongoDB 存数据、ES 建索引）。需要极低延迟的缓存、会话、实时热数据，选 Redis。多数系统会组合使用：MySQL 存核心业务、MongoDB 存非结构化的文档与计数、Redis 做缓存加速、ES 承担搜索，各取所长。