Работа с супер-узлами и индексированными отношениями в Neo4j, часть 2

В предыдущем посте мы сравнивали производительность выборки отношений из густонаселенных узлов с использованием собственного хранилища Neo4j и индекса lucene. Мы видели, что мы можем извлечь небольшое подмножество отношений из суперузла (содержащего ~ 1M отношений) непосредственно из индекса Lucene, производительность первого запуска (cold-caches) лучше, чем при использовании магазина Neo непосредственно. Последующие прогоны с разогретыми кэшами показывают сопоставимую производительность, слегка в пользу прямой выборки из магазина Neo, что соответствует низкоуровневой оптимизации кэша.

В завершение нашего исследования в этой записи блога мы рассмотрим производительность извлечения большого количества связей из супер-узлов.

Давайте вспомним о наборе данных, который мы используем:

• 5 узлов, представляющих города / поселки (например, «Лондон», «Манчестер», «Эдинбург», «Кембридж» и «Оксфорд»)
• Каждый городской узел имеет отношение «IS_IN» к узлу страны UK (каждый город связан с узлом страны с отношением IS_IN, и у нас есть только один узел страны — Великобритания)
• У нас есть 1M пользователей, и каждый из них имеет отношение «HAS_VISITED» к каждому из пяти городов. Я знаю, что это маловероятный сценарий, но в большом наборе данных (скажем, среди всех пользователей Facebook) вы найдете более 5 городов, которые посетили более 100 000 пользователей.
• В итоге мы имеем 1 000 006 узлов (1M пользователей + 5 городов + 1 узел страны в Великобритании) и 5 ​​000 005 отношений (1M пользователей-HAS) _VISITED-5 городов + 5 городов IS_IN UK).

В предыдущей записи блога мы извлекали отношения IS_IN из каждого суперузла города, причем у каждого города было только одно отношение этого типа (1 000 001 или 0,0001%).

В этом примере. мы собираемся загрузить все отношения HAS_VISITED для городского узла, что означает, что мы заинтересованы в загрузке 99,9999% отношений для данного узла. Мы собираемся сравнить использование API Neo4j для обхода отношений и
IndexedRelationshipExapnder, который мы представили в предыдущей записи блога.

Чтобы получить все отношения HAS_VISITED с помощью Neo API, мы будем использовать код, аналогичный описанному выше:

Iterable<Relationships> relationships = city.getRelationships(DynamicRelationshipType.withName("IS_IN"));
for (Relationship r : relationships) {
   cnt++;
}

RelationshipType relationshiptype = DynamicRelationshipType.withName("HAS_VISITED");
Direction direction = Direction.INCOMING;
TraversalDescription traversal =
    Traversal.description()
    .evaluator(Evaluators.atDepth(1))
    .expand(
        IndexedRelationhipExpander.create(this.embeddedGraphDatabase, relationshipType, direction)
    );
traversal.traverse(city);

public class OrderedIndexedRelationhipExpander implements RelationshipExpander{
 //The rest of the class is same as in the
 //IndexedRelationshipExpander
 //Omitted for clarity
public static final int DEFAULT_MAX_HITS = 100000;

    @Override
    public Iterable<Relationship> expand(Node node) {

        QueryContext queryContext = new QueryContext(this.relationshipType.name())
          .sort(Sort.INDEXORDER)
      .top(DEFAULT_MAX_HITS); #1
        Iterable<Relationship> hits = null;
        ReadableRelationshipIndex autoIndex = this.graphDatabaseService.index().getRelationshipAutoIndexer().getAutoIndex();
        switch (this.direction){
            case OUTGOING:
                hits = autoIndex.query("type",queryContext, node, null);
                break;
            case INCOMING:
                hits = autoIndex.query("type", queryContext, null, node);
                break;
            case BOTH:
                IndexHits<Relationship> out = autoIndex.query("type", queryContext, node, null);
                IndexHits<Relationship> in = autoIndex.query("type", queryContext, null, node);
                hits = Iterables.concat(out, in);
                break;
        }

        return hits;
    }

}

Давайте теперь повторим шаблон, пройдя через отношения HAS_VISITED на супер-узле. Помните, мы возвращаем 100K лучших результатов — все еще достаточно большая коллекция.

Листинг 4: Использование OrderedIndexedRelationshipExpander для загрузки 100-тысячных отношений

RelationshipType relationshiptype = DynamicRelationshipType.withName("HAS_VISITED");
Direction direction = Direction.BOTH;
TraversalDescription traversal =
    Traversal.description()
    .evaluator(Evaluators.atDepth(1))
    .expand(
        OrderedIndexedRelationhipExpander.create(this.embeddedGraphDatabase, relationshipType, direction)
    );
traversal.traverse(city);

Таблица 2 показывает результаты измерения производительности:

Таблица 2: Результаты производительности OrderedIndexedRelationshipExpander

Удар первого прохода составляет менее 3 секунд, при этом производительность теплых кэшей стабилизируется на уровне около 500 мс, что является огромным улучшением.

Мы знали, что Neo4j иногда борется с обходом супер узлов. Мы также знали, что Neo4j имеет отличные возможности поисковой системы Lucene, встроенные в серверную систему.
В этом блоге мы продемонстрировали, что использование магазина Neo имеет лучшую производительность, чем индекс Lucene, при извлечении большого количества связей из супер-узлов. Тем не менее, производительность не была идеальной (более 1 секунды).