爲什麼鑽取連接查詢未針對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進行完全優化？

回答

相關問題