Поиск конкретного пути в Neo4j Быстро

Question

У меня recently asked about how to find all paths between two types os nodes in a way where all the edges in the path had the same attribute (как у того же ID). Это было бы что-то вроде:

MATCH (a {type: 'cin1'})-[rels:Next*1.. {value: 1}]->(b {type: 'cancer'}) 
RETURN (a), (b) 

, где вместо того, чтобы иметь значение: 1 я бы значение: то же для всех ребер.

я нашел способ решить эту проблему, используя что-то вроде этого (так ответили на мой другой вопрос):

MATCH (a:Label {type: 'cin1'}) 
MATCH (b:Label {type: 'cancer'}) 
MATCH shortestPath((a)-[rels:Next*1..20]->(b)) 
WHERE ALL(r in tail(rels) WHERE (head(rels)).value = r.value) 
RETURN (a), (b) 

Проблема у меня в том, что этот подход сначала создать все возможные различные пути к затем отфильтруйте их, что в моем случае создает экспоненциально много путей. Возьмем, например, следующий график

:

Подход данное будет первым соответствовать всем пути:

id:1 -> id:1 -> id:1 
id:1 -> id:2 -> id:1 
id:1 -> id:1 -> id:2 
id:1 -> id:2 -> id:2 
id:1 -> id:2 -> id:3 
... 

И только затем отфильтровать эти параметры, чтобы вернуть 1-> 1-> 1, 2-> 2-> 2, 3-> 3-> 3 и так далее. Поэтому оказывается, что этот подход очень неэффективен, и мне интересно, есть ли более простой способ.

Answer 1

Что касается оптимизации, я бы сначала рассмотрел способы оптимизации быстрых совпадений на стартовых и конечных узлах, так как это должно значительно сократить сканируемые узлы.

Моя догадка заключается в том, что вы, вероятно, не индексируете: Label.type, и если это ваше основное средство для сопоставления с узлами, это, вероятно, что-то для рассмотрения и тестирования.

Также может быть полезно увидеть, можете ли вы добавлять метки на начальном или конечном узлах. По крайней мере, похоже: Рак может быть применен эффективно, хотя, если это предназначено для более общего медицинского приложения, такой запрос должен быть эффективным для многих заболеваний, поэтому я не уверен, что это возможно для вы.

В этом случае я считаю, что лучше всего оптимизировать shortestPath() и PROFILE ваш запрос, чтобы гарантировать, что ваше предложение WHERE ALL используется при расчете shortestPath, а не как фильтр после исчерпывающих поисков (см. Shortest Path и Shortest Path Planning). Если профилирование показывает, что оно используется в качестве фильтра, а не при построении кратчайшего пути, вам нужно будет увидеть, можете ли вы выбрать более эффективный кратчайший путь предиката, который быстро не удастся для несоответствующих шаблонов.