什么可能導致neo4j的這種糟糕的表現？

Question

在我們的堆棧中，我們使用neo4j並遇到了經典的性能問題：一旦需要來自neo4j的數據，應用程序就會很慢。

只聽我的勇氣（雙關語）我啟動了JVisualVM並完成了應用程序的分析。

此應用程序托管在JavaEE服務器（Glassfish）中，並使用由Empire-RDF ， Blueprints和neo4j組成的准語義堆棧。 jCA neo4j-connector提供對neo4j的訪問。

就像這個截圖所示，有強有力的證據表明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（沒有對默認設置進行自定義）。
• 芝麻是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包含Blueprints的綁定，這可能值得一看。

Answer 2

好的，是時候結束那個玩笑了，感謝Mike和我一起幫助過我。

性能問題不是neo4J 1.5故障，也不是Empire，也不是Blueprints one，而是我對自己的持久性堆棧的不了解。

你還記得我說用過的neo4j實例是從JCA連接器獲得的嗎？

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

幸運的是，我已經准備好了該版本的升級，允許我直接向neo4j發送參數（比如設置cache_type）。 所以我完成了升級 ，捆綁了它，將它部署到我的本地存儲庫，將其集成到我的域中，測試並且......成功！ x20性能提升！