Titan 以顶点为中心的索引与 Neo4j 标签

Question

我试图在处理这两种技术时对这两种技术进行比较，我想知道你们中是否有人已经有处理其中任何一种或两种技术的经验？ 在处理类似用例时，我主要对性能数据感兴趣。

Answer 1

这两个概念的区别在于全局索引和局部索引的区别。

据我了解，Neo4j 顶点标签允许您通过顶点的“类别”来划分索引空间。这样，O(log(|V|)) 查找现在是O(log(|V|/c))，其中c 是您在顶点集上拥有的类别/标签的数量，并且（等式）假设每个类别中的顶点数量相等。因此，顶点标签有助于全局索引调用，因为这是V 的函数。

接下来，Titan 的以顶点为中心的索引对顶点的入射边进行排序和索引。通过关联到顶点的标签/属性查找特定边的成本是O(log(inc(v)))，其中inc(v) 是设置到顶点v 的入射边的大小。因此，以顶点为中心的索引是局部索引，因为这是v 的函数。

据我了解，Neo4j 不支持以顶点为中心的索引。您目前在 Titan、OrientDB 和 TinkerGraph 中看到了这个概念（……RDF 存储也以这种方式排序——通过 spog 配对） .接下来，所有已知的图形数据库都支持全局索引，但（我相信只有 Neo4j 和 OrientDB）通过标签的概念支持顶点集分区。

再次假设我对 Neo4j 中顶点标签使用的假设是正确的，我们正在讨论两种不同的用例——全局索引与本地索引。从超节点问题的角度来看，全局索引并不能解决遍历大顶点的问题，而这是局部以顶点为中心的索引的唯一目的。

您可以在此处了解超级节点问题和以顶点为中心的索引：
http://thinkaurelius.com/2012/10/25/a-solution-to-the-supernode-problem/

Answer 2

同意 Marko 所说的一切，人们可以更进一步认为，在图形数据库世界中，本地索引可以（甚至应该）替代全局索引。在我看来，图数据模型的最大优势在于它允许您将数据模型编码到图拓扑中，从而在灵活性、易于演化和性能方面获得定性优势。考虑到这一点，我认为 Neo4j 中的标签实际上减损了这一切。将标签具体化为具有指向具有该标签的源的相邻边的节点更符合“模式即图”的理念。

当然，如果您的引擎缺少本地索引，我们又回到了超级节点问题。但是，如果您确实拥有它们（我想说这应该是被称为图形数据库的东西的要求），您可以轻松地将标签转换为节点L，并为这些顶点创建指向该节点的关系你想用L标记的

v -[L]-> L

表示v 具有标签L。现在，如果您希望 Titan 中的它表现得像 Neo4j 标签，只需将 -[L]-> 关系设为“manyToOne”（参见 Titan cardinality constraints）并创建一个以顶点为中心的索引。这种模式让您可以使用标签获得所有可能的东西等等；你可以

• 有效地将其用作与该标签相关的属性的命名空间
• 在一个标签内对元素进行排序
• 轻松嵌套标签而不损失性能（只需使用复合键）
• 将标签 L 的声明与使用它标记的元素的访问方式分开

Answer 3

标签可以提供一些设计模式，通过降低图形的密度来提高性能。例如：它们消除了对类型节点的需求，这些节点通常会变得非常密集。标签可以选择与唯一索引相关联。在这里，索引属性的能力并不新鲜，但唯一地约束它的能力是新的。如果您之前在您的应用程序中工作，您可能会通过让数据库处理来体验一些性能提升。 （这样做肯定更方便。）最后，如果您不为标签分配唯一索引，它仍然会被索引，以提高某些类型查询的性能（例如“给我所有的具有标签的节点")

总而言之，虽然标签在某些情况下可能有助于提高性能，但它们的引入更多是考虑到易用性。我们刚刚开始使用 Neo4j 2.1，它专门解决密集节点性能（我知道你一直在等待），以及其他性能和可扩展性改进......包括删除（出于所有实际目的消除）上部尺寸限制。

菲利普