ArangoDB 전체 수거 검사와 내가 같이, 하나 개의 필터 ArangoDB에서 실행 내부에 가입 할 때

Question

가입 :

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} 

내가 인덱스가 무시되는 것을 알 수는 .. 내 말은 .. 그것은 전체를 실행 컬렉션 스캔. 동일한 쿼리를 직렬화하면 완벽하게 작동합니다. 이유를 모르겠다 .. 마지막 4 번 전에 멈추면 괜찮습니다. 어디에 문제가 있습니까? 전체 컬렉션 스캔이 필요한 이유는 무엇입니까?

Answer 1

n 후자의 쿼리 (인덱스를 사용하지 않는 쿼리)에서는 쿼리 최적화 프로그램이 쿼리에서 FOR 루프를 이동시키는 함수를 실행합니다. 쿼리의 의미를 변경하지 않는 FOR 루프의 가능한 모든 순열을 만들려고 시도합니다.

후자의 쿼리에서 문제가 될 수있는 FILTER 문이 없기 때문에 옵티마이 저는 9 개의 FOR 루프 중 하나를 자유롭게 이동할 수 있습니다. 여기서 옵티마이 저는 FOR 루프를 이동하여 새로운 실행 계획을 작성하기 시작할 것입니다. 이것은 9를 만들 수 있습니다! (교수, 즉 362880)의 다른 실행 계획이 있지만, 기본적으로 옵티 마이저는 조합 계획 폭발을 피하기 위해 192 개 계획에서 중단됩니다. 그리고 그 계획의 수에 도달하면 최적화 프로그램은 전체 최적화 런타임을 제한하기 위해 몇 가지 추가 최적화 적용을 중지합니다. 두 번째 쿼리에 EnumerateCollectionNode들 IndexNode들로 변환되지 않는 이유입니다

. 이미 많은 실행 계획이 있으므로 옵티마이 저는이 단계 전에 중지되었습니다.

첫 번째 쿼리에서 FILTER 문은 일부 동작을 제한하기 때문에 옵티마이 저는 FOR 루프를 자유롭게 이동할 수 없습니다. 이 때문에, 실행 계획이 많이 생성되지 않고 조기에 최적화가 중단되지 않습니다.

릴리스 3.0.2에는이 문제가 해결되었습니다. 그 이전의 임시 해결 방법은 두 번째 쿼리에있는 하나의 FILTER 문을 여러 개의 작은 FILTER 문으로 분할하고 해당 FOR 루프 근처로 이동시키는 것입니다.