PolarDB-X 的 in 常量查询

场景

实际场景中经常需要根据一些常量指标做IN查询,并且IN值往往是分区键。例如在电商场景中,有两张表,买家表与订单表。订单的具体信息会记录到订单表中,该表按照订单ID进行哈希拆分;买家表则会保存买家ID及其关联的订单ID。一个买家经常需要查询其已购买的所有订单,一种普遍的做法是首先查询买家表获取该买家的所有订单ID,然后根据上述订单ID查询订单的具体信息。假设订单表有4个分片,买家A已下单的订单ID分别为1、 2、4、5和9,那么便会产生如下的SQL,即包含5个值的IN条件查询。

逻辑sql: select * from order where order_id in (1, 2, 4, 5, 9);

执行方式

不同于MySQL,PolarDB-X的架构可以分为计算层和存储层,存储层的DN 节点(数据节点)保存所有的数据。更多背景信息可以参考专栏文章 PolarDB-X 简介。

那么计算节点在收到这条逻辑SQL后,如何从DN节点拉取数据并进行计算呢?

Naive的执行方式

下发至所有分片的物理SQL中均包含所有的in值,如下所示。这种naive的执行方式会带来两个问题,一是随着订单表分片数的增多,需要扫描的分片数急剧增加,而该买家订单数据所在的分片数并未增加;二是随着in值的增多,下发的物理SQL在执行时会由索引扫描变为全表扫描,以上两个原因使得RT急剧升高。

分片1 物理sql: select * from order_01 where order_id in (1, 2, 4, 5, 9);
分片2 物理sql: select * from order_02 where order_id in (1, 2, 4, 5, 9);
分片3 物理sql: select * from order_03 where order_id in (1, 2, 4, 5, 9);
分片4 物理sql: select * from order_04 where order_id in (1, 2, 4, 5, 9);

基于动态裁剪的执行

由上述讨论可知,我们希望可以裁剪掉一定不包含所需数据的分片,由于in字段即为分区键,因此我们可以使用分区算法计算每个in值所属分区,如下所示。

hash(1) = 1, hash(2) = 2, hash(4) = 4, hash(5) = 1, hash(9) = 1

以上述例子为例,显然我们无需向分片3下发物理SQL。进一步地,因为分片1只可能包含订单ID为1、5和9的数据,而不可能包含订单ID为2或4的数据,于是我们可以进一步对物理SQL中包含的in值进行裁剪。

现在我们知道了需要下发的SQL涉及三个分片,那么如何下发这三条物理SQL呢,或者说下发SQL并等待结果的并行度是多少呢?显然,有两种极端,一是全部串行,该方式执行效率极低;二是全部并行,同时起有效分片数个线程向各个分片发送所有物理SQL,该方式的问题是如果分片数太多,会给系统带来非常大的压力,同时会有大量的线程上下文切换。综合考虑,我们默认将下发物理SQL的并行度设置为机器的CPU核数,使用类似滑动窗口的方式下发物理SQL。

此外,我们希望下发到每个分片的物理SQL中包含的in值不要太多,否则该SQL在DN节点执行时很有可能进行全表扫描而非预期的索引扫描。因此当in值较多时,我们会对in值进行切割,分批下发,执行流程如下图所示。

仍然以上述的例子为例,假设我们的CN节点只有两个核,假设每次下发的物理SQL中的in值不超过两个(当然实际中不会设置的这么小),那么我们会共计下发四条物理SQL,如下所示,其会被划分为两个批次,也就是说计算节点和数据节点需要有两次网络交互。试想一下,如果我们下发的物理SQL只有两条时,那么我们便可以在一个批次中完成所有物理SQL的下发,此时计算节点和数据节点只有一次网络交互。因此,当用户对于RT要求较高时,我们建议in值数量应当较少,以保证其涉及的分片数不超过CPU核数且每个分片只会下发一条物理SQL。

//第一次下发了两条物理sql
分片1 物理sql-1: select * from order_01 where order_id in (1, 5);
分片2 物理sql: select * from order_02 where order_id in (2);
//第二次下发了两条物理sql
分片1 物理sql-2: select * from order_01 where order_id in (9);
分片4 物理sql: select * from order_04 where order_id in (4);

in值数量不固定带来的挑战

为了加速SQL的执行,我们会对参数化SQL的执行计划进行缓存,而业务代码中的in值数量有时并不相同,这会使得执行计划的缓存空间可能会被仅是in值数量不同的SQL占满,导致其他SQL的执行计划失效。解决这个问题的思路也比较简单,我们会用一个问号来替代in的列表,从而避免上述情况的发生。

测试

我们在规格为2×16C64G的节点上,针对一张分表数为64,分表记录数为百万的表在不同in值数量、不同并发下进行了测试,分区方式为哈希分区,测试结果如下。

测试场景1-1

不同并发,不同in值数量,开启IN查询动态裁剪能力,查看RT变化。

测试场景1-2

不同并发,不同in值数量,关闭IN查询动态裁剪能力,查看RT变化。

测试场景2-1

不同并发,不同in值数量,开启IN查询动态裁剪能力,查看吞吐变化。

测试场景2-2

不同并发,不同in值数量,关闭IN查询动态裁剪能力,查看吞吐变化。

测试结论

● 开启IN查询的动态裁剪能力后,吞吐和RT都有明显的改善。
● 对于RT比较敏感的客户,建议in值数量不要取的太多。

总结

本篇首先介绍了in查询的一个经典应用场景,接着分析了分布式数据库中执行in查询sql时naive的执行方式,其执行效率非常低下。为了提高执行效率,我们进行了分区裁剪与in值裁剪。进一步地,考虑到物理SQL中的in值太多会使得存储节点在执行物理SQL时有更大的可能进行全表扫描而非预期的索引扫描,因此当一个分片涉及的in值较多时,我们会将in值进行分割,分批次下发in查询。为了防止并发量过大给系统带来巨大的压力,下发物理SQL的默认并发度为机器CPU核数。此外,我们还针对in值数量不同可能导致计划缓存失效的问题进行了优化。最后,我们测试了打开与关闭in查询动态裁剪的情况下,吞吐量与延迟的变化,测试结果表明开启IN查询的动态裁剪能力后,吞吐和RT都有明显的改善。此外,我们建议对于RT比较敏感的客户,in值数量不要取的太多。

作者:越寒

原文链接

本文为阿里云原创内容,未经允许不得转载。

  • 0
    点赞
  • 0
    收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值