Question

我在具有64 GB RAM和32核的系统中使用neo4j-community-3.5.3服务器。

我的数据库大小当前为160 GB，并且每天增长到1.5GB。我在页面缓存中保留12 GB，在堆中保留8GB。

除了唯一性约束外，我还在某些节点属性上创建索引。因为在当前的neo4j版本lucene_native-1.0中已弃用索引，所以我使用默认的native-btree-1.0。

所以我面临的问题是我的写入性能非常好。但是，在读取查询结果而不是使用索引查询时，结果大约需要1分钟。

我的索引大小几乎为21 GB。我的数据库大小正在不断增长，但是我没有获得预期的查询性能。

请给我一些更健康的建议，以便我调整查询。预先感谢。

这是我的查询带有索引的示例，以及一些配置文件：

PROFILE
OPTIONAL MATCH (u1:USER)<-[p:MENTIONS]-(tw:TWEET)<-[m:POST]-(u2:USER)
USING INDEX tw:TWEET(date)
WHERE tw.date='2019-03-03' AND u1.author_screen_name='xxx'
RETURN
  u1.author_screen_name as mentioned_author,
  u2.author_name as mentioned_by_author,
  count(*) AS weight
ORDER BY weight DESC LIMIT 20

Query_profile1_using_indexing

Query_profile2_using_indexing

Query_profile3_using_indexing

这是一个查询没有索引和一些配置文件：

PROFILE
OPTIONAL MATCH (u1:USER)<-[p:MENTIONS]-(tw:TWEET)<-[m:POST]-(u2:USER)
WHERE tw.date='2019-03-03' AND u1.author_screen_name='xxx'
RETURN
  u1.author_screen_name as mentioned_author,
  u2.author_name as mentioned_by_author,
  count(*) AS weight
ORDER BY weight DESC LIMIT 20

Query_profile1_without_using_indexing

Query_profile2_without_using_indexing

Query_profile3_without_using_indexing

不使用索引查询所花费的时间为880572毫秒对于相同的查询，使用索引查询花费的时间为57674毫秒。

Answer 1

无论哪种情况，您都在进行聚合的同时进行投影，这并不高效。首先，由于只有一个u1，因此请在开始时为此输入author_screen_name，而基数则仅位于一行。

然后，在您进行匹配之后，根据节点本身进行汇总，排序和限制，然后对结果进行汇总，然后进行预测，因此您只需进行最少的工作；您不希望对只有有限结果集的情况下只会丢弃的大量行进行属性访问：

MATCH (u1:USER)
WITH u1, u1.author_screen_name as mentioned_author
OPTIONAL MATCH ...
...
WITH mentioned_author, u2, count(*) AS weight 
ORDER BY weight DESC 
LIMIT 20
RETURN mentioned_author, u2.author_name as mentioned_by_author, weight

而不是创建适当的索引查询需要花费大量时间，但是neo4写入足够快

1 个答案: