ArangoDB-IN運算符非常慢

Question

我在ArangoDB中使用IN運算符時遇到一些性能問題。

簡而言之，我有一個來自拆分函數的計算（運行時）id數組，我只想獲取Collection的選定元素，然后收集或過濾其他數據。

在這里您可以找到AQL查詢 ：

LET toInclude = SPLIT('Collection/1,Collection/2,Collection/3', ',')

FOR result IN Collection
  FILTER result._id IN toInclude  
  COLLECT property = result.property 
  WITH COUNT INTO count
return  {property, count}

數組toInclude的元素可以是300000+，查詢可以花費10分鍾以上來完成工作。

該split -函數結束在3秒時， property字段建立索引，所以這個問題是在IN操作符。

我該怎么做才能解決此演出問題？

非常感謝你！

丹尼爾

Answer 1

我嘗試對包含100,000個文檔的toInclude 500,000個字符串條目進行查詢。

確實需要很長時間才能完成2.7。 執行時間約為4xx秒。 該查詢花費大量時間IN此處評估FILTER的IN運算符。 實際上，將為找到的每個文檔評估FILTER條件。 這將與我使用的數據進行大約100,000 x 500,000 / 2比較。

在2.8中，使用相同的數據進行相同的查詢大約需要2.7秒，因此該問題似乎沒有發生。 2.8中有很多優化程序更改，而導致加速的原因是IN表達式將直接在索引中求值。 FILTER將在那里進行優化。

因此，一種解決方案是在ArangoDB 2.8可用時使用它（當前它在beta中）。

另一個解決方法是改進優化程序，以檢測IN的右側在查詢中是const，以便它可以對結果進行排序，並可以使用二分查找（對數而不是線性復雜度）進行IN 。 但這還不可用。

2.7的解決方法是單獨計算IN列表，並將其作為數組插入查詢中。 這樣， IN列表將是一個常量值，優化器將能夠對其進行預排序，以便可以使用二進制搜索。 但是，這要求在原始查詢之前/之前執行SPLIT操作。

更新 ：在2.8中，現在存在一個附加的優化器規則，可以針對上述情況和其他情況對IN列表值進行預排序。 這使IN運算符可以使用二進制搜索，它具有對數復雜度，而不是某些情況下的線性復雜度。 此更改將包含在2.8 beta2中。