Разница в производительности при использовании вершин и ребер VS Joins в ArangoDB - PullRequest
Новая
       12

Разница в производительности при использовании вершин и ребер VS Joins в ArangoDB

0 голосов
/ 30 декабря 2018

Ниже приведено несколько подробностей.

Запрос 1 : также с использованием присоединенного плана выполнения Graph Traversal.

Здесь я использую грань между CollectionA и CollectionB.

Строка запроса: 

for u in CollectionA filter u.FilterA == @opId and u.FilterB >= @startTimeInLong and u.FilterB <= @endTimeInLong 
for v in 1..1 OUTBOUND u CollectionALinksCollectionB
filter 
v.FilterC == null return v

Execution plan:

     Id   NodeType           Est.   Comment
      1   SingletonNode         1   * ROOT
      9   IndexNode         45088     - FOR u IN CollectionA   /* skiplist index scan */
      5   TraversalNode         1       - FOR v  /* vertex */ IN 1..1  /* min..maxPathDepth */ OUTBOUND u /* startnode */  CollectionALinksCollectionB
      6   CalculationNode       1       - LET #6 = (v.`ReceivedRating` == null)   /* simple expression */
      7   FilterNode            1       - FILTER #6
      8   ReturnNode            1       - RETURN v

    Indexes used:
     By   Type       Collection                    Unique   Sparse   Selectivity   Fields                                Ranges
      9   skiplist   CollectionA                  false    false       100.00 %   [ `FilterA`, `FilterB` ]   ((u.`FilterA` == "8277") && (u.`FilterB` >= 1526947200000) && (u.`FilterB` <= 1541030400000))
      5   edge       CollectionALinksCollectionB   false    false       100.00 %   [ `_from` ]                           base OUTBOUND

    Traversals on graphs:
     Id   Depth   Vertex collections   Edge collections              Options                                   Filter conditions
      5   1..1                         CollectionALinksCollectionB   uniqueVertices: none, uniqueEdges: path   

    Optimization rules applied:
     Id   RuleName
      1   use-indexes
      2   remove-filter-covered-by-index
      3   remove-unnecessary-calculations-2

Запрос 2: 

         Query string:
          for u in CollectionA filter u.FilterA == @opId and u.FilterB >= @startTimeInLong and 
          u.FilterB <= @endTimeInLong 
           for v in CollectionB
          filter 
          v._key==u._key and
          v.FilterC == null return v
Execution plan:

     Id   NodeType           Est.   Comment
      1   SingletonNode         1   * ROOT
      8   CalculationNode       1     - LET #6 = CollectionB   /* all collection documents */   /* v8 expression */
     11   IndexNode         45088     - FOR u IN CollectionA   /* skiplist index scan */
     10   IndexNode         45088       - FOR v IN CollectionB   /* primary index scan, scan only */
     12   CalculationNode   45088         - LET #4 = (CollectionB   /* all collection documents */.`FilterC` == null)   /* v8 expression */
      7   FilterNode        45088         - FILTER #4
      9   ReturnNode        45088         - RETURN #6

    Indexes used:
     By   Type       Collection       Unique   Sparse   Selectivity   Fields                                Ranges
     11   skiplist   CollectionA     false    false       100.00 %   [ `FilterA`, `FilterB` ]   ((u.`FilterA` == "8277") && (u.`FilterB` >= 1526947200000) && (u.`FilterB` <= 1541030400000))
     10   primary    CollectionB   true     false       100.00 %   [ `_key` ]                            (CollectionB.`_key` == u.`_key`)

    Optimization rules applied:
     Id   RuleName
      1   move-calculations-up
      2   use-indexes
      3   remove-filter-covered-by-index
      4   remove-unnecessary-calculations-2

Как Query 1 работает лучше, чем Query 2Кроме того, результат запроса почти аналогичен для меньшего набора данных, но Query 1 работает лучше с большими данными.

Может кто-нибудь подробно объяснить мне, как здесь помогает обход графика

...