文档结构设计原则

文档结构设计原则

MongoDB作为文档型数据库，其核心优势在于灵活的文档结构设计。合理的文档结构能显著提升查询性能、简化应用逻辑并降低维护成本。与传统关系型数据库不同，MongoDB鼓励通过嵌套和数组实现数据关联，但过度嵌套也可能导致性能问题。

内嵌与引用选择

决定数据该内嵌还是引用是结构设计的首要问题。内嵌适合频繁一起查询且更新不频繁的子文档。例如用户地址信息通常内嵌在用户文档中：

{
  _id: "user123",
  name: "张三",
  addresses: [
    {
      type: "home",
      street: "人民路100号",
      city: "北京"
    },
    {
      type: "work",
      street: "科技园路200号",
      city: "深圳"
    }
  ]
}

引用关系则适用于多对多关系或频繁独立更新的场景。比如博客系统中的评论可采用引用方式：

// 文章文档
{
  _id: "post1",
  title: "MongoDB设计模式",
  commentIds: ["comment1", "comment2"]
}

// 评论文档
{
  _id: "comment1",
  content: "很有帮助",
  userId: "user123"
}

预聚合数据

在需要频繁计算的场景，预先存储计算结果能极大提升查询性能。电商平台的商品文档可以包含销售统计：

{
  _id: "product001",
  name: "无线耳机",
  price: 299,
  stats: {
    totalSales: 1542,
    monthlySales: 213,
    averageRating: 4.7
  }
}

这种设计避免了每次查询时的实时计算，特别适合仪表盘类应用。但需要注意在数据更新时同步维护这些预计算字段。

分桶模式处理时间序列

对于传感器数据等时间序列信息，采用分桶存储能有效控制文档数量。每小时存储一个文档而非每分钟一条记录：

{
  sensorId: "temp001",
  date: ISODate("2023-05-20T00:00:00Z"),
  readings: [
    { time: 0, value: 23.4 },
    { time: 15, value: 23.7 },
    // ...其他分钟数据
  ],
  stats: {
    max: 24.1,
    min: 23.2,
    avg: 23.6
  }
}

这种模式将原本可能产生的1440个文档合并为24个，大幅提升查询效率。

处理多对多关系

实现多对多关系时，应考虑查询模式决定存储方式。学生选课系统的两种设计方案：

// 方案1：课程存储学生引用
{
  _id: "course101",
  name: "数据库原理",
  studentIds: ["stu1", "stu2"]
}

// 方案2：学生存储课程引用
{
  _id: "stu1",
  name: "李四",
  courseIds: ["course101", "course102"]
}

实际应用中常采用双向引用，并在应用层维护数据一致性：

// 课程文档
{
  _id: "course101",
  name: "数据库原理",
  students: [
    { id: "stu1", name: "李四" },
    { id: "stu2", name: "王五" }
  ]
}

// 学生文档
{
  _id: "stu1",
  name: "李四",
  courses: [
    { id: "course101", name: "数据库原理" }
  ]
}

模式版本控制

随着应用演进，文档结构可能需要变更。采用版本字段实现平滑迁移：

{
  _id: "user456",
  schemaVersion: 2,
  basicInfo: {
    firstName: "王",
    lastName: "小明"
  },
  // V2新增的认证信息
  auth: {
    lastLogin: ISODate("2023-05-20T08:30:00Z"),
    loginCount: 42
  }
}

应用代码根据schemaVersion决定如何处理文档，允许新旧数据共存直至完成迁移。

读写比例考量

文档结构应配合读写比例优化。高频读取但很少更新的场景适合高度归一化：

// 商品详情页文档
{
  _id: "product789",
  name: "智能手表",
  fullDescription: "...详细HTML内容...",
  specs: {
    // 所有规格参数
  },
  reviews: [
    // 最新20条评价
  ]
}

而频繁更新的场景则需要将易变数据分离：

// 主文档
{
  _id: "article123",
  title: "MongoDB最佳实践",
  content: "...",
  staticData: {...}
}

// 独立计数器文档
{
  _id: "article123_stats",
  views: 12456,
  shares: 342,
  lastUpdated: ISODate("2023-05-20T10:00:00Z")
}

索引设计协同

文档结构必须与索引策略协同设计。例如支持地理位置查询的场所数据：

{
  _id: "place001",
  name: "中央公园",
  location: {
    type: "Point",
    coordinates: [ -73.97, 40.78 ]
  },
  // 为分类查询优化
  tags: ["park", "landmark", "tourist"],
  // 为范围查询优化
  visitorStats: {
    lastMonth: 15000,
    lastWeek: 4200
  }
}

对应的索引应包括地理位置、标签和访问量：

db.places.createIndex({ "location": "2dsphere" })
db.places.createIndex({ "tags": 1 })
db.places.createIndex({ "visitorStats.lastWeek": -1 })

文档大小限制

MongoDB单个文档不得超过16MB。处理大型内容时可采用分块存储：

// 文档元数据
{
  _id: "doc_abc",
  title: "用户手册",
  chunkSize: 102400,
  totalChunks: 15,
  currentVersion: 3
}

// 内容分块
{
  docId: "doc_abc",
  chunkNum: 1,
  data: BinData(0, "...base64编码数据...")
}

这种模式特别适合存储文件内容或大型文本字段。

原子性操作支持

需要原子性更新的字段应放在同一文档中。购物车设计示例：

{
  _id: "cart_user123",
  items: [
    {
      productId: "prod1",
      quantity: 2,
      price: 99,
      addedAt: ISODate("2023-05-20T09:15:00Z")
    }
  ],
  summary: {
    itemCount: 1,
    total: 198
  }
}

通过$inc操作符可以原子更新数量和总价：

db.carts.updateOne(
  { _id: "cart_user123" },
  {
    $inc: {
      "summary.itemCount": 1,
      "summary.total": 99
    },
    $push: {
      items: {
        productId: "prod2",
        quantity: 1,
        price: 199
      }
    }
  }
)

应用场景适配

不同业务场景需要不同的结构优化策略。社交媒体平台的用户关系设计：

// 用户基础文档
{
  _id: "user789",
  username: "tech_enthusiast",
  profile: {
    displayName: "技术爱好者",
    avatar: "url/to/avatar.jpg"
  },
  // 粉丝数/关注数预聚合
  counts: {
    followers: 5423,
    following: 123
  }
}

// 关系文档（关注列表分页）
{
  _id: "user789_following_1",
  userId: "user789",
  page: 1,
  following: [
    { userId: "user123", since: ISODate("2023-01-15") },
    // ...其他关注用户
  ]
}

这种混合设计平衡了读取性能与写入效率。