mongoDB设计原则

简介

mongoDB是非关系型数据库，以Document存储数据，Document的内容是JSON（JavaScript Objet Notation）格式，多个Document可以组成一个Collection。

mongoDB 数据库中可以存放比较复杂的数据结构，可以把对象的属性值存放到一个 collection 中。这样可以保证数据物理上连续，一次查询不需要多次磁盘寻道，可提高查询效率。

{
 "name": "notebook",
 "qty": 50,
 "rating": [ { "score": 8 }, { "score": 9 } ],
 "size": { "height": 11, "width": 8.5, "unit": "in" },
 "status": "A",
 "tags": [ "college-ruled", "perforated"]
}

如上面的json数据描述了notebook的相关属性，只需要一次查询就可以获得所有属性，而在传统的关系型数据库中则需要多表联合查询。

根据数据规模选择不同的嵌入模式（内嵌、子引用、父引用）

一对很少：这种情况可以直接将“很少”的内容嵌入“一”。称为内嵌

一对较多：这种情况可以在“一”中嵌入“较多”的每个id，形成引用关系。称为子引用

一对很多：这种情况可以在“很多”中的每个内容中嵌入“一”的id。称为父引用

详见MongoDB数据库设计中6条重要的经验法则，part 1（每日一译：2014-07-23)

双向关联和反范式化

双向关联即双向引用，如在日报系统中可报和接收者直接将存在这种双向引用的关系，这样就可以通过接收者找到所有发给他的日报，也可以根据日报找到他的接收者。

反范式，范式是为了减少数据冗余，反范式肯定增加了冗余，但是增加冗余不是目的，而是为了读取时更加方便。因为会破坏操作的原子性，如果要更改则需要更改实体本身的属性和所有引用到的地方。故对于几乎不会更改但是又会频繁读取到的数据可以利用反范式。

反范式可以让你避免一些应用层级别的join，但是这也会让更新变的更复杂，开销更大。不过冗余那些读取频率远远大于更新频率的字段还是值得的。

详见MongoDB数据库设计中6条重要的经验法则，part 2（每日一译：2014-07-24）

六条原则

1、优先考虑内嵌，除非有什么迫不得已的原因。

2、需要单独访问一个对象，那这个对象就不适合被内嵌到其他对象中。

3、数组不应该无限制增长。如果many端有数百个文档对象就不要去内嵌他们可以采用引用ObjectID的方案；如果有数千个文档对象，那么就不要内嵌ObjectID的数组。该采取哪些方案取决于数组的大小。

4、不要害怕应用层级别的join：如果索引建的正确并且通过投影条件（第二章提及）限制返回的结果，那么应用层级别的join并不会比关系数据库中join开销大多少。

5、在进行反范式设计时请先确认读写比。一个几乎不更改只是读取的字段才适合冗余到其他对象中。

6、在mongodb中如何对你的数据建模，取决于你的应用程序如何去访问它们。数据的结构要去适应你的程序的读写场景。

详见MongoDB数据库设计中6条重要的经验法则，part 3（每日一译：2014-07-25）