NoSQL数据库探讨之一 － 为什么要用非关系数据库？

找到两篇相关的好文章，期待有达人翻译一下：

http://horicky.blogspot.com/2009/11/nosql-patterns.html

http://www.slideshare.net/guestdfd1ec/design-patterns-for-distributed-nonrelational-databases

这两篇文章都很棒，所以我说NoSQLDB钻研进去，也挺博大精深的，有空的话是应该仔细研读一下。

不过从我个人实用角度出发，我对偏理论的paper不是太感兴趣，我更感兴趣的是具体的产品特点、用法和适用场景，以及我应该在什么场景选择什么产品，制订怎样的解决方案。

可惜MongoDb对全文检索的支持不好，本来还打算用他的。

TC的数据量非常大的话，性能下降很快，具体的数据我已经忘了，但印象中当达到百万数据量的时候，写数据的操作已经到达了秒级别，也可能是我不懂怎么优化。

Redis正如Robbin所说，它的List操作PUSH和POP时间复杂度都是O(1)。但是如果内存数据太大，（写盘）会导致性能下降，而限制内存的话，当达到上限的时候就会出现写失败。所以最适合一边生产一边消费的Queue应用，可以称得上是最快的消息队列服务了。实际上Github的resque非常好地利用了这一特性，性能上大大操过DJ。对绝大多数Ruby网站都很有意义，因为（潜在的）你几乎可以在任何一个action中加入queue操作而不影响用户响应时间和本Ruby进程。redis支持主从复制结构，但master崩溃的时候需要手工复制。

这里有篇很棒的文章，介绍各个NoSQLDB： NoSQL: If Only It Was That Easy

他提到Tokyo Cabinet在大数据量的时候性能下降问题：



当我们尝试在单个TT服务器节点里面插入1.6亿条2-20KB的记录的时候，TC的写数据性能迅速下降，你可以看到一个像滑雪一样的性能下降曲线。

看来是当数据量上亿条的时候，TC性能开始大幅度下降，从TC作者自己提供的mixi数据来看，至少上千万条数据量的时候还没有遇到这么明显的写入性能瓶颈。

关于tc scale的问题，可以关注下lightcloud

半年前，我对mongodb就开始关注子了，这个东西非常像mysql。

他介乎key-value和rdbms之间，各自的优点都具备。

另外版本升级飞快，从0.x到现在支持的特性越来越多，我也准备应用他作为social game的后端存储。

个人认为 SQL 与否并不是问题的实质，真正的问题在于为不同的场景选择不同的数据结构及其存储方式。传统的关系数据库把一切数据看成“关系”这种离散的逻辑数据结构，而关系是要切实存储下来的，于是出来了各种存储引擎，针对关系的各种检索方式，出来了各种索引（树，散列表等等）。这些索引的用途实际上只是以“适应算法要求”的最高效率的方式找到所需的“关系”集合。

基于这种思路，所谓的 NoSQLDB 只是让问题回归实质而已——使用不同的数据结构来存储数据，这些数据的存取方式各异。

而 key-value 数据库，实际上只是“关系+散列索引”的另一种表现形式。这种数据结构不支持 range 查询。

想支持还是可以支持的。

不过前面的话我还是很赞同的。

第一篇打不开，郁闷 ~~~