在项目设计的初期，我当时有了这样的想法，同时也是在满足下面几个条件的情况下来选择最终的nosql方案的：
1、需求变化频繁：开发要更加敏捷，开发成本和维护成本要更低，要能够快速地更新进化，新功能要在最短的周期内上线。
2、客户端/api支持，因为这直接影响开发效率
3、部署简单
4、扩展能力强
5、节省系统资源，对cpu等资源耗费较小
满足这些要求的nosql方案，就剩下了mongodb和redis了，对于redis，我并不是说他不好，而是有一个重要原因，我们的项目的数据处理格式都是采用json的形式来处理的，这一点对于后来两者之间的选择，起到了决定性作用。
当然，redis对丰富数据类型的操作很吸引人，可以轻松解决一些应用场景，其读写性能也相当高，之前的版本是存储和内存挂钩是挂钩的，这样如果存储大量的数据需要消耗太多的内存，当然现在的版本已经么有这样的问题了。
mongodb是一个面向文档的数据库，目前由10gen开发并维护，，它的功能丰富，齐全，完全可以替代mysql。
在我项目实施的过程中，我总结了mongodb的一些很好的亮点：
为什么mongodb可以替代mysql?
1、使用json风格语法，易于掌握和理解：mongodb使用json的变种bson作为内部存储的格式和语法。针对mongodb的操作都使用json风格语法，客户端提交或接收的数据都使用json形式来展现。相对于sql来说，更加直观，容易理解和掌握。这也是根据我自己项目的情况出发，最后选择了mongodb的一个原因。
2、schema-less，支持嵌入子文档：mongodb是一个schema-free的文档数据库。一个数据库可以有多个collection，每个collection是documents的集合。collection和document和传统数据库的table和row并不对等。无需事先定义collection，随时可以创建。collection中可以包含具有不同schema的文档记录。 这意味着，你上一条记录中的文档有3个属性，而下一条记录的文档可以有10个属性，属性的类型既可以是基本的数据类型(如数字、字符串、日期等)，也可以是数组或者散列，甚至还可以是一个子文档(embed document)。这样，可以实现逆规范化(denormalizing)的数据模型，提高查询的速度。
3、简单易用的查询方式：直接使用json，支持范围查询、正则表达式查询。
4、crud更加简单，支持in-place update：只要定义一个数组，然后传递给mongodb的insert/update方法就可自动插入或更新;对于更新模式，mongodb支持一个upsert选项，即：“如果记录存在那么更新，否则插入”。mongodb的update方法还支持modifier，通过modifier可实现在服务端即时更新，省去客户端和服务端的通讯。这些modifer可以让mongodb具有和redis、memcached等kv类似的功能：较之mysql，monodb更加简单快速。modifier也是mongodb可以作为对用户行为跟踪的容器。在实际中使用modifier来将用户的交互行为快速保存到mongodb中以便后期进行统计分析和个性化定制
5、所有的属性类型都支持索引，甚至数组：这可以让某些任务实现起来非常的轻松。在mongodb中，“_id”属性是主键，默认mongodb会对_id创建一个唯一索引。
6、性能高效，速度快： mongodb使用c++/boost编写，在多数场合，其查询速度对比mysql要快的多，对于cpu占用非常小。部署也很简单，对大多数系统，只需下载后二进制包解压就可以直接运行，几乎是零配置。
7、服务端脚本和map/reduce：mongodb允许在服务端执行脚本，可以用javascript编写某个函数，直接在服务端执行，也可以把函数的定义存储在服务端，下次直接调用即可。mongodb不支持事务级别的锁定，对于某些需要自定义的“原子性”操作，可以使用server side脚本来实现，此时整个mongodb处于锁定状态。map/reduce也是mongodb中比较吸引人的特性。map/reduce可以对大数据量的表进行统计、分类、合并的工作，完成原先sql的groupby等聚合函数的功能。并且mapper和reducer的定义都是用javascript来定义服务端脚本。