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

随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：

1、High performance - 对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。

2、Huge Storage - 对海量数据的高效率存储和访问的需求
类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。

3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求
在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？

在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：

1、数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。

2、数据库的写实时性和读实时性需求
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说我（JavaEye的robbin）发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。

3、对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生，现在这两年，各种各样非关系数据库，特别是键值数据库(Key-Value Store DB)风起云涌，多得让人眼花缭乱。前不久国外刚刚举办了NoSQL Conference，各路NoSQL数据库纷纷亮相，加上未亮相但是名声在外的，起码有超过10个开源的NoSQLDB，例如：

Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB，  ......

这些NoSQL数据库，有的是用C/C++编写的，有的是用Java编写的，还有的是用Erlang编写的，每个都有自己的独到之处，看都看不过来了，我(robbin)也只能从中挑选一些比较有特色，看起来更有前景的产品学习和了解一下。这些NoSQL数据库大致可以分为以下的三类：

一、满足极高读写性能需求的Kye-Value数据库：Redis，Tokyo Cabinet， Flare

高性能Key-Value数据库的主要特点就是具有极高的并发读写性能，Redis，Tokyo Cabinet， Flare，这3个Key-Value DB都是用C编写的，他们的性能都相当出色，但出了出色的性能，他们还有自己独特的功能：

1、Redis
Redis是一个很新的项目，刚刚发布了1.0版本。Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过10万次读写操作，是我知道的性能最快的Key-Value DB。

Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存List链表和Set集合的数据结构，而且还支持对List进行各种操作，例如从List两端push和pop数据，取List区间，排序等等，对Set支持各种集合的并集交集操作，此外单个value的最大限制是1GB，不像memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一个功能加强版的memcached来用。

Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，并且它没有原生的可扩展机制，不具有scale（可扩展）能力，要依赖客户端来实现分布式读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。目前使用Redis的网站有github，Engine Yard。

2、Tokyo Cabinet和Tokoy Tyrant
TC和TT的开发者是日本人Mikio Hirabayashi，主要被用在日本最大的SNS网站mixi.jp上，TC发展的时间最早，现在已经是一个非常成熟的项目，也是Kye-Value数据库领域最大的热点，现在被广泛的应用在很多很多网站上。TC是一个高性能的存储引擎，而TT提供了多线程高并发服务器，性能也非常出色，每秒可以处理4-5万次读写操作。

TC除了支持Key-Value存储之外，还支持保存Hashtable数据类型，因此很像一个简单的数据库表，并且还支持基于column的条件查询，分页查询和排序功能，基本上相当于支持单表的基础查询功能了，所以可以简单的替代关系数据库的很多操作，这也是TC受到大家欢迎的主要原因之一，有一个Ruby的项目miyazakiresistance将TT的hashtable的操作封装成和ActiveRecord一样的操作，用起来非常爽。

TC/TT在mixi的实际应用当中，存储了2000万条以上的数据，同时支撑了上万个并发连接，是一个久经考验的项目。TC在保证了极高的并发读写性能的同时，具有可靠的数据持久化机制，同时还支持类似关系数据库表结构的hashtable以及简单的条件，分页和排序操作，是一个很棒的NoSQL数据库。

TC的主要缺点是在数据量达到上亿级别以后，并发写数据性能会大幅度下降，NoSQL: If Only It Was That Easy提到，他们发现在TC里面插入1.6亿条2-20KB数据的时候，写入性能开始急剧下降。看来是当数据量上亿条的时候，TC性能开始大幅度下降，从TC作者自己提供的mixi数据来看，至少上千万条数据量的时候还没有遇到这么明显的写入性能瓶颈。

这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考

3、Flare
TC是日本第一大SNS网站mixi开发的，而Flare是日本第二大SNS网站green.jp开发的，有意思吧。Flare简单的说就是给TC添加了scale功能。他替换掉了TT部分，自己另外给TC写了网络服务器，Flare的主要特点就是支持scale能力，他在网络服务端之前添加了一个node server，来管理后端的多个服务器节点，因此可以动态添加数据库服务节点，删除服务器节点，也支持failover。如果你的使用场景必须要让TC可以scale，那么可以考虑flare。

flare唯一的缺点就是他只支持memcached协议，因此当你使用flare的时候，就不能使用TC的table数据结构了，只能使用TC的key-value数据结构存储。

