mongo 于2015，12，8 正式发布了3.2的稳定版，这次重大的更新后，主要包括以下几个比较令人兴奋的点。
1.wiredtiger 引擎
在3.0发布时，wiredtiger作为数据引擎之一。3.2之后wiredtiger作为创建数据库的默认数据库，官方的文档中介绍wiredtiger引擎将提高7-10倍的的写效率。意味着更少的硬件支出也能够支持很大的并发操作和密集型操作。
附：所有的mongo引擎：
2.减少80%的物理存储
支持本机的压缩。可根据应用需求来选择算法进行压缩，来提高性能和存储效率。
3.减少95%的维护量
主要体现在
- 减少了复制集故障切换时间
- 文档的验证
为了在一个新的集合上指定文档验证，在db.createCollection()方法使用新的validator选项。为了添加文档验证到一个存在的集合。为了查看一个集合的验证规则，使用db.getCollectionInfos()方法。
以上主要介绍了3.2在更新中的一些特性，说了这么多，下面主要想的是来介绍一下mongo数据库设计
一、为何选择mongo？
mysql与mongo相比，事务与约束性更强。在处理较为价值较高的数据时，关系型数据库有它天然的优势，然而任何一种业务情况下，关系型数据库都不是银弹策略。任何来抛开业务来谈论技术，都是在耍流氓。那么在什么情况下去选择mongo呢？
- 数据价值不是重点
- 属性查询需求较少
- 数据之间约束较少
二、mongo的数据库设计方案
1.嵌入式
嵌入式的设计类似于如下的设计{
"_id" : "2f1a18a6c11b47229ec37f23c97454de",
"_class" : "yingding.edu.facade.user.entity.User",
"userName" : "U18310300203",
"phone" : "18310300203",
"userPwd" : "123456",
"createDate" : "2016-02-02 15:21:54:117",
"role" : [
{
"_id" : "745fed9eb9ec42dc843c3d7f1f44243a",
"roleName" : "游客",
"reMark" : "用户注册，默认角色为游客！",
"domainId" : "12121",
"createDate" : "2016-02-02 15:21:56:441",
"updateDate" : "2016-02-02 15:21:55:172"
}
],
"dataComplete" : "0",
"isExist" : "0",
"classInfoId" : "",
"updateDate" : "2016-02-02 15:21:53:370"
}如上，在user对象中签入了role实体，这样在查询时能够直接通过查询到user对象来直接获取user对象的属性以及角色信息。
这样来做的目的摒弃了之前在关系型数据库中的连接查询，由于mongo数据库本身的内存机制，进一步减少了磁盘IO带来的损耗。
对应在关系型数据库中，能够解决这种的many-to-many的物理数据库设计问题。
2.引用式
与嵌套式的数据库设计，相对的当然是引用式设计。引用式设计，本质上其实还是在遵循关系型数据的设计方式来进行。这种的设计方式，其实是在某种意义上是抛弃了mongo这种bjon的存储方式的。但是在现实的数据库设计过程中，我们无法去规避这种设计方案来去配合业务。
如下：
{
"_id" : "df170e16629f442a923e08336a23de88",
"_class" : "yingding.edu.facade.classinfo.entity.ClassInfo",
"className" : "1班",
"gradeName" : "高一",
"schoolInfoId" : "ec4fac512af84299b870bbb8a21d282c",
"createDate" : "2016-02-17 16:50:21:977",
"updateDate" : "2016-02-17 16:50:21:977"
}在class集合中引用了关于学校的id。这样的情况下，其实是极不推荐的。因为在mongo中原子性的操作是位于document级别的，相比关系型数据库的连接查询，mongo操作起来更为的繁琐。
