KunlunDB 查询优化(一)

前言

有朋友之前看过KunlunDB的架构以及技术介绍后,比较好奇其查询优化的过程,本篇章带来的是查询优化这一块的具体流程介绍,后续也会出一篇实例来举例演示。

当然后续也会对KunlunDB的其它技术方面(比如数据分片这些)做实例演示,以方便大家去了解KunlunDB。

查询优化流程

KunlunDB是计算和存储分离的分布式数据库系统,当一条查询SQL发送到KunlunDB任一计算节点(CN)时,KunlunDB语法解析器(Parser)首先会对原始查询文本做出解析以及一些简单的合法性验证,之后会对查询做逻辑优化:如查询重写,分区修剪,列裁剪,谓词下推等。

KunlunDB在逻辑优化过程中会采取最大下推的策略。

计算下推不但可以避免CN和DN间数据网络交互还可以充分利用多分片并发执行的能力和各个DN资源,加速查询。

优化后的算子分为两类:

  • 可以下推的算子:RemoteScan将该算子推送到对应的数据节点上执行,执行完成后拉取相应的数据到计算节点做后继处理。支持下推的算子包括:过滤条件,如WHERE或HAVING中的条件。聚合算子,如COUNT,GROUP BY等,会分成两阶段进行聚合计算。排序算子,如ORDER BY,JOIN和子查询。Project,投影操作。Distinct排重。
  • 无法下推的部分算子:如跨 shard 的join,需要将数据从数据节点拉取到计算节点做计算,优化器会选择最优的方式来执行,如选择合适的并行度策略等

全局执行流程如下:

KunlunDB 查询优化(一)_第1张图片

优化流程如下:

KunlunDB 查询优化(一)_第2张图片

最大下推策略如下:

KunlunDB 查询优化(一)_第3张图片

KunlunDB 查询优化(一)_第4张图片

KunlunDB 查询优化(一)_第5张图片

综述:为获取最大性能,在定义分区键时要充分考虑业务在执行SQL 语句的场景,以最大限度避免跨节点数据操作。

*KunlunDB项目已开源

【GitHub:】
https://github.com/zettadb

【Gitee:】
https://gitee.com/zettadb

END

你可能感兴趣的:(数据库)