上一期我们介绍了 ER 表的第一种实现方式,第二种其实不用配置 child_table 也可以实现 ER 表。

如图,有这样的 6 张表 tableA-F。这些表我设置了拆分列、分布节点和拆分算法。

把它们分为三组,可以看到表格最后一列的分组号为 1 的,它们的分布节点以及拆分算法完全一样时,这三张表其实可以互为 ER。因为拆分列在将来做 JOIN 的时候是要用作 ON 的条件。但只要规则分布相同,他们之间可以互为 ER。

另外几张表,一个是算法一样但分布节点是反的,另外一种是算法就不一样。这就没法做为 ER 表关联了,这样配置更灵活,不需要去配置 child_table,但会有一些限制。

我们来看这样一个配置。

这两张表除了表名,其他基本一样,是互为 ER 的关系。

接下来,看一下演示操作。

首先看下表数据,再看一下 JOIN 的结果,结果正确。

我们再去看一下 EXPLAIN 查询计划,同样有四行结果。前两行表示整体的 JOIN 下发给 MySQL,第三行表示合并,第四行做 shuffle_field 就是转发,这是现在我们很熟悉了。

我现在把关联关系改一下,它又回到我们普通的一个流程。把数据收集上来,然后做中间件,再做跨库查询。那么当你不知道 DBLE 内部怎么处理 SQL 的时候,可以 EXPLAIN。

比如你的期望是使用 ER 表或者使用 Global 表,但实际有没有用到呢?可以通过 MySQL 追加 general log 来判断。当然通过 DBLE 查询计划里面来判断也挺方便的。他会把 SQL 如何下发,下发到哪里的一个结果展示出来。

这就是我们另外一种 ER 表的实现方式。

除了有我们的 ER 表、Global 表之外,DBLE 还拥有一些其他的功能。比如我们提到过的关联子查询。有一些逻辑可以整体下发到 MySQL 节点,但是 DBLE 语法不支持,怎么办我们下次介绍。

好,我们今天先介绍到这里。
图文稿为了方便阅读,在不影响学习的情况下优化了一些口语化词汇,文稿与视频会尽量保持一致。

DBLE 及相关项目代码地址:

https://github.com/actiontech/dble

https://github.com/actiontech/dble-docs-cn

https://github.com/actiontech/dble-test-suite

课程咨询:

  • 「爱可生开源社区」微信公众号:ActiontechOSS

  • 「爱可生开源社区」官方技术交流群(669663113)