code搬运工_关于Phoenix的Secondary Index

存储在HBase中的数据:
(1) HBase唯一索引 primary row key
(2) 全表扫描 scan
(3) 二级索引(辅助索引)
通过列或表达式作为备用rowkey, 实现点查找和范围扫描

covered indexes : 覆盖索引

• 只需找到索引即可,无需返回主表,节省读取时间开销
• 只需将我们关心的数据绑定在索引行中即可
  (select列和where列)
  create index my_index on my_table(v1,v2)include(v3)

Functional indexes : 函数索引 (4.3以上引入)

• 在表达式上建立索引
• 查询使用该表达式时 , 索引可用于检索结果
  create index upper_name_index on emp(upper(first_name||''||last_name))
select emp_id from emp where upper(first_name||''||last_name)

Global Indexes : 全局索引

• 适用于多读少写场景

• 通过单独HBase表存储数据表的索引数据

• 索引数据&主表数据 :
  当写入数据到主表时,索引数据会被同步到索引表中
  索引表中主键是索引列和数据表主键的组合值
  include列存储到索引表的普通列中,查询性能更高效
  只需查询一次索引表就能获得数据,不用回查主表

• 使用row_timstamp特性不能使用全局索引

• 合理设计数据表主键规避建过多索引表

• order by groupBy可以使用全局索引

• 对索引表适当使用加盐特性提高性能

Local Indexes : 本地索引

• 适用于写多读少,空间有限场景
• Phoenix查询时自动选择是否使用本地索引
• 使用本地索引,避免进行写操作带来的网络开销
• 索引表和表数据存放相同服务器中
• 查询字段不完全是索引字段也会被使用
  本地索引与全局索引区别 :
• 所有本地索引都单独存储在同一张共享表中。
• 无法预先确定region位置 , 读数据会检查每个region , 读性能开销大

Index Population : 异步索引

• 默认创建索引,会在create index调用期间同步填充索引

• Phoenix 4.5开始支持DDL语句支持ASYNC，异步完成索引填充
  create index async_index on my_schema.my_table(v)ASYNC

• 通过HBase命令行单独启动填充索引表mr作业

• 当mr作业完成时，才会激活索引并开始查询中使用
  $ {HBASE_HOME} / bin / hbase org.apache.phoenix.mapreduce.index.IndexTool --schema MY_SCHEMA --data-table MY_TABLE --index-table ASYNC_IDX --output-path ASYNC_IDX_HFILES

  Index Usage:索引用法

• 除非查询中引用的所有列都包含在索引中，否则不会使用全局索引

• 通过在索引中包含v2列创建覆盖索引
  create index my_index on my_table(v1) include(v2)

• 提示查询强制使用索引
  select /* + index(my_table my_index)*/ v2 from my_table where v1=‘foo'

• 创建本地索引
  create local index my_index on my_table(v1)

  Index Removal : 移除索引

  `drop index my_index on my_table`
  

• 数据表中删除索引列，会自动删除索引(含覆盖索引)

  Index Properties : 索引属性

• create index可以传递属性应用于基础HBase表

• 对其进行加盐操作:
  create index my_index on my_table(v2 desc,v1) include(v3)
salt_buckets=10,data_block_encoding=‘NONE'

• 主表被加盐,索引表以相同方式自动为全局索引加盐

• 相对于主表与索引表大小,索引MAX_FILESIZE向下调整

• 本地索引不允许salt_buckets

  Consistency Guarantees : 一致性保证

• 索引更新与HBase提供的相同强一致性保证同步

• 索引存储与数据表不同的表中 : 表的属性和索引的类型
  服务器端崩溃导致提交失败,表和索引之间一致性有所不同
  Transactional Tables : 交易表
  Immutable Tables : 不可变表
  非事务性 , 不可变表的索引没有适当的机制来自动处理提交失败。
  保持表和索引之间的一致性留给客户端来处理。
  因为更新是幂等的，所以最简单的解决方案是让客户端继续重试一批突变，
  直到它们成功为止
  Mutable Tables : 可变表