复杂 SQL 查询跑不动?DRDS 只读实例来解决!

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
简介: 在实际业务生产环境中,业务应用系统在使用 OLTP 数据库将数据进行存储后,均会存在如后台运营类系统进行统计报表分析等场景的复杂 SQL 查询诉求。

背景
在实际业务生产环境中,业务应用系统在使用 OLTP 数据库将数据进行存储后,均会存在如后台运营类系统进行统计报表分析等场景的复杂 SQL 查询诉求。

为满足此类复杂 SQL 查询快速响应的需求,DRDS 团队基于第三代分布式SQL引擎,进一步引入自研 MPP 多机并行计算引擎(Fireworks)及对应的优化策略,极大地补强了 DRDS 的复杂查询处理能力。

千万级数据下的分布式多表Join、聚合、排序、子查询操作秒级返回结果,可极大的提升响应速度。自身利用同一份数据(RDS只读)进行处理,无需数据同步至其他数据源,降低业务架构整体链路复杂度,节省业务运维及预算成本。
1

主要特性
自研 MPP 多机并行计算引擎 Fireworks

DRDS 只读实例搭载了一个具备完整多机并行处理能力的 SQL 执行引擎(Fireworks)。它与 DRDS 主实例上搭载的 SQL 执行引擎有显著差异。

DRDS 主实例的执行引擎采用单机架构,采取尽可能将计算下推至底层各物理分库执行的策略,依靠物理分库的计算能力实现了逻辑SQL的分布式计算。

而 DRDS 只读实例上搭载的 Fireworks 引擎是一个由多个计算节点组成的集群,将一个 SQL 查询转换为一个分布式计算任务,突破下挂
物理库计算能力的限制,大幅提升针对复杂逻辑SQL的计算速度,对 Join、Aggregate 和 Sort 计算有显著加速效果。

Fireworks 会将 Join、Aggregate 和 Sort 这类计算任务通过 Shuffle 的方式打散并分发到计算集群的多个计算节点上,通过多计算节点并行计算达到计算加速的目的。

针对多机并行执行模式定制打造的优化器

原 DRDS 主实例优化器主要侧重 OLTP 场景,核心理念是尽量将一切计算下推至下挂的物理库执行。其目的是充分利用物理库的计算资源,同时可以避免产生大量的数据流动,从而得到较快的响应速度。

而当面对涉及较大数据量级下的复查查询场景时,整体性能会受到下挂物理库的限制,同时也会对物理库产生较大的压力从而影响稳定性,总体来看其 OLAP 能力有很多局限性。

在引入了 MPP 多机并行计算引擎 Fireworks 之后,DRDS 本身在计算能力上得到了极大地提升,优化器的整体优化策略也有所调整:

  1. 尽量将复杂计算(如 Join 、Aggregation 、Sort )上提至自身执行引擎计算,通过 Fireworks 计算集群实现计算加速与可扩展性;
  2. 将轻量级的计算(如 Project 、Filter )继续下推至至物理库从而减少数据拉取的成本。

DRDS 分布式 SQL 优化器通过对执行计划最细粒度的优化可以产生出对多机并行执行引擎友好的执行计划,获得更好执行效率。

同时提供精细化算子下推策略,将对 RDS 较小压力的算子下推至物理库取得更高的计算性价比,同时保护 RDS 免受代价较大算子的影响,从而保证在线流量的稳定性。

基于在线数据直接分析

以新零售业务为代表的新兴互联网业务不断涌现,这类业务除了有实时的 OLTP 需求,还伴随着一些有一定复杂度的准实时 OLAP 的需求用以支持实时决策等需求。

而目前大多数的数据分析场景的解决方案均需要将 OLTP 数据库的生产数据导出至其他数据源进行再次离线分析,这种传统方案很难满足准实时的需求,同时在数据导出至离线系统时也存在数据丢失的风险。

DRDS 只读实例无需进行冗长繁琐的数据同步任务,基于 RDS 只读实例或 RDS 主实例直接进行复杂数据处理,降低业务架构整体链路复杂度,节省业务运维及预算成本。

DRDS 只读实例在避免数据同步的同时,可保证数据处理时效性,最高可做到 READ COMMITED 的实时性 (基于 RDS 主实例)。

边界清晰的 SQL 兼容性

DRDS 只读实例全面兼容 DRDS 主实例的 SQL 查询语法,与 DRDS 5.3 版本的 SQL 兼容性和 SQL 支持边界高度保持一致。

与同类产品相比具备兼容性高以及支持边界清晰的特点。可以提供与 DRDS 主实例几乎一致的体验。

