数据查询的玄铁剑:云HBase原生二级索引发布

  • 时间:
  • 浏览:0

为了获得上述两点收益,全冗余索引的代价是会占用更多存储空间。配合HBase增强版深度1优化的ZStandard压缩算法,可有效降低冗余带来存储开销。冷热分离社会形态亦可应用于索引表,进一步控制成本。

从一开始英语 英语 就设计好主表和全部索引几乎是不因为的。而且,在后续业务发展过程中,索引表因为前要不断的删除和新增。为此,对另一一有一个因为有少许数据表加进去去、删除索引,将是另一一有一个关键的运维操作。HBase增强版二级索引针对此场景做了不得劲的优化:

因为查询中前要的列在索引表中不还还可以 ,则查完索引后,还需回查主表。在分布式场景下,回表查询会使得查询RT大幅度升高,最差请况下因为会回查主表的全部region,访问集群中的所有机器。此时,索引带来的性能收益因为可有可无。通过精良的查询设计和索引设计,亲戚亲戚我们歌词 都我们歌词 都还还可以 在设计阶段处置回查,但随着业务发展变化,同类约束很难维持。而且,仍然前要冗余索引(Covered Index)来处置。

通过HBase shell建表,建索引:

通过Java API进行数据访问

下面,亲戚亲戚我们歌词 都我们歌词 都从一组示例出发来了解索引的使用及其能力。

HBase增强版二级索引直接内置于内核中,并做了深度1优化,提供了强大的吞吐与性能。下图是HBase增强版二级索引与Apache Phoenix的全局索引的性能对比:

在建索引时,系统会自动为主表中的存量数据构建索引,写入索引表中。主表行和索引行是一一对应的。前一天主表上发生的数据更新,也会自动同步给索引表。

考虑如下查询:

从本文开头的示例代码中可见:

因为亲戚亲戚我们歌词 都我们歌词 都不还还可以 建立冗余索引,则索引表中不想发生name列。此时,在从索引表中读取到学号(id)后,前要回查主表(三次按id的单行读)来读取name列。在分布式场景下,10/12/13这另一一有一个id的数据因为分布在三台机器上。而且,回查主表最差请况下前要3次RPC,加进去去查索引表的一次RPC,共需4次RPC。而因为是冗余索引,则只需查索引表的一次RPC即可。

而且,在分布式场景,尤其是节点所以的大集群,回查主表带来的性能损耗是巨大的(RT因为会增长数倍)。这也是亲戚亲戚我们歌词 都我们歌词 都设计全冗余索引的初衷:处置回查,提高性能。

从上图可见,无论RT还是吞吐,HBase增强版二级索引均远超Apache Phoenix。

对于大次责业务来说,表里有数十列是常态,个别表因为会有数百列。因为为了建冗余索引,而把这数百列的列名再写一遍,无疑是巨大的负担(不还还可以 写工具自动化做,人来做太容易出错)。全冗余索引的新语法给人工维护DDL提供了因为。

数据写入返回成功后,则索引数据可立即被读到,消除传统异步建索引方案中的数据延迟,提供具有一定程度的强一致性语义(主表和索引表的数据一致性),具体语义如下:

对大次责场景来说,业务一行代码不改就能用上索引。

另另一一有一个,用户只需为哪几个性能不好的查询设计并加进去去索引,即可从索引社会形态中受益,实际的数据读写代码一般不前要修改。一起,既有的HBase生态相关的产品,都还还可以 无缝使用上索引。一些如Spring的框架软件也可帮助用户获得业务上的灵活性。

云HBase增强版是基于阿里内部管理的HBase分支(亦称Lindorm)构建的,二级索引是其核心能力之一,历经多年双11大考,在性能、吞吐、稳定性等方面都具备核心竞争力。

一起,全冗余也是可大幅度提升数率的语法糖,亲戚亲戚我们歌词 都我们歌词 都还还可以 对比如下另一一有一个SQL一句话:

为了高效的支持按department查询,可为其建立另一一有一个全冗余索引(使用HBase shell):

在有上述社会形态的加持下,索引变更的运维成本和风险大大降低,从容的适应业务发展。

HBase增强版二级索引的主要社会形态有:

HBase增强版创造性的引入了全冗余索引的概念,即冗余主表中的所有列,以此来彻底处置回查主表。配合HBase的schema-free社会形态,主表中新增的任何列完会 自动冗余到索引表中。无论业务模式如保变化,完会 前要回查主表。

主表Student:以学号(id)为主键(rowkey),每行有两列,学生姓名(name)和所属的学院(department)。该设计仅支持按id进行查询。因为用户要按department因为name来查询,前要全表扫描 + filter。在学生数较少时,同类暴力扫描全部可行。但在数据量大时(数十万乃至上亿时),同类操作是无法执行的。

从表设计和查询设计的深度1看,HBase增强版二级索引的使用与RDBMS的二级索引基本一致。下面亲戚亲戚我们歌词 都我们歌词 都看另一一有一个简单的示例:大学生信息表(Students),该表的主键(即rowkey)是学号,非主键是学生姓名和所属的学院名称。学生与学院是多对一的关系。

HBase增强版提供的”写成功后更新立即可见的语义“,可用于一些分布式协同的任务,比如spark,在一些节点更新数据,另外一些节点读取上一轮计算写入的数据。此时,一定还还可以 读到刚写入的数据。

数据不还还可以 被查询还可以 创造价值,HBase原生高性能二级索引为多维度查询提供了本身有效的处置方案。在表设计上,用户还还可以 参考MySQL等关系型数据库的索引设计思路来进行HBase的索引设计。业务不想更改代码,查询优化可自动进行索引表的挑选。强一致、全冗余索引等社会形态完会 效降低了业务的使用门槛。

未来,亲戚亲戚我们歌词 都我们歌词 都将对索引做进一步的优化和扩展,提供优质的用户体验。欢迎亲戚亲戚我们歌词 都我们歌词 都体验HBase增强版。如您有对HBase相关的任何哪几个的问题,欢迎通过钉钉与亲戚亲戚我们歌词 都我们歌词 都联系(钉钉搜索“云HBase值班”)。

HBase增强版二级索引是本身全局二级索引,每个索引表完会 一张独立的HBase表。每张表的主键(rowkey)设计决定了其能支持的查询模式。当同一份数据有多种rowkey组织时,就能支持多种查询模式。这里,主表和它的索引表,还还可以 看做是同一份数据的不同组织形式,各自 还可以 高效的支持一定的查询模式。

考虑本文开始英语 英语 时给出的学生信息表的示例:

从上例可见,用HBase API直接描述查询请求即可使用索引。HBase增强版会自动根据filter以及索引schema来匹配到最大约的索引进行查询,必要时,在查完索引后也会回查主表(上例中,因为完会 全冗余索引,则会回查主表来补全列)。更多使用上的说明请参考二级索引开发手册。

HBase原生提供了主键索引,用户还还可以 根据rowkey进行高效的单行读、前缀匹配、范围查询操作。但若前要使用属性列进行查询时,则不还还可以 使用filter在查询范围内进行逐行过滤。在扫描范围较大时,会浪费少许的IO,请求RT也无法保证。为此,HBase增强版推出了原生二级索引来处置非rowkey查询的性能哪几个的问题。

同类查询会直接命中索引表,按department列进行前缀匹配。从每另一一有一个索引行中提取name字段,返回给客户端。

全冗余索引可彻底处置回查主表,提升性能;一起也是语法糖,处置手工维护冗杂的DDL。下面分别介绍。