浅尝key-value数据库（一）——一览NoSQL
最近由于一个项目的关系，研究了一下key-value数据库这个最近很火的概念。本系列从项目需求的角度分析并测试了几个key-value数据库的性能。
key-value数据库，又称作NoSQL数据库，他的最基本的基础原理就是CAP。
CAP是2000年PODC上Eric Brewer提出的一个概念，即
C -> Consistency;
A -> Availability;
P -> Tolerance to network Partitions;
You can have at most two of these properties for any shared-data system.
翻译成中文，大致是完备性、可用性、网络可分割性，三者不可兼得。
那么经典的关系型数据库在C,A两方面做的非常好，于是在互联网飞速发展的今天，在网络扩展方面出现了致命的硬伤。由于各种web2.0网站追求用户创造内容，于是产生了大量的写操作，关系型数据库的replication模式已经不能承受，数据库必须进行分割。但分割对于业务没有普遍性，于是数据库的扩容变得捉襟见肘。于是，key-value数据库应运而生。
key-value数据库就是尽可能地满足A,P两方面，甚至不惜牺牲C来满足。
于是在key-value数据库中，基本不支持事务，大多自带replication功能，可以很方便的分表以及分布式实现。
以下是robbin的《NoSQL数据库探讨之一 －为什么要用非关系数据库？》一文中提到的一些著名的key-value数据库：
1、Redis Redis
本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过10万次读写操作。但有硬伤就是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，并且它没有原生的可扩展机制，不具有可扩展能力，要依赖客户端来实现分布式读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
2、Tokyo Cabinet和Tokyo Tyrant
前者是一个高性能的存储引擎，后者是一个提供了多线程高并发的服务器。一听名字就是日本人开发的，最初被用在日本最大的SNS站点mixi.jp上。TC除了支持Key-Value存储之外，还支持保存Hashtable数据类型，因此很像一个简单的数据库表，并且还支持基于column的条件查询，分页查询和排序功能，基本上相当于支持单表的基础查询功能了，所以可以简单的替代关系数据库的很多操作。但他的主要缺点是在数据量达到上亿级别以后，并发写数据性能会大幅度下降——《NoSQL: If Only It Was That Easy》。
3、MongoDB
MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bson格式，因此可以存储比较复杂的数据类型，他主要是用来解决海量数据的访问效率问题。他的存储似乎对磁盘空间方面的需求比较大。新版本开始支持分布式。
4、Hypertable
Hypertable与类似的HBase都是从Google的Bigtable模式发展出来的，对分布式支持比较好，不过配置起来比较复杂。先介绍这几个吧，其他还有许多key-value数据库正在或已经发展起来。不过学术界似乎并不看好key-value数据库。在我看来，key-value现在很热，但是炒作的成分比较大，在真正的应用中还是应该根据自身的特点来选择数据存储方式才是王道。