database-design - 为什么在图形数据库中 inode 或索引属性会更好？

Question

我刚刚进入图形数据库，我似乎一直遇到问题，决定是使用“ inode ”还是“索引属性”来跟踪诸如“节点类型”之类的内容。由于到目前为止我还没有真正的经验，我没有任何信息可以作为决定的依据，而且这两种方法似乎同样有效。

所以，问题是:两种方法之间的权衡是什么，规模(即节点数量)如何影响决策？

对于示例场景，假设有两种类型的“事物”:User和 Product ，而 User 节点和 Product 节点之间的边并不那么重要，但我们关心的是我们是否想要 type: User和 type: Product每个节点上的属性，或者如果我们希望每个节点都有一条边指向 User节点和 Product节点，分别。

在什么情况下哪种方法更好？

注意:我特别关注 Neo4j 和 Titan，但我认为这也将更普遍地适用。

Answer 1

首先，你需要问自己:顶点/节点的类型是否需要被索引？即您是否需要按类型检索顶点/节点，比方说，从图中检索所有“用户”顶点，还是需要回答从检索给定类型的所有顶点开始然后进一步过滤/处理这些顶点的查询？

如果这个问题的答案是是 ，那么我建议您将该类型存储为已编入索引的字符串属性。或者，如果您使用基于 jvm 的语言进行开发，您可以定义一个类型枚举并将其用作属性类型，以实现更多类型安全和自动错误检查。 Titan 支持任意用户定义的类/枚举作为属性类型，并将压缩它们以减少内存占用。

但是，这种方法的缺点是无法扩展，因为您正在构建低选择性索引。这意味着可能会有很多“用户”或“产品”类型的顶点，所有这些都需要分别与“用户”或“产品”的索引条目相关联。这使得维护和查询此索引非常昂贵且难以扩展(想象一下 Facebook 有一个“类型”索引:“照片”条目下将有数十亿个顶点)。如果您(还)不关心缩放，那么这可以工作。

如果问题的答案是否 ，然后我建议将类型建模为图中的顶点/节点。即有一个“用户”顶点和一个“产品”顶点以及从每个用户到“用户”顶点标记为“类型”的边，等等。

这种方法的优点是您可以使用图形对数据进行建模，而不是让数据库外的字符串值代表关键类型信息。在您构建应用程序时，图形数据库将成为其核心组件并持续很长时间。随着编程语言和开发人员的来来去去，您不希望数据建模和类型信息随之而来并面临这样的问题:“SPECIAL_USER 是什么意思？”相反，有一个 SPECIAL_USER 顶点并向其添加出处信息，即谁创建了这种类型，它代表什么以及一个简短的描述——所有这些都在数据库中。

这种方法的一个问题是，随着应用程序的扩展，“用户”和“产品”顶点会有很多边缘事件。换句话说，您正在创建会产生扩展问题的 super 节点。这就是 Titan 引入单向边概念的原因。单向边就像网络上的链接:起始顶点指向另一个顶点，但该顶点不知道该边。由于您不想从“用户”顶点遍历到所有用户顶点，因此您不会失去任何东西，而是获得了可扩展性和性能。