Является ли графическая база данных лучше для алгоритмов кратчайших путей?

Моя цель - написать алгоритм кратчайшего пути для дорожной сети.

В настоящее время моя архитектура примерно такая: я храню все данные в базе данных PostgreSQL с поддержкой PostGIS. Я выполняю один метод SELECT * FROM , который занимает менее 3 секунд для таблицы со 100 000 ребер (путей), и после этого я применяю алгоритм кратчайшего пути (на основе Java, Ruby или чего-либо еще) к график, который уже находится в памяти. Вторая операция может занять около 1,5 секунд на графе со 100 000 ребер.

Итак, требуется:

• 2-3 секунды, чтобы загрузить все пути из базы данных в память и создать граф (узлы хранятся в одной таблице со способами (ребрами));
• 1-1,5 секунды для вычисления кратчайшего пути на графике, который уже находится в памяти.

Это очень похоже на то, что делает pgRouting (насколько мне известно, он использует C Boost для сохранения графика в памяти), за исключением того, что pgRouting занимает в общей сложности около 2 секунд, чтобы вычислить кратчайший путь для того же набора данных (да, это быстро, но для меня это черный ящик, поэтому мне нужен собственный).

Но недавно я узнал о базах данных Graph и о Neo4j. На своем сайте они заявляют, что «возможность выполнять эти вычисления со скоростью менее секунды на графиках миллионов дорог и путевых точек позволяет во многих случаях отказаться от обычного подхода предварительного вычисления индексов с хранилищами K / V и иметь возможность поставить маршрутизацию на критический путь с возможностью адаптации к текущим условиям и создания высоко персонализированных и динамических пространственных сервисов ».

Итак, возникает вопрос: будет ли графическая база данных быстрее справляться с моей конкретной проблемой?

Проблема имеет следующие свойства:

• база данных состоит из одной таблицы (способов);
• единственный запрос к базе данных - получить все пути в память (для построения графа);
• мне не нужно масштабируемость, т. е. вероятно, что граф не будет расти.