key-value数据库

http://blog.csdn.net/byane/article/details/6928519

传统的文件系统中，需要维护目录的层次结构，使用dentry，inode，directory等复杂结构保存元数据的信息；而面对更多定制文件系统的需求，越来越多的系统考虑使用key-value形式保存文件系统中的元数据信息。使用数据库来保存这些元数据的key-value对是一个不错的选择，相比传统的关系型数据库，key-value数据库在这方面更贴近应用需求，因为，保存元数据的数据库往往不会有复杂的关系操作，仅仅需要提供高效的读写性能，可靠性和持久化。

Berkeley DB

比较经典的key-value数据库，C语言开发，能够提供较高的读写性能，支持海量存储应用，数据库自身实现了备份机制，支持两种备份开发机制，接口简单。开源，但是貌似现在没有人维护了，据说在持久化上做得不太好。

SQLite

1. ACID事务
2. 零配置 – 无需安装和管理配置
3. 储存在单一磁盘文件中的一个完整的数据库
4. 数据库文件可以在不同字节顺序的机器间自由的共享
5. 支持数据库大小至2TB
6. 足够小, 大致3万行C代码, 250K
7. 比一些流行的数据库在大部分普通数据库操作要快
8. 简单, 轻松的API
9. 包含TCL绑定, 同时通过Wrapper支持其他语言的绑定
10. 良好注释的源代码, 并且有着90%以上的测试覆盖率
11. 独立: 没有额外依赖
12. Source完全的Open, 你可以用于任何用途, 包括出售它
13. 支持多种开发语言,C, PHP, Perl, Java, ASP .NET,Python

相关文章：http://www.sqlite.com.cn/

Redis
Redis是一个很新的项目。Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作。Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存List链表和Set集合的数据结构，而且还支持对List进行各种操作，它的值可以是string，list，sets，或者是ordered sets。例如 从List两端push和pop数据，取List区间，排序等等，对Set支持各种集合的并集交集操作，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一 个功能加强版的memcached来用。

Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，并且它没有原生的可扩展机制，不具有scale（可扩展）能力，要依赖客户端来实现分布式读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。根据Redis的官网测试报告，50个并发请求，10w次访问，写速度为11x10e4/s,读速度为8100次/s.目前使用Redis的网站有 github，Engine Yard。

基本数据类型介绍：http://www.cnblogs.com/xhan/archive/2011/02/02/1948891.html

http://timyang.net/data/redis-misunderstanding/

交互命令：http://redis.io/commands

Tokyo Cabinet和Tokoy Tyrant
TC和TT的开发者是日本人Mikio Hirabayashi，主要被用在日本最大的SNS网站mixi.jp上，TC发展的时间最早，现在已经是一个非常成熟的项目，也是Kye-Value 数据库领域最大的热点，现在被广泛的应用在很多很多网站上。TC是一个高性能的存储引擎，而TT提供了多线程高并发服务器，性能也非常出色，每秒可以处理 4-5万次读写操作。TC除了支持Key-Value存储之外，还支持保存Hashtable数据类型，因此很像一个简单的数据库表，并且还支持基于column的条件 查询，分页查询和排序功能，基本上相当于支持单表的基础查询功能了，所以可以简单的替代关系数据库的很多操作。TC/TT在mixi的实际应用当中，存储了2000万条以上的数据，同时支撑了上万个并发连接，是一个久经考验的项目。TC在保证了极高的并发读写性能的同时，具有可靠的数据持久化机制，同时还支持类似关系数据库表结构的hashtable以及简单的条件，分页和排序操作，是一个很棒的NoSQL 数据库。

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

MongoDB
满足海量存储需求，Mongo主要解决的是海量数据的访问效率问题，根据官方的文档，当数据量达到50GB以上的时候，Mongo的数据库访问速度是MySQL的10 倍以上。Mongo的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理0.5万－1.5次读写请求

CouchDB
支持海量存储，CouchDB仅仅提供了基于HTTP REST的接口，因此CouchDB单纯从并发读写性能来说，是非常糟糕的。

Cassandra

满足高可扩展性和可用性的面向分布式计算的数据库，被看做是一个开源的google的big table。Facebook，twitter和digg.com都在使用Cassandra。Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的一个写操作，会被 复制到其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事情， 只管在群集里面添加节点就可以了。看到有文章说Facebook的Cassandra群集有超过100台服务器构成的数据库群集。Cassandra以单个节点来衡量，其节点的并发读写性能不是特别好，有文章说评测下来Cassandra每秒大约不到1万次读写请求，其并发性 能取决于整个系统的节点数量，路由效率，而不仅仅是单节点的并发负载能力。

Voldemort

和Cassandra类似，也是提供高可扩展性和可用性的面向分布式计算的数据库。Voldemort官方给出Voldemort的并发读写 性能也很不错，每秒超过了1.5万次读写。

LevelDB

google开发的数据库，LevelDB是一个嵌入式的key-value数据库。它的键和关联值可以是任意的字节数组，并且按照键值排序，排序机制是可以被重载的。数据存储机制非常简单，仅仅支持Put，Get和Delete命令，然后还有前向和后向迭代遍历。数据会自动使用Snappy压缩，这是一个压缩库，Google将其用于BigTable，MapReduce和RPC中，并且宣布开源。LevelDB也有一些局限：不支持 SQL查询和索引，支持多线程单进程访问，并且可以用于嵌入式设备。LevelDB优化了批量写操作。它将多个修改请求有序缓存在内存中，在累计到配置文件预设置的阈值之后再写入到磁盘中。对于顺序和随机写操作，以及顺序读操作来说，它的性能非常优秀，根据Google的性能基准测试，它能在某些测试项目中得分领先SQLite两个数量级。SQLite在随机读操作中比LevelDB稍好，而在写入较大数据的时候速度两倍快于LevelDB。LevelDB同样也表现得比Kyoto Cabinet优秀，Kyoto Cabinet也是一个key-value数据库，不过Google并没有像SQLite那样在所有测试项目中均进行比较。同样，Riak进行了一些测试对比LevelDB和InnoDB，在一些测试项目中，Google的LevelDB要比InnoDB要优秀或者能达到相同性能。LevelDB是使用C++编写，一些外部的依赖库已经成功地移植到Windows、Mac OS X、Android和各种Unix上。在实际的应用中，Chrome的一些实验性版本中已经使用了LevelDB，将其作为IndexDB API的实现。而Riak则将其用于节点级的存储。

nosql

常规关系型数据库仅仅支持每秒数千次或是数万次的访问，内存数据库的访问速度可以达到几万次到十多万次，支持高并发，海量存储，高可扩展性和高可用性

参考资料：

http://blog.csdn.net/21aspnet/article/details/6614013

http://blog.evanweaver.com/articles/2009/07/06 /up-and-running-with-cassandra

http://hb.qq.com/a/20110823/000019.htm

http://www.docin.com/p-115838909.html

http://www.iteye.com/topic/617156

http://blog.s135.com/dtcc/