二、满足海量存储需求和访问的面向文档的数据库：MongoDB，CouchDB

面向文档的非关系数据库主要解决的问题不是高性能的并发读写，而是保证海量数据存储的同时，具有良好的查询性能。MongoDB是用C++开发的，而CouchDB则是Erlang开发的：

1、MongoDB
MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。

Mongo主要解决的是海量数据的访问效率问题，根据官方的文档，当数据量达到50GB以上的时候，Mongo的数据库访问速度是MySQL的10倍以上。Mongo的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理0.5万－1.5次读写请求。对于Mongo的并发读写性能，我（robbin）也打算有空的时候好好测试一下。

因为Mongo主要是支持海量数据存储的，所以Mongo还自带了一个出色的分布式文件系统GridFS，可以支持海量的数据存储，但我也看到有些评论认为GridFS性能不佳，这一点还是有待亲自做点测试来验证了。

最后由于Mongo可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎，很多项目都考虑用MongoDB来替代MySQL来实现不是特别复杂的Web应用，比方说why we migrated from MySQL to MongoDB就是一个真实的从MySQL迁移到MongoDB的案例，由于数据量实在太大，所以迁移到了Mongo上面，数据查询的速度得到了非常显著的提升。

MongoDB也有一个ruby的项目MongoMapper，是模仿Merb的DataMapper编写的MongoDB的接口，使用起来非常简单，几乎和DataMapper一模一样，功能非常强大易用。

2、CouchDB
CouchDB现在是一个非常有名气的项目，似乎不用多介绍了。但是我却对CouchDB没有什么兴趣，主要是因为CouchDB仅仅提供了基于HTTP REST的接口，因此CouchDB单纯从并发读写性能来说，是非常糟糕的，这让我立刻抛弃了对CouchDB的兴趣。

三、满足高可扩展性和可用性的面向分布式计算的数据库：Cassandra，Voldemort

面向scale能力的数据库其实主要解决的问题领域和上述两类数据库还不太一样，它首先必须是一个分布式的数据库系统，由分布在不同节点上面的数据库共同构成一个数据库服务系统，并且根据这种分布式架构来提供online的，具有弹性的可扩展能力，例如可以不停机的添加更多数据节点，删除数据节点等等。因此像Cassandra常常被看成是一个开源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java开发的：

1、Cassandra
Cassandra项目是Facebook在2008年开源出来的，随后Facebook自己使用Cassandra的另外一个不开源的分支，而开源出来的Cassandra主要被Amazon的Dynamite团队来维护，并且Cassandra被认为是Dynamite2.0版本。目前除了Facebook之外，twitter和digg.com都在使用Cassandra。

Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的一个写操作，会被复制到其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事情，只管在群集里面添加节点就可以了。我看到有文章说Facebook的Cassandra群集有超过100台服务器构成的数据库群集。

Cassandra也支持比较丰富的数据结构和功能强大的查询语言，和MongoDB比较类似，查询功能比MongoDB稍弱一些，twitter的平台架构部门领导Evan Weaver写了一篇文章介绍Cassandra：http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/，有非常详细的介绍。

Cassandra以单个节点来衡量，其节点的并发读写性能不是特别好，有文章说评测下来Cassandra每秒大约不到1万次读写请求，我也看到一些对这个问题进行质疑的评论，但是评价Cassandra单个节点的性能是没有意义的，真实的分布式数据库访问系统必然是n多个节点构成的系统，其并发性能取决于整个系统的节点数量，路由效率，而不仅仅是单节点的并发负载能力。

2、Voldemort
Voldemort是个和Cassandra类似的面向解决scale问题的分布式数据库系统，Cassandra来自于Facebook这个SNS网站，而Voldemort则来自于Linkedin这个SNS网站。说起来SNS网站为我们贡献了n多的NoSQL数据库，例如Cassandar，Voldemort，Tokyo Cabinet，Flare等等。Voldemort的资料不是很多，因此我没有特别仔细去钻研，Voldemort官方给出Voldemort的并发读写性能也很不错，每秒超过了1.5万次读写。

从Facebook开发Cassandra，Linkedin开发Voldemort，我们也可以大致看出国外大型SNS网站对于分布式数据库，特别是对数据库的scale能力方面的需求是多么殷切。前面我（robbin）提到，web应用的架构当中，web层和app层相对来说都很容易横向扩展，唯有数据库是单点的，极难scale，现在Facebook和Linkedin在非关系型数据库的分布式方面探索了一条很好的方向，这也是为什么现在Cassandra这么热门的主要原因。

