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://www.cnblogs.com/jingzhishen/p/3804571.html