DRDS 主实例上无法执行或执行较慢的复杂 SQL 可以直接迁移到只读实例来执行,免去SQL改写的额外开销。

产品体验灵活自主

DRDS 只读实例自动同步 DRDS 主实例的账号权限信息,原生VPC支持,内外网可同时开启,根据业务情况灵活变配,数据处理能力线性提升。

技术架构总览

DRDS 只读实例整体架构与 DRDS 主实例基本保持一致,仅在查询层有所变化,增加了 MPP 执行引擎和对应优化器,如下如所示:

2

DRDS协议层负责处理网络交互与 MySQL 协议的解析,收到查询请求后会将 SQL 转交至查询层处理。查询层负责解析 SQL 并由执行器产生经过优化的执行计划,然后交由执行引擎到存储层进行查询以及计算。
如果需要使用 Fireworks 引擎计算,在得到执行计划之后查询层还会将该执行计划进一步转换为分布式执行计划并将其作为分布式任务提交给 Fireworks Cluster。由远端的 Fireworks 集群完成到存储层进行数据查询以及后续计算的工作。

简单来说,DRDS 只读实例可以认为是在原 DRDS 基础上增加了一条具备多机并行处理能力的执行链路。

适用场景

总体来说 DRDS 只读实例适用于处理低并发高延迟的大数据量级下的复杂查询。如数据分析及报表类场景,该类场景的典型特征为含有大
量的关联、聚合及排序操作且参与计算的数据规模较大。

目前 DRDS 只读实例在阿里集团内部已经落地了多个业务,其中最具代表性的当属盒马、商业大脑等新零售场景。围绕人、货、场、仓多个维度进行关联分析,对分散在不同逻辑库的几张甚至十几张逻辑表进行关联然后再聚合、排序以满足库存对账、决策支持等业务上的需求。

DRDS 只读实例的出现使业务开发同学不再需要配置、维护数量繁多的数据同步链路,不用担心因数据不同步而造成的结果时效性差或不准确等问题,一定程度上减轻了开发同学的工作负担。

对于已经在使用 DRDS 的用户来说,DRDS 只读实例可以解决如下两类已知问题:

  1. 在使用 DRDS 过程中可能会发现某一些涉及Join、聚合、排序的复杂 SQL因为不能完全下推而需要在DRDS执行引擎中进行二次计算,而这种计算因为受到单机执行引擎在内存方面的限制而无法执行。
  2. SQL 的复杂计算部分可以下推但是涉及到的数据规模较大造成物理库压力增高影响 OLTP 业务或者响应时间过慢达不到要求。

小结

长期以来 DRDS 受到单机架构执行引擎的限制一直无法对基于大数据规模的复杂查询提供很好的支持,也无法通过扩展物理资源来实现对自身本地计算能力的线性扩展。

DRDS只读实例的推出彻底地弥补了 DRDS 在 OLAP 场景下的短板,使得 DRDS 在提供强大 OLTP 能力的同时提供可扩展的 OLAP 能力,为同时具有 OLTP 需求与中等规模数据分析需求的用户提供了一站式整体解决方案,为用户带来便利。

后续半年时间内 DRDS 只读实例将发布跨逻辑库的关联查询功能,并通过更多的技术手段,不断增强只读实例核心能力,在并发度、响应时间、数据量、交互式查询等方面将拥有更好的表现,满足企业级应用对数据库的严苛要求。

目前 DRDS 只读实例与 DRDS 主实例同享8折限时优惠,活动详情https://promotion.aliyun.com/ntms/act/drdsreadonlydisc.html
欢迎大家持续关注 DRDS(阿里云分布式关系型数据库服务),产品详情
https://www.aliyun.com/product/drds