如今，NoSQL数据库是个令人很兴奋的领域，总是不断有新的技术新的产品冒出来，改变我们已经形成的固有的技术观念，我自己（robbin）稍微了解了一些，就感觉自己深深的沉迷进去了，可以说NoSQL数据库领域也是博大精深的，我（robbin）也只能浅尝辄止，我（robbin）写这篇文章既是自己一点点钻研心得，也是抛砖引玉，希望吸引对这个领域有经验的朋友来讨论和交流。

从我（robbin）个人的兴趣来说，分布式数据库系统不是我能实际用到的技术，因此不打算花时间深入，而其他两个数据领域（高性能NoSQLDB和海量存储NoSQLDB）都是我很感兴趣的，特别是Redis，TT/TC和MongoDB这3个NoSQL数据库，因此我接下来将写三篇文章分别详细介绍这3个数据库。

评论

35 楼 willko 2009-11-25  

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

34 楼 robbin 2009-11-25  

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

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

引用

We tried to insert 160mil 2k -20k documents into a single Tokyo Tyrant server, and performance quickly dropped off and kept going down. You could have had a nice holiday skiing on the graph of inserts/sec. This is pretty typical of anything that you write to a disk. The more you write, the slower it goes. We could distribute the write easily, because Tokyo doesn’t scale.

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

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

33 楼 potian 2009-11-25  

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

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

32 楼 genki 2009-11-25  

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

31 楼 robbin 2009-11-25  

庄表伟 写道

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

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

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

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

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

30 楼 庄表伟 2009-11-25  

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

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

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

29 楼 dalviker 2009-11-25  

robbin的看法很独到。
对于bigtable，不能用SQL的用法来要求它。几年之后，随着NoSql的普及，大家会把它用在它适合发挥的地方，同时形成一套成熟的用法。

28 楼 robbin 2009-11-25  

hideto 写道

robbin 写道

bingobird 写道

非关系型数据库更多的是解决海量数据时主键型查询及更新的问题。
它有个比较难解决的就是非主键的查询，比如取一用户的所有好友列表。

大数据量下我们目前解决方法是通过搜索引擎或数据库集群+缓存处理，但前者用作查询并不合适，后者mysql及pg在这块的支持还不是很好，收费的又太贵。

这个需求一点都不难，关键还是你对数据存储结构的设计是不是合理，比方说用Redis的话，用单独的Set来保存某个用户的好友列表： user:id:friends => [friend_id1, friend_id2, ...]，如果是用TC的话，就更简单了，用一个单独的表保存用户订阅关系，然后直接查询就行了。

这个例子还是太简单了，比较复杂的查询用key-value应该是没法实现的，比如论坛用户积分top10列表。
所以一般是需要借助一些外部search engine来做

1、NoSQLDB和SQLDB不是一个完全的取代关系，而是互补的关系，不要假设所有的应用场景都强迫自己用NoSQLDB。

以上面那个用户订阅的例子来说，很多情况下是需要用NoSQLDB存储的，比方说twitter类型的应用，对用户的follows列表有非常高的读取的需求，如果存储在关系数据库里面，SQL负载会太重，不如NoSQLDB速度快，而且并发读取性能更高。所以那是一个很适合用NoSQLDB的场景。

而你举例论坛top积分用户，这个需求根本就不需要高性能读取，甚至也不需要实时性，完全没有必要用NoSQLDB，而且即便是用SQL数据库，也不能很好的处理这种需求，以JavaEye的博客排行榜为例，生成月度和年度博客排行榜是一个非常耗时的SQL查询，根本就不能搞成实时查询，我们是每天晚上跑一个复杂的SQL语句，把结果生成html片段保存下来，然后页面直接拼接起来显示。

2、即使用NoSQLDB单纯的取论坛用户积分top10列表，TT/TC也不过就是一条查询而已，和SQLDB没有任何区别，TC的table存储结果本身就支持条件查询，分页结果集和排序。

27 楼 rmn190 2009-11-25  

谢谢robbin分享这么难得的文章！

26 楼 willko 2009-11-25  

非常期待下篇文章。

我也是选择了，Redis，TT/TC和MongoDB了。
主要是解决了不同问题，其次是php能够很好支持也是一大原因之一。

25 楼 hideto 2009-11-25  

robbin 写道

bingobird 写道

非关系型数据库更多的是解决海量数据时主键型查询及更新的问题。
它有个比较难解决的就是非主键的查询，比如取一用户的所有好友列表。

大数据量下我们目前解决方法是通过搜索引擎或数据库集群+缓存处理，但前者用作查询并不合适，后者mysql及pg在这块的支持还不是很好，收费的又太贵。

这个需求一点都不难，关键还是你对数据存储结构的设计是不是合理，比方说用Redis的话，用单独的Set来保存某个用户的好友列表： user:id:friends => [friend_id1, friend_id2, ...]，如果是用TC的话，就更简单了，用一个单独的表保存用户订阅关系，然后直接查询就行了。

这个例子还是太简单了，比较复杂的查询用key-value应该是没法实现的，比如论坛用户积分top10列表。
所以一般是需要借助一些外部search engine来做

24 楼 luolonghao 2009-11-25  

ahuaxuan 写道

数据库革命还谈不上，这些东西最多就是弥补数据库的缺点，在整个架构中，属于和数据库相互补充的这个一个角色。

当然我也想知道是否有大型网站完全不用数据库的，知道的同志出来说说。

mixi.jp在极少数功能里用了TC，大部分功能还是memcached + mysql架构。
其它网站不知道，完全不用关系数据库不太可能吧，Key-Value数据库应该是弥补关系数据库缺点的，不是代替关系数据库的。

23 楼 robbin 2009-11-25  

bingobird 写道

非关系型数据库更多的是解决海量数据时主键型查询及更新的问题。
它有个比较难解决的就是非主键的查询，比如取一用户的所有好友列表。

大数据量下我们目前解决方法是通过搜索引擎或数据库集群+缓存处理，但前者用作查询并不合适，后者mysql及pg在这块的支持还不是很好，收费的又太贵。

这个需求一点都不难，关键还是你对数据存储结构的设计是不是合理，比方说用Redis的话，用单独的Set来保存某个用户的好友列表： user:id:friends => [friend_id1, friend_id2, ...]，如果是用TC的话，就更简单了，用一个单独的表保存用户订阅关系，然后直接查询就行了。

22 楼 robbin 2009-11-25  

AreYouOK? 写道

我在工作中也遇到很多问题，关系数据库确实有些力不从心了，但是不使用关系数据库，面对复杂的查询，没有好的解决方案。
从这篇文章的介绍看，我对MongoDB最感兴趣，期待后续。

我的需求和这里列出的Web2.0的网站需求还不太一样。我的场景是：

• 数据量非常巨大，写操作特别多。数据量可以说是无限的，就看系统能处理多少，如果能处理更多就要接入更多的数据（一般来说我们只接入了部分数据）。
• 读操作非常少，可以用每天多少次来衡量（就那么几个使用人员，他用的时候才有查询操作），但是一旦有查询操作，往往都是重量级的。
• 查询操作可以稍微慢点，能在5秒内出来就不错了，如果进行复杂的查询，30秒出来也算不错了。10分钟甚至1个小时才查出结果，是非常不好的，但是能出来总比不能要好。
• 写操作允许丢失少量数据，但是整个数据库的完整性要有保证
• 数据最好能够压缩存储

在某个项目里面，数据量大的时候大约每天40、50G，使用postgresql，居然也支撑了下来，但是查询非常慢。接下来的一些项目数据量会更大，可能会有这个量的100倍以上，目前没有好的办法，只能从数据源头先做过滤。

我在1年前，开始尝试进行一些探索，根据产品需求特点，使用自定义的数据格式存储。目前能够解决的问题有：

• 对数据进行简单的解析和压缩存储
• 能够对压缩的数据进行简单的查询（指定数据源、时间范围、关键字），查询较慢，但是比SQL有一个好处，就是能看见当前查询到哪个时间点了，而不是像SQL一样，等运行完了才能给用户看到
• 高性能的写入。目前在我的笔记本上进行简单的测试，每秒2万条的UDP包，丢包率是0.5%，在复杂的环境下性能是会下降的，但服务器的性能会更好

不幸的是，我只有很少的时间能投入到这上面，有时候几个星期都没空去弄，所以到现在还有很多要完善的地方，没有在项目里面实用。有时候我都怀疑这条路是不是走错了。

目前没有解决的问题是高性能的、对数据的复杂查询。数据可以分为2部分，原始数据和格式化后的数据，目前我这里只解决了原始数据的问题，对于格式化数据的复杂查询，还是需要类似关系数据库的功能才行。这也是我对MongoDB比较感兴趣的原因。

这种应用场景比较适合MongoDB，很多MongoDB的应用都是用Mongo来存储海量的日志数据，然后对日志数据进行查询和分析。 应付几十上百GB的单表进行SQL查询，关系数据库的查询性能下降的非常可怕，动辄几十秒到几分钟，而Mongo主要特点就是对海量存储数据的查询速度非常快，查询速度往往在毫秒级别搞定。

21 楼 robbin 2009-11-25  

keakon 写道

平时经常做GAE的开发，所以经常接触BigTable。

感觉这个GAE上的BigTable的限制还是比较多的。例如无索引就不能查询，不能对2个以上的属性进行不等于操作（如>、<），使用不等于操作必须先对该属性进行排序，事务操作时不能使用查询，事物中操作的实体必须在同一个实体组…

我不知道其他NoSQLDB是不是也有这些问题，但对开发肯定有影响。例如想找最近10天评价最高的几篇帖子就是不可能的，因为对时间进行了不等于操作，就必须先对时间排序，之后才能对评价进行排序。

非关系型还有个缺点就是表之间的关联。Join操作不能用了，于是得取出一个表里所有符合的列，再对另一个表进行多次的查询（虽然BigTable也支持IN操作，但限制数目最多20，而且内部实现是多个并发的=操作）。如果涉及到3个以上的表的话，这种操作的效率和代码量更是不可接受的。

你还是在用关系数据库SQL的思路去套BigTable，对于NoSQLDB来说，不是简单的换个数据库就可以了，你的编程思路和设计要相应的转变。

keakon 写道

至于读写的效率，我感觉BigTable也并没有什么优势。
昨天刚写了一个测试，保存1个含10个字符串属性的实体到数据库，约需30ms；获取约需10ms（我是直接用key来获取，没有进行查询操作）：
http://test.latest.keakon.appspot.com/test

之前还测试过大批数据的存取：保存、删除100个含1个字符串的实体，需700～800ms，500个需3000～4000ms；获取10个约需40ms，100个需150～200ms，500个需300～400ms，1000个需500～600ms。（500和1000是写、读的最大限制了，不能继续往下测试了。）
http://gaejava.appspot.com/

因为大批数据的操作是由数据库完成的，网络延时可以忽略了。我不知道GAE后台部署了多少数据库服务器，但肯定是个集群，所以这种测试也不只是使用一个数据库。
由于写操作基本和数目成正比，所以差不多就这个性能了，每个约7ms；读似乎还能提速，但应该达不到1W的并发。注意这还只是操作的记录数，而不是操作的次数（操作只有1次）。如果按每次读10个来计算，能达到1000的并发就不错了。
顺带一提，现在我的这个模型（表）的大小约100MB（含索引），而MySQL要达到这个性能应该是很轻松的。

当然，对我来说根本用不到1000并发，GAE本身也有每分钟3万次页面请求的配额限制。
而数据量的话，我那个blog有20篇日志，用了约500个实体，占用约300KB数据库空间。要到GB级的话，我得写十万篇日志，对个人网站来说基本不可能…

事实上BigTable给我的感觉就是限制太多，性能一般，优点用不上。
虽然对搜索引擎有用，但那至少是几十万台服务器的，否则如何支撑几十亿的PV？[/url]

我主贴已经很明确的指出，BigTable这种分布式的数据库系统面向的问题领域是横向扩展，而不是为了追求高性能高并发读写的速度，而且我已经举出来Cassandra的例子着重谈了这点，显然你还没有理解BigTable的应用场合以及要解决的是什么问题。

BigTable要解决的是scale的问题，例如海量用户比方说几亿几十亿用户同时去访问这个系统，而这个系统不会被如此巨大访问量冲溃的问题，具体到单个用户，他读写速度只要在可以接受的范围就可以了，并不要求单个用户的请求在极快的时间内处理完毕。

20 楼 robbin 2009-11-25  

风向逆转 写道

期待robbin的后续文章。
公司产品在用TT/TC,且发布在mixi.jp上。藉此robbin的介绍文章，回头研究一下TT/TC在我们产品上面的使用

莫非是阳光牧场？ social game需要很高的并发写数据请求，用TT/TC倒是很合适。

19 楼 ahuaxuan 2009-11-25  

数据库革命还谈不上，这些东西最多就是弥补数据库的缺点，在整个架构中，属于和数据库相互补充的这个一个角色。

当然我也想知道是否有大型网站完全不用数据库的，知道的同志出来说说。


==================================================================
对于TT+TC, 之前做过一个简单的测试，不过是针对较大数据的，使用的是memcached协议测试的：
keylength valuelength threads request/per thread get set r/s w/s read write
20b 11kb 5 10000 31.587 26.25 1612/s 1923/s 17m/s 20m/s
20b 22kb 5 10000 113.463 162.317 442 308 9m/s 6m/s
20b 33kb 5 10000 267.256 1218.055 187 41 6m/s 1m/s
20b 55kb 5 10000 274.635 2096.671 182 23 9m/s 1m/s
20b 110kb 5 10000 579.711 5921.827 86 8 9m/s <1m/s


memcached客户端也换了几个，有spymemcached, dennis的xmemcached，还有我自己也写了一个nio的客户端，测试结果基本一样，区别不是很大。

11kb时的性能还是相当的好的，每秒写入的速度达到了20M, 我用bdb做local的测试，最快每秒写入可以到达35M,那么应该说来tt+tc在11kb下的写入速度收到网络方面的影响（测试方法：client和server在同一台机器上，而且client请求的是localhost）

如果要达到读写4w/s,那估计value要小于1kb才行，或者直接SSD

===================================================================
而cassandra确实不错，之前我也看了一些代码，主要是dynamic和bigtable两种理论的结合，客户端和服务器之间没有中间的层次，减少的层次上的通信，加上bigtable，确实可以提供给我们很多特性（对我来说最有用的应该是版本号）。不过目前它还在0.4版本，不知道靠不靠谱。有待验证。

18 楼 comet12345678 2009-11-25  

在web应用的推动下，非关系数据库得到了极大的发展空间

17 楼 arust 2009-11-25  

Redis 现在已经发布了 1.02 版，从 TODO 来看，在未来的版本更新中，现有的很多缺点都将得到改进

引用

VERSION 1.1 TODO (Zsets, Integer encoding, Append only journal)
VERSION 1.2 TODO (Hash type)
VERSION 1.3 TODO (Virtual memory)
VERSION 1.4 TODO (Fault tollerant sharding)
VERSION 1.5 TODO (Optimizations and latency)

数据库革命已经来临，大家拭目以待吧

16 楼 Trustno1 2009-11-25  

庄表伟 写道

Trustno1 写道

庄表伟 写道

Trustno1 写道

实际上从Codd的观念来说,当今的RMDB其实都不算是关系数据最多就是只是算SQLRMDB.关系数据的第一条就是,数据的关系与底层的实现是没有关系的.数据上存在关系，与你底层使用key-value,还是table还是层次数据或者网状数据，都没有关系。Codd只是说，如果一个数据库能够接受一个关系代数并且给出相关结果，那么就是关系数据库。

正好想问问你，或者说大家来探讨一下：

为什么，Codd的观念，大家都没遵守呢？虽然大家都尊他为关系型数据库之父。

性能,关系数据一大要求就是不能因为性能而改变逻辑结构。比如说一个tuple{id,year,name,salary},按照SQL的做法搞一个表吧,按照id为key.然后存啊存啊存，发现数据越大查询性能越慢，恩然后程序员说我们分表吧，一年一个表.这种情况在关系数据里是不允许的。

如果真是这么简单的原因的话，那么Codd的不允许，岂不是一开始就错了？

当年Codd针对关系数据提出了12条Rule,其中Rule 8,Rule9就是说的这个
Rule 8: Physical data independence:
Changes to the physical level (how the data is stored, whether in arrays or linked lists etc.) must not require a change to an application based on the structure.


Rule 9: Logical data independence:
Changes to the logical level (tables, columns, rows, and so on) must not require a change to an application based on the structure. Logical data independence is more difficult to achieve than physical data independence.