我有一个节点类型,它具有一个字符串属性,该属性经常具有相同的值。等等。数百万个节点,只有该字符串值的 5 个选项。我将按该属性进行搜索。
我的问题是在性能和内存方面什么更好:a)将其实现为节点属性并有很多重复项(并使用 WHERE 进行搜索)。b) 将其实现为 5 个附加节点,其中所有原始节点都引用其中一个(并使用附加 MATCH 进行搜索)。
我有一个节点类型,它具有一个字符串属性,该属性经常具有相同的值。等等。数百万个节点,只有该字符串值的 5 个选项。我将按该属性进行搜索。
我的问题是在性能和内存方面什么更好:a)将其实现为节点属性并有很多重复项(并使用 WHERE 进行搜索)。b) 将其实现为 5 个附加节点,其中所有原始节点都引用其中一个(并使用附加 MATCH 进行搜索)。
在不了解更多细节的情况下,很难给出一个通用的答案。
从性能的角度来看,最好尽早限制搜索。如果您不必查看属性进行遍历,则更有益。
鉴于我认为最好将查找属性移动到单独的节点并使用该值作为关系类型。
使用标签;这篇博文很好地介绍了这个 Neo4j 2.0 的新特性:
我也稍微考虑过这个问题。就我而言,我必须代表状态:
总体而言,节点 + 关系方法看起来更有吸引力,因为每次只需要维护一个关系引用而不是属性字符串,并且您不需要扫描必须在属性上维护的额外附加索引(内存和性能将直观地支持这种方法)。
另一个优点是它很容易支持一个节点链接到多个“特殊节点”的能力。如果您预见到在您的模型中应该可以这样做的情况,这比必须使用属性数组(并使用“in”搜索)要好。
在实践中我发现问题就变成了,你每次如何访问这些特殊节点。您要么维护某种常量引用,在其中拥有这些特殊节点的节点 ID,您可以在 START 语句中直接跳转到它们(这就是我们所做的),或者您需要对每个特殊节点的属性进行搜索时间(也许是名字),然后遍历它的关系。这并不适合最漂亮的密码查询。