Исследование графика: влияет ли выбор использования входящих или исходящих ребер на производительность?

В течение некоторого времени я возился с графиками, с целью использования соответствующих частей стека на стороне сервера. Я использовал Scala-Graph и Neo4J, и я изучаю Spark GraphX. Практически во всех приложениях, которые я реализовал, была модель графа свойств (Node -> Edge -> Node, с атрибутами).

При разработке графика (точнее, групп DAG), если я обнаружу сильную и направленную связь между двумя узлами, я установлю ребро от одного узла к одному узлу. Это очевидно и интуитивно понятно. Если человеку нравится сайт, его связывает преимущество со свойством "лайки". Таким образом:


[Нирмаля] - (Нравится) -> [StackOverFlow]

[Джон] - (Нравится) -> [StackOverFlow]

[Тед] - (Нравится) -> [GoogleGroups]

[Нирмаля] - (Нравится) -> [Neo4J]


Теперь, используя исходящие края, я могу легко узнать, какие сайты нравятся Нирмаля.

Но когда я хочу выяснить, кому еще нравится то , что любит Нирмаля (например, Джон), я склонен думать, что я должен создать ребро от узла типа сайта к узлу типа лица (со свойством isLikedBy), поэтому что путь очевиден, а обход интуитивен. Каждый человек и сайт должны быть связаны в обоих направлениях, чтобы я мог связаться с другим с любого из них, чтобы ответить на вопросы, подобные этому.


[Нирмаля] - (Нравится) -> [StackOverFlow] - (IsLikedBy) -> [Джон]


Но из многих примеров, приведенных экспертами, я вижу, что это не предписано. Вместо этого это достигается за счет использования таких операторов, как входящие. Другими словами, если между двумя узлами установлено ребро, мне не нужно явно указывать оба направления ребра (достаточно просто "лайки", излишне "isLikedBy"). Реализация матрицы смежности делает это возможным, возможно, но я немного запутался, потому что мне позволяют выводить противоположное направление, даже когда это направление не указано в DAG.

Мой вопрос, где пробел в моем понимании? Это то, что направление IsLikedBy в идеале должно присутствовать, но мы оптимизируем? В качестве альтернативы, могут ли быть случаи использования, когда такие двунаправленные ребра необходимы, и мне нужно их обнаружить? Я полностью пропускаю теоретическое обоснование?

Я буду рад стать мудрее.

1 ответ

Решение

Я думаю, что это зависит от программного обеспечения. Я могу говорить за Neo4j, но не за другие инструменты, которые вы упомянули;)

В Neo4j отношения разработаны для прохождения как вперед, так и назад без снижения производительности. Это относится как к обходу в API Java, так и к использованию Cypher. Вы можете запросить как указание направления входящего / исходящего трафика, так и запрос отношений, не заботясь о направлении, и это также должны быть те же характеристики производительности.

Другие вопросы по тегам