SQL查询优化器 课后习题 | 青训营笔记

dadongc
166 阅读5分钟

SQL查询优化器 课后习题 | 青训营笔记

这是我参与「第四届青训营 」笔记创作活动的的第1天

题目来源：juejin.cn/post/712275…

  1. Top-down 和 Bottom-up 的优化方式各有什么优缺点？
    1.   io-meter.com
    2. 自底向上
    3.   自底向上的算法最为直观：当我们试图计算节点 A 的最优方案时， 其子树上每个节点对应的等价集合和最优方案都已经计算完成了，我们只需要在 A 节点上不断寻找可以应用的规则，并利用已经计算好的子树成本计算出母树的成本，就可以得到最优方案。 事实上，包括 SQL Server 在内的一些成熟的数据库系统都采用这种方法。
    4.   然而这种方案存在一些难以解决的问题:
    5.   1、不方便应用剪枝技巧，在查询中可能会遇到在父亲节点的某一种方案成本很高，后续完全无需考虑的情况， 尽管如此，需要被利用的子计算都已经完成了，这部分计算因此不可避免
    6.   2、难以实现启发式计算和限制计算层数。由于程序要不断递归到最后才能得到比较好的方案， 因此即使计算量比较大也无法提前得到一个可行的方案并停止运行
    7. 自顶向下
    8.    因此，Volcano Optimizer 采取了自顶向下的计算方法，在计算开始， 每棵子树先按照原先的样子计算成本并作为初始结果。在不断应用规则的过程中，如果出现一种新的结构被加入到当前的等价集合中， 且这种等价集合具有更优的成本，这时需要向上冒泡到所有依赖这一子集合的父亲等价集合， 更新集合里每个元素的成本并得到新的最优成本和方案。
    9.   值得注意的是，在向上冒泡的过程中需要遍历父亲集合内的每一个方案，这是因为不同方案对于 Input 成本变化的敏感性不同，不能假设之前的最优方案仍然是最优的。
    10.   自顶向下的方法尽管解决了一些问题，但是也带来了对关系代数节点操作十分繁琐、 要不断维护父子等价集合的关系等问题，实现相对比较复杂。

  1. Aggregate 和 Join 上面的 Filter 下推需要注意什么？什么类型的谓词才能下推倒 Aggregate 和 Join 算子的下面？

    1.   spark sql 源码剖析 PushDownPredicate：谓词不是想下推，想推就能推-spark技术分享
    2. 在谓词下推的时候，只有operator 包含的所有expression都是确定性的时候才可以下推， 同理不能下推的还包括 rand 表达式
    3. Filter 的字段必须要在 group by 的维度字段里面，aggregate 包含的表达式也必须是确定性的
    4. 窗口聚合，谓词下推的表达式必须是窗口聚合的分区key，谓词必须是确定性的。

  1. Runtime Filter 在什么情况下会造成性能回退？

    1.   字节跳动数据平台技术揭秘:基于ClickHouse的复杂查询实现与优化-51CTO.COM
    2. 但需要注意的是，Runtime Filter是一种特殊场景下的优化，针对场景是右表数据量不大，并且构建的Runtime Filter对左表有比较好的过滤效果。若右表数据量较大，构建的Runtime Filter的时间比较久，或对左表的数据过滤没有效果。Runtime Filter反而会增加查询的耗时和计算的开销。因此要根据数据的特征和规模来决定是否开启优化。

  1. 了解一下 Spark 系统中 Join Cardinality 的估算方式

    1. HLL聚合（不确定）

    2. 相关资料

      1. towardsdatascience.com/efficient-c…
      2. 大叔算法分享(4)Cardinality Estimate 基数计数概率算法 - 匠人先生 - 博客园

  1. 了解一下 Aggregate cardinality/NDV 的估算方式

    1. NDV Function HLL计算

  1. 了解直方图在统计信息估计中的作用

    1. 解决数据倾斜情况：假设表t(c1)有1000的数据量，NDV：10，其中num:0数据量占910，其他1-9分别为10。在没有直方图的情况下，c1 = 0-9都会估计有100行。
    2. Oracle Histogram 基础介绍_勉仁的博客-CSDN博客

  1. RBO 里几种 pattern 匹配规则（ARBITRARY，DEPTH_FIRST，TOP_DOWN，BOTTOM_UP）有什么优缺点？

    1. 以下为个人思考，不一定正确
    2. ARBITRARY：按任意顺序匹配（因为它是有效的，而且大部分的 Rule 并不关心匹配顺序）
    3. BOTTOM_UP：自下而上，先从子节点开始匹配，父节点可以直接利用子节点结果
    4. TOP_DOWN：自上而下，先从父节点开始匹配，可以剪枝，限制运算层数
    5. DEPTH_FIRST：深度优先匹配，某些情况下比 ARBITRARY 高效（为了避免新的 vertex 产生后又从 root 节点开始匹配）。

  1. RBO 直到没有可以匹配的 rule 才结束在 serving 场景（在线服务场景）可能会有什么问题？（考虑 rule 很多的情况）除了这种结束方式，还有什么其他结束方式？

    1. io-meter.com
    2. 时钟: 使用最大迭代计数或最大物理执行时间作为限制
    3. 成本阈值: 当优化方案的成本低于某个阈值是结束算法(相比原始成本或固定值)

  1. CBO 里 Branch-and-bound pruning 可以以 bottom-up 的方式进行吗？

    1. 应该不行，bottom-up已经计算好子节点的cost，再剪枝没有意义了
avatar
文章
阅读
粉丝