异常教程

MongoDB 关系（一文讲透）

更新时间:

💡一则或许对你有用的小广告

欢迎加入小哈的星球 ，你将获得：专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

  • 新项目:《从零手撸：仿小红书（微服务架构）》 正在持续爆肝中，基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...，点击查看项目介绍 ;
  • 《从零手撸：前后端分离博客项目（全栈开发）》 2 期已完结，演示链接： http://116.62.199.48/ ;

截止目前， 星球 内专栏累计输出 82w+ 字，讲解图 3441+ 张，还在持续爆肝中.. 后续还会上新更多项目，目标是将 Java 领域典型的项目都整一波，如秒杀系统, 在线商城, IM 即时通讯，权限管理，Spring Cloud Alibaba 微服务等等，已有 2900+ 小伙伴加入学习 ，欢迎点击围观

前言：关系型数据库与 MongoDB 的思维差异

在传统关系型数据库（如 MySQL）中，"关系"是通过外键约束、JOIN 操作和事务机制实现的。但 MongoDB 作为文档型数据库，其核心设计哲学是去关系化——它通过文档嵌套和应用层逻辑来模拟关联，而非通过数据库层的硬约束。这种设计既带来了灵活性，也要求开发者重新理解"关系"的实现方式。

本文将从 MongoDB 的文档模型出发，通过实际案例讲解如何在文档数据库中管理关联数据，并对比传统关系型方案的异同。我们还会通过代码示例，展示如何用 MongoDB 的聚合框架（Aggregation Framework）和应用逻辑实现类似关系型数据库的关联查询效果。

MongoDB 的文档模型基础：结构化数据的柔性表达

MongoDB 的核心是文档（Document），每个文档是键值对的集合，存储在集合（Collection）中。与关系型数据库的表行结构不同，文档允许以下特性：

  • 动态模式：不同文档可以拥有不同的字段
  • 嵌套结构：字段可以包含子文档或数组
  • 类型丰富：支持字符串、数组、子对象等复杂数据类型

形象比喻：可以把一个 MongoDB 文档想象为一个装满不同物品的文件夹，文件夹内可以有单独的纸条（简单字段）、其他文件夹（子文档）或文件夹数组（数组字段）。这种结构天然适合存储具有层级关系或变化频繁的数据。

示例：用户信息文档

{
  "_id": ObjectId("..."),
  "username": "alice",
  "email": "alice@example.com",
  "profile": {
    "age": 28,
    "address": "123 Main St"
  },
  "orders": [
    { "order_id": "ORD-1001", "amount": 99.99 },
    { "order_id": "ORD-1002", "amount": 49.99 }
  ]
}

处理 MongoDB 关系的两种核心策略

在 MongoDB 中，"关系"的实现主要通过以下两种策略：

  1. 文档嵌入（Embedded Documents）：将关联数据直接存储在父文档中
  2. 引用关系（Referenced Documents）：通过对象 ID 引用其他集合的文档

策略选择的黄金法则

  • 嵌入适合：
    • 频繁一起查询的关联数据
    • 结构简单且大小可控的子数据
    • 关联数据更新频率低
  • 引用适合：
    • 关联数据需要独立管理（如需要被多个父文档引用）
    • 关联数据可能变得庞大（如日志记录）
    • 需要跨文档事务操作

策略一：文档嵌入——将关系"内化"到文档结构中

通过将关联数据直接嵌入到父文档中，MongoDB 可以在单次查询中获取完整数据，避免了复杂的关联操作。

案例：用户与订单的嵌入式设计

假设我们有一个电商系统，用户信息和订单信息需要频繁一起展示。我们可以将订单直接嵌入到用户文档的 orders 数组中：

// 用户集合中的文档示例
{
  "_id": ObjectId("64d1a2b3c4d5e6f7a8b9c0d1"),
  "name": "Bob",
  "email": "bob@example.com",
  "orders": [
    {
      "order_id": "ORD-202301",
      "items": [
        { "product_id": "P-001", "quantity": 2 },
        { "product_id": "P-002", "quantity": 1 }
      ],
      "total": 149.99
    }
  ]
}

优势：

  • 单次查询即可获取用户及其所有订单
  • 无需处理 JOIN 操作的复杂性

局限性：

  • 单文档大小不能超过 16MB（MongoDB 的硬性限制）
  • 更新操作可能需要处理数组元素的增删

实战技巧：使用 $push 和 $pull 更新数组

// 向用户的 orders 数组添加新订单
db.users.updateOne(
  { _id: ObjectId("64d1a2b3c4d5e6f7a8b9c0d1") },
  { $push: { orders: newOrderDocument } }
);

// 移除特定订单
db.users.updateOne(
  { _id: ObjectId("...") },
  { $pull: { "orders.order_id": "ORD-202301" } }
);

策略二：引用关系——通过对象 ID 实现松耦合

当数据需要被多个文档引用，或存在潜在的规模问题时，可以使用 ObjectId 引用其他集合的文档。

案例：分离用户与订单集合

// 用户集合
{
  "_id": ObjectId("64d1a2b3c4d5e6f7a8b9c0d1"),
  "name": "Alice",
  "email": "alice@example.com"
}

// 订单集合
{
  "_id": ObjectId("64d1a2b3c4d5e6f7a8b9c0d2"),
  "user_id": ObjectId("64d1a2b3c4d5e6f7a8b9c0d1"),
  "items": [ ... ],
  "total": 99.99
}

关联查询的实现：
通过应用层逻辑或聚合框架的 $lookup 操作符实现关联查询。

方法一：应用层手动关联

// 先查询用户
const user = db.users.findOne({ _id: ... });

// 再查询订单
const orders = db.orders.find({ user_id: user._id });

方法二：使用 $lookup 聚合操作

db.users.aggregate([
  {
    $lookup: {
      from: "orders",          // 被引用的集合
      localField: "_id",       // 当前集合的关联字段
      foreignField: "user_id", // 被引用集合的关联字段
      as: "orders"            // 结果数组的字段名
    }
  }
]);

聚合框架：MongoDB 的关联查询利器

MongoDB 的聚合框架（Aggregation Framework）提供了类似 SQL 的管道操作符，其中 $lookup 是实现跨集合关联的核心操作符。

示例：复杂关联查询

假设我们有一个 products 集合和 reviews 集合，需要获取商品及其平均评分：

db.products.aggregate([
  {
    $lookup: {
      from: "reviews",
      localField: "_id",
      foreignField: "product_id",
      as: "reviews"
    }
  },
  {
    $addFields: {
      average_rating: {
        $avg: "$reviews.rating"
      }
    }
  }
]);

输出示例：

{
  "_id": ObjectId("..."),
  "name": "Wireless Headphones",
  "price": 149.99,
  "reviews": [ ... ],
  "average_rating": 4.5
}

关系设计的性能优化与权衡

在 MongoDB 中，关系设计本质上是灵活性与查询性能的权衡：

  • 嵌入的性能优势：单文档查询速度快，但可能导致数据冗余
  • 引用的扩展性优势：避免数据重复，但需要额外查询或聚合操作

优化技巧

  1. 预计算字段：在用户文档中存储订单总数 
    db.users.updateOne(
  { _id: ... },
  { $inc: { order_count: 1 } }
)
  2. 使用覆盖查询：确保索引包含所需字段，避免回表查询
  3. 分片设计：对高吞吐量场景，按关联字段进行分片键设计

特殊场景：多对多关系与图结构

对于更复杂的关联需求（如社交网络的"好友关系"），可以采用以下方法：

  • 双向引用：在双方文档中互相存储对方 ID
  • 中间集合：创建 user_connections 集合存储关系元数据
  • 图查询：通过 $graphLookup 实现递归查询

示例：使用 $graphLookup 查找所有朋友的朋友

db.users.aggregate([
  {
    $match: { _id: ObjectId("current_user_id") }
  },
  {
    $graphLookup: {
      from: "user_connections",
      startWith: "$friends",
      connectFromField: "friends",
      connectToField: "user_id",
      as: "second_degree_friends"
    }
  }
]);

MongoDB 关系设计的常见误区

  1. 过度嵌套：将大型文档嵌套导致超过 16MB 限制
  2. 忽视索引：引用关系未在 foreignField 上建立索引
  3. 误用事务：在跨集合操作中未正确使用 MongoDB 的多文档 ACID 事务（4.0+ 版本支持）

结论：选择最适合业务场景的设计

MongoDB 的"关系"设计没有绝对正确的方法，而是需要根据以下因素权衡：

  • 数据访问模式（读多写少 vs 写多读少）
  • 数据规模和复杂度
  • 系统性能与扩展性需求

通过合理运用文档嵌入、引用关系和聚合框架，开发者可以构建出既灵活高效，又符合业务需求的 MongoDB 数据模型。记住：文档模型的"去关系化"本质，反而提供了比传统关系型数据库更强大的关联数据管理能力。

（全文约 1800 字）

最新发布

查看更多文章