Я все еще пытаюсь использовать neo4j для выполнения сложного запроса (аналогично поиску по кратчайшему пути, за исключением того, что к этому поиску применяются очень странные условия, такие как минимальная длина пути с точки зрения числа пройденных узлов).
Мой набор данных содержит около 2,5 млн. Узлов одного типа и около 1,5 млрд. Ребер (также одного типа).Каждый данный узел имеет в среднем 1000 направленного отношения к «следующему» узлу.
Тем не менее, у меня есть запрос, который позволяет мне получить этот кратчайший путь, учитывая все мои условия, но единственный способ, которым я нашел приличныйВремя отклика (менее одной секунды) фактически ограничивает число результатов после каждого нового узла, добавленного к пути, фильтрует его, упорядочивает его и затем следует к следующему узлу (это своего рода жадный алгоритм, я полагаю).
Я бы хотел ограничить их намного меньше, чем я, чтобы в результате получить больший путь, но проблема заключается в экспоненциальной сложности этого поиска, которая делает переход от LIMIT 40 до LIMIT 60 обычновопрос х10 ~ х100 времени обработки.
При этом я все еще оцениваю несколько решений для увеличения скорости запроса, но я совершенно не уверен в результате, который они дадут, так как я не уверен, как neo4j действительно хранит мои данные внутри.
Решение, о котором я пока думаю, состоит в том, чтобы добавить в мои отношения свойство, которое будет целым числом от 1 до 15, потому что я обычно запрашиваю только отношения, которые имеют одно или два максимальных различных значения для этого свойства.,(например, только отношения, которые имеют это свойство для 8 или 9).
Как я могу догадаться, для каждого отношения neo4j затем должен собрать исходные свойства узла и использовать его для применения моих дальнейших фильтров, которыезанимает очень много времени при пересечении длинного пути из 4 узлов с 1000 взаимосвязями в каждом (я думаю, O (1000 ^ 4)).Я прав?
Со свойствами отношений будет ли он иметь прямой доступ к нему без дальнейшей выборки данных?Есть ли шанс, что это сделает мои запросы быстрее?Как хранятся свойства ребер neo4j?
ОБНОВЛЕНИЕ
Следуя совету @logisima, я написал процедуру непосредственно с помощью API обхода Java neo4j.Затем я переключился на необработанный API-интерфейс Java-процедуры Neo4J, чтобы использовать еще больше мощности и гибкости, как того требовал мой сценарий использования.
Результаты действительно хорошие: сложность нижней границы в целом немного меньше, чем была раньше, но верхняя граница примерно в десять раз быстрее, и когда хотя бы некоторые из узлов, которые будут использоваться для обхода,в кеше Neo4j производительность просто поразительна (глубина 20 менее чем за секунду для одного из моих тестов, когда мне нужна только глубина 4).
Но это еще не все.Процедуры делают его очень легко настраиваемым, сохраняя при этом производительность в лучшем виде и оптимизируя каждую операцию в лучшем виде.В результате я могу использовать гораздо более мощные фильтры за гораздо меньшее время и легко обновлять свою процедуру, добавляя новые функции.И последнее, но не менее важное: процедуры очень легко подключаются к Spring-данным для neo4j (которые я использую для подключения neo4j к моему HTTP API).Где, как и в случае с cypher, мне пришлось бы автоматически генерировать запросы (поскольку они были очень сложными, было около 30 java-классов для правильного выполнения задачи), и я должен был использовать jdbc для neo4j, обрабатывая отдельный пул соединений только для этого запроса.Не могу порекомендовать больше использовать потрясающий java API neo4j.
Еще раз спасибо @ logisima