只需一步,DLA开启TableStore多元索引查询加速!

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: Data Lake Analytics(简称DLA)在构建第一天就是支持直接关联分析Table Store(简称OTS)里的数据,实现存储计算分离架构,满足用户基于SQL接口分析Table Store数据需求。

一、背景介绍

Data Lake Analytics(简称DLA)在构建第一天就是支持直接关联分析Table Store(简称OTS)里的数据,实现存储计算分离架构,满足用户基于SQL接口分析Table Store数据需求。

玩转DLA+OTS:https://ots.console.aliyun.com/index#/demo/cn-hangzhou/dla
王烨:DLA如何分析Table Store的数据

​DLA控制台:https://openanalytics.console.aliyun.com/

二、DLA与Table Store的密切配合

这是DLA与Table Store在生态中的关系,作为存储计算分离架构,DLA负责主要的SQL算子计算,而Table Store则负责部分计算(由DLA下推下来)和核心存储功能。

001.jpg

三、Table Store的数据原型

目前,Table Store的宽数据表结构(https://help.aliyun.com/document_detail/89879.html)中的列, 主要分成两部分:主键(所有主键都不可改,也不为空;其中第一主键是物理分区键),非主键列(可改可覆盖可为空,可有可无):

002.jpg

假设有张表tbl(主键:pk1,pk2;非主键:col1,col2),当DLA收到这样的SQL时:

select pk2,col1 from tbl where pk1 = 123 and pk2 >= '2019-01-10' and col2 = 'zzz'

DLA就会基于Table Store的SDK接口下发相关的查询:

1)查询tbl表数据,其中只查询pk2、pk3、col3这几个列;

2)按照pk1做分区裁剪,只下推查询到pk1=123所在的分区;
3)下推 pk1 =123、pk2 >='2019-01-10'和col4 ='zzz' 这三个条件;
4)如果当前分区的数据很大,则会切分出多个分片,并行查询;

这里,最关键的条件就是 pk1 =123,DLA基于这个第一主键(分区键)条件来筛选OTS的目标分区然后下发查询条件。其他支持的分区条件有

比较条件:>,>=,=,<,<=,!=
范围条件:[1,20], (2,10), (-∞,10], (20,+∞)等

四、DLA+Table Store查询时的瓶颈

针对上面的表结构,如果遇到如下的SQL:

select pk2,pk3,col3 from tbl where pk2 >= '2019-01-10' and col4 = 'zzz'

因为pk1并没有出现在条件中,无法做分区裁剪,因此目前DLA会先将整个TableStore的表切好分片,然后下推其他条件,并行获取每个分片的数据并做计算。这样的问题就是:

  • 如果where条件的过滤性很强(满足条件的数据不多),那这种拉取大量数据方式就会引起极大的浪费;即使where条件是可以下推的,但Table Store内部也要消耗大量的CU来做计算和过滤;
  • 虽然通过并行计算来加速,但整体延时还是会很高,无论这些计算是在Table Store内部还是DLA这一侧;尤其是强过滤性的SQL,更加不符合用户需求;

无论是计算成本还是延时,都会影响客户的体验。

而多元索引是基于倒排索引(https://en.wikipedia.org/wiki/Inverted_index)来设计和实现的:

  1. 把一行Table Store记录看成一篇Document,而Pk是这个Document的DocId;
  2. 每个索引字段都当成一个Term,每个Term值都反向形成一个DocId的链表;
  3. 在查询时针对where条件中每个列找到满足值域的Term列表,再对应产生多个DocId列表;
  4. 再通过拉链合并算法,最终得到合并DocId之后的最大公共集合;
  5. 基于这个合并之后的DocId集合(即Pk集合),再回主表查询数据和过滤、返回;

因此,DLA全面升级了,支持直接以SQL方式访问Table Store的多元索引(https://help.aliyun.com/document_detail/91974.html
从而来加速查询。

五*、DLA访问Table Store的多元索引

对DLA的客户来说,只需一步,就可以使用DLA来访问Table Store的多元索引。因为目前统计信息采集及优化器等原因,暂时还不支持自动判断多元索引,所以需要利用DLA的hint来主动开启(DLA的hint机制:https://zhuanlan.zhihu.com/p/55068247):

/*+ ots-index-first=<相关的索引开关> */ select * from tbl1 where ...

其中,索引开关有几种模式:

  • auto模式,会寻找与表相关的索引,只要有满足条件的索引,就会强制使用:
/*+ ots-index-first=auto */ select * from tbl1 where ...
  • custom模式,根据用户选择表列表,来自动选择满足条件的索引;其中tbl1不需要显示指定库名,是因为当前连接上已经绑定了一个库(比如use xxx);如下case中,只有tbl1和tbl2会走索引,而tbl3则不会:
/*+ ots-index-first=[tbl1, dla_schema2.tbl2, ...] */ select * from tbl1 
join dla_schema2.tbl2 join dla_schema3.tbl3 where ...
  • threshold模式,会根据当前条件匹配的数据量来动态决策,如果找到一个索引,其匹配的数据量小于一定的行数或者一定比例,那就会自动选择;threshold:200表示where条件匹配的行数不超过200行才会使用,而threshold:5%则表示匹配的比例不超过5%才会使用(至于200和5%,DLA内部会调用Table Store的count接口做快速测试并预估判断):
/*+ ots-index-first=threshold:200 */ select * from tbl1 where ...
/*+ ots-index-first=threshold:5% */ select * from tbl1 where ...

另外,早期客户给DLA做的角色授权策略里并没有这些新增的多元索引接口,因此老客户需要重新给DLA做跨云服务访问的角色授权,[戳这里>>>
](https://ram.console.aliyun.com/#/role/authorize?request=%7B%22Requests%22:%20%7B%22request1%22:%20%7B%22RoleName%22:%20%22AliyunOpenAnalyticsAccessingOTSRole%22,%20%22TemplateId%22:%20%22OTSRole%22%7D%7D,%20%22ReturnUrl%22:%20%22https:%2F%2Fopenanalytics.console.aliyun.com%2F%22,%20%22Service%22:%20%22OpenAnalytics%22%7D)

六、多元索引不是银弹,请合理使用

虽然Table Store多元索引很好用,但他也不是银弹,需要合理的使用。有几个场景的约束:

  • 查询多元索引时,只能构建并下发一个分片,因此无法利用并行计算优势;因此对于匹配行数非常少时,单分片索引计算是有优势的;而过滤性很差、数据量很多时就没有优势;
  • 目前多元索引与主表数据之间不是强一致同步的(正常同步时间在毫秒到秒级),因此业务上需要容忍这个延时;
  • 通过索引找到一批Pk列表后,会再发起随机query来查找主表数据,所以可能会更慢;
  • 索引字段的类型、定义等,可能不符合数据库的使用特性(比如定义了全文索引字段等),暂时也不能被自动使用起来;

当然,针对传统数据库的索引中的一些特性,在DLA中也尽量采纳进来,比如Covering Index(http://literatejava.com/sql/covering-indexes-query-optimization/) 来避免随机查询主表,DLA和Table Store也支持,比如这样的SQL:

-- pk1, pk2是主键,col1,col2是非主键列,索引是idx_col1_col2
select pk1, col1 from tbl where col2 = 21

这里col1和col2都在索引中,而pk1和pk2也间接在索引中,因此这个SQL完全可以在索引上完成过滤和输出,从而避免回主表查询。

七、未来方向考虑

除了多元索引之外,目前Table Store团队也在积极地推广二级索引(https://help.aliyun.com/document_detail/91935.html),帮助用户更好的使用Table Store。未来DLA也会将这块能力集成进来,这样DLA可以帮助用户在主表、二级索引表、多元索引表之间最优化选择,帮助客户提升性能并且降低成本。

未来,DLA需要实现预先采集更多的统计信息,免去用户主动添加hint的麻烦,完全自动化的选择和路由,做到真正的数据库体验。

未来,DLA还需要下推更多的计算到Table Store上,实现更好的”近存储计算“,比如聚合能力下推、函数下推、支持全文索引等等,让用户使用DLA+Table Store获得更好的体验。

八、相关文档

相关实践学习
消息队列+Serverless+Tablestore:实现高弹性的电商订单系统
基于消息队列以及函数计算,快速部署一个高弹性的商品订单系统,能够应对抢购场景下的高并发情况。
阿里云表格存储使用教程
表格存储(Table Store)是构建在阿里云飞天分布式系统之上的分布式NoSQL数据存储服务,根据99.99%的高可用以及11个9的数据可靠性的标准设计。表格存储通过数据分片和负载均衡技术,实现数据规模与访问并发上的无缝扩展,提供海量结构化数据的存储和实时访问。 产品详情:https://www.aliyun.com/product/ots
目录
相关文章
|
存储 索引
表格存储根据多元索引查询条件直接更新数据
表格存储是否可以根据多元索引查询条件直接更新数据?
113 3
|
NoSQL 开发工具
TableStore表格存储(阿里云OTS)多行数据操作查询,支持倒序,过滤条件和分页
1. 批量读取操作 批量读取操作可以通过多种方式进行,包括: GetRow:根据主键读取一行数据。 BatchGetRow:批量读取多行数据。 GetRange:根据范围读取多行数据。
873 0
|
SQL 存储 自然语言处理
表格存储最佳实践:使用多元索引加速 SQL 查询
表格存储(Tablestore)在 2022 年 5 月正式发布了 SQL 商业化版本,业务上只需要在数据表上建立映射关系,就可以基于 SQL 引擎方便地对表格存储中的数据进行访问和计算,大大地降低了用户的学习成本。
724 0
|
存储 SQL 运维
Tablestore 与 Elasticsearch 在数据库查询加速场景使用对比
过去三十年,我们从企业应用开始,经历了 PC 互联网、移动互联网的爆发式发展,到如今的产业互联网。在这些不同时代,一直变化的是应用形态,不变的是核心数据的价值。对于核心数据的存储,首选的方案是使用数据库存储,从互联网初期开始,开源关系型数据库 MySQL 成长成为了数据库存储的第一选择,关系型数据库解决了数据的快速建模,高可靠存储和快速查询,但是关系数据库中的高效查询主要依赖二级索引,如果出现索引
1734 2
Tablestore 与 Elasticsearch 在数据库查询加速场景使用对比
|
SQL 存储 Java
表格存储 SQL 查询多元索引
多元索引是表格存储产品中一个重要的功能,多元索引使用倒排索引技术为表格存储提供了非主键列上的快速检索功能,另外也提供了统计聚合功能。表格存储近期开放了SQL查询功能,SQL引擎默认从原始表格中读取数据,非主键列上的查询需要扫描全表。
表格存储 SQL 查询多元索引
|
存储 SQL NoSQL
海量结构化数据存储技术揭秘:Tablestore存储和索引引擎详解
海量结构化数据存储技术揭秘:Tablestore存储和索引引擎详解
418 0
海量结构化数据存储技术揭秘:Tablestore存储和索引引擎详解
|
SQL 存储 NoSQL
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-SQL 查询和分析
前言前面我们介绍了基于 MySQL + Tablestore 分层架构的订单系统。订单数据储存进入 Tablestore 后,用户可以使用 SDK 中的 API 访问数据,也可以继续使用 SQL 访问 Tablestore 中的数据。Tablestore 提供了多种 SQL 的接入方式,客户可以通过 DLA 访问 Tablestore,也可以利用 Tablestore 自身对 SQL 的支持能力,
971 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-SQL 查询和分析
|
存储 SQL 运维
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-基于 DLA 的联邦查询
前言在订单系统中,基于订单数据对客户和商家商品进行画像分析是一种常见的需求。常见的分析需求有:基于主键、分区键数据的条件组合检索,例如获取某用户最近 30 的订单列表。根据非主键列、分区键的条件组合检索工作,例如查询过去一天异常订单列表、查询过去一天成交额最大的10 笔订单。聚合统计类需求,比如统计某店铺过去一个月各商品销售额排名;统计双十一期间销售额前 10 的店铺;统计双十一期间某店铺每天订单
596 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-基于 DLA 的联邦查询
|
SQL NoSQL 关系型数据库
DLA一键发现Tablestore元数据,轻松开启数据湖SQL分析之旅
为了使用DLA标准SQL分析Tablestore数据,往往需要很多步骤才能在DLA中创建相应元数据映射,进而使用SQL去分析Tablestore数据。 现在,数据湖分析DLA发布了一个免费的新功能可以一键快速发现Tablestore元数据,自动创建DLA库表映射到Tablestore的实例和表上,仅倒一杯水的时间即可开启SQL分析Tablestore数据之旅。
DLA一键发现Tablestore元数据,轻松开启数据湖SQL分析之旅