2016-09-21 2 views
6

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

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

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

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

ответ

7

Извините за задержку, мы работаем над 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.

+0

Это действительно то, что делает моя команда. Прямо сейчас, эти агрегаты занимают около 5 секунд каждый, хотя, когда шесть одновременно запускаются, сервер значительно замедляется, и запросы начинаются с 30-40 секунд. Это около 60 потоков с до 70 000 сообщений. Предположительно, когда мы перейдем к кластеру, мы увидим, что это вернется примерно к 5 секундам, но нам бы очень хотелось ускорить его. –

+0

Хорошо понял;) Возможно ли, что вы могли бы дать нам некоторый анонимный набор данных, чтобы мы могли попытаться оптимизировать происходящее? Для нас всегда проще «реальный» набор данных, чем если бы мы его генерировали. Мы готовы подписать NDA для этого (я не подробно проинформирован о том, что все коммуникации продолжаются, поэтому, если у нас уже есть такой набор данных, я получу свои руки и быстрее получаю ваш запрос). Я также недоволен все выше 1s. – mchacki

+0

Моя команда работает над настройкой! –

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