Database 对于最短路径算法，图形数据库更好吗？

我的目标是为道路网络编写一个最短路径算法

目前我的架构是这样的：我将所有数据存储在支持PostGIS的PostgreSQL数据库中。我做了一个

SELECT*FROM ways

，这在一个有100000条边（ways）的表上花费不到3秒钟，然后我将对已经驻留在内存中的图应用一个（Java、Ruby或任何基于Ruby的）最短路径算法。在一个有100000条边的图形上，第二个操作可能需要大约1.5秒

因此，需要：

• 2-3秒，将数据库中的所有路径加载到内存中，并创建一个图形（节点存储在一个带有路径（边）的表中）
• 1-1.5秒计算内存中已存在的图形上的最短路径

这与pgRouting的功能非常相似（据我所知，它使用C Boost将图形存储在内存中），不同的是pgRouting在同一数据集上计算最短路径总共需要2秒钟（是的，它很快，但对我来说是一个黑盒，所以我需要自己的）

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

所以问题是：对于我的特殊问题，图形数据库会更快吗

此问题具有以下属性：

• 数据库由一个表（方式）组成
• 对数据库的唯一查询是将所有方法都放入内存（构建一个图形）
• 我不需要可伸缩性，即图表可能不会增长

---

我没有使用“图形”数据库的经验，但根据你的问题判断，我有几点想法

首先，简单的答案是“创建这样一个图形数据库，并与您的解决方案进行性能比较”。您可以测量内存使用率、执行时间（速度）、cpu利用率和/或其他指标。这将为您提供足够的数据来做出决策

我的另一个建议是修改您的方法适用于您当前的领域，但不适用于graph数据库的领域。这是一种完全不同的编程范式，您可能必须调整和调整您的方法以适应这些特殊类型数据库的领域。如果您在非标准数据库中应用标准方法，则进行性能或任何其他类型的比较是不合理的环境（如图形数据库）

概述：将您的问题转化为图形数据库的术语，并对其进行相应的建模。然后，对两种解决方案进行性能比较

---

我敢打赌，假设您将问题转换为适合于图形数据库的模型，它将为您提供更好的性能“很简单，但除非进行积极的优化，否则效果不会很好。

图形数据库最初可能不会将所有数据加载到内存中，但随着时间的推移，因为好的数据库设计用于处理超大数据集。然而，一旦数据存在，图形数据库就必须做的工作比关系数据库更少，以遍历链接。这是因为它可以使用相关对象的标识直接访问相关对象，而不必使用B树索引和（可能）联接表，因此一旦缓存了节点和边，它应该会更快。

如果使用任何图形数据库，如Neo4j，当然不必重新发明轮子。许多最短路径算法都是内置的，它的设计是为了处理复杂性，如果你必须考虑在任何特定的道路、单行道、道路得分等方面的速度限制。当你的数据增长10倍或100倍时，你如何跟上性能。考虑到100000种方式的总计算时间为3sec，1M种方式的计算时间为分钟，Neo4j的响应时间为毫秒。

图形数据库的突破不仅在于性能，更在于概念：您的路由算法处理的是单关系图。（也就是说，graph WAR链接都是相同类型的）而GraphDatabase有一个多关系图

这使您能够计算仅使用特定类型的边或避免使用其他类型的边的节点之间的最短路径

有关更多信息，您应该阅读管道的定义和概念

我强烈建议项目从图形数据库开始