什么可能导致neo4j的这种糟糕的表现？

Question

在我们的堆栈中，我们使用neo4j并遇到了经典的性能问题：只要需要来自neo4j的数据，应用程序就会很慢。

只听我的勇气（双关语）我启动了JVisualVM并完成了应用程序的分析。

此应用程序托管在JavaEE服务器（Glassfish）中，并使用由Empire-RDF，Blueprints和neo4j组成的准语义堆栈。访问neo4j由JCA neo4j-connector提供。

就像这个截图所示，有强有力的证据表明neo4j数据检索存在瓶颈。

我的问题是双重的，但很简单。

1. 表现水平正常吗？ （我猜不是）
2. 我可以做些什么来改善这些表现？

编辑以下是有关测试程序的一些信息，应该启发你们。

对我来说，我的图形结构是未知的：因为我在Blueprints / Sesame / Neo4J之上使用Empire-RDF，我只知道我正在操作的Java对象，这是十个相互关联的类，并且它们不幸地是我们商业的核心，所以我不能透露它们。

考虑到这个例子，他们创建了一个视觉元素树，链接到表示URI目标的实体。

我有一个maven测试，它运行读/写操作的组合（我会说有20到50个JPA操作）。此maven测试运行时间<300秒。

在较低的层面上，

• 应用程序在Windows-7和Mac OS X 10.6上运行，具有各种Java 1.6子版本。
• 应用程序托管在Glassfish 3.1.1
上
• neo4j DB是版本1.5，通过neo4j-connector访问JCA（没有对默认设置进行自定义）。
• Sesame是版本2.6.0
• 蓝图是版本1.1
• Empire-RDF是版本0.7

作为最后一个世界，深入了解jVisualVM采样器可以发现大部分应用时间都用在NodeManager#getNodeForProxy次调用中。

Answer 1

我最后一次使用neo4j Sail时，我对表现感到非常失望。插入，甚至批量插入，都是慢得令人无法接受的，除了最简单的查询之外的任何东西对于任何类型的面向用户的界面来说都太慢了。

当然，这是大约两年前的情况，所以它的性能可能与我上一次看到的不同（甚至可能更好），但当时它远远落后于所有专用的RDF数据库，我不知道不要想象他们已经赶上了。

如果您将它用作图形存储，那么neo4j很好，但我认为它不适合RDF。使用真正的RDF数据库会好得多。既然你正在使用Empire，它应该很容易放入大多数任何其他RDF数据库，并看看它如何影响性能，假设你不依赖于任何neo4j / Blueprints特定的东西。如果是这种情况，Stardog包含蓝图的绑定，这可能值得一看。

Answer 2

好的，是时候结束这个笑话，感谢Mike帮助了我。

性能问题不是neo4J 1.5故障，也不是Empire，也不是Blueprints one，而是我对自己的持久性堆栈的理解不足。

你还记得我说用过的neo4j实例是从JCA连接器获得的吗？

好吧，我使用的是连接器的0.2版，它与neo4j 1.4配合使用......是的，1.4！

幸运的是，我已经准备好了该版本的升级，允许我直接向neo4j发送参数（比如设置cache_type）。所以I finished that upgrade捆绑了它，将它部署到我的本地存储库，将其集成到我的域中，测试并成功！ x20 改善表现！