两万条数据需要做个数据图_微课程 | 第七课不同拆分规则的表视频图文稿

最新推荐文章于 2024-07-20 17:29:37 发布

weixin_39929253

最新推荐文章于 2024-07-20 17:29:37 发布

阅读量69

点赞数

文章标签：两万条数据需要做个数据图

本文链接：https://blog.csdn.net/weixin_39929253/article/details/111297381

版权

上一期我们介绍了复杂查询功能，这期我们继续讲解不同拆分规则的表。

现在我有四个节点，四个节点是按照求模拆分的，tb_mod 上有这样 5 条数据。这边 6 7 打个括号，意思是如果有 6 7 的话将会是这样一个数据分布。然后通过 jump hash 算法拆分后是这样的，1 2 3 分布在 dn2 上，4 6 分布在 dn1 上。这时我要做一个 tb_mod 和 jump_hash 的 JOIN，如果直接把 JOIN 下发是不对的。看图可以知道，这样只有 dn2 的 1 和 dn1 的 4 能关联上，2 3 都会被都丢掉，所以我们来看一下跨库 JOIN。跨库 JOIN

这里面我会有三个例子 INNER JOIN，LEFT JOIN 和 RIGHT JOIN。因为 jump_hash 里面的 id 和 code 都是一样的，所以我这里面写的是 id。

我们来执行一下，看到 1 2 3 4 数据都已经出来了。LEFT JOIN 结果也对的，大家对 LEFT JOIN 也比较熟悉，左边在的数据右边没有也会查出来，RIGHT JOIN 也是一样的。我们来看看是怎么做的，我们前面加一个EXPLAIN，这是我们分布式查询计划。

分布式查询计划

因为我这个终端为了清晰，放的有点大，稍微有点乱，我们把这个查询结果简化 select * 改为只需要的列，把横向长度稍微缩小点。不然看起来是有点点累。我们再加一个 \G ，把这个表横过来看一下。

我们可以先看到有 12 行，从头来看，首先我们关注的是前面几行。然后我们发现前四行的内容是一样的，唯一不同的就是 datanode。前四行其他列都是一样的，代表我的查询下发给这四个结点。然后四个节点结果回来以后，在我的中间件进行合并和排序。排序原因这个我们待会再解释。然后会有列的整合和筛选，对于当前这个例子来说其实这个步骤没有实际的工作在做，只是转发给下一步而已。

然后接下来是对第二张表 jump hash 的，SQL 下发到两个节点。然后这两个节点回来以后也会做一个合并。我们可以看到 dn2 后面还有序号，这是为了和前面 dn1 dn2 区别。然后 shuffle field，最后才会去做一个 JOIN，JOIN 就是把刚才 merge shuffle_field 的结果集做一个合并。第三个shuffle field，这里其实仍然是一个转发的过程。最终我才能得到一个JOIN之后的结果。通过这样一个执行计划我们才能去理解跨库 JOIN。这个例子 JOIN 是完全在 dble 中间件去做的，所以两个节点来说收集和排序，收集好数据以后做合并做 JOIN。

排序的实现

现在给大家说一下为什么刚才会有排序。理论上我不做排序，我去各个数据节点上把数据拿回来。在中间件做 JOIN，其实是用我左边的每一行数据去匹配右表的每一行数据，也就是做个笛卡尔积。如果我在中间件中各个节点做了排序，大家可以想象。比如我们刚才例子一个表是 12345，另一个是 12346，做 JOIN 时候，如果我是一个有序的，他是不需要笛卡尔积的。它只要比较队头部就可以了，队头的意思就是第一列比较。这 1 和 1 比较，匹配上了，接下来 1 和 2 比较，发现匹配不上。由于表数据是有序的，所以一旦匹配不上以后就再也匹配不上了，所以左边的 1 也就出局了。

所以我们通过这样一个优化，我们可以把时间复杂度。在中间件的时间复杂度从笛卡尔积做到两个表的数据行数和乘以 2，这样的复杂度会比笛卡尔积小很多。当然相应带来的消耗就是 MySQL 的消耗。原来不需要排序，现在需要排序了。对我们来说可能认为中间件尽量做少的计算，把计算下发到 MySQL 上，是一个比较有效的一个做法，这是我们展示的不同拆分规则的表。

好，我们今天先介绍到这里。