分布式存储数据库的Key的随机分布(RP)和顺序分布(OPP)

时间:2024-07-07 18:07:02

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

对于Key的存储,有两种截然不同的分布方式,我们称之为:随机分布(RP)和顺序分布(OPP)

RP和OPP之间并没有绝对的优劣,不能直接断定谁比谁好,只能说是否适合当前的业务场景。在这篇文章中我们希望能够讨论一下两种方式的优劣:

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.

缺点:

1. 目前我只想到了负载均衡问题。

对于这个缺点我们从“写入数据”和“读取数据”两个方面来看:

1. 写入数据

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

2. 读取数据

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

RP

讨论完OPP之后我们会更容易讨论RP,因为基本上RP的缺点就是OPP的优点,RP的优点敲好是OPP的缺点。RP使用Consistent Hash(一致性哈希)解决了分片问题,从此以后负载均衡成了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分开,各弄一套,适合不同应用才是最佳选择。