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性能 - 计数节点 - 链表性能 - 替代方案？

回答

相关问题