Phoenix 索引

查询条件对查询性能的影响

下面是一张存有商品的编号、日期、价格、销量、库存的数据表

CREATE TABLE IF NOT EXISTS Product (
    id           VARCHAR not null,
    time         VARCHAR not null,
    price        FLOAT,
    sale         INTEGER,
    inventory    INTEGER,

    CONSTRAINT pk PRIMARY KEY (id, time)
) COMPRESSION = 'GZ', SALT_BUCKETS = 6

在这个 Phoenix SQL 创建的 HBase 表里,id 和 time 组成了 HBase 的 row key,并且 id 在前 time 在后,由于 HBase 的数据是以 row key 排序的,所以这里相当于先按 id 排序,再按 time 排序,这时如果以 id 和 time 以外的字段作为查询条件的话,都会导致全表扫描,即会查询所有的 row key,即需要遍历所有 id 的所有 time,因为 HBase 并不知道哪行记录存有满足条件的值,比如

select * from Product where price > 200
select * from Product where sale > 100
select * from Product where inventory < 50 

如果以 time 查询,由于 time 是 row key 的后半部分,所以需要遍历所有 id 的部分 time,比如

select * from Product where time > '2020-01-01'

如果以 id 查询,由于 id 是 row key 的前半部分,可以直接把满足条件的数据找出来,比如

select * from Product where id > '10000'

可以看到,查询性能和 row key 的设计有很大关系,但一张表可能有多种查询需求,row key 的设计无法满足所有情况,这时可以通过创建索引提升查询性能

索引

如果希望提升以 sale 做查询条件时的性能,可以创建下面的索引

create index INDEX_PRODUCT on Product(sale) include(
    price
) SALT_BUCKETS=6;

索引实际上是创建另一张 HBase 表,这张表按顺序以 sale、id、time 组成 row key(原表的 row key 一定会出现在索引表的 row key),而被 include 的 price 则在 CF 列,这样当查询条件是 sale,同时要获取的是 key 字段或是被 include 的字段时,Phoenix 会去索引表取值,由于在这个索引里 sale 是在 row key 的最前面,这样就能避免全表扫描,比如查询

select time, price from Product where sale > 100

但是如果要查询的字段即不是 key 也没被 include,这样依然会去查原表,比如

select * from Product where sale > 100

这时需要把 inventory 也 include 进来才会用到索引
(由于原表的 key 一定会加进来所以不用 include)

create index INDEX_PRODUCT on Product(sale) include(
    price, inventory
) SALT_BUCKETS=6;

如果只是把第二个 key 即 time 做索引,比如

create index INDEX_PRODUCT on Product(time) SALT_BUCKETS=6;

那么索引表的 row key 由 time、id 组成,相当于原 row key 交换了顺序,并且没有 CF 值

触发索引的条件

总结一下触发索引需要满足以下条件

  • where 字段是索引字段,或是索引字段和 key 字段
  • select 字段是 key 字段,或是索引字段,或是被 include 的字段

索引对查询性能的影响

索引不一定能显著提升查询性能,这取决于数据分布和查询条件

如果是以 time 为查询条件,在原表需要查询所有 id 的部分 time,而在索引表是直接查询 time,这样如果满足查询条件的 id 很少,性能会有显著提升,如果满足查询条件的 id 本来就非常多,性能可能就没有明显提升

如果是以 sale 为查询条件,在原表需要查询所有 id 的所有 time,即需要查询原表所有 row key,而在索引表是直接查询 sale,一般来讲性能会有显著提升,除非满足查询条件的 id + time 非常多,即满足条件的原表 row key 非常多,那性能可能就没有明显提升

强制使用索引

在不把 inventory include 进来的情况下也可以强制使用索引表
通过在 select 时加上 /*+ INDEX(table index) */ 的方式

select /*+ INDEX(Product INDEX_PRODUCT ) */ * FROM Product where sale > 100

这样会强制查询索引表,但由于 inventory 其实不在索引表,最后还是会去查询原表,但可能会缩小查询范围

比如以 time 为查询条件,在原表需要查询所有 id 的部分 time,而先查询索引可以先过滤出满足查询条件的 id,再去原表查询满足条件的 id 的部分 time,如果过滤出来的 id 很少,性能会有显著提升,如果过滤出来的 id 非常多,性能可能就没有明显提升,甚至可能会有下降,因为要查两张表

同样的,如果以 sale 为查询条件,在原表需要查询所有 id 的所有 time,而先查索引表可以先过滤出满足条件的 id 和 time,再去原表查询过滤出来的 id 和 time,如果过滤出来的 id 和 time 比较少,性能会有显著提升,如果过滤出来的非常多,性能可能就没有明显提升,甚至会下降,因为要查两张表

对写性能的影响

索引会导致写性能下降,因为要写两张表,同时消耗更多的磁盘空间

explain 命令

可以通过 explain 命令查看数据库是如何查询的

explain select * from Product where sale > 100


异步创建索引

如果创建索引时原表已经有大量数据了,可能会等很长时间,这时可以使用异步创建的方式

create index INDEX_PRODUCT on Product(sale) include(
    price
) ASYNC;

再用 hbase 命令触发执行

hbase org.apache.phoenix.mapreduce.index.IndexTool \
    --data-table=Product \
    --index-table=INDEX_PRODUCT \
    --output-path=/user/spark/ASYNC_INDEX_HFILES     <-- 必须先在 hdfs 创建这个目录




你可能感兴趣的:(Phoenix 索引)