查詢條件對查詢性能的影響
下面是一張存有商品的編號懒棉、日期、價格该抒、銷量慌洪、庫存的數(shù)據(jù)表
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 創(chuàng)建的 HBase 表里顶燕，id 和 time 組成了 HBase 的 row key，并且 id 在前 time 在后冈爹，由于 HBase 的數(shù)據(jù)是以 row key 排序的涌攻，所以這里相當(dāng)于先按 id 排序，再按 time 排序频伤，這時如果以 id 和 time 以外的字段作為查詢條件的話恳谎，都會導(dǎo)致全表掃描，即會查詢所有的 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 的前半部分谭企，可以直接把滿足條件的數(shù)據(jù)找出來，比如
select * from Product where id > '10000'
可以看到评肆，查詢性能和 row key 的設(shè)計有很大關(guān)系债查，但一張表可能有多種查詢需求，row key 的設(shè)計無法滿足所有情況瓜挽，這時可以通過創(chuàng)建索引提升查詢性能
索引
如果希望提升以 sale 做查詢條件時的性能攀操，可以創(chuàng)建下面的索引
create index INDEX_PRODUCT on Product(sale) include(
price
) SALT_BUCKETS=6;
索引實際上是創(chuàng)建另一張 HBase 表，這張表按順序以 sale秸抚、id速和、time 組成 row key（原表的 row key 一定會出現(xiàn)在索引表的 row key），而被 include 的 price 則在 CF 列剥汤，這樣當(dāng)查詢條件是 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 組成砾莱，相當(dāng)于原 row key 交換了順序，并且沒有 CF 值
觸發(fā)索引的條件
總結(jié)一下觸發(fā)索引需要滿足以下條件
- where 字段是索引字段凄鼻，或是索引字段和 key 字段
- select 字段是 key 字段腊瑟，或是索引字段聚假，或是被 include 的字段
索引對查詢性能的影響
索引不一定能顯著提升查詢性能，這取決于數(shù)據(jù)分布和查詢條件
如果是以 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 比較少蒲赂，性能會有顯著提升，如果過濾出來的非常多刁憋，性能可能就沒有明顯提升滥嘴，甚至?xí)陆担驗橐閮蓮埍?br>
對寫性能的影響
索引會導(dǎo)致寫性能下降至耻，因為要寫兩張表氏涩，同時消耗更多的磁盤空間
explain 命令
可以通過 explain 命令查看數(shù)據(jù)庫是如何查詢的
explain select * from Product where sale > 100
異步創(chuàng)建索引
如果創(chuàng)建索引時原表已經(jīng)有大量數(shù)據(jù)了届囚，可能會等很長時間，這時可以使用異步創(chuàng)建的方式
create index INDEX_PRODUCT on Product(sale) include(
price
) ASYNC;
再用 hbase 命令觸發(fā)執(zhí)行
hbase org.apache.phoenix.mapreduce.index.IndexTool \
--data-table=Product \
--index-table=INDEX_PRODUCT \
--output-path=/user/spark/ASYNC_INDEX_HFILES <-- 必須先在 hdfs 創(chuàng)建這個目錄
