图数据库能否在未指定的端节点上表现良好?
Can Graph DBs perform well with unspecified end nodes?
我一直在针对一个非常具体的场景试验 neo4j,但我一直无法让它表现良好 - 查询需要几分钟才能完成 return。我想知道这是否是工作技术错误的情况?
下面是我的场景的简化版本。我有 Town
s,它们通过路由相互链接。每条路线都有一段距离。
我想问的问题是:计算从 Town A
到从 Town A
可达的所有其他城镇的最短路线。在这种情况下,有未指定数量的端节点。对于小型数据集,此查询需要几分钟 return,对于具有 50,000 个节点的大型数据集,根本不需要 return。
如果我问这个问题:计算从 Town A
到 Town E
的最短路线,回复似乎是即时的。在这种情况下,起始节点和结束节点都是已知的。
我的问题是,图形数据库是否适合开放式问题(计算从 Town A
到从 Town A
可到达的所有其他城镇的最短路线)?如果是这样,是否只是我构建阻碍性能的数据的方法?
您的数据结构看起来不错(也许您可以添加一个带有“ROAD”边的“Intersection”顶点,其长度存储在 ROAD 边上,但不确定您有哪些可用数据)并且是的,这绝对是一个很好的图形用例。
我使用 Neoj4 的次数不多,但问题很可能是您对涉及的算法(查询)所采用的方法。
Neo4j 应该可以轻松处理您想要完成的任务。我建议观看一些有关该主题的 Neo4j 视频并模仿他们对最短路径算法的方法。
Neo4j(最短路径):https://youtu.be/baEeRfuK1Nk
我一直用来实现这些的图形数据库一直在 TigerGraph 上,但所有图形数据库都能够快速处理 50,000 个节点。
TigerGraph(最短路径):https://youtu.be/Ra0qORVKsWs
已编辑(添加文档链接):
NEO4J
单源最短路径算法
文档:https://neo4j.com/docs/graph-algorithms/current/labs-algorithms/single-source-shortest-path/
TIGERGRAPH
单源最短路径(未加权)
文档:https://docs.tigergraph.com/v/2.6/graph-algorithm-library#single-source-shortest-path-unweighted
单源最短路径(加权)
文档:https://docs.tigergraph.com/v/2.6/graph-algorithm-library#single-source-shortest-path-weighted
由于还有其他图数据库和其他图查询语言,这里介绍如何使用Objectivity/DB及其DO查询语言解决问题。 (有关图表架构和设置,请参阅以下问题:Link to schema and setup.)
CREATE WEIGHT CALCULATOR routeDistance {
minimum: 0,
default: 0,
edges: {
()-[r:Road]->(): r.distance
}
};
Match m = MAX WEIGHT 100.0 routeDistance
((:Town {name == 'TownA'})-[*]->(tEnd:Town))
group by tEnd.name
order by Weight(m) asc
return tEnd.name, weight(m);
查询首先指定用于限制搜索的 MAX WEIGHT。如果您想查看所有可能的结果,请将此值设置为大于将遇到的最大权重的值。接下来,我们使用用户定义的“routeDistance”权重计算器来指定如何计算边缘权重(请参阅链接的问题以获取相关说明。)然后我们按终点(tEnd.name)分组并排序按每个端点的权重。
基于参考图表的结果是:
{
_Projection
{
tEnd.name:'TownD',
weight(m):3.00000
},
_Projection
{
tEnd.name:'TownB',
weight(m):4.00000
},
_Projection
{
tEnd.name:'TownE',
weight(m):4.00000
},
_Projection
{
tEnd.name:'TownF',
weight(m):8.00000
},
_Projection
{
tEnd.name:'TownG',
weight(m):11.0000
},
_Projection
{
tEnd.name:'TownH',
weight(m):21.0000
},
_Projection
{
tEnd.name:'TownC',
weight(m):31.0000
}
}
我一直在针对一个非常具体的场景试验 neo4j,但我一直无法让它表现良好 - 查询需要几分钟才能完成 return。我想知道这是否是工作技术错误的情况?
下面是我的场景的简化版本。我有 Town
s,它们通过路由相互链接。每条路线都有一段距离。
我想问的问题是:计算从 Town A
到从 Town A
可达的所有其他城镇的最短路线。在这种情况下,有未指定数量的端节点。对于小型数据集,此查询需要几分钟 return,对于具有 50,000 个节点的大型数据集,根本不需要 return。
如果我问这个问题:计算从 Town A
到 Town E
的最短路线,回复似乎是即时的。在这种情况下,起始节点和结束节点都是已知的。
我的问题是,图形数据库是否适合开放式问题(计算从 Town A
到从 Town A
可到达的所有其他城镇的最短路线)?如果是这样,是否只是我构建阻碍性能的数据的方法?
您的数据结构看起来不错(也许您可以添加一个带有“ROAD”边的“Intersection”顶点,其长度存储在 ROAD 边上,但不确定您有哪些可用数据)并且是的,这绝对是一个很好的图形用例。
我使用 Neoj4 的次数不多,但问题很可能是您对涉及的算法(查询)所采用的方法。
Neo4j 应该可以轻松处理您想要完成的任务。我建议观看一些有关该主题的 Neo4j 视频并模仿他们对最短路径算法的方法。
Neo4j(最短路径):https://youtu.be/baEeRfuK1Nk
我一直用来实现这些的图形数据库一直在 TigerGraph 上,但所有图形数据库都能够快速处理 50,000 个节点。
TigerGraph(最短路径):https://youtu.be/Ra0qORVKsWs
已编辑(添加文档链接):
NEO4J
单源最短路径算法
文档:https://neo4j.com/docs/graph-algorithms/current/labs-algorithms/single-source-shortest-path/
TIGERGRAPH
单源最短路径(未加权)
文档:https://docs.tigergraph.com/v/2.6/graph-algorithm-library#single-source-shortest-path-unweighted
单源最短路径(加权)
文档:https://docs.tigergraph.com/v/2.6/graph-algorithm-library#single-source-shortest-path-weighted
由于还有其他图数据库和其他图查询语言,这里介绍如何使用Objectivity/DB及其DO查询语言解决问题。 (有关图表架构和设置,请参阅以下问题:Link to schema and setup.)
CREATE WEIGHT CALCULATOR routeDistance {
minimum: 0,
default: 0,
edges: {
()-[r:Road]->(): r.distance
}
};
Match m = MAX WEIGHT 100.0 routeDistance
((:Town {name == 'TownA'})-[*]->(tEnd:Town))
group by tEnd.name
order by Weight(m) asc
return tEnd.name, weight(m);
查询首先指定用于限制搜索的 MAX WEIGHT。如果您想查看所有可能的结果,请将此值设置为大于将遇到的最大权重的值。接下来,我们使用用户定义的“routeDistance”权重计算器来指定如何计算边缘权重(请参阅链接的问题以获取相关说明。)然后我们按终点(tEnd.name)分组并排序按每个端点的权重。
基于参考图表的结果是:
{
_Projection
{
tEnd.name:'TownD',
weight(m):3.00000
},
_Projection
{
tEnd.name:'TownB',
weight(m):4.00000
},
_Projection
{
tEnd.name:'TownE',
weight(m):4.00000
},
_Projection
{
tEnd.name:'TownF',
weight(m):8.00000
},
_Projection
{
tEnd.name:'TownG',
weight(m):11.0000
},
_Projection
{
tEnd.name:'TownH',
weight(m):21.0000
},
_Projection
{
tEnd.name:'TownC',
weight(m):31.0000
}
}