数据库事务需要满足四个特性，ACID，即原子性(Atomic)，一致性(Consistency)，隔离性(Isolation)，持久性(Durability)。在关系数据库中，这些特性需要借助借助redo log、锁、snapshot等手段来实现。

隔离性要求各事务之间相互独立，所进行的操作不会相互影响，其用意还是保证各数据读写操作的一致性。标准SQL92规范定义了四种隔离级别，以及相应要禁止的三种现象(Phenomena)。隔离级别越高，数据一致性的保证越强，但同时数据库的并发能力也越差。

数据库并发操作引起的问题(现象)有：

1. 脏读(Dirty read)。事务A读取了事务B中尚未提交的数据。如果事务B回滚，则A读取使用了错误的数据。
2. 不可重复度(Unrepeatable read)。在事务A多次的读取过程中，事务B对数据进行了修改，导致事务A多次读取的数据不一致。
3. 幻读(Phantom read)。在事务A多次读取构成中，事务B对数据进行了新增操作，导致事务A多次读取的数据不一致。幻读和不可重复读的区别在于，不可重复是针对记录的update操作，只要在记录上加写锁，就可避免；幻读是对记录的insert操作，要禁止幻读必须加上全局的写锁(比如在表上加写锁)。

另外说一下两类丢失更新：

4.第一类丢失更新(回滚丢失，Lost update)。在事务A期间，事务B对数据进行了更新；在事务A撤销之后，覆盖了事务B已经提交的数据。SQL92没有定义这种现象，标准定义的所有隔离界别都不允许第一类丢失更新发生。
5.第二类丢失更新(覆盖丢失，Second lost update)。在事务A期间，事务B对数据进行了更新；在事务A提交之后，覆盖了事务B已经提交的数据。第二类丢失更新，实际上和不可重复读是同一种问题。

SQL92定义的四种隔离级别：

1.未提交读(Read uncommitted)。写操作加写锁，读操作不加锁。禁止第一类丢失更新，但是会出现所有其他数据并发问题。
2.提交读(Read committed)。写操作加写锁，读操作加读锁。禁止第一类丢失更新和脏读。这是大部分关系数据库的默认隔离级别。
3.可重复读(Read repeatable)。对于读操作加读锁到事务结束，其他事务的更新操作只能等到事务结束之后进行。和提交读的区别在于，提交读的读操作是加读锁到本次读操作结束，可重复读的锁粒度更大。禁止两类丢失更新，禁止脏读和不可重复度，但是可能出现幻读。
4.序列化(Serializable)。读操作加表级读锁至事务结束。可以禁止幻读。

	第一类丢失更新	脏读	不可重复读	第二类丢失更新	幻读
Read uncommitted	禁止	不禁止	不禁止	不禁止	不禁止
Read committed	禁止	禁止	不禁止	不禁止	不禁止
Read repeatable	禁止	禁止	禁止	禁止	不禁止
Serializable	禁止	禁止	禁止	禁止	禁止

大多数关系数据库默认使用Read committed的隔离级别，Mysql InnoDB默认使用Read repeatable的隔离级别，这和Mysql replication机制使用Statement日志格式有关。各数据库隔离级别的实现也是有差别的，例如Oracle支持Read committed和Serializable两种隔离级别，另外可以通过使用读快照在Read committed级别上禁止不可重复读问题；Mysql InnoDB在Read repeatable级别上使用next-key locking策略来避免幻读现象的产生。

Memcachedb与Tokyo Tyrant这两个东西，出发点不同，但结果却有点殊途同归。Memcachedb以bdb作为后端，给memcached增加持久化功能、事务支持及主辅同步等功能；Tokyo Tyrant 则是为 Tokyo Cabinet提供了网络接口和前端缓存。最终的结果，都是出现了一个支持高并发的分布式持久存储系统，适合于高速读写、无严格事务要求的应用场景。Tokyo Tyrant 同时提供了兼容Memcachedb的接口，因而理论上memcached的各种client也可用于Tokyo Tyrant 。

Memcachedb比较一提，因为它是国内的老牌门户sina的开源作品，广泛用于新浪博客等产品线中，像digg.com这样的站点也使用了memcachedb。虽然在此之前，cache+key-value数据库的方案其实已然大行其道，但首先开源的新浪，还是值得表扬表扬的。

Memcachedb引入bdb持久存储的代价还是不小的，虽然数据是先写到bdb的过程是异步的，性能上的cutoff还是相当客观；其并发写入的性能降到memcached的一般一下，不过读数据的性能损失较小。

From javaeye

随着互联网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这么热门的主要原因。

mysql会生成mysql-bin.xxxxxx形式的日志文件，从mysql-bin.000001开始，序号依次增长。这些日志文件中记录了所有在mysql中执行过的sql数据操作语句，如UPDATE，INSERT，CREATE之类，即使这些语句没有匹配的数据也会被记录下来。
这些日志有两个作用：
1. 用于主从同步。从服务器从主服务器同步日志，进行和主服务器一样的数据操作，完成数据库同步；
2. 用于从备份恢复。如果某个数据库操作命令造成了数据库数据的损坏、丢失，可以使用这些日志设法挽回损失。

这些日志增长的很快，一段时间后就会占满我机器上的小硬盘，为此要定期清除日志。

mysql-bin.index文件中记录了现在的日志，可以使用show binary logs;查看。如果有从服务器，需要使用SHOW SLAVE STATUS查看所有从服务器在读取那个日志，只能够删除所有从服务器均已读取过的日志。
使用FLUSH LOGS;或者RESET MASTER;可以重新开始生成日志。如果只要清除较早的日志，那么使用：
PURGE MASTER LOGS TO 'mysql-bin.000080'; 可以清除mysql-bin.000080以前记录的日志
PURGE MASTER LOGS BEFORE '2008-12-19 21:00:00';可以清除2008-12-19以前记录的日志

如果不需要记录日志，可以在mysql的配置文件中(/etc/my.cnf for linux)，注释掉：
#log-bin=mysql-bin
如果对binlog要求不是太高的话，可以设置自动清除的，mysql有一个参数expire_logs_days ,即保留多长时间的binlog
set @expire_logs_days＝xxx;
flush logs;