mongo文档模型设计

文档模型设计原则：

1.性能
高并发低延迟
2.开发易用
代码书写简单

MongoDB 文档模型设计三步曲

image.png

第一步：建立基础文档模型

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

1-1 关系建模： portraits

1.基本原则：一对一关系以内嵌为主作为子文档形式 或者直接在顶级不涉及到数据冗余。
2.例外：如果内嵌后导致文档大小超过16MB。

1-N 关系建模： Addresses

1.基本原则：一对多关系同样以内嵌为主，用数组来表示一对多不，涉及到数据冗余。
2.例外情况：内嵌后导致文档大小超过16MB数组。长度太大（数万或更多），数组长度不确定。

N-N 关系建模：内嵌数组模式

1.基本原则：不需要映射表，一般用内嵌数组来表示一对多，通过冗余来实现N-N。
2.例外情况：内嵌后导致文档大小超过16MB，数组长度太大（数万或更多），数组长度不确定。

90:10 规则： 大部分时候你会使用内嵌来表示 1-1，1-N，N-N

内嵌类似于预先聚合（关联）

内嵌后对读操作通常有优势（减少关联）

第二步：根据读写工况细化

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

考虑以下工况

● 最频繁的数据查询模式
● 最常用的查询参数
● 最频繁的数据写入模式
● 读写操作的比例
● 数据量的大小

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

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

MongoDB 引用设计的限制

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

第三步：模式套用

1、对于大批量的时序数据：使用分桶设计。组合一段时间内的全部数据到一条文档。从一分钟一条到一个小时一条，数据量缩小为原来的60分之一。

image.png

image.png

2.对于 大文档，很多字段，很多索引：解决方案: 列转行。

image.png

image.png

3.模型灵活了，如何管理文档不同版本，解决方案: 增加一个版本字段

image.png

image.png

4.问题: 统计网页点击流量， 解决方案: 用近似计算

image.png

image.png

4.问题: 业绩排名，游戏排名，商品统计等精确统计： 预聚合

image.png

image.png