Каков оптимальный метод изоляции несвязанных наборов данных в neo4j?

Я использую neo4j для хранения временных наборов данных из разных исходных систем. Мои данные состоят из нескольких родительских объектов, каждый из которых содержит ~ 4-7 слоев дочерних объектов разных типов. Общее количество объектов в наборе данных варьируется от 2000 до 1,5 миллиона. Я использую библиотеку python py2neo, которая показала хорошую производительность как на этапе создания данных, так и при передаче шифровальных запросов для отчетов.

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

  1. Проще всего реализовать (для моего кода) объект «проект» верхнего уровня. Этот объект проекта будет иметь несколько прямых дочерних элементов (через отношения) и много косвенных дочерних элементов. Я беспокоюсь, что когда я хочу отфильтровать по проекту, мне придется использовать подстановочный знак отношения MATCH (pr:project)<-[:IN_PROJECT*7]-(c:child_object) Distance, что кажется очень дорогим с точки зрения запросов.

  2. Я также мог бы установить прямую связь между объектом проекта и любым другим объектом в проекте. MATCH (pr:project)<-[:IN_PROJECT]-(c:child_object)Это должно быть проще для написания запросов, но я не знаю, что может произойти, когда у меня есть один объект с потенциальными миллионами связей.

  3. Наконец, я могу установить свойство project-id для каждого отдельного объекта в наборе данных. MATCH (c:child_object {project-id:"A1B2C3"}) Это кажется расточительным решением, но я думаю, что это может быть лучше с точки зрения производительности в модели графовой БД.

Извините, если я исказил пример запросов Cypher/терминологию neo4j. Я отложил этот проект на 6 недель, и я немного заржавел.


python neo4j py2neo
person scottwed    schedule 13.11.2017    source источник
comment
Как ни странно, проходило третье собрание разработчиков openCypher, OCIM3. сегодня во Франции. Основной темой мероприятия была обработка множественных графиков, что даст хороший способ справиться с этой проблемой. До тех пор вы застряли с обходными путями. Я добавлю свой предпочтительный способ через минуту.   -  person Gabor Szarnyas    schedule 13.11.2017

Ответы (1)


arrow_upward
1
arrow_downward

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

MATCH (c:child_object:DataSourceA)

Ярлыки всегда индексируются, поэтому производительность должна быть лучше, чем у ваших предложений 1-3. Я также думаю, что это более элегантное решение, однако оно будет сложным, если вы заранее не знаете количество наборов данных. В последнем случае вы можете использовать что-то вроде

MATCH (c:child_object)
WHERE 'DataSourceA' IN labels(c)

Но это больше похоже на «полное сканирование таблицы», поэтому с точки зрения производительности вам лучше использовать ваш подход 3 и построить индекс на project-id.

person Gabor Szarnyas    schedule 13.11.2017
comment
Это интересно. Я забыл, что разрешены несколько меток, так как у меня не было соответствующего варианта использования, когда я впервые начал изучать neo4j. Я должен увидеть, сколько хлопот было бы обнаружить эти неизвестные метки во время выполнения. Возможно, дать им одинаковый префикс, чтобы я мог их идентифицировать? Нужно посмотреть, насколько дружелюбным будет py2neo и с несколькими метками. - person scottwed; 13.11.2017
comment
Ну, метки легко обнаружить: запрос MATCH (n) UNWIND labels(n) AS label RETURN DISTINCT label должен помочь. - person Gabor Szarnyas; 13.11.2017
comment
После некоторых экспериментов я думаю, что буду использовать метод свойств (#3). Я понял, что мне также нужно фильтровать свои отношения, и когда я выполняю специальные запросы в базовом веб-интерфейсе neo, просмотр свойства всех возвращаемых объектов и отношений немного упрощает устранение неполадок в моем коде. - person scottwed; 14.11.2017
comment
Я согласен с тем, что веб-интерфейс не очень хорошо обрабатывает несколько ярлыков. Один трюк, который я использовал, чтобы обойти это, состоит в том, чтобы изменить другой размер, чтобы представить источник данных и цвета, чтобы представить метку, определяющую тип узла. - person Gabor Szarnyas; 14.11.2017