我一直在修补Graphs，目标是使用它们实现适当的部分服务器端堆栈。我使用过Scala-Graph和Neo4J，我正在学习Spark GraphX。在我实现的几乎所有应用程序中，模型都是属性图（Node - ＆gt; Edge - ＆gt; Node，带有属性）。
在设计图形时（DAG是精确的），如果我发现两个节点之间的强大且有针对性的关系，我设置从一个节点到一个节点的边缘。这显而易见且直观。如果一个人喜欢一个网站，那么一个有财产的边缘会喜欢＆＃39;连接他们。因此：
[Nirmalya] - （喜欢） - ＆gt; [计算器]
[约翰] - （喜欢） - ＆gt; [计算器]
[泰德] - （喜欢） - ＆gt; [GoogleGroups]
[Nirmalya] - （喜欢） - ＆gt; [Neo4j的]
现在，使用传出边缘，我可以轻松找到Nirmalya 喜欢的网站。
但是，当我想找出其他人喜欢 Nirmalya喜欢的东西（即John）时，我倾向于认为我应该创建从Site-type Node到Person-type Node的边缘（也有属性＆＃39; isLikedBy＆＃39;），因此路径很明显，遍历很直观。每个人和站点必须在两个方向上连接，以便我可以从任何一个回答另一个回答这样的查询。
[Nirmalya] - （喜欢） - ＆gt; [StackOverFlow] - （IsLikedBy） - ＆gt; [约翰]
但是从专家提供的许多例子中，我看到这没有规定。相反，这是通过使用传入之类的运算符来实现的。换句话说，如果两个节点之间设置了边缘，我不需要明确地设置边缘的方向（只是“喜欢”就足够了，＆＃39; isLikedBy＆＃ 39;是多余的）。邻接矩阵的实现可能使这成为可能，但我有点困惑，因为即使DAG中的方向不明确，我也被允许导出反向。
我的问题是我理解的差距在哪里？这是＆＃39; IsLikedBy＆＃39;理想情况下应该存在方向，但我们正在优化？或者，是否有可能存在需要这种双向边缘的UseCases并且我需要发现它们？我完全错过了理论基础吗？
我会很高兴变得更聪明。
答案 0 :(得分：1)
我认为这取决于软件。我可以代表Neo4j，但不能代表你提到的其他工具;）
在Neo4j中，关系设计为可以向前和向后遍历，而不会产生性能成本。这既适用于遍历Java API，也适用于使用Cypher。您可以同时查询指定传入/传出的方向以及查询关系而不关心方向，它也应该具有相同的性能特征。