MongoDB数据库设计中6条重要的经验法则
MongoDB数据库设计参考指标
- MongoDB默认占用50%内存,可适当调节
- Document文档最大16MB
故设计的时候不要造成文档过大,尤其注意有数组的时候这个数组是不是可以无限push - Document中对数组的$elemMatch操作,其delete,push,pop性能巨差
当文档中的数组大到一定程度,对数组中元素的delete,push,pop操作性能巨差
尽量保证文档中数组的数量较少或者固定数组的数量 - Document物理迁移,性能巨差
下面这些是你需要谨记的：
1、优先考虑内嵌，除非有什么迫不得已的原因。
2、需要单独访问一个对象，那这个对象就不适合被内嵌到其他对象中。
3、数组不应该无限制增长。如果many端有数百个文档对象就不要去内嵌他们可以采用引用ObjectID的方案；如果有数千个文档对象，那么就不要内嵌ObjectID的数组。该采取哪些方案取决于数组的大小。
4、不要害怕应用层级别的join：如果索引建的正确并且通过投影条件（第二章提及）限制返回的结果，那么应用层级别的join并不会比关系数据库中join开销大多少。
5、在进行反范式设计时请先确认读写比。一个几乎不更改只是读取的字段才适合冗余到其他对象中。
6、在mongodb中如何对你的数据建模，取决于你的应用程序如何去访问它们。数据的结构要去适应你的程序的读写场景。
设计指南
当你在MongoDB中对“一对多”关系进行建模，你有很多的方案可供选择，所以你必须很谨慎的去考虑数据的结构。下面这些问题是你必须认真思考的：
关系中集合的规模有多大：是一对很少，很多，还是非常多？
对于一对多中”多“的那一端，是否需要单独的访问它们，还是说它们只会在父对象的上下文中被访问。
被冗余的字段的读写的比例是多少？
数据建模设计指南
在一对很少的情况下，你可以在父文档中内嵌数组。
在一对很多或者需要单独访问“N”端的数据时，你可以采用数组引用ObjectID的方式。如果可以加速你的访问也可以在“N”端使用父引用。
在一对非常多的情况下，可以在“N”端使用父引用。
如果你打算在你的设计中引入冗余等反范式设计，那么你必须确保那些冗余的数据读取的频率远远大于更新的频率。而且你也不需要很强的一致性。因为反范式化的设计会让你在更新冗余字段时付出一定的代价（更慢，非原子化）
总结
三种基础方案：内嵌文档，子引用，父引用的补充选择。
使用双向引用来优化你的数据库架构，前提是你能接受无法原子更新的代价。
可以在引用关系中冗余数据到one端或者N端。
在决定是否采用反范式化时需要考虑下面的因素：
你将无法对冗余的数据进行原子更新。
只有读写比较高的情况下才应该采取反范式化的设计。
