ArangoDB vollständige Sammlung Scan und JOIN

Question

wenn ich versuche, mit nur einem Filter, wie dies eine innere Verknüpfung in ArangoDB auszuführen:

FOR doc1 in catalogue 
FOR doc2 in RepoNodes 
FOR doc3 in RepoEdges 
FOR doc4 in RepoNodes 
    FOR doc5 in RepoEdges 
      FOR doc6 in RepoNodes 
      FOR doc10 in catalogue 
      FOR doc11 in similarities 
       FOR doc12 in clearance 

FILTER doc1.trackid== "TRAAAAK128F9318786" AND doc1.trackid==doc2.mongodbsongs 
AND doc3._from==doc2._id AND doc3._to ==doc4._id AND doc5._from==doc4._id and doc6._id ==doc5._to 
AND doc10.trackid== doc6.mongodbsongs 
AND doc11._from==CONCAT("Tracks/",doc6.neo4jSong) 
AND doc6.redisclearance== doc12._key 
     return {doc10,doc11,doc12} 

i feststellen, dass Indizes werden ignoriert .. ich meine .. Es führt eine vollständige Sammelscan wenn ich die gleiche Abfrage serialisieren, funktioniert es perfekt. Ich verstehe nicht, warum .. Wenn ich vor den letzten 4 aufhören, denn es ist in Ordnung .. wo ist das Problem? Warum wird ein vollständiger Sammlungsscan benötigt?

Answer 1

In der letzten Abfrage (die keine Indizes verwendet) führt der Abfrageoptimierer eine Funktion aus, die die FOR-Schleifen in der Abfrage verschiebt. Es wird versuchen, alle möglichen Permutationen von FOR-Schleifen zu erstellen, die die Bedeutung der Abfrage nicht ändern.

In der letzteren Abfrage kann der Optimierer sich frei in einer der 9 FOR-Schleifen bewegen, da zwischen ihnen keine FILTER-Anweisungen liegen, die problematisch sein könnten. Hier beginnt der Optimierer mit der Erstellung von neuen Ausführungsplänen mit herumgedrehten FOR-Schleifen. Dies könnte 9 schaffen! (faculty, d. h. 362880) unterschiedliche Ausführungspläne, aber standardmäßig stoppt der Optimierer bei 192 Plänen, um diese kombinatorische Explosion zu vermeiden. Und wenn diese Anzahl von Plan erreicht ist, wird der Optimierer keine weiteren Optimierungen mehr anwenden, um die gesamte Laufzeit der Optimierung zu begrenzen.

Das ist der Grund, warum in der zweiten Abfrage die EnumerateCollectionNode s umgewandelt werden nicht in IndexNode s. Der Optimierer wurde vor diesem Schritt gestoppt, da es bereits so viele Ausführungspläne gibt.

In der ersten Abfrage ist der Optimierer nicht so frei, um die FOR-Schleifen zu verschieben, da die FILTER-Anweisungen einige der Bewegungen einschränken. Aus diesem Grund wird es nicht so viele Ausführungspläne generieren und nicht vorzeitig aufhören zu optimieren.

Release 3.0.2 enthält eine Lösung dafür. Eine vorübergehende Problemumgehung davor besteht darin, die eine FILTER-Anweisung in der zweiten Abfrage in mehrere kleinere FILTER-Anweisungen aufzuteilen und sie in die Nähe ihrer jeweiligen FOR-Schleifen zu verschieben.