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

原文转载自：http://robbin.iteye.com/blog/524977

1.NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，

随着互联网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个数据库。 

2.数据库事务   隔离级别、锁的理解与整理（转载自：http://wangcfxbg.iteye.com/blog/1137719）

         数据库事务是数据库并发控制的基本单位，是一组操作的一个集合。这些操作要么都执行，要么都不执行，是一个不可分割的整体。。比如银行的转账，钱从一个账户转移到另一个账户，账户A扣钱账户B加钱，要么都执行，要么都不执行。不可能A扣了钱B没有加钱，也不可能A没扣钱B却加了钱。

        数据库事务应该有一下特性：

Atomic（原子性）

事务中包含的操作被看做一个逻辑单元，这个逻辑单元中的操作要么全部成功，要么全部失败。

Consistency（一致性）

只有合法的数据可以被写入数据库，否则事务应该将其回滚到最初状态。

Isolation（隔离性）

事务允许多个用户对同一个数据进行并发访问，而不破坏数据的正确性和完整性。

同时，并行事务的修改必须与其他并行事务的修改相互独立。

事务的隔离性一般由事务的锁来进行控制。

Durability（持久性）

事务结束后，事务处理的结果必须能够得到固化。

数据库的事务和线程相似的地方：

1.线程之间共享同一片资源，而事务共享的则是数据库内的数据。

2.多线程的意义在于并发执行，提高效率；事务并发执行也能提高程序与数据库交互的效率。

选择完隔离级别与设计完事务之后，在使用过程中常常会遇到以下几种情况：

 

1.更新丢失（Lost update）：两个事务同时更新，但是第二个事务却中途失败退出，导致对数据的两个修改都失效了。

2.脏读（Dirty Reads）：一个事务开始读取了某行数据，但是另外一个事务已经更新了此数据但没有能够及时提交。这是相当危险的，因为很可能所有的操作都被回滚。

3.不可重复读取（Non-repeatable Reads）：一个事务两次读取，但在第二次读取前另一事务已经更新了。

4.虚读（Phantom Reads）：一个事务两次读取，第二次读取到了另一事务插入的数据。

5.两次更新问题（Second lost updates problem）：两个事务都读取了数据，并同时更新，第一个事务更新失败。

 

 

 

隔离级别（低->高）

 

●   未授权读取（Read Uncommitted）

允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个数据则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。

 

●   授权读取（Read Committed）

允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。

 

●   可重复读取（Repeatable Read）

禁止不可重复读取和脏读取，但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。

 

●   序列化（Serializable）

提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

 

 

个人觉得隔离级别的翻译不是很好理解，直接按照英语的意思理解更方便。

 

 

 

eg：

 

假设账户c1有1000元,c2有1000元,c3有1000元

操作员u1执行一次转账事务m1从c1转移500元到c2，再从c1的余额中转移50%元平均分配到 c1 c2 c3 c4 c5余额中

操作员u2执行一次转账事务m2从c2转移1000元到c1

操作员u3执行一次转账事务m3从c1转移200元到c2

操作员u4开户c4

 

 

账户表为T_C，其包含字段为 账户名称cname 余额money

记录为{c1,1000},{c2,1000}

事务m1的操作包括,读c1,读c2,写c1,写c2,提交c1c2,读c1,读c3,写c3,写c3,提交c1c3

事务m2的操作包括,读c2,读c1,写c2,写c1,提交c1c2

事务m3的操作包括,读c1,读c2,写c1,写c2,提交c1c2

事务m4的操作包括,写c4，提交c4

 

 

1.若未授权读取ReadUncommitted

m1读c1,c2,写了c1但没写c2此时m2不可以写c2,可以读取c1和c2,但是c2是脏读。隔离级别使用了“排他写锁”。

 

2.若授权读取ReadCommitted

m1读c1,c2,写了c1但没写c2此时m2不可以写c2,可以读取c1,不能读取c2，因为c2是脏读。隔离级别使用了“排他写锁”。

m1读写了c1,c2,提交c1c2,m3提交了c1c2此时m1准备第二次c1是允许的。隔离级别使用了“瞬间共享读锁”。（但由于第二次读产生了不可重复读的问题，事务1脱力了元自行，因为逻辑上看事务1中被插入了3，影响了c1的余额50%的计算。）

 

3.若可重复读取RepeatableRead

m1读c1,c2,写了c1但没写c2此时m2不可以写c2,可以读取c1,不能读取c2，因为c2是脏读。隔离级别使用了“排他写锁”。

m1读写了c1,c2,提交c1c2,m4提交了c4此时m3是能读不能写c1并更新提交的。此时m4是能读能能插入c4的。隔离级别使用了“共享读锁”。（和ReadCommitted比RepeatableRead区别对已经提交的事务可以进行读，但不能写，但是同一张表可以插入新的记录。）

 

4.序列化Serializable

任何事务都只能等前一事务完全执行完再执行。 但是失去了并发性。

 

对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed，它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、虚读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

 

选取数据库的隔离级别时，应该注意以下几个处理的原则：

首先，必须排除“未授权读取”，因为在多个事务之间使用它将会是非常危险的。事务的回滚操作或失败将会影响到其他并发事务。第一个事务的回滚将会完全将其他事务的操作清除，甚至使数据库处在一个不一致的状态。很可能一个已回滚为结束的事务对数据的修改最后却修改提交了，因为“未授权读取”允许其他事务读取数据，最后整个错误状态在其他事务之间传播开来。

其次，绝大部分应用都无须使用“序列化”隔离（一般来说，读取幻影数据并不是一个问题），此隔离级别也难以测量。目前使用序列化隔离的应用中，一般都使用悲观锁，这样强行使所有事务都序列化执行。

 

       剩下的也就是在“授权读取”和“可重复读取”之间选择了。我们先考虑可重复读取。如果所有的数据访问都是在统一的原子数据库事务中，此隔离级别将消除一个事务在另外一个并发事务过程中覆盖数据的可能性（第二个事务更新丢失问题）。这是一个非常重要的问题，但是使用可重复读取并不是解决问题的唯一途径。

 

 

SQL语句可以使用SET TRANSACTION ISOLATION LEVEL来设置事务的隔离级别。

如：SET TRANSACTION ISOLATION LEVEL   Read Committed。

若要在应用程序中使用更严格或较宽松的隔离级别，可以通过使用   set transaction isolation level语句设置会话的隔离级别，来自定义整个会话的锁定。指定隔离级别后，sql server会话中所有select语句的锁定行为都运行于该隔离级别上，并一直保持有效直到会话终止或者将隔离级别设置为另一个级别。

 

 

锁（并发控制的手段）

 

独占锁（排他锁） 只允许一个事务访问数据 

共享锁 允许其他事务继续使用锁定的资源 

更新锁

 

锁就是保护指定的资源，不被其他事务操作，锁定的资源包括行、页、簇、表和数据库。为了最小化锁的成本，SQL Server自动地以与任务相应等级的锁来锁定资源对象。锁定比较小的对象，例如锁定行，虽然可以提高并发性，但是却有较高的开支，因为如果锁定许多行，那么需要占有更多的锁。锁定比较大的对象，例如锁定表，会大大降低并发性，因为锁定整个表就限制了其他事务访问该表的其他部分，但是成本开支比较低，因为只需维护比较少的锁。

 

  设置事务级别：SET TRANSACTION ISOLATION LEVEL

开始事务：begin tran 

提交事务：COMMIT

回滚事务：ROLLBACK 

创建事务保存点：SAVE TRANSACTION savepoint_name 

回滚到事务点:ROLLBACK TRANSACTION savepoint_name

       

3.存储过程        

             存储过程（Stored Procedure）是在大型数据库系统中，一组为了完成特定功能的SQL 语句集，经编译后存储在数据库中，用户通过指定存储过程的名字并给出参数（如果该存储过程带有参数）来执行它。
              

             存储过程就是已经编译好的、优化过的放在数据库服务器中的一些SQL语句；可供应用程序直接调用。使用存储过程有以下几个优点

 1、执行速度比普通的SQL语句快
      再运行存储过程前，数据库已对其进行了语法和句法分析，并给出了优化执行方案。这种已经编译好的过程可极大地改善SQL语句的性能。 由于执行SQL语句的大部分工作已经完成，所以存储过程能以极快的速度执行。
2、便于集中控制
      当企业规则变化时，只需要在数据库的服务器中修改相应的存储过程，而不需要逐个的在应用程序中修改，应用程序保持不变即可，这样就省去了修改应用程序工作量。
3、可以降低网络的通信量

4、保证数据库的安全性和完整性

      通过存储过程不仅可以使没有权限的用户在控制之下间接地存取数据库，保证数据的安全；而且可以使相关的动作在一起发生，从而可以维护数据库的完整性。
5、灵活性
      存储过程可以用流控制语句编写，具有很强的灵活性，可以完成复杂的判断和运算，可以根据条件执行不通SQL语句。

4存储过程与事务的区别：

存储过程：是 已经编译好了，优化过了的，存放在数据库服务器中一系列SQL语句的集合 。用户可以提供参数或者不提供参数来调用这个 存储过程。

事务：是数据库并发控制的最小单元，是一系列操作的集合。集合的所有操作要么全部执行，要么全部不执行。四个特征：原子型，隔离型，一致性，持久性。