Данные временного ряда структурирования в ArangoDB

Question

У меня есть данные временного ряда (примерно 1-5 пунктов в день). Мне нужно иметь быстрый доступ в webapp, используя ArangoDB. Данные привязаны к определенному профилю, но одна коллекция используется для всех данных для всех профилей. Между узлом профиля и узлом данных имеется узел отчета и узел события. Отчет представляет собой просто группу точек данных из данного события. Существующая структура графа выглядит следующим образом:

profile =====> event1 ========> reportA =======> data1 
    \    \     \=======> data2 
     \    \ 
     \    \========> reportB =======> data3 
     \        \=======> data4 
     \ 
      \==> event2 ========> reportA =======> data1  
        \     \=======> data2 
        \ 
        \========> reportB =======> data3 
             \=======> data4 

диаграммы Я хотел бы эффективно представлять data1 последовательно, с помощью ассоциированного события, отсортированного по атрибуту события. Аналогичная табличная структура результирующего набора, я хотел бы выглядеть следующим образом:

event  dataAttr  value 
------------------------------- 
event1  data1  42 
event2  data1  6 
event3  data1  7 
event4  data1  343 

Я, скорее всего, чтобы запустить этот запрос для каждого dataAttr в данном докладе, для эффективного создания временных рядов результатов каждого dataAttr на конкретный профиль для последних 10-20 событий.

При исследовании этой проблемы в Neo4J они рекомендовали напрямую подключать последовательные события друг к другу. Мне интересно, если это также лучший подход в ArangoDB.

Это означало бы, создавая дополнительный график, который выглядит примерно так:

data1 (of event1) => data1 (of event2) => data1 (of event3) => data1 (of event4) 
data2 (of event1) => data2 (of event2) => data2 (of event3) => data2 (of event4) 

И т.д.

Каждый dataAttr подключен к своему кузену в предыдущем случае, таким образом, после прохождения до самого последнего события в первом графике второй график будет использоваться для перехода n-слоев к прошлым событиям (практически 10-20).

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

Будет ли этот запрос быстрее просто запрашивать коллекции документов с индексами, а не через обход графика? Структура коллекции документов может поставить хэш-индекс на dataAttr и skiplist на событие (они будут упорядочены последовательно с сортировкой строк).

Я предполагаю, что проходя вниз к data1 из event1, обратно до profile и обратно event2data1 и так далее будет очень неэффективно.

Answer 1

Если производительность имеет решающее значение, то попытка максимально эффективно обрабатывать индексы имеет первостепенное значение. Переходы превосходят, если у вас неизвестная длина пути, что не является вашим прецедентом.

Я бы рекомендовал денормализовать данные, хранящиеся в узле данных. Вы хотите вернуть все узлы данных, принадлежащие profile, и данные dataAttr, отсортированные по отметке времени timeStamp, правильно? В этом случае я бы, по крайней мере, добавил идентификатор профиля к узлу данных и использовал индекс с индексом пропуска по profileId, dataAttr и timeStamp.