gpt4 book ai didi

performance - 基于索引的查询太慢

转载 作者:行者123 更新时间:2023-12-04 02:46:56 27 4
gpt4 key购买 nike

首先,我不是 titan 和图形数据库方面的专家,所以任何评论都将不胜感激。

目前我有大约 12.000.000 个顶点和 16.000.000 个边。我创建了 2 个索引,顶点索引“fbid”和边索引“dateInMs”。

graph.makeKey("fbid").dataType(String.class).single().indexed(Vertex.class).unique().make();
graph.makeKey("dateInMs").dataType(Long.class).indexed(Edge.class).make();

然后,我运行了以下查询。

g.query().interval("dateInMs",1394247600000,1394420400000).edges()

其中数字代表毫秒中的两个日期(2014-03-08 和 2014-03-10)

因为我是基于索引字段进行查询,所以我期待一个快速的响应,但是查询太慢了,所以我不知道这是预期的结果还是我做错了什么。

注意:当我运行查询时,我收到以下消息:com.thinkaurelius.titan.graphdb.transaction.StandardTitanTx - Query requires iterating over all vertices [(dateInMs >= 1394247600000 AND dateInMs < 1394420400000)]. For better performance, use indexes,

但是我使用的是索引 dateInMs。

有什么线索吗?

最佳答案

请参阅:Titan Limitations

Edge Retrievals are not O(1)

Retrieving an edge by id, e.g tx.getEdge(edge.getId()), is not a constant time operation. Titan will retrieve an adjacent vertex of the edge to be retrieved and then execute a vertex query to identify the edge. The former is constant time but the latter is potentially linear in the number of edges incident on the vertex with the same edge label.

This also applies to index retrievals for edges via a standard or external index.

这种行为的原因是 Titan 存储顶点和边的方式(参见 Data Model )。只能直接访问顶点 (O(1))。

底线:即使您有属性的边索引,Titan 仍然必须遍历所有相邻顶点以通过 id 识别边。

尝试更改您的模式,以便您可以从可以继续遍历的地方查询顶点。

干杯,丹尼尔

关于performance - 基于索引的查询太慢,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/22386338/

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