Большое количество типов отношений в запросе cypher

Question

Я прототипирую схему авторизации/защиты данных в Neo4j, и я столкнулся с странной проблемой с одним из моих запросов. Для фона концепция заключается в том, что пользователь, пытающийся получить от a, может быть, если у них есть правильный идентификатор доступа. Итак, наши ребра имеют типы, в которых есть идентификаторы доступа. Я тестирую эту схему, создавая множество узлов и соединяя их пары с разными доступами. То есть, у меня есть множество наборов:

(a)-[:ACCESS_A]->(b) 

С разными доступами. Я запрашиваю для них:

{some query} with a match (a)-[:ACCESS_A|:ACCESS_B|<...>|:ACCESS_Z]->(b) return b 

где размер списка в матче края растет с числом обращается пользователь.

Все это прекрасно работает, пока список не получит доступ к 201 году. На этом этапе в профиле показаны удары db и время, проведенное WAY up. В 200 типах отношений профиль показывает 1051 дБ, но 201 тип отношений показывает 31801. Это 30-кратное увеличение для еще одного типа! Время увеличивается аналогичным образом. переход от 199 до 200 только поднимается примерно на 50 ударов, и это связано с увеличением числа узлов.

После завершения работы, похоже, что круглый номер 200 - это больше красная селедка, чем проблема. Раньше мои типы отношений составляли 4 символа. Когда я изменил их на 9 символов (добавив «EDGE_», в качестве теста), проблема началась в 50 типах - 50 имеет 36 обращений, а у 51 - 291 - меньший скачок, но значителен по сравнению с предыдущим увеличением в том же контрольная работа.

Похоже, что существует какое-то отношение имени отношения к тому месту, где запрос падает, но я все еще расследую.

Вещи, которые я проверил и не нашла, чтобы представлять интерес:

• длина всего запрос (размер строки): Это не может в совершенно разных размерах запросов с 4 и 9 типов отношений характера
• длина списка в [e: < ...>] (размер строки). Как указано выше, она не в очень разных размерах
• количества узлов или ребер в графе

Answer 1

Насколько мне известно, вы не должны быть запущены в вопросы производительности только 200 типов отношений.

До версии 3.0 количество типов отношений было ограничено 64k. Этот предел был удален с версией 3.0.

Answer 2

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