图表数据库更适合最短路径算法吗?

前端之家收集整理的这篇文章主要介绍了图表数据库更适合最短路径算法吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我的目标是为道路网络编写最短路径算法.

目前我的架构是这样的:我将所有数据存储在启用PostGIS的Postgresql数据库中.我做一个SELECT * FROM方法,在具有100,000条边(方式)的表上花费不到3秒,之后我将(Java,Ruby或任何基于任何东西)最短路径算法应用于已经驻留在内存中的图形.在具有100,000条边的图形上,第二个操作可能需要大约1.5秒.

所以,它需要:

> 2-3秒将数据库中的所有路径加载到内存中并创建图形(节点以方式(边缘)存储在一个表中);
> 1-1.5秒计算已经在内存中的图形上的最短路径.

这与pgRouting非常相似(根据我的知识,它使用C Boost将图形存储在内存中),除了pgRouting总计大约需要2秒来计算同一数据集上的最短路径(是的,它很快,但是对我来说这是一个黑盒子,所以我需要自己的).

但最近我发现了Graph数据库和Neo4j.在他们的网站上,他们声称“仍然能够在数百万条道路和航路点的图表上以亚秒级速度进行这些计算,这使得在许多情况下放弃使用K / V存储预先计算索引的正常方法并且能够将路由放入关键路径,可以适应现场条件,建立高度个性化和动态的空间服务.“

所以问题是:对于我的特定问题,图表数据库会更快吗?

该问题具有以下属性

>数据库由一个表(方式)组成;
>对数据库的唯一查询获取进入内存的所有方法(构建图形);
>我不需要可伸缩性,即图表可能不会增长.

解决方法

如果你使用任何图形数据库,比如Neo4j,你当然不必重新发明轮子.许多最短路径算法都内置于此,它旨在处理复杂性,以防您在任何特定道路,单向道路,道路评分等时考虑速度限制.当数据增长时,如何跟上性能10次,或100次.考虑到100,000个方式的总计算时间为3秒,对于1M方式,它可以在几分钟内完成,在Neo4j中,响应将以毫秒为单位.

猜你在找的MsSQL相关文章