微课程 | 第七课《不同拆分规则的表》

雨燕双飞 提交于 2019-12-09 17:08:48

https://v.youku.com/v_show/id_XNDQ2MzQ0NTA5Mg==.html

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

现在我有四个节点,四个节点是按照求模拆分的,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

https://v.youku.com/v_show/id_XNDQ2MzQ0NzM3Mg==.html

这里面我会有三个例子 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 上,是一个比较有效的一个做法,这是我们展示的不同拆分规则的表。

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

图文稿为了方便阅读,在不影响学习的情况下优化了一些口语化词汇,文稿与视频会尽量保持一致。

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!