Mongodb数据存储优缺点

相对于Mysql来讲

在项目设计的初期，我当时有了这样的想法，同时也是在知足下面几个条件的状况下来选择最终的nosql方案的：

一、需求变化频繁：开发要更加敏捷，开发成本和维护成本要更低，要可以快速地更新进化，新功能要在最短的周期内上线。
二、客户端/api支持，由于这直接影响开发效率
三、部署简单
四、扩展能力强
五、节省系统资源，对cpu等资源耗费较小

知足这些要求的nosql方案，就剩下了mongodb和redis了，对于redis，我并非说他很差，而是有一个重要缘由，咱们的项目的数据处理格式都是采用JSON的形式来处理的，这一点对于后来二者之间的选择，起到了决定性做用。

固然，Redis对丰富数据类型的操做很吸引人，能够轻松解决一些应用场景，其读写性能也至关高，以前的版本是存储和内存是挂钩的，这样若是存储大量的数据须要消耗太多的内存，固然如今的版本已经么有这样的问题了。

MongoDB是一个面向文档的数据库，目前由10gen开发并维护，它的功能丰富，齐全，彻底能够替代MySQL。

在我项目实施的过程当中，我总结了mongodb的一些很好的亮点：

为何MongoDB能够替代MySQL？

一、使用JSON风格语法，易于掌握和理解：MongoDB使用JSON的变种BSON做为内部存储的格式和语法。针对MongoDB的操做都使用JSON风格语法，客户端提交或接收的数据都使用JSON形式来展示。相对于SQL来讲，更加直观，容易理解和掌握。这也是根据我本身项目的状况出发，最后选择了mongodb的一个缘由。

二、Schema-less，支持嵌入子文档：MongoDB是一个Schema-free的文档数据库。一个数据库能够有多个Collection，每一个Collection是Documents的集合。Collection和Document和传统数据库的Table和Row并不对等。无需事先定义Collection，随时能够建立。Collection中能够包含具备不一样schema的文档记录。 这意味着，你上一条记录中的文档有3个属性，而下一条记录的文档能够有10个属性，属性的类型既能够是基本的数据类型（如数字、字符串、日期等），也能够是数组或者散列，甚至还能够是一个子文档（embed document）。这样，能够实现逆规范化（denormalizing）的数据模型，提升查询的速度。


三、简单易用的查询方式：直接使用JSON，支持范围查询、正则表达式查询。


四、CRUD更加简单，支持in-place update：只要定义一个数组，而后传递给MongoDB的insert/update方法就可自动插入或更新；对于更新模式，MongoDB支持一个upsert选项，即：“若是记录存在那么更新，不然插入”。MongoDB的update方法还支持Modifier，经过Modifier可实如今服务端即时更新，省去客户端和服务端的通信。这些modifer可让MongoDB具备和Redis、Memcached等KV相似的功能：较之MySQL，MonoDB更加简单快速。Modifier也是MongoDB能够做为对用户行为跟踪的容器。在实际中使用Modifier来将用户的交互行为快速保存到MongoDB中以便后期进行统计分析和个性化定制


五、全部的属性类型都支持索引，甚至数组：这可让某些任务实现起来很是的轻松。在MongoDB中，“_id”属性是主键，默认MongoDB会对_id建立一个惟一索引。

 

六、性能高效，速度快： MongoDB使用c++/boost编写，在多数场合，其查询速度对比MySQL要快的多，对于CPU占用很是小。部署也很简单，对大多数系统，只需下载后二进制包解压就能够直接运行，几乎是零配置。


七、服务端脚本和Map/Reduce：MongoDB容许在服务端执行脚本，能够用Javascript编写某个函数，直接在服务端执行，也能够把函数的定义存储在服务端，下次直接调用便可。MongoDB不支持事务级别的锁定，对于某些须要自定义的“原子性”操做，可使用Server side脚原本实现，此时整个MongoDB处于锁定状态。Map/Reduce也是MongoDB中比较吸引人的特性。Map/Reduce能够对大数据量的表进行统计、分类、合并的工做，完成原先SQL的GroupBy等聚合函数的功能。而且Mapper和Reducer的定义都是用Javascript来定义服务端脚本。

MonoDB在数据库表设计方面的难题，

　　内部造成了两种意见，一种就是使用单表存储的方式，把全部的用户的行为记录存储到一张collection表里，这样之后这张表可能会很大，可是开发难度低，

　　另外一种是根据用户id将用户记录存储到各自的collection中，这样的好处很明显，在插入数据的时候人为的下降了每一个collection表的数量，例如一千万条记录分别是属于10个用户的，分给10个collection，每一个collection平均分配到一百万条记录，可是缺点显而易见，开发难度大，

　　我看了下mongoid这个gem，没有对collection动态建立的操做，每一个model固定对应一个collection，按照第二种设计方案，每建立一个用户就须要动态建立一个collection。

　　mongodb要很是当心，速度太快時表有毁掉的危險，至今無解。

111