MongoDB / Mon goose поиск пути к документу

Question

Я работаю над стеком научных данных c. У авторов есть работы, а у работ много авторов. Я пытаюсь разработать «поиск пути от документа к документу» (не могу сформулировать это лучше, ха-ха), это не слишком сложно:

Допустим, автор X хочет знать, как они могут связаться с автором T ( цель) через его связи. Я хочу разработать решение, чтобы найти кратчайший путь из (как, например):

автор X -> работа A из X -> автор Y, которая работала над A -> работа B из Y -> автор T, который работал над B

По сути, чтобы найти кратчайший путь от автора к другому автору в базе данных, используя отношения автор-работа-автор.

Я не удовлетворен моим текущим решением, которое, я считаю, не использует достаточно того, что MongoDB может сделать, чтобы упростить ситуацию. Я в настоящее время l oop через диапазон соответствующих глубин населения (от 3 до 5), используя это (учитывая глубину и initialAuthorId):

    let populateOptions;
    for (let i = 0; i < depth; i++) {
        populateOptions = {
            path: "works", model: "Work",
            select: "_id",
            populate: {
                path: "authors",
                model: "Author",
                select: "_id",
                match: {_id: {$ne: initialAuthorId}},
                populate: populateOptions
            }
        }
    }

    let relatedSummaries = await this.model.findOne({_id: initialAuthorId}).populate(populateOptions)

И затем выясняю, находится ли targetAuthorId внутри ответа, используя просто:

if (JSON.stringify(queryResults).includes(targetAuthorId))

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

Производительность невелика, тем более, что мой запрос Mon go не отфильтровывает «повторяющиеся отношения» между работами и авторами: как, например, он будет заполнять рабочий массив автора, но каждый заполняется Работа снова будет содержать идентификатор этого автора, и этот автор будет заполняться взад и вперед, что значительно увеличит размер результирующего дерева.

С моим решением слишком много проблем, и производительность не удовлетворяет. Мне особенно интересно, как его улучшить, если MongoDB проделает некоторую «умную» работу.