nosql数据库选型

http://blogread.cn/it/article/6654

今天在书店里翻完了一遍《七天七数据库》。这本书简单介绍了postgreSQL，riak，mongodb，HBase，riak，Neo4j，redis七个数据，并着重谈了数据库的特性差异和在部署维护时候的特点，并对不同需求下的数据库选型做了很多建议，感觉受益非浅。

我的几个项目，都遇到了mysql 向nosql过渡的问题，应该如何选型，我终于有了初步的方案。

社区网站的关系数据：neo4j

原来大量使用关联表的方式来存储，schema怎么看都觉得恶心，一共只有三列，两列是双重主键。现在有了对neo4j这样的图数据库，天生就是为了解决这样的问题而生的。原来网站里，人对小站的关注关系，图片和相册的关系，图博和标签的关系，这些现在都可以用neo4j来存储。不光是简单存储关系，还可以存储关系的hash信息，几乎1:1直接还原了设计思想。neo4j现在主要的问题是分布式能力不足，虽说官方宣称可以存储上百亿的关系，但是整个系统里留这么一个单点，总是让人不放心。好在这个社区网站的规模还远远没有大到上亿的级别，neo4j足以应付。并且用neo4j可以在编程模式上有很大的帮助，性能上也有很大提升。

社区网站的内容数据：mongodb

社区网站有用户、站点、相册、图片、博客等模型，这些模型都有丰富的元数据，其中不乏很多字段会出现空值，原来用mysql，会造成空间浪费，但是如果用nosql就可以避免空间浪费。这些模型大多数情况都是主键查询，nosql能够发挥很大的性能优势。目前的规模并不大，对性能没有特别的要求，但是由于业务逻辑非常复杂，经常会出现复杂查询，cassandra和riak对索引虽然有支持，但是非常非常有限，完全不能满足业务的需要。mongodb对索引的支持非常好，对各种查询条件的支持几乎能兼容mysql绝大多数的功能。我们希望能够简单快速地实现复杂查询，满足业务快速迭代的需要。因此，mongodb最适合最为社区主要模型的存储数据库。

原来的redis主要就是用来缓存常用模型的，而mongodb其实也有内存缓存，之前有过相关的测试，证明如果mongodb能够载入所有的数据到内存中，性能和redis相差无几。如果使用mongodb，那么redis这一层其实基本上是多余的。那么我们就只需要mongodb+neo4j就能完整实现整个应用了。

微博数据的本地缓存：cassandra

本来我考虑是用mongodb，因为mongo的数据类型是JSON，和微博的返回结果完全一致，可以在不考虑任何数据结构的情况下，将查询结果直接存进mongodb。但是mongodb有两个比较大的问题，一是他是强一致性的，而实际上我们对一致性的要求并不高，甚至希望用弱一致性(W=0,R=1)来保证高可用；二是他的写性能并不如cassandra，由于cassandra采用了多层SSTable的方式，使得它能够在多次对同一个内容进行写操作时，merge多个SSTable成一个SSTable，即使反复update同一份数据也不会降低性能，非常适合SSD。

这个业务的特点是，写比读还多，并且同一份数据经常反复写。所以看来还是cassandra更加合适一点。

高并发api接口服务数据库：cassandra/riak

需求是读取和写入的并发都非常大，每天动态访问量上亿，尤其是读取。排除HBase，因为太笨重，排除mongodb，因为它仍然是主从结构，我非常不喜欢投票选主的模式，数据分片方面支持有限。其实可选择的只剩下riak和cassandra了。riak支持任意格式的数据，比较适合全手动地存储。cassandra是面向列的，能够帮助我们更多地完成一些业务逻辑。riak完整实现了向量时钟，而cassandra通过时间戳维护一致性。不过对cassandra和riak的索引机制还不够了解，无法确定索引的方便程度和可维护性。暂时还是偏向于cassandra。