MongoDB文档设计

mongodb设计法则
MongoDB 表设计

Mongodb文档设计（主要考虑读和更新的频率）

参考文档

1. 基础篇

考虑因数：一对多中的多是否需要一个单独实体
提出三个类型：内嵌、子引用、父引用

1.1、一对很少

适合内嵌文档

1.2. 一对许多

子级引用

    以一产品多零件为例，每个零件都有自己的文档对象（part），
      每个产品的文档对象(products)中以数组(catalog_number)存放多零件的objectID    
      为了快速执行查询，必须确保products.part和part_id存在索引，提高查询速度
      缺点：在修改一个零件，需要到所有引用该零件的产品进行更新（需考虑读写频率）

1.3. 一对非常多

一个收集各种机器日志为例 ---->父级引用

由于每个mongodb文档有16M的大小限制，直接存储objectID内存不足
“父级引用”  ：用一个文档存储主机，在每个日志文档中保存这个主机的ObjectID

2.提升篇

双向关联、反范式化

2.1 双向关联

任务追踪系统，有person和task两个集合，在各自的集合中都有相关联的对象id

为了快速的获取某个用户负责的项目可以在task对象中嵌入附加的person引用关系
缺点：无法保证操作的原子性，使用该方法，先确认用例是否能允许该操作

2.2 反范式化

你将可能无法对冗余数据进行原子更新
只有读写比较高的情况下才采用反范式化设计

2.2.1 反范式many >> one

以产品（project）和零件（part）为例，在产品（project）中冗余存储零件的名字

产品中保存零件名
 考虑问题：考虑产品和零件的修改频率，
  零件变化的频率高，付出的更新代价高
  零件变化的频率低，付出的更新代价低

2.2.2 反范式 one >> many

冗余产品的名字到零件表

一旦更新产品的名字就必须更新所有和这个产品有关的零件
  这个比只更新一个产品对象来说代价明显更大，更要慎重考虑读写频率

总结

1、优先考虑内嵌，除非有什么迫不得已的原因。
2、需要单独访问一个对象，那这个对象就不适合被内嵌到其他对象中。
3、数组不应该无限制增长。
    如果many端有数百个文档对象就不要去内嵌他们可以采用引用ObjectID的方案；
    如果有数千个文档对象，那么就不要内嵌ObjectID的数组。
    该采取哪些方案取决于数组的大小。
4、不要害怕应用层级别的join：如果索引建的正确并且通过投影条件限制返回的结果，
    那么应用层级别的join并不会比关系数据库中join开销大多少。
5、在进行反范式设计时请先确认读写比。一个几乎不更改只是读取的字段才适合冗余到其他对象中。
6、在MongoDB中如何对你的数据建模，取决于你的应用程序如何去访问它们。
    数据的结构要去适应你的程序的读写场景。