phoenix索引

╰半橙微兮° 2022-10-31 12:13 247阅读 0赞

## 1. 介绍 ##

> 二级索引这个特性应该是大部分用户引入Phoenix主要考虑的因素之一。HBase因其历史原因只支持rowkey索引，当使用rowkey来查询数据时可以很快定位到数据位置。现实中，业务查询需求条件往往比较复杂，带有多个查询字段组合，如果用HBase查的话，只能全表扫描进行过滤，效率很低。而Phoenix支持除rowkey外的其它字段的索引创建，即二级索引，查询效率可大幅提升。

为什么需要用二级索引?

对于HBase而言，如果想精确地定位到某行记录，唯一的办法是通过rowkey来查询。如果不通过rowkey来查找数据，就必须逐行地比较每一列的值，即全表扫瞄。对于较大的表，全表扫描的代价是不可接受的。但是，很多情况下，需要从多个角度查询数据。例如，在定位某个人的时候，可以通过姓名、身份证号、学籍号等不同的角度来查询，要想把这么多角度的数据都放到rowkey中几乎不可能（业务的灵活性不允许，对rowkey长度的要求也不允许）。所以，需要secondary index（二级索引）来完成这件事。secondary index的原理很简单，但是如果自己维护的话则会麻烦一些。现在，Phoenix已经提供了对HBase secondary index的支持。

## 2. Phoenix Global Indexing And Local Indexing ##

2.1 Global Indexing

Global indexing，全局索引，适用于读多写少的业务场景。使用Global indexing在写数据的时候开销很大，因为所有对数据表的更新操作（DELETE, UPSERT VALUES and UPSERT SELECT），都会引起索引表的更新，而索引表是分布在不同的数据节点上的，跨节点的数据传输带来了较大的性能消耗。在读数据的时候Phoenix会选择索引表来降低查询消耗的时间。在默认情况下如果想查询的字段不是索引字段的话索引表不会被使用，也就是说不会带来查询速度的提升。

2.2 Local Indexing

Local indexing，本地索引，适用于写操作频繁以及空间受限制的场景。与Global indexing一样，Phoenix会自动判定在进行查询的时候是否使用索引。使用Local indexing时，索引数据和数据表的数据存放在相同的服务器中，这样避免了在写操作的时候往不同服务器的索引表中写索引带来的额外开销。使用Local indexing的时候即使查询的字段不是索引字段索引表也会被使用，这会带来查询速度的提升，这点跟Global indexing不同。对于Local Indexing，一个数据表的所有索引数据都存储在一个单一的独立的可共享的表中。在读取数据的时候，标红的那句话不会翻译大意就是在读数据的时候因为存储数据的region的位置无法预测导致性能有一定损耗。

> Phoenix提供两种类型的索引技术：注重提升读性能的Global Indexing和注重提升写性能的Local Indexing。下面分别对这两种索引技术简单使用一下。

## 3. Immutable index And Mutable index ##

3.1 immutable index

immutable index，不可变索引，适用于数据只增加不更新并且按照时间先后顺序存储（time-series data）的场景，如保存日志数据或者事件数据等。不可变索引的存储方式是write one，append only。当在Phoenix使用create table语句时指定IMMUTABLE\_ROWS = true表示该表上创建的索引将被设置为不可变索引。Phoenix默认情况下如果在create table时不指定IMMUTABLE\_ROW = true时，表示该表为mutable。不可变索引分为Global immutable index和Local immutable index两种。

3.2 mutable index

mutable index，可变索引，适用于数据有增删改的场景。Phoenix默认情况创建的索引都是可变索引，除非在create table的时候显式地指定IMMUTABLE\_ROWS = true。可变索引同样分为Global immutable index和Local immutable index两种。

## 4.Global Indexing ##

### 4.1 配置hbase-site.xml ###

> 使用Global Indexing的话需要配置hbase-site.xml，在HBase集群的每个regionserver节点的hbase-site.xml中加入如下配置并重启HBase集群。

<property>
        <name>hbase.regionserver.wal.codec</name>
        <value>org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec</value>
    </property>

*  1
 *  2
 *  3
 *  4

> 在华三的管理平台修改配置文件如下：  
> ![在这里插入图片描述][20181216011325435.png]

### 4.2 创建表 ###

> 进入phoenix的CLI的界面创建company表：

create table company(id varchar primary key, name varchar, address varchar);

*  1

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70]

> 查看company表索引

![在这里插入图片描述][20181216011531324.png]

### 4.3 创建索引 ###

> 对company表的name字段创建索引，索引名为my\_index。  
> create index my\_index on company(name);  
> 查看当前所有表会发现多一张MY\_INDEX索引表，查询该表数据。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 1]

> 该表中会有2个字段，其中:ID是自动创建的，其实就是HBase中的主键RowKey，0:NAME是我们刚刚手动创建的。

### 4.4 插入数据 ###

> 在company表中添加测试数据。

upsert into company(id, name, address) values('001', 'dimensoft', 'nanjing');

*  1

### 4.5 查询数据 ###

> 查询company表数据

select name,address from company where name='dimensoft';

*  1

![在这里插入图片描述][20181216011836613.png]

> 查询索引表my\_index

![在这里插入图片描述][2018121601190998.png]

> 从HBase的CLI界面查看索引表MY\_INDEX

![在这里插入图片描述][20181216011952927.png]

2个索引字段NAME和ID的值被合并为索引表MY\_INDEX的rowKey，\\x000是十六进制表示，转换为字符串是空格。

### 2.6 高能预警： ###

select name,address from company where name='dimensoft';

*  1

> 这样的查询语句是不会用到索引表的

> name字段虽然是索引字段但是address字段并不是索引字段！也就是说需要查询出来的字段必须都是索引字段如：  
> select name from company where name=‘dimensoft’;

> 如果希望使用索引表进行查询的话可以使用以下三种方式来解决这个问题:

> 创建covered index 采取INCLUDE(index cover，即索引覆盖)的方式:

> 索引覆盖其实就是将INCLUDE里面包含的列都存储到索引表里面，当检索的时候就可以从索引表里直接带回这些列值。要特别注意索引列和索引覆盖列的区别，索引列在索引表里面是以rowkey的形式存在，多个索引列以某个约定的字节分割然后一起存储在rowkey里面，也就是说当索引列有很多个的时候，rowkey的长度也相应会变长，大小取决于索引列值的大小。而索引覆盖列，是存储在索引表的列族中。

> 创建索引的时候指定一个covered字段，先删除my\_index索引

drop index my_index on company;

*  1

> 创建covered index

create index my_index on company(name) include(address);

*  1

> 使用这种方式创建的所有会导致address字段的值被拷贝到索引中，缺点就是会导致索引表大小有一定的增加。

> 查询索引表my\_index数据。

select * from my_index;

*  1

![在这里插入图片描述][20181216012326166.png]

> 这里的数据是自动同步过来的，可以发现address字段的值也被存储了。  
> 从HBase的CLI中查看MY\_INDEX表数据会发现比不使用include的时候多了一行数值，并且里面包含了address字段的值。

![在这里插入图片描述][20181216012344176.png]

> 这个时候就再使用下面的查询语句就会使用到索引来进行查询了。

select name,address from company where name='dimensoft';

*  1

**强制使用索引表**

> 在进行查询的时候通过sql语句强制使用索引查询。

SELECT /\*+ INDEX(company my\_index) \*/ name,address FROM company WHERE name = ‘dimensoft’;

> 这样的查询语句会导致二次检索数据表，第一次检索是去索引表中查找符合name为dimensoft的数据，这时候发现address字段并不在索引字段中，会去company表中第二次扫描，因此只有当用户明确知道符合检索条件的数据较少的时候才适合使用，否则会造成全表扫描，对性能影响较大。

**采用多列索引的方式**

create index my_index on company(name,address)

*  1

【说明】

> 多列索引在满足前缀式的情况才会用到，如创建了A,B,C顺序的多列索引，当在where条件指定A条件、A B条件或者A B C条件均会走索引，但是 B C条件则无法走索引。

## 5.Local Indexing ##

> Local indexing适用于写操作频繁的场景。与Global indexing一样，Phoenix会自动判定在进行查询的时候是否使用索引。使用Local indexing时，索引数据和数据表的数据是存放在相同的服务器中的避免了在写操作的时候往不同服务器的索引表中写索引带来的额外开销。使用Local indexing的时候即使查询的字段不是索引字段索引表也会被使用，这会带来查询速度的提升，这点跟Global indexing不同。一个数据表的所有索引数据都存储在一个单一的独立的可共享的表中。在读取数据的时候，标红的那句话不会翻译大意就是在读数据的时候因为存储数据的region的位置无法预测导致性能有一定损耗。

### 5.1 配置hbase-site.xml ###

> 使用Local Indexing的话需要配置hbase-site.xml，在HBase集群的master节点的hbase-site.xml中添加如下配置并重启HBase集群。

> 配置这个参数的目的是确保数据表与索引表协同定位。:

<property>
        <name>hbase.master.loadbalancer.class</name>
        <value>org.apache.phoenix.hbase.index.balancer.IndexLoadBalancer</value>
    </property>
    <property>
        <name>hbase.coprocessor.master.classes</name>
        <value>org.apache.phoenix.hbase.index.master.IndexMasterObserver</value>
    </property>
    
    #高能预警：如果使用的是Phoenix 4.3+的版本的话还需要在HBase集群的每个regionserver节点的hbase-site.xml中添加如下配置并重启HBase集群。
    <property>
        <name>hbase.coprocessor.regionserver.classes</name>
        <value>org.apache.hadoop.hbase.regionserver.LocalIndexMerger</value>
    </property>

*  1
 *  2
 *  3
 *  4
 *  5
 *  6
 *  7
 *  8
 *  9
 *  10
 *  11
 *  12
 *  13
 *  14

### 5.2 创建表 ###

create table company(id varchar primary key, name varchar, address varchar);

*  1

> 查看company表索引

![在这里插入图片描述][20181216012808897.png]

### 5.3 创建索引 ###

> 对company表的name字段创建索引，索引名为my\_index。

create local index my_index on company(name);

*  1

> 查看当前所有表会发现多一张MY\_INDEX索引表，查询该表数据。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 2]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 3]

> 从HBase的CLI界面查看当前所有表。

list

*  1

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 4]

> 高能预警：这里的索引表并不叫MY\_INDEX，而是叫\_LOCAL\_IDX\_COMPANY，但是在Phoenix的CLI中进行数据查询的时候仍然是使用MY\_INDEX进行查询，应该是做了映射。

> 在company表中添加测试数据。

upsert into company(id, name, address) values('001', 'dimensoft', 'nanjing');

*  1

、

### 5.4 查询数据 ###

> 查看company表数据以及索引表my\_index数据。

select * from company;
    select * from my_index;

*  1
 *  2

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 5]

> 从HBase的CLI界面查看索引表\_LOCAL\_IDX\_COMPANY。  
> scan ‘\_LOCAL\_IDX\_COMPANY’  
> ![在这里插入图片描述][2018121601370513.png]

> 3个索引字段\_INDEX\_ID、NAME和ID的值被合并为索引表的rowKey，其中\_INDEX\_ID并没有值（\\x000是十六进制表示，转换为字符串是空格）。

## 6.说明 ##

### 6.1说明内容 ###

> 觉得还是有必要把这种类型的索引说明一下，phoenix将其二级索引技术划分为global and local indexing 2种，但是如果继续往下细分的话又分为mutable global indexing、mutable local indexing、immutable global indexing、immutable local indexing一共四种。  
> 默认创建的二级索引为mutable的（mutable global ing或者mutable local indexing）。在上两篇文章中都对这两种索引技术大致都做出了说明。immutable类型的索引主要针对的是数据一次入库之后永不改变的场景（only written once and never updated）。

### 6.2 Append-only Data ###

> For a table in which the data is only written once and never updated in-place, certain optimizations may be made to reduce the write-time overhead for incremental maintenance. This is common with time-series data such as log or event data, where once a row is written, it will never be updated. To take advantage of these optimizations, declare your table as immutable by adding the IMMUTABLE\_ROWS=true property to your DDL statement:

CREATE TABLE my_table (k VARCHAR PRIMARY KEY, v VARCHAR) IMMUTABLE_ROWS=true;

*  1

> All indexes on a table declared with IMMUTABLE\_ROWS=true are considered immutable (note that by default, tables are considered mutable). For global immutable indexes, the index is maintained entirely on the client-side with the index table being generated as change to the data table occur. Local immutable indexes, on the other hand, are maintained on the server-side. Note that no safeguards are in-place to enforce that a table declared as immutable doesn’t actually mutate data (as that would negate the performance gain achieved). If that was to occur, the index would no longer be in sync with the table.  
> 在一些数据一次写入永不更新的场景中，核心的优化就是减少了在写数据时性能的开销。例如日志数据与事件类型的数据都是一次写入永不更新。通过在场景数据表的时候声明IMMUTABLE\_ROWS=true来显示的说明该表的所有索引都是immutable的（默认的是mutable类型）。Global immutable indexes由客户端维护，而Local immutable indexes由服务端维护。即使创建表的时候使用了immutable声明，数据表中的数据也是可以进行更新的。如果进行了这个的操作会引起数据表的数据与索引表的数据不同步。

### 6.3 创建表 ###

> 在创建数据表的时候声明IMMUTABLE\_ROWS=true来显示的说明该表的所有索引都是immutable的。

create table company_immutable(id varchar primary key, name varchar, address varchar) IMMUTABLE_ROWS=true;

*  1

### 6.4 创建表 ###

> 对company\_immutable表的name字段创建索引。

> create index name\_test on company\_immutable(name);

### 6.5 创建索引 ###

> 对company\_immutable表的name字段创建索引。

create index name_test on company_immutable(name);

*  1

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 6]

### 6.7 插入数据 ###

> 插入测试数据。

> upsert into company\_immutable(id, name, address) values(‘001’, ‘dimensoft’, ‘nanjing’);

### 6.8 查询数据 ###

> 查询数据表与索引表数据。

> select \* from company\_immutable;  
> select \* from name\_test;  
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 7]

### 6.9 更新数据 ###

> 更新id为001的数据（这里是为了测试才进行数据更新操作的，否则的话最好不要对声明了immutable的表进行数据更新）。

upsert into company_immutable(id, name, address) values('001', 'baidu', 'beijing');

*  1

> 重新查询数据表与索引表。

select * from company_immutable;
    select * from name_test;

*  1
 *  2

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 8]

> 可以看到索引表中的数据并没有被修改，而是被追加了！这就是immutable类型的索引。

[20181216011325435.png]: /images/20221024/abbfd6c43b4343bbabffc55d95abefca.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70]: /images/20221024/1d60345ab58742a6ad3fbfab8acaf25c.png
[20181216011531324.png]: /images/20221024/a885e14241754404838afe125ac76e4b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 1]: /images/20221024/07665c9b61b244de835acd6013725a77.png
[20181216011836613.png]: /images/20221024/6e8a014700354114a43c2da734abfcb5.png
[2018121601190998.png]: /images/20221024/86e18591ea264de59908da4bbc571b85.png
[20181216011952927.png]: /images/20221024/21f053d43b4a4bcc90f289199b6dd3b9.png
[20181216012326166.png]: /images/20221024/a6336a63f48342cf8412bcc4fde4be11.png
[20181216012344176.png]: /images/20221024/f74bfcd62f8f423f9b634b4fb7a48fbe.png
[20181216012808897.png]: /images/20221024/ce3a604680b04a559ddce7dcd29325fa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 2]: /images/20221024/ec0e33d31fd64d6a82dd0c3064655750.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 3]: /images/20221024/f5a2af9042c04e51926fb8c9b9867126.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 4]: /images/20221024/8a2ac26d23774acd91ef0bb5941c8b47.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 5]: /images/20221024/7619be004f074db2854c1dc407e07450.png
[2018121601370513.png]: /images/20221024/1e823e52a40e4f2780350cfb3c4a13cb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 6]: /images/20221024/b0062f3c6cbe4213860e74b8dce70144.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 7]: /images/20221024/0359050d779e48e19ec00413f2439c90.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JpbmdveHViaW4_size_16_color_FFFFFF_t_70 8]: /images/20221024/cc43709172904994b036cdbe7d155876.png