Neo4j性能 - 計數節點 - 鏈表性能 - 替代方案？

更新：韋斯在這裏擊出一個本壘打！謝謝..我已經添加了一個Rails版本，我正在開發使用neography Gem ..完成同樣的事情，但他的版本更快..看到下面的比較Neo4j性能 - 計數節點 - 鏈表性能 - 替代方案？

我在Neo4j（1.9， REST，Cypher）來幫助保持評論的正確順序（是的，我知道我可以按時間排序）。

(object node)---[:comment]--->(comment)--->(comment)--->(comment).... etc

目前，我有900條意見和它採取秒在整個列表，讓 - 完全不可接受的..我只是在該節點的ID（我知道，不要」這樣做，但這不是我的帖子）。

我想要做的是找到評論的用戶的ID，所以我可以返回一個計數..（如「喬和405人對你的帖子發表了評論」）..現在，我甚至沒有計算在這一點上的唯一節點 - 我只是返回每個記錄的author_id ..（我會擔心後面的計數 - 首先照顧基本的性能問題）。

start object=node(15837) match object-[:COMMENTS*]->comments return comments.author_id

7秒是waaaay太長..

而不是使用一個鏈表，我可以只讓一個對象，並直接鏈接的所有意見，以節點 - 但是這可能會導致超級節點這只是陷入困境，然後找到最新的評論，即使是跳過和限制，將是狗慢..

關係指數會在這裏幫助嗎？除了確保獨特的關係，或者查看是否存在關係，我還沒有使用過它們，但是我可以在密碼查詢中使用它們來幫助加快速度嗎？

如果不是，我還能做些什麼來減少返回ID所花費的時間？

比較：下面是一個使用「第二階段」的Neography寶石的方法Rails的版本：

next_node_id=18233 
@neo=Neography::Rest.new 
start_node = Neography::Node.load(next_node_id, @neo) 
all_nodes=start_node.outgoing(:COMMENTS).depth(10000) 
raise all_nodes.size.to_i

結果：290ms發現526個節點..

Wes的解決方案用了5毫秒.. :-)

來源

2014-09-23 Ruben Catchme Obregon

關係指數無濟於事。我建議使用非託管擴展和遍歷API--對於長列表上的這個特定查詢，它將比Cypher快很多。這個例子應該讓你關閉：

https://github.com/wfreeman/linkedlistlength

我根據它的馬克李約瑟的例子在這裏： http://www.markhneedham.com/blog/2014/07/20/neo4j-2-1-2-finding-where-i-am-in-a-linked-list/

來源

2014-09-23 06:30:55

我將如何通過REST使用它？我沒有使用JRuby - 相當普通的舊Rails 3.2和Rest .. – 2014-09-23 14:03:20

你將它安裝到你的neo4j服務器lib文件夾中，重新啓動，然後通過rest調用它：localhost：7474/linkedlistlength /：nodeid – 2014-09-23 14:15:21

好的。一個n00b在這裏，但我停止了服務器，將該文件夾複製到我的rails項目的本地neo4j lib文件夾中，重新啓動，並且出現：HTTP ERROR 404 訪問/ linkedlistlength /：2343問題。原因：未找到本站由Jetty：// – 2014-09-23 14:50:42

如果你只是這樣做是爲了返回一個數，這裏最好的解決方案是不因爲它不會經常改變，所以在每個查詢中都要弄明白。將節點上的結果緩存到節點的total_comments屬性中。每次添加或刪除關係時，更新該計數。如果你想知道是否有任何當前用戶的好友評論，所以你可以說，「喬和700人發表了評論，」你可以做第二個查詢：

start joe=node(15830) object=node(15838) match joe-[:FRIENDS]->friend-[:POSTED_COMMENT]->comment<-[:COMMENTS]-object RETURN friend LIMIT 1

你把它限制在1因爲你只需要一個評論過的朋友的名字。如果它返回某人，請將顯示的註釋數量調整爲1，幷包含用戶的姓名。你可以用JS做到這一點，所以它不會延遲你的頁面加載。對不起，如果我的Cypher有點關閉，不適用於< 2.0語法。

來源

2014-09-23 17:07:03 subvertallchris

謝謝！但我已經這樣做了評論的數量 - 我的帖子有點令人困惑，因爲我概括了這個問題..我想要做的是計數*獨特*評論員 - 我有點離開那部分，因爲我只是試圖解決基本性能問題。當我計算評論的數量，而不是評論者時，我完全按照你的解釋。謝謝！ – 2014-09-23 17:51:26

哦，我明白了！您需要獨特的評論來顯示評論數量，而不是評論數量。那麼在對象節點上緩存呢？添加評論時，執行匹配以確定該用戶是否評論過。如果不是，請將計數增加1？做同樣的事情，減少刪除的計數？或者您是否每次都需要每個獨特評論者的作者ID？ – subvertallchris 2014-09-23 17:58:08

嗯..現在這是一個想法 - 我不需要它每次..我要使用關係索引來存儲關係，並檢查它是否存在..但即使這需要100ms來創建，然後誰知道在保存時需要多長時間閱讀。並且爲了增加它，我使用每個用戶的鏈接列表來進行他們的操作..但是，我會嘗試這種方法 - 在保存時檢查關係索引以查看它們是否已經存在如果不是，則增加計數器的數量。 – 2014-09-23 18:11:51

Neo4j性能 - 計數節點 - 鏈表性能 - 替代方案？

回答

相關問題