📣读完这篇文章里你能收获到

• 为什么很多人认为MongoDB是无模式？
• 文档模型跟传统的关系模型有什么区别？
• 关于MongoDB的模型设计模式，你知道几个？
• MongoDB如何进行表关联？
• 文档模型的设计规范及设计原则
• 文档建模模型设计三部曲
• 1-1关系建模，1-N关系建模，N-N关系建模的建议
• 针对不同的场景提供丰富的设计案例分享

一、JSON 文档模型设计特点

1 为什么人们都说 MongoDB 是无模式？

• 严格来说，MongoDB 同样需要概念/逻辑建模
• 文档模型设计的物理层结构可以和逻辑层类似
• MongoDB 无模式由来：可以省略物理建模的具体过程

2 文档模型与关系模型有什么区别？

3 MongoDB 文档模型设计的三个误区（下述说法均为错误！）

• 1： 不需要模型设计
• 2：MongoDB 应该用一个超级大文档来组织所有数据
• 3：MongoDB 不支持关联或者事务

4 JSON 文档模型的设计规范

• 文档模型设计处于是物理模型设计阶段 （PDM）
• JSON 文档模型通过内嵌数组或引用字段来表示关系
• 文档模型设计不遵从第三范式，允许冗余

5 JSON 文档模型的设计原则

• 性能
• 易用

二、MongoDB 文档模型设计三步曲

三、入门！基础模型的快速设计

1 建立基础文档模型

• 根据概念模型或者业务需求推导出逻辑模型 – 找到对象
• 列出实体之间的关系（及基数） - 明确关系
• 套用逻辑设计原则来决定内嵌方式 – 进行建模
• 完成基础模型构建

2 实例：联系人管理应用

1. 找到对象

Contacts
Groups
Address
Portraits

1. 明确关系

一个联系人有一个头像 （1-1)
一个联系人可以有多个地址（1-N ）
一个联系人可以属于多个组，一个组可以有多个联系人 (N – N)

1-1 关系建模

1-N 关系建模

N-N 关系建模

3 基础建模小结

• 1:9 规则： 大部分时候你会使用内嵌来表示 1-1，1-N，N-N
• 内嵌类似于预先聚合（关联）
• 内嵌后对读操作通常有优势（减少关联）

四、进阶！基础模型的需求细化

• 基于内嵌的文档模型根据业务需求，使用引用来避免性能瓶颈使用冗余来优化访问性能

1 联系人分组需求遭遇瓶颈

1. 用于客户营销
2. 有千万级联系人
3. 需要频繁变动分组（group）的信息，如增加分组及修改名称及描述以及营销状态
4. 一个分组可以有百万级联系人

2 针对瓶颈设计解决方案

• Group 使用单独的集合
• 类似于关系型设计
• 用 id 或者唯一键关联
• 使用 $lookup 来提供一次查询多表的能力（类似关联）

3 引用模式下的关联查询

• 查询时使用aggregate结合$lookup进行联表查询

db.contacts.aggregate([
    {
        $lookup:
        {
            from: "groups",  
            localField: "group_ids", 
            foreignField: "group_id", 
            as: "groups"
        }
    }
])

4 什么时候该使用引用方式？

• 内嵌文档太大，数 MB 或者超过 16MB
• 内嵌文档或数组元素会频繁修改
• 内嵌数组元素会持续增长并且没有封顶

5 MongoDB 引用设计的限制

• MongoDB 对使用引用的集合之间并无主外键检查
• MongoDB 使用聚合框架的 $lookup 来模仿关联查询
• $lookup 只支持 left outer join
• $lookup 的关联目标（from）不能是分片表

五、成神！MongoDB设计模式案例分享

• 文档模型：无范式、无思维定式、充分发挥想象力
• 设计模式：实战过屡试不爽的设计技巧，快速套用

1 分桶模式

• 背景：数据量大，有规律的分布（如按时间），数据颗粒度小

• 场景描述

  • 物联网场景下的海量数据处理 – 飞机监控数据
  • 10万架飞机，1年的数据，每架飞机每分钟记录一条

分析：100000 365 24 * 60 = 52.6B数据量，数据大小大概4000GB，索引大小大概6000GB，一年下来的数据量极其庞大

• 解决方案：分桶设计

分析：由原先模型中的events的对象更改为events数组，每个文档存储60个events也就是一个小时的数据，那么数据量由52.6B降至876M，索引大小由6000GB降至100GB，数据大小由4000GB降至600GB，不管是索引还是数据量都有了质的减少

• 模式小结：分桶

2 列转行模式

• 背景：大文档，很多字段，很多索引

• 场景描述

  • 有很多部电影
  • 需要记录每部电影各自在各个国家的最新上映时间
• 原来的数据格式及原来的索引设计

分析：由于需要根据国家去查询电影的上映日期，因此需要设计大量的国家索引

• 解决方案：列转行

• 索引：db.movies.createIndex({“releases.country”:1, “releases.date”:1})

分析：将国家及日期提取为数组形式，只需要创建一个索引即可

• 模式小结：列转行

3 版本管理模式

• 背景：模型灵活了，如何管理文档不同版本？

• 场景描述

  • 有很多个版本，每个版本的字段都有区别
  • 查询某个版本或者某个版本的数据以及对这部分数据作统一处理
• 原来的数据格式

分析：由于不同的版本导致MongoDB的collection模型差异过大，容易导致数据的管理失控

• 解决方案: 增加一个版本字段

分析：增加版本字段，可以明确的知道哪部分数据是哪个版本产生的

• 模式小结：版本管理

4 近似计算模式

• 背景：需要统计大量的不重要数据

• 场景描述

  • 统计网页点击流量
  • 每访问一个页面都会产生一次数据库计数更新操作
  • 统计数字准确性并不十分重要

分析：由于点击所需要更新的数据过于频繁，对数据库的写操作造成较大的压力

• 解决方案: 用近似计算，每个10（X）次写一次 Increment by 10(X)

分析：数据近似，数据库的写入压力得以缓解

• 模式小结：近似计算

5 预聚合模式

• 背景：各种需要精确统计的场景

• 场景描述

  • 热销榜：某个商品今天卖了多少，这个星期卖了多少，这个月卖了多少？
  • 电影排行：观影者，场次统计传统解决方案：通过聚合计算

分析：消耗资源多，聚合计算时间长

• 解决方案: 用预聚合字段

分析：模型中直接加入聚合字段，聚合查询速度得以保障

• 模式小结：预聚合