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 創建這個目錄



免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM