内容简介:来源 | 阿丸笔记
来源 | 阿丸笔记
封图| CSDN 下载于视觉中国
前面,我们已经打下了很多关于HBase的理论基础,今天,我们主要聊聊在实际开发使用HBase中,需要关注的一些最佳实践经验。
Schema设计七大原则
1)每个region的大小应该控制在10G到50G之间;
2)一个表最好保持在 50到100个 region的规模;
3)每个cell最大不应该超过10MB,如果超过,应该有些考虑业务拆分,如果实在无法拆分,那就只能使用mob;
4)跟传统的关系型数据库不同,一个HBase的表中列族最多不超过3个,列族中的列可以动态添加的,不要设计过多列族;
5)列族名必须尽量短,因为我们知道在存储的时候,每个keyvalue都会包含列族名;
6)如果一个表存在一个以上的列族,那么必须要注意,不同列族之间行数相差不要太大。例如列族A有10万行,而列族B有1亿行,那么rowkey就有1亿行,而region是按照行键进行切分的,因此列族A可能会被打散为很多很多小region,这会导致在扫描列族A时会引发较多IO,效率低下。
7)列族可以设置TTL时间,HBase在超过设定时间后,会自动删除数据。
设置方法有两种:
# 建表时设置,TTL单位为秒,此例中列簇'f1'的数据保留1天(86400秒)
hbase(main):002:0>create 'table', {NAME => 'f1', TTL => 86400}
# 通过修改表设置
hbase(main):002:0>alter 'table', {NAME => 'f1', TTL => 86400}
这里需要注意,一旦超过设定时间后,该数据就无法读取了,但是,真正的过期数据删除,是发生在major compaction时。
.
Ro wKey设计三大策略
HBase作为一个分布式存储数据库,虽然扩容非常容易,但是,对于“热点”问题,还是非常头疼的。
所谓“热点”问题(HotSpotting),就是请求(读或者写)短时间内落在了集中的个别region上,导致了该region所在机器的负载急剧上升,超过了单点实例的承受能力,从而引起性能下降或者不可用。
要解决这个问题,就需要设计RowKey时,使得数据尽量往多个region上去写。
举个例子:
假如region按照26个字母分成26个,那么同时写入m开头的rowkey的记录都会同时写入同一个region
比如m001,m002,m003,m004,m005。
因此,RowKey的设计非常关键。常见的设计策略有这么几种。
1)salting
salting策略就是将生成随机数放在行键的开头作为前缀,使得每个行键有随机的字典序。
对上面的案例进行优化,我们采用了salting策略,插入前给每个rowkey生成一个随机的字母,变成了
am001,zm002,nm003,qm004,lm005
这样就能同时往5个region里面写入了,成功打散。
副作用:由于前缀生成是随机的,因此如果想要按照字典序查询这些行,则需要做更多的事情。从这个角度上看,salting增加了写操作的吞吐量,却也增大了读操作的开销。
2)Hashing
Hashing策略也是一种特殊的salting,是用一个单向的 hash 来取代随机指派前缀。
这样能使一个给定rowkey的行在“salted”时有相同的前缀,因此,这样既可以分散RegionServer间的负载的,同时也允许在读操作时能够预测这个前缀值是什么。确定性hash( deterministic hash )可以让客户端重建完整的行键,然后就可以像正常一样用Get方法查询确定的行。
3)reverse key
第三种预防hotspotting的方法是反转一段固定长度或者可数的键,让变化最多的某个位置放在rowkey的第一位,
副作用:对于Get操作没有影响,但是不利于Scan操作进行范围查询,因为数据在原RowKey上的顺序已经被打乱。
预分区
在 HBase核心特性—region split 中,我们知道已经提到过关于预分区。
主要原因是当一张表被首次创建时,只会分配一个region给这个表。因此,在刚刚开始时,所有读写请求都会落在这个region所在的region server上,而不管你整个集群有多少个region server。不能充分地利用集群的分布式特性。
因此,预分区主要也是解决“热点”问题。
最为常见的建表语句为:
create ‘tb’,{NAME => ‘f1’,COMPRESSION => ‘snappy’ }, { NUMREGIONS => 50, SPLITALGO => ‘HexStringSplit’ }
-
NUMREGIONS 为 region的个数,一般按照每个region 8-10GB左右来计算region数量,如果集群规模非常大,那么region数量可以适当取大一些
-
SPLITALGO 为 rowkey分割的算法,Hbase自带了三种pre-split的算法,分别是 HexStringSplit、DecimalStringSplit 和 UniformSplit。
各种Split算法适用场景:
-
HexStringSplit: rowkey是十六进制的字符串作为前缀的
-
DecimalStringSplit: rowkey是10进制数字字符串作为前缀的
-
UniformSplit: rowkey前缀完全随机
读性能优化
前面主要讲一些设计方面的优化点。
那如果在HBase的使用过程中,发现查询较慢,那么就需要根据具体情况,分析查询慢的原因,并采取相应的策略。
防疫、复工如何并行?天云数据推出人工智能监测方案!到底如何做到事前预防,而不是事后诸葛亮?本周四晚8点,天云数据VP陈勇为各位揭晓答案!扫描下方二维码免费报名~
今日福利:评论区留言入选,都可获得价值 299 元的「 2020 AI 开发者万人大会」在线直播门票一张。 快来动动手指,写下你想说的话吧
推荐阅读:只要 8 个步骤,学会这个 Docker 命令终极教程! 2020 年,为什么非要采用 DevOps 文化不可? 近 10 年新秀编程语言大 PK,Pick 它! 5 亿微博数据疑泄露,Python 爬虫如何避免踩天坑? 你的企业在什么情况下需要人工智能?快来看看你需要具备哪些条件与能力! 自称中本聪的他被法官怒怼:你的证词毫无可信度! 真香,朕在看了!
以上所述就是小编给大家介绍的《生产环境使用HBase,你必须知道的最佳实践》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 多云环境下的安全最佳实践
- 容器环境应用一键拉起实践
- Docker环境的持续部署优化实践
- Spring Boot 多环境配置最佳实践
- Istio在生产环境中的应用实践
- webpack与SPA实践之开发环境搭建
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
文明之光(第一册)
吴军 / 人民邮电出版社 / 2014-6-25 / 59.00元
人类的历史,是从野蛮蒙昧一步步走向文明进步的过程。在文明的进程中,人类创造出多元的文化,它们有着各自的特长。要实现人类和平发展的终极理想,一个重要的前提是承认文化的多元性,并且取长补短,相互融合。 吴军博士写作《文明之光》系列,希望能开阔人们的视野,让我们看到各种各样的人类文明。虽然今天不同的地区发达程度不同,文明历史的长短不一,国家亦有大小之分,但是文明之光从世界的每一个角落发出,对人类的......一起来看看 《文明之光(第一册)》 这本书的介绍吧!