为什么钻取连接查询未针对MongoDB进行完全优化？

我正在研究概念证明以优化通过演练执行的连接查询的性能。底层存储是基于NO-SQL的数据库 - Mongo DB。返回连接查询结果所用的时间是46秒。经过进一步分析，根据查询的实际计划，观察到左侧（150万条记录）和右侧表（130万条）都被完全扫描，分别需要24秒和20秒。为什么钻取连接查询未针对MongoDB进行完全优化？

下面是该查询：

select ta.[SOME_COLUMN] 
from mongo.Test.TABLEA ta 
INNER JOIN mongo.Test.TABLEB ta ON ta.Id = tb.Id and ta.Id ='123'

记录表A：150万条
记录在表B：130万

筛选条件：身份证是两个表中的索引字段（升序）

钻计划显示正在执行的哈希联接：

为什么钻获取所有记录到内存中，即使是对一个表提供索引列上的筛选条件？在mongo级别，我观察到收集扫描是用索引扫描来完成的，这可能是由什么原因造成的？（因为我的加入&过滤器条件应用于索引列）
如果钻取计划程序/优化程序足够智能，则记录可能已根据连接条件在第二个表上过滤（以减少数据集，因此导致更快的执行时间）。是否MongoDB存储插件没有完全优化，这是造成这种情况？

来源

2016-11-04 Mridul Chopra

也许是因为MongoDB没有连接？即使它是$ lookup汇总函数仍然完全是这样 – Sammaye

确实，mongoDB没有加入。但是Drill通过将连接分解为从组成表扫描并进行HashJoin来提供该功能。但它没有以有效的方式进行扫描。所有的过滤，投影，排序等应该传递给mongoDB，因为它可以更有效地使用索引。 –

Drill的MongoDB存储插件不支持下推连接。它仅支持按下过滤器。

存储插件是负责与Drill支持的数据源通信的插件。

如果您愿意，您必须为下推连接提供自己的优化规则。这将需要Apache Calcite的经验，并编写一个新的存储插件来贡献这些规则。

我不知道是否有另一种方式来提供新的规则，除非有一个自定义插件。该插件不应该处理MongoDB，它只需提供必要的规则。

来源

2017-09-14 10:31:22

为什么钻取连接查询未针对MongoDB进行完全优化？

回答

相关问题