gpt4 book ai didi

graph - 按日期检索时的 Neo4j 链表性能

转载 作者:行者123 更新时间:2023-12-02 03:35:53 24 4
gpt4 key购买 nike

我认为标题并不能完全代表我所想的问题。

我目前正在设计一个应用程序,就所有意图和目的而言,它与 RSS 提要阅读器完全一样。我使用 neo4j 是因为社交功能将在应用程序生命周期的后期集成。

我构建我的应用程序的方式是这样的:

user:USER -[:HAS_FEED]-> feed:FEED
feed:FEED -[:HAS_SUBSCRIPTION]-> subscription:SUBSCRIPTION
subscription:SUBSCRIPTION -[:NEXT_POST]-> post:POST -[:NEXT_POST]-> post:POST etc etc

本质上,每个订阅都有一个链接的帖子列表。每个帖子都有一个日期(unix 时间)。我最初决定建立一个链接列表的原因是因为帖子是按日期组织的,也是按日期检索的(原因很明显)。由于不太明显的原因,RSS 提要并不总是按包含帖子的日期排序,但是,由于我想按发布顺序显示他们的提要,而不是按我检索它们的顺序,这让我质疑性能问题随着应用程序的增长和链接列表可能在每个订阅下有成千上万的帖子(一个提要也可以由许多订阅组成,这可能会进一步影响性能。

目前我使用以下密码查询获取提要

START feed = node({id})
OPTIONAL MATCH feed -[:HAS_SUBSCRIPTION]-> (subscriptions:SUBSCRIPTION) <-[:NEXT_POST*1..]- posts
WHERE HAS (posts.date) AND posts.date > 00000000000000
RETURN DISTINCT posts
ORDER BY posts.date DESC
LIMIT 100

本质上,我想知道这个查询的效率如何。

我的第一个问题是 - neo4j 是否一定要遍历整个链表,获取每个帖子,然后按日期过滤?

我的第二个问题是 - 这将如何扩展具有一百个或更多订阅的 feed 以及可能有数万个帖子的订阅。

我的第三个问题是——在这种情况下,放弃链表,而是将每个帖子直接连接到它的订阅(即订阅:订阅 -[:HAS_POST]-> post:POST)会更有效吗?

如果您有关于我如何组织这个的替代方案,我愿意接受建议,但是,放弃 neo4j 不是一个选项(特别是因为我花时间为这个特定项目为 node.js 编写了我自己的 neo4j 驱动程序! )

我正在使用 neo4j > 2.0

最佳答案

在这种情况下,是的,Neo4j 将遍历整个列表,通过日期谓词过滤掉内容。如果您选择非常小的日期范围并且您有非常大的链接列表或负载很重,这可能会成为一个问题。

从根本上说,使用您在此处布置的数据结构,任何实现都必须扫描整个列表。由于日期未排序,因此在查看所有条目之前,您永远无法知道是否找到了给定日期的最后一个条目。

你可以在这里做两件事:

  1. 您添加一些您可以排序的第二个日期属性,例如分隔“createDate”和“publishDate”,其中对 publishDate 进行排序。因为 cypher 不知道 publishDate 已排序,所以您仍然需要使用类似遍历框架的东西来编写命令式遍历此链并在正确的点停止。

  2. 您向图中添加一个时间索引结构,每个提要一个,然后您可以使用它按任意时间跨度匹配提要的各个部分。通过这种方法,您可以使用密码,但需要使时间索引保持最新。有关此方法的详细信息,请参阅此 SO 问题:Time-based data in neo4j

关于graph - 按日期检索时的 Neo4j 链表性能,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23483523/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com