1. 概念
Phoenix Salted Table是phoenix为了防止hbase表rowkey设计为自增序列而引发热点region读和热点region写而采取的一种表设计手段。通过在创建表的时候指定SALT_BUCKETS来实现pre-split。如下表示创建表的时候将表预分割到20个region里面。
CREATE TABLE SALT_TEST (a_key VARCHAR PRIMARY KEY, a_col VARCHAR) SALT_BUCKETS = 20;
对salted table创建二级索引,那么二级索引表也会相应与源表一样分割到相同数量的region里面。
2. 原理
Phoenix Salted Table的实现原理是在将一个散列取余数后的byte值插入到 rowkey的第一个字节里,并通过定义每个region的start key 和 end key 将数据分割到不同的region,以此来防止自增序列引入的热点,平衡集群的读写性能。
salted byte的计算方式大致如下:
hash(rowkey) % SALT_BUCKETS
SALT_BUCKETS的取值为1到256。
默认下salted byte将作为每个region的start key 及 end key,以此分割数据到不同的region,这样能做到具有相同salted byte的数据能够位于同一个region里面。
3. 实践
CREATE TABLE SALT_TEST (a_key VARCHAR PRIMARY KEY, a_col VARCHAR) SALT_BUCKETS = 4;
UPSERT INTO SALT_TEST(a_key, a_col) VALUES(‘key_abc‘, ‘col_abc‘);
UPSERT INTO SALT_TEST(a_key, a_col) VALUES(‘key_ABC‘, ‘col_ABC‘);
UPSERT INTO SALT_TEST(a_key, a_col) VALUES(‘key_rowkey01‘, ‘col01‘);
从phoenix sqlline.py查询数据,没感觉有什么不同:
通过hbase shell 观察验证,看出确实是在rowkey的第一个字节插入byte字节来迫使数据能够散列到不同的region,以提高hbase并发读写性能:
这里可以判断phoenix写入的时候做了处理,插入了这个字节,并且在读取的API里面也相应的进行了处理,将这个字节给过滤掉,所以只能通过phoenix接口来获取数据已确保拿到正确的rowkey。
时间: 2024-10-12 05:11:17