высчитывать удалить принимает навсегда

Question

Я пытаюсь удалить данные из Neo4j, используя следующий запрос:

MATCH (c:Customer {customerID: '16af89a6-832b-4bef-b026-eafea3873d69'}) 
MATCH (c)<-[r:DEPT_OF]-(dept:Dept)-[*]-(n2) WITH r, dept, n2 LIMIT 10 
DETACH DELETE r, dept, n2; 

Это утверждение принимает навсегда и не удаляя ничего, когда я проверить узел DEPT, например. Здесь что-то не хватает?

Answer 1

Вы иметь переменную длину пути без указания верхней границы в этой строке:

MATCH (c)<-[r:DEPT_OF]-(dept:Dept)-[*]-(n2) WITH r, dept, n2 LIMIT 10 

Это приведет много прохождений. Позволяет ли ваша модель данных определять верхнюю границу числа переходов в соответствии с n2. Кроме того, вы должны указать ярлык или метки для n2.

Кроме того, вам не нужно включать r в инструкцию DETACH DELETE. Любые существующие отношения удаляемого узла также будут удалены при использовании DETACH DELETE.

Редактировать

Шаблон (dept:Dept)-[*]-(n2) указует на двунаправленный пути любой длины (без верхнего предела). Чтобы указать верхнюю границу пути переменной длины, просто замените фигуру (dept:Dept)-[*]-(n2) рисунком (dept:Dept)-[*1..3]-(n2). Это ограничит длину путей, пройденных до трех отношений между (dept:Dept) и (n2) (хотя это может быть неприемлемо для вашей модели данных). Также было бы хорошо, чтобы добавить метки и направление отношения к образцу (подходит для вашей модели данных), что-то вроде:

MATCH (c)<-[r:DEPT_OF]-(dept:Dept)<-[:BELONGS_TO*1..2]-(n2:Product) WITH r, dept, n2 LIMIT 10 

Answer 2

Есть много различных вопросов в запросе. Вот тот, который я определил.

1. число путей обнаруживаемых с помощью запроса с переменной длиной пути (предположим, нижняя граница равна 0 или 1) примерно экспоненциально зависит от максимальной длины пути. То есть, если каждый соответствующий узел имеет отношения M и поиск максимальной глубины (или, если нет верхней границы, максимально возможная глубина) составляет N, то в худшем случае количество возможных путей равно (M^N). Например, если мы подключаем 5 и 10 для M и N, мы получаем 9,765,625 возможных путей (и столько же узлов и связей, которые нужно удалить). Вероятно, это основная причина, по которой ваш запрос занимает много времени.

2. Второй серьезной проблемой будет полный сбой запроса из-за нехватки памяти в двигателе neo4j из-за потенциально огромного объема данных, которые должны быть в памяти. Вы, видимо, еще не сталкивались с этим, но можете. Вы можете попытаться свести к минимуму количество найденных путей, используя только соответствующие полные пути (то есть пути, в которых последний узел не имеет другого узла для подключения). Я не знаю вашу модель данных, поэтому я не могу показать вам предложение Cypher, чтобы сделать это для ваших данных. Но если вы это сделаете, ваш запрос нужно будет изменить, чтобы использовать все узлы в найденных путях, а не только конечные узлы пути.

3. Второго MATCH положение будет соответствовать только dept узлам, которые имеют, по меньшей мере, одну связи, кроме r, потому что по умолчанию нижней границы для пути переменной длиной является длиной 1.Поэтому этот запрос не удалит узлы dept, у которых нет других отношений. Вы можете решить это, указав нижнюю границу 0, как в: [*0..].

4. У вас есть LIMIT 10 на вашем предложении WITH, поэтому ваш запрос только собирается попытаться удалить несколько dept и n2 узлов. Кроме того, поскольку вы не обязательно удаляете полные пути, вы можете получить «отключенные подграфы», которые больше не связаны ни с чем другим. Итак, вы должны удалить пункт LIMIT, хотя это сделает ваш запрос еще длиннее.

5. Теоретически возможно (но я не знаю вашу модель данных) для n2 будет таким же, как c. Если ваши данные позволяют это сделать, но вы никогда не захотите, чтобы ваш запрос удалял c, вам необходимо добавить предложение WHERE сразу после соответствующего предложения MATCH, чтобы предотвратить это (см. Ниже).

6. Поскольку пункт MATCH отфильтровывает любые матчи, где же связь используется дважды, ваш второй MATCH положение фактически делает дополнительную работу, чтобы гарантировать, что ни один из отношений в каждой переменной длины пути соответствует r. Поскольку ваш прецедент не нуждается в этой проверке (после исправления пункта 5), вы можете избежать этой ненужной проверки, разделив второе предложение MATCH так, чтобы r соответствовал его собственному предложению.

Вот пример исправления для пунктов 3, 4, 5, 6:

MATCH (c:Customer {customerID: '16af89a6-832b-4bef-b026-eafea3873d69'}) 
MATCH (c)<-[r:DEPT_OF]-(dept:Dept) 
MATCH (dept)-[*0..]-(n2) 
WHERE n2 <> c 
DETACH DELETE dept, n2; 

Но, так как выше не решает пунктов 1 или 2, ваш запрос еще может занять очень долгое время время и/или сбой. Если вы предоставите более полное представление о своей модели данных, мы, возможно, сможем решить пункт 2. Однако элемент 1 является основной проблемой и может потребовать переосмысления вашей модели данных или, возможно, разделения удаления на несколько запросов.