分布式存储数据库的Key的随机分布(RP)和顺序分布(OPP)-阿里云开发者社区

开发者社区> rollenholt> 正文

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

简介:
+关注继续查看

在分布式存储数据库的世界中,无论是基于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分开,各弄一套,适合不同应用才是最佳选择。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
sqlite数据库中自增key的设定,autoincrement 和 rowid
在用sqlite设计表时,每个表都有一个自己的整形id值作为主键,其实可以不指定这么一个id值,sqlite内部本来就会为每个表加上一个 rowid,这个rowid可以当成一个隐含的字段使用,但是由sqlite引擎来维护的,在3.0以前rowid是32位的整数,3.0以后是 64位的整数,为什么不直接使用这个内部的rowid作为每个表的id主键呢。
1315 0
怎么设置阿里云服务器安全组?阿里云安全组规则详细解说
阿里云服务器安全组设置规则分享,阿里云服务器安全组如何放行端口设置教程
6846 0
分布式数据库如何实现 Join?
PolarDB-X 不仅语法兼容 MySQL,作为分布式数据库,也力求保持与单机数据库一致的使用体验。在分布式场景下,Join 的两张表可能都是分布式表,因此需要通过多次网络请求获取相应的数据。如何高效地实现这一点呢?
603 0
SAP CRM WebClient UI的配置存储数据库表
SAP CRM WebClient UI的配置存储数据库表
9 0
分布式实时分析数据库citus数据插入性能优化
前言 从可靠性和使用便利性来讲单机RDBMS完胜N多各类数据库,但当数据量到了一定量之后,又不得不寻求分布式,列存储等等解决方案。citus是基于PostgreSQL的分布式实时分析解决方案,由于其只是作为PostgreSQL的扩展插件而没有动PG内核,所有随快速随PG主版本升级,可靠性也非常值得信任。
1585 0
数据库存储时间的时区问题
先说一下mysql中DATETIME和TIMESTAMP的区别 TIMESTAMP是标准的unix timestamp,它存储的是1970-1-1到现在经过的秒数,4字节存储。mysql用这个类型还蛮方便的,一个是有很多内置的函数和trigger来处理它,比如CURRENT_TIMESTAMP宏,最关键的是在取数据的时候mysql会自动帮你处理DST和时区的问题。 DATETIME的范围更
1794 0
分布式实时分析数据库citus数据查询性能简单对比
分布式实时分析数据库citus数据查询性能简单对比 如果单纯看实时数据插入的速度,并不能体现citus的价值,还要看聚合查询的性能。下面将集群的查询性能和单机做个简单的对比。
2192 0
Android官方开发文档Training系列课程中文版:数据存储之数据库存储
原文地址:http://android.xsoftlab.net/training/basics/data-storage/databases.html 对于保存重复的结构化的数据最理想的方式就是存到数据库,比如联系人信息。
753 0
Hawkeye:助力TISPLUS实现数据化运营
背景 TISPLUS平台的数据分析能力主要由hawkeye提供,但是之前存在如下几个问题:1.数据化场景的功能没有凸显,隐藏较深;2.产品形态设计单一,没有一个较好的产品闭环引导用户关注数据化的结果;3.数据分析内容简单,覆盖面不足,远远达不到让用户数据化运营服务的目标;4.重点关注了数据分析的结果,但缺少衡量数据分析结果为搜索服务本身带来的价值大小。
1483 0
+关注
406
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载