首页 / HBASE / HBase应用与发展之HBase RowKey与索引设计

HBase应用与发展之HBase RowKey与索引设计

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了HBase应用与发展之HBase RowKey与索引设计，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含5706字，纯文字阅读大概需要9分钟。

内容图文

RowKey设计可以说是一个非常基础的话题，因为每一个HBase的使用/开发人员，都是从表/RowKey设计着手的。但细究起来，RowKey设计也有很多难点，尤其是如何与应用特点很好的结合起来。

这篇演讲的第一部分，首先简单介绍HBase的基础内容，而后探讨RowKey在读写流程中所发挥的关键作用。HBase的基础内容大部分已经在下面的文章里面详细探讨：

RowKey与索引设计，需要紧密结合业务需求场景。索引的设计目标是为HBase提供更多维度的查询能力。在实际应用中应该通过构建尽量少的索引，来满足更多的查询场景。因此第二部分介绍设计前需求调研的几个关键维度包括负载特点、查询场景以及数据特点。

负载特点
- 读写TPS；读写比重
- 重写轻读？重读轻写？读写相当？
数据负载均衡与高效读取时常是矛盾的。
在重读轻写的大数据场景中，RowKey设计应该更侧重于如何高效读取。
而在重写轻读的大数据场景中，在满足基本查询需求的前提下，应该更关注整体的吞吐量，这就对数据的负载均衡提出了很高的要求。
查询场景
需要支持哪些查询场景？时延要求？
最高频的查询场景是什么？
- 最有价值的数据排序场景是什么
是否有其它维度的价值查询场景？频度？
是否是组合字段场景？
各个字段的匹配类型？
- Equal? Prefix Match? Wildcard? Text-Search?
数据特点
查询条件字段的离散度信息？
- 字段离散度的定义：
- 字段A的离散度 = (字段A的可能的枚举值数目)/数据总记录条数
查询条件字段的数据分布特点？
- 数据分布影响RowKey的设计，更进一步影响如何合理的划分Region信息
数据生命周期？
- 影响到一个表的一次Major Compaction发生时涉及到的最大数据量

第三部分介绍RowKey设计的几点技巧，二级索引RowKey设计的方法，组合字段RowKey/索引的适用场景/设计原则，字段组合的合理顺序等等。

影响查询性能的关键因素
基于某一个索引/RowKey进行查询时，影响查询的最关键因素在于能否将扫描的候选结果集限定在一个合理的范围内。
知识点备注：查询驱动条件与查询过滤条件：直接影响数据扫描范围的查询条件，称之为查询驱动条件。而其它的能够起到过滤作用的查询条件，则称之为查询过滤条件。影响查询的关键因素在于如何合理的设置查询驱动条件。
RowKey字段的选取
遵循的最基本原则：
唯一性： RowKey必须能够唯一的识别一行数据。
无论应用是什么样的负载特点，RowKey字段都应该参考最高频的查询场景。数据库通常都是以如何高效的读取和消费数据为目的，而不是数据存储本身。
- 而后，结合具体的负载特点，再对选取的RowKey字段值进行改造，组合字段场景下需要重点考虑字段的顺序。
避免数据热点的方法 - Reversing
- 如果经初步设计出的RowKey在数据分布上不均匀，但RowKey尾部的数据却呈现出了良好的随机性，此时，可以考虑将RowKey的信息翻转，或者直接将尾部的bytes提前到RowKey的前部。
- 缺点：更场景利于Get但不利于Scan，因为数据在原RowKey上的自然顺序已被打乱。
避免数据热点的方法 - Salting
- Salting的原理是在原RowKey的前面添加固定长度的随机bytes，随机bytes能保障数据在所有Regions间的负载均衡。
- 缺点：既然是随机bytes，基于原RowKey查询时无法获知随机bytes信息是什么，也就需要去各个可能的Regions中去查看。可见，Salting对于读取是利空的。
- 避免数据热点的方法 - Hashing
  - 基于RowKey的完整或部分数据进行Hash，而后将Hashing后的值完整替换原RowKey或部分替换RowKey的前缀部分。
  - 缺点：与Reversing类似，Hashing也不利于Scan，因为打乱了原RowKey的自然顺序。
分布式数据库的常见数据分片方式
- 有两种常见的基础数据分片方式：Hash分片和Range分片
- 原理与区别如图所示。在实际应用中，两者还可以结合应用。