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 创建这个目录