ArangoDB: агрегирование подсчетов посредством обхода графа

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

Данные структурированы довольно просто: у меня есть предметный узел, ребро, простирающееся до узла потока со связанными датой и категорией, и ребро от узла потока до узла сообщения.

Я хотел бы вернуть данные, хранящиеся в узле потока, и количество сообщений, прикрепленных к потоку.

Я не знаю, как это сделать с синтаксисом for v, e, p in 1..2 outbound. Должен ли я просто сделать for v, e, p in outbound с вложенным графом внутри него? Это все еще работает?


traversal graph-databases aql arangodb
person Nate Gardner    schedule 21.09.2016    source источник

Ответы (1)


arrow_upward
7
arrow_downward

Извините за задержку, мы много работаем над релизом 3.1;)

Я думаю, вы уже пришли к правильному решению: нелегко выразить то, чего вы хотели бы достичь, в выражении 1..2 OUTBOUND. Это проще сформулировать двумя 1..1 OUTBOUND операторами.

Из вашего объяснения я думаю, что вы бы использовали следующий запрос:

FOR thread IN 1 OUTBOUND @start @@threadEdges
  LET nr = COUNT(FOR message IN 1 OUTBOUND thread @@messageEdges RETURN 1)
  RETURN {
    date: thread.date,
    category: thread.category,
    messages: nr
  }

Для пояснения: сначала я выбираю связанный поток. Затем я делаю подзапрос, чтобы просто могли сообщения для одного потока. Наконец, я возвращаю нужную мне информацию.

С точки зрения производительности: с точки зрения доступа к данным (который, скорее всего, является «узким местом») нет разницы в FOR x IN 1..2 OUTBOUND [...] и FOR x IN 1 OUTBOUND [...] FOR y IN 1 OUTBOUND x [...], оба должны просматривать одни и те же документы. В последнем случае оптимизация запроса может быть немного медленнее, но разница намного меньше 1ms.

person mchacki    schedule 21.10.2016
comment
Фактически это то, чем занимается моя команда. Прямо сейчас эти агрегации занимают около 5 секунд каждое, хотя при одновременном запуске шести сервер значительно замедляется, и запросы начинают занимать 30-40 секунд. Это около 60 потоков, содержащих до 70 000 сообщений. Предположительно, когда мы перейдем к кластеру, мы увидим, что это вернется к примерно 5 секундам, но мы действительно хотели бы сделать это быстрее. - person Nate Gardner; 28.10.2016
comment
Хорошо, понял;) Возможно ли, что вы могли бы дать нам какой-то анонимный набор данных, чтобы мы могли попытаться оптимизировать то, что происходит? Для нас всегда проще с реальным набором данных, чем если бы мы его генерировали. Мы готовы подписать для этого NDA (я не проинформирован подробно обо всех происходящих сообщениях, поэтому, если мы уже получили от вас такой набор данных, я получу его и получу ваш запрос быстрее). Я также недоволен все выше 1 с. - person mchacki; 29.10.2016