Collection 的单个 doc 有大小上限，现在是 16MB，这就使得你不可能把所有东西都揉到一个 collection 里。而且如果 collection 结构过于复杂，既会影响查询、更新效率，也会造成维护困难和操作风险。你有尝试过手一抖就把一个 doc 不小心存成 null 的么，反正我做过，要是一个人所有信息都在这个 collection 里面，那感觉一定相当酸爽吧。
一般的原则是：
- 按照查询方式来聚类
- 需要经常一起读取的数据放一起.
- 在逻辑上关系紧密的信息放在一起。
- 有 map-reduce/aggregation 需求的数据放在一起，这些操作都只能操作单个 collection。
- 按照数据量来拆分
- 如果发现要在 collection 里面用数组，数组长度还会不断增加，那么应该把数据内容放到一个专门的 collection，每条数据都引用当前这个 doc 的主键（就像 mysql 的 1..N 外键依赖一样）。
- 如果发现某个 doc 层次过深（超过 2 层），八成得考虑要拆分了，要不然性能和可维护性都会有问题。
- 按照有表结构的方式来设计
- MongoDB 是没有表结构这个概念的，但是实际使用的时候，很少说一个 collection 里面存在各式各样结构的 doc，如果发现 doc 的结构差别越来越大了，那么应该考虑怎么抽象成类似结构，把变化的东西扔到其他 collection 去，用外键依赖的方式互相引用。
比如设计一个用户系统，user collection 应该放 name 等常用的信息，也应该放 lastLoginAt 这些仅跟 user 相关的东西，或许应该把用户有哪些访问权限的信息也放进来，但是不要放用户的登录日志这种信息会不断增加的信息。
至于 user 之间的关系是否存在 user collection 则需要讨论。假如仅仅需要存储用户间的关系，记录下好友的 uid 就行，而且好友数量也不太大，几百个最多了，那么我倾向于放在一个 collection 里。如果关系数据本身就比较复杂，或者好友数会上千，那我倾向于拆分。
另外，Mongodb 官方的 数据模型设计范式 很值得一读，推荐去好好看看。