Как оптимизировать обходы графика в ArangoDB?

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

Но этот вопрос звучит довольно обидно.

Вы, люди в triAGENS, отлично поработали над созданием базы данных "multi-paradigm". Будучи пользователем PostgreSQL, PostGIS, MongoDB и Neo4J/Titan, я очень благодарен за решение "все-в-одном":)

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

Кроме того, даже после создания соответствующего индекса, я сталкиваюсь с некоторыми серьезными проблемами производительности при выполнении такого рода материалов в Gremlin

g.v('an_id').out('likes').in('likes').count()

который возвращает результат через ~ 3 секунды (воспринимаемое время)

Я предположил, что я плохо понял, как работал Gremlin и Blueprint/ArangoDB, поэтому я попытался переписать тот же запрос с помощью AQL:

LET lst = (FOR e1 in NEIGHBORS(vertices, edges, "an_id", "outbound", [ { "$label": "likes" } ] )
    FOR e2 in NEIGHBORS(vertices, edges, e1.edge._to, "inbound", [ { "$label": "likes" } ] )
        RETURN 1
    )
RETURN length(lst)

Который дает мне задержку того же порядка.

Если я попытался запустить тот же запрос в базе данных Titan или Neo4j (с теми же данными), запросы возвращаются почти сразу (воспринимаемое время: < 200ms)

Итак, мне кажется, что графические функции ArangoDB являются "интеллектуальным графическим слоем" над "традиционной базой документов", но ArangoDB не является "родной" базой графов.

Чтобы подтвердить это чувство, я преобразую данные для загрузки в PostgreSQL и запускаю запрос (с несколькими таблицами JOIN, как вы можете предположить) и получил аналогичные (для ArangoDB) задержки выполнения

Я сделал что-то неправильно (в запросе AQL)?

Есть ли способ оптимизировать базу данных, чтобы получить лучшее время прохождения?

В PostgreSQL, концептуально, я бы смешал край и node и использовал предложение CLUSTER, чтобы физически упорядочить данные, что-то подобное можно сделать в ArangoDB? (Я предполагаю, что это было бы трудно, так как это включало бы "чересстрочные" ребра и узлы, просто интуицию)

Ответ 1