Neo4j对任意查询的性能表现

Question

Neo4j对任意查询的性能表现

databaseperformanceneo4jgraph-databases

12

我正在阅读Neo4J发布的一篇论文（一段时间前）：http://dist.neo4j.org/neo-technology-introduction.pdf。倒数第二页的Drawbacks部分指出，Neo4J不适用于任意查询。

假设我有用户节点，具有以下属性：姓名、年龄、性别，并且有以下关系：LIKE（指向体育、技术等节点）和FRIEND（指向另一个USER）。那么，Neo4J在查询类似以下内容时是否效率不高：

查找给定节点的朋友，这些朋友喜欢体育、技术和阅读，并且年龄超过21岁。

因此，你必须先找到USER1的FRIEND边，然后找到他们朋友的LIKE边，并确定该节点是否标记为Sports，还必须确定给定朋友的年龄属性是否大于21。

这是一个不好的数据模型吗？特别是对于图数据库而言？LIKE关系的原因在于你想找到所有喜欢运动的人。

对于这个问题，哪种数据库选择更好？Redis、Cassandra、HBase、PostgreSQL？为什么？

有没有任何实证数据相关的信息呢？

- HelloWorld

3

顺便提一下，那篇文章是2006年的，已经过去了将近8年了 :) 实际上，Neo4j在查询方面非常出色，例如：

MATCH (u:User {name:"Brian"})-[:FRIEND]->(f)-[:LIKE]->(t:Thing) WHERE f.age > 21 AND  t.name IN ["Sports","Tech","Reading"] RETURN distinct f

- Michael Hunger

这是我注意到的一件事。本来希望是这样的，但它是他们网站上的链接，所以我不知道那是否仍然适用。他们应该更新它！ - HelloWorld

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- FrobberOfBits · Accepted Answer

这是一个关于图数据库本质的一般性问题。希望neo4j的开发人员能够在这里介入，但这是我的理解。

你可以将任何数据库视为以某种方式“自然索引” 。在关系型数据库中，当您在存储中查找记录时，通常下一个记录就存储在它旁边。我们可能称其为“自然索引”，因为如果您要扫描一堆记录，关系结构基本上就是使其执行得非常好的根本原因。

另一方面，图数据库通常按关系进行自然索引。(如果neo4j在磁盘上的存储需要细化，Neo4J的开发人员可以介入)。这意味着通常情况下，图数据库能够快速遍历关系，但在大规模/批量查询方面表现不佳。

现在，我们只谈论相对性能。以下是RDBMS样式查询的示例。我预计MySQL在此查询的性能上会胜过neo4j：

MATCH n WHERE n.name='Abe' RETURN n;

请注意，这并没有利用任何关系，强制数据库扫描所有节点。您可以通过缩小到特定标签或按名称索引来改进此操作，但通常情况下，如果您有一个名为“people”的MySQL表格和一个“name”列，则关系型数据库管理系统将在此类查询中得心应手，而图形数据库的效果可能会较差。

好的，那么这有什么好处呢？让我们看一下这个查询：

MATCH n-[r:foo|bar*..5]->m RETURN m;

这是完全不同的东西。查询的真正操作在于匹配n到m之间的可变长度路径。在关系型数据库中，我们可以设置“节点”和“边缘”表，然后在它们之间添加一个PK/FK关系。然后你可以编写一个SQL查询，递归地连接这两个表来遍历那条“路径”。相信我，在SQL中尝试过这种方法需要妙手级别的技能来表达那个查询的“1到5个跳跃之间”的部分。而且，RDMBS会对这个查询表现得像一只狗一样，因为它选择性不是很好，并且递归查询非常昂贵，需要执行所有那些重复的连接。

在像这样的查询上，neo4j将超越关系型数据库。

所以 - 关于您关于任意查询的问题 - 世界上没有一个系统擅长任意查询，也就是说，所有查询。系统有优点和缺点。Neo4J可以执行任意查询，但不能保证对于某些类别的查询，它会比某个替代方案表现更好。但是这个观察是普遍的 - 对MySQL、MongoDB和您选择的任何其他事物都是如此。

好的，底线和观察：

图形数据库在RDMBS（和其他一些数据库）表现不佳的查询类别上表现良好。
对于像我提供的示例那样的大规模/批量查询，图形数据库并不适用于高性能调优。它们可以做到，并且可以调整其性能以改善这方面的事情，但它们永远不会像关系型数据库那样好。
这是因为它们的布局方式、它们如何考虑/存储数据的方式根本不同。
那么你应该做什么？如果你的问题涉及大量关系/路径遍历类型的问题，图形数据库是一个巨大的胜利！（即，您的数据是一个图形，并且遍历关系对您很重要）。如果你的问题涉及扫描大量对象集，则关系模型可能更适合。

使用工具在它们擅长的领域中。不要像关系型数据库一样使用neo4j，否则它的表现就像你试图用螺丝刀敲钉子一样糟糕。