Relational DB vs. Key-Value store

在我还在上学的时候，key-value这个词更多的还是和hash表联系在一起的。而现在，当我看见key-value这个词，马上联想到的就是 BigTable，SimpleDB和云计算。当下，key-value store（或者叫key-value Database，云存储等等）是个非常时髦的词汇，越来越多的开发人员（特别是互联网企业）开始关注和尝试key-value的存储形式。这年头如果你还和别人聊关系型数据库，貌似你都不好意思和人打招呼。

可是，key-value store真的有这么神奇吗？毕竟，关系型数据库已经主导市场三十多年了。

背景

 

key-value形式的存储并不是凭空想出来的。在我看来，是两个问题导致了key-value这种存储方式的崛起：

1. 大规模的互联网应用。对于google，ebay这样的互联网企业，每时每刻都有无数的用户在使用它们提供的互联网服务，这些服务带来的就是大量的数据吞吐量，在同一时间，会并发的有成千上万的连接对数据库进行操作。在这种情况下，单台服务器或者几台服务器远远不能满足这些数据处理的需求，简单的升级服务器性能这样的scale up的方式也不行，所以唯一可以采用的办法就是scale out了。scale out的方法有很多种，但大致分为两类：一类仍然采用RDBMS，然后通过对数据库的垂直和水平切割将整个数据库部署到一个集群上，这种方法的优点在于可以采用RDBMS这种熟悉的技术，但缺点在于它是针对特定应用的，就是说，由于应用的不同，切割的方法是不一样的。关于数据库的垂直和水平切割的具体细节可以查看文献【2】。
还有一类就是google所采用的方法，抛弃RDBMS，采用key-value形式的存储，这样可以极大的增强系统的可扩展性（scalability），如果要处理的数据持续增大，多加机器就可以了。事实上，key-value的存储就是由于BigTable等相关论文的发表慢慢进入人们的视野的。

2. 云存储。如果说上一个问题还有可以替代的解决方案（切割数据库）的话，那么对于云存储来说，也许key-value的store就是唯一的解决方案了。云存储简单点说就是构建一个大型的存储平台给别人用，这也就意味着在这上面运行的应用其实是不可控的。如果其中某个客户的应用随着用户的增长而不断增长时， 云存储供应商是没有办法通过数据库的切割来达到scale的，因为这个数据是客户的，供应商不了解这个数据自然就没法作出切割。在这种情况 下，key-value的store就是唯一的选择了，因为这种条件下的scalability必须是自动完成的，不能有人