2017-02-19 19 views
1

На работе мы поддерживаем приложение местоположения, основанное на узле JS + Mongo DB (Mongoose). Необходимые геолокационные функции были очень простыми и доступны уже в MongoDB ($ near, $ geoWithin и $ geoIntersect). Наша основная проблема только пришла с требованиями, нужно ли нам использовать функцию «кратчайшего пути», чтобы проверять лучшие маршруты между некоторыми местами, которые мы получили.mongoDB, узел JS и функция кратчайшего пути, доступна любая опция?

Поиск и поиск в Интернете, похоже, что у mongo нет функции кратчайшего пути, и в некоторых статьях предлагается использовать вторую базу данных для выполнения этой задачи (neo4j или postgis).

Вопрос в том, что существует доступный способ достижения кратчайшего пути с помощью монго и узла? или если дело со второй базой данных, что может быть лучшей комбинацией ?.

UPDATE

Недавно я нашел функцию $ graphLookup в Монго DB 3.4, в Mongo Db Европе 16 встречаются переговоры о том, как может быть полезно для отслеживания кратчайшего пути. Является ли это в настоящее время подходящей функцией для достижения того, что я ищу?

ответ

0

В mongodb нет встроенной операции, которая вычисляет кратчайший путь.

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

Чтобы избежать реализаций кратчайшего алгоритма пути самостоятельно вы можете использовать библиотеку, такую ​​как node-dijkstra

Согласно узлу dijstra документации вам необходимо инициализировать график предоставления весов для каждого ребра, а затем вызвать функцию path.

const Graph = require('node-dijkstra') 

const route = new Graph() 

route.addNode('A', { B:1 }) 
route.addNode('B', { A:1, C:2, D: 4 }) 
route.addNode('C', { B:2, D:1 }) 
route.addNode('D', { C:1, B:4 }) 

route.path('A', 'D') // => [ 'A', 'B', 'C', 'D' ] 
+0

благодаря cjungel, на самом деле это один из возможных решений, основная проблема заключается в том, что во многих случаях количество узлов может быть в значительной мере большое, чтобы просто загрузить его в памяти на основе, что тысячи пользователей потенциально будут использовать эту функцию , – dakairus

+0

@ dakairus в этом случае, я думаю, что ваш единственный вариант - представить новый магазин данных для вашей архитектуры. В зависимости от ваших потребностей в реальном времени и объема ваших данных вы можете реализовать периодический импорт своего графика в neo4j или другой магазин grapth. Затем вы можете использовать neo4j для расчета кратчайшего пути в реальном времени. Если вам всегда нужны последние данные для рассмотрения в ваших расчетах, я думаю, вы должны изменить свое приложение, чтобы использовать neo4j для хранения и запросов всех операций, связанных с графикой. – cjungel

 Смежные вопросы

  • Нет связанных вопросов^_^