相关实践学习
快速体验PolarDB开源数据库
本实验环境已内置PostgreSQL数据库以及PolarDB开源数据库:PolarDB PostgreSQL版和PolarDB分布式版,支持一键拉起使用,方便各位开发者学习使用。
相关文章
|
1月前
|
SQL 数据挖掘 数据库
第三篇:高级 SQL 查询与多表操作
本文深入讲解高级SQL查询技巧,涵盖多表JOIN操作、聚合函数、分组查询、子查询及视图索引等内容。适合已掌握基础SQL的学习者,通过实例解析INNER/LEFT/RIGHT/FULL JOIN用法,以及COUNT/SUM/AVG等聚合函数的应用。同时探讨复杂WHERE条件、子查询嵌套,并介绍视图简化查询与索引优化性能的方法。最后提供实践建议与学习资源,助你提升SQL技能以应对实际数据处理需求。
128 1
|
3月前
|
SQL 运维 监控
SQL查询太慢?实战讲解YashanDB SQL调优思路
本文是Meetup第十期“调优实战专场”的第二篇技术文章,上一篇《高效查询秘诀,解码YashanDB优化器分组查询优化手段》中,我们揭秘了YashanDB分组查询优化秘诀,本文将通过一个案例,助你快速上手YashanDB慢日志功能,精准定位“慢SQL”后进行优化。
|
3月前
|
SQL 索引
【YashanDB知识库】字段加上索引后,SQL查询不到结果
【YashanDB知识库】字段加上索引后,SQL查询不到结果
|
1月前
|
SQL 关系型数据库 MySQL
凌晨2点报警群炸了:一条sql 执行200秒!搞定之后,我总结了一个慢SQL查询、定位分析解决的完整套路
凌晨2点报警群炸了:一条sql 执行200秒!搞定之后,我总结了一个慢SQL查询、定位分析解决的完整套路
凌晨2点报警群炸了:一条sql 执行200秒!搞定之后,我总结了一个慢SQL查询、定位分析解决的完整套路
|
3月前
|
SQL 人工智能 自然语言处理
OmniSQL:开源文本到SQL神器!自然语言秒转查询到复杂多表连接等SQL需求
OmniSQL是开源的文本到SQL转换模型,通过创新的数据合成框架生成250万条高质量样本,支持7B/14B/32B三种模型版本,能处理从简单查询到复杂多表连接等各种SQL需求。
284 16
OmniSQL:开源文本到SQL神器!自然语言秒转查询到复杂多表连接等SQL需求
|
3月前
|
SQL 大数据 数据挖掘
玩转大数据:从零开始掌握SQL查询基础
玩转大数据:从零开始掌握SQL查询基础
187 35
|
3月前
|
SQL 关系型数据库 MySQL
如何优化SQL查询以提高数据库性能?
这篇文章以生动的比喻介绍了优化SQL查询的重要性及方法。它首先将未优化的SQL查询比作在自助餐厅贪多嚼不烂的行为,强调了只获取必要数据的必要性。接着,文章详细讲解了四种优化策略:**精简选择**(避免使用`SELECT *`)、**专业筛选**(利用`WHERE`缩小范围)、**高效联接**(索引和限制数据量)以及**使用索引**(加速搜索)。此外,还探讨了如何避免N+1查询问题、使用分页限制结果、理解执行计划以及定期维护数据库健康。通过这些技巧,可以显著提升数据库性能,让查询更高效流畅。
|
4月前
|
SQL 关系型数据库 OLAP
云原生数据仓库AnalyticDB PostgreSQL同一个SQL可以实现向量索引、全文索引GIN、普通索引BTREE混合查询,简化业务实现逻辑、提升查询性能
本文档介绍了如何在AnalyticDB for PostgreSQL中创建表、向量索引及混合检索的实现步骤。主要内容包括:创建`articles`表并设置向量存储格式,创建ANN向量索引,为表增加`username`和`time`列,建立BTREE索引和GIN全文检索索引,并展示了查询结果。参考文档提供了详细的SQL语句和配置说明。
110 2
|
3月前
|
SQL 缓存 关系型数据库
SQL为什么不建议执行多表关联查询
本文探讨了SQL中不建议执行多表关联查询的原因,特别是MySQL与PG在多表关联上的区别。MySQL仅支持嵌套循环连接,而不支持排序-合并连接和散列连接,因此在多表(超过3张)关联查询时效率较低。文章还分析了多表关联查询与多次单表查询的效率对比,指出将关联操作放在Service层处理的优势,包括减少数据库计算资源消耗、提高缓存效率、降低锁竞争以及更易于分布式扩展等。最后,通过实例展示了如何分解关联查询以优化性能。
|
4月前
|
SQL 数据可视化 IDE
SQL做数据分析的困境,查询语言无法回答的真相
SQL 在简单数据分析任务中表现良好,但面对复杂需求时显得力不从心。例如,统计新用户第二天的留存率或连续活跃用户的计算,SQL 需要嵌套子查询和复杂关联,代码冗长难懂。Python 虽更灵活,但仍需变通思路,复杂度较高。相比之下,SPL(Structured Process Language)语法简洁、支持有序计算和分组子集保留,具备强大的交互性和调试功能,适合处理复杂的深度数据分析任务。SPL 已开源免费,是数据分析师的更好选择。

热门文章

最新文章