Блог

Главная - Вопросы по программированию - ArangoDB: обходы, где ребра соединены с другими ребрами

ArangoDB: обходы, где ребра соединены с другими ребрами

#graph-databases #arangodb #aql

#графические базы данных #arangodb #aql

Вопрос:

Недавно я прочитал, что ArangoDB способен соединять ребра с другими ребрами в графе. Как в этой ситуации будет выполняться запрос пути? Например:

 car <-------- part
        ^
        |
        |
installationEvidence

В этом случае installationEvidence является узлом, соединяющимся с ребром между деталью и автомобилем. Начиная с узла car, какой AQL должен возвращать, installationEvidence но не part возвращает? Рассматриваются ли оба installationEvidence и part на p.vertices[1] уровне?

Ответ №1:

В ArangoDB ребра представляют собой особый тип документов. Вот почему вы можете хранить ребра, указывающие на другие ребра. С точки зрения запроса для этих ребер есть два направления: A) Обход приводит к target edge . В этом случае предполагается, что это общий тип документа, и обход не будет следовать ни в каком направлении target edge . Это означает, что вам пришлось бы написать 2 шага обхода в инструкции. Первое заканчивается на ребре. Второй, начинающийся с _from или _to ребра. В вашем случае запрос мог бы выглядеть следующим образом:

 FOR edge IN 1 OUTBOUND @installationEvidece @@edges1
  LET car = DOCUMENT(edge._to)
  RETURN car

Б) Обход проходит через ребро, на которое указывают другие ребра.
Этот случай более сложный. В архитектуре ArangoDB «вершина» ничего не знает о присоединенных к ней ребрах, ребра знают свои вершины.
Что вы могли бы сделать в этом случае, так это снова написать два оператора обхода, где второй начинается с встреченного ребра, например:

 FOR part,edge IN 1 INBOUND @car @@edges1
  FOR installationEvidence IN 1 INBOUND edge @@edges2
    [...]

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

Комментарии:

1. Приятно знать, я понятия не имел, что ребро может указывать на другое ребро, но это имеет смысл. Поскольку коллекция ребер — это просто _to и _from , то они могут указывать на любой допустимый _id .

2. Спасибо за отличную информацию! Означает ли это, что синтаксис for v, e, p in 1..2 с p.edges[1] и p.vertices[1] просто не применяется? Это потенциальный вариант использования для моей команды, однако маловероятно, что мы включим его в ближайшем будущем. Мы исследуем это как способ упростить нашу структуру запросов и получить более прямой доступ к некоторым релевантным данным.

3. Мы еще не решили, какой синтаксис мы хотим использовать, можем ли мы повторно использовать тот, который уже есть (что я предпочитаю), или это было бы крайне запутанно. Дело в том, что если мы перейдем от car к installationEvidence тому, как должно p выглядеть? {vertices: [car, installationEvidence], edges: [car<--part, *<--evidence ]} в этом случае довольно сложно определить фактическую связь между вершинами и ребрами. Мы рады помочь вам с этим и найти решение, которое соответствует обеим нашим потребностям.

4. Спасибо! Мы пока обошли это, так что это не критическая необходимость, но когда мы перейдем к этапу оптимизации базы данных, мы можем вернуться к этому!

5. @mchacki есть ли какие-нибудь новости об этой функции? удалось ли команде ArangoDB определить унифицированный синтаксис?