存储模式RP和OPP

在分布式存储数据库的世界中，无论是基于Key/Value的数据库还是Column Base的数据库，都有一个重要的因子——Key，或者叫RowKey。我们总是根据Key来快速的获取存储的数据。毫不夸张的说，Key是读数据的基础。

对于Key的存储，有两种截然不同的分布方式，我们称之为：随机分布（RP）和顺序分布（OPP）

RP和OPP之间并没有绝对的优劣，但遗憾的是任何数据库只能选择其中的一种。在这篇文章中我们希望能够讨论一下两种方式的优劣，经典数据库的选择和我们的选择。

我们先来讨论OPP，因为我们可能更喜欢这种方式。OPP的意思是顺序分布，Key在分布式节点中是严格排序的，比如200一定是位于100和300之间的。这一特性带来了以下的优缺点：

优点：

1. 容易分片，我们能很容易的将大量的数据分成N片，只需要知道每一片的StartKey和EndKey。根据分片表我们可以很容易的定位任何一个Key。分片对于分布式系统来说是一个非常重要的功能，它意味着我们能不能将大量的数据分而治之。

2. 快速区间扫描，这可能是OPP对于RP的一个绝对优势。给我一个StartKey和一个EndKey，我可以给你扫出区间内的所有数据。这种方式在很多应用中都会用到，但RP却无法快速完美的做到。举个例子，有一个问题跟踪系统每天要记录大量的Log，每一条Log的Key是当时的时间。有一天问题发生了，管理员希望查看当天所有的Log。OPP很容易做到这件事，它从开始点一条一条往下读，直到结束点。RP就傻眼了，当天的Log被散落在各个节点中，更严重的是它不知道当天有多少Log。它只能作出如下回答：

1) 告诉我一个具体时间，我给你一条Log.

2) 等等我，我要扫描全部的Log，之后我会给你一份当天Log的Report.

缺点：

我们认为OPP只有一个缺点，那就是负载均衡问题。我们可以分两个方面来看这个问题。

1. 写入数据

有一种写入方式可以让基于OPP的分布式数据库完全发挥不了威力。就是刚才那个记Log的系统，将时间作为Key，连续不断的写入。由于时间在不断增长，每一次写入都添加在数据的末尾。这意味着什么？对于分片系统来说只有最后一片在不断增加，也就是说只有管理最后一片的节点在工作，其它节点完全干瞪眼帮不上忙。这时候分布式系统退化成了单节点的系统，再也没什么优势可言。

2. 读取数据

假设我们有一批Key需要读取数据。如果使用RP，无论这些Key是怎样的内容，读取的操作都会被很均匀的分布到各个节点。但对于OPP来说如果不凑巧这一批Key是连续的，属于同一个分片，同样的事情发生了，只有一个节点在工作，其他的干瞪眼。

讨论完OPP之后我们会更容易讨论RP，因为基本上RP的缺点就是OPP的优点。值得一提的是很久以前就有聪明的人用Consistent Hash解决了RP的分片问题，从此以后负载均衡成了RP最大的资本，无论是读还是写，RP总是能充分的使用每个节点。同样区间扫描依然是RP的致命伤。

了解完基本概念之后我们来看看一些经典数据库的选择：

HBase，毫无疑问HBase是OPP的忠实支持者。有了HDFS的支持，HBase不在担心数据冗余问题，大胆的使用OPP来构建系统。对于负载均衡的问题，HBase的回答是：对不起，我们就是这个样子的！

Dynamo，讨论Dynamo可能稍稍有点过时了，但他毕竟是Cassandra的前身，奠定了很多基础的思想。Dynamo可以说是RP的忠实支持者，在Amazon系统中的成功应用使得它坚信基于Key/Value的系统可以解决绝大多数问题。对于RP的区间扫描问题，Dynamo的回答是：开什么玩笑，你能在HashMap中扫描区间吗？

Cassandra，这个可以说是近两年的后起之秀了，继承了Dynamo和BigTable的优点。但在RP还是OPP的选择上它却模棱两可。它两种方式都提供，爱用啥用啥，但只能选一样哦。说实话，厉害，实在是厉害。

应用！应用！

扯了这么多，估计大家也都明白了，用RP还是OPP关键看应用，也许把RP和OPP分开，各弄一套，适合不同应用才是最佳选择。可问题是那些小企业搞一套已经很吃力了，你让他搞两套他能吃得消？呵呵….