phoenix 三板斧之加盐压缩加索引
作者:互联网
phoenix 作为大数据生态圈中的一员得力干将,并没有大家想象中的那么神秘,它对原始的hbase 进行了封装,而hbase是列式存储数据库,可能跟传统的关系型数据还是有那么一点差异的,所以想要熟悉并初步掌握phoenix,则需要熟悉它的三板斧之功效:
第一板斧之加盐(SALT_BUCKETS)
正如前面所说的phoenix 是对hbase 进行了封装,那么hbase存在的特性预分区,也会在phoenix 中体现出来——加盐正是这种体现,那么SALT_BUCKETS具体设置多少合适呢,则需要参考三个因素:1.regionserver 个数 2.数据量 3.CPU的核数
当block cache和表的大小差不多时,SALT_BUCKETS设置成REGIONSERVER的相同大小;
当表的大小远大于block cache时,SALT_BUCKETS 可以相对设置大一些,但是要考虑CPU的情况,参考文档https://community.cloudera.com/t5/Support-Questions/How-many-salt-buckets-should-I-use-for-my-Phoenix-tables/m-p/159797
第二板斧之压缩(ompression)
phoenix目前常用的压缩方法:SNAPPY,GZ
create table order_center.tr_order_bak
( row_key varchar(64) not null primary key,
id bigint,
tenant_id varchar(64) ,
localorderid varchar(64) ,
shopid varchar(64) ,
shopcode varchar(32) ,
shopname varchar(128) ,
orderchannel varchar(32) ,
total_amount decimal(16,2)
)SALT_BUCKETS=5,compression='SNAPPY';
第三板斧之索引(index)
phoenix 中的主键跟hbase的row key 类似,如果不建索引,只有通过row key 查询效率才会高,但是在正常的使用过程中,往往会遇到复杂的查询或者计算,那么就必须要使用到索引,注意phoenix 的索引跟关系型数据库索引的不同。
mysql:b+tree索引,索引上只存储了键值和指针
phoenx:将数据重新复制了一份,然后将索引列当做rowkey的过程,所以索引必须包含查询中所有的列,否则不走索引。
create index idx_oder_orderid_shopcode_bak on order_center.tr_order_bak(tenant_id,localorderid,shopcode)
include(id,shopid,shopname,orderchannel)SALT_BUCKETS=5;
通过上面两张SQL的执行计划的对比可以看到查询语句之间只差了一个total_amount,就发生了翻天地覆的变化,在执行效率上也会天差地别的。当表中的数据已经存在数据了,但是新增了查询的业务场景怎么办呢?
create index idx_oder_orderid_shopcode_bak on order_center.tr_order_bak(tenant_id,localorderid,shopcode)
include(id,shopid,shopname,orderchannel)ASYNC;
/usr/hdp/2.6.5.0-292/hbase/bin/hbase org.apache.phoenix.mapreduce.index.IndexTool --schema ORDER_CENTER --data-table TR_ORDER_BAK --index-table idx_oder_orderid_shopcode_bak --output-path idx_oder_orderid_shopcode_bak_HFILES
正常情况下,经过上面两步就可以了,但是当数据量非常大的时候,需要考虑服务器磁盘的使用情况,新增索引就是重新复制了一份数据,如果磁盘使用超过90%的时候,可能导致创建索引创建失败。
标签:varchar,phoenix,三板斧,shopcode,索引,加盐,hbase,bak 来源: https://blog.csdn.net/yuexuelingfeng/article/details/118253608