mongodb 3.2 实战（一）非关系型数据库设计，如何进行mongo的数据库设计？

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操作起来更为的繁琐。