Neo4j использует массив фиксированного размера для хранения информации об узлах и отношениях. Одним из преимуществ, предоставляемых структурой, является то, что он может найти местоположение узла или отношения в файле с его внутренним идентификатором, вычисляя умножение идентификатора и фиксированный размер элементов. Таким образом, Neo4j не нуждается в структуре Btree (которая популярна в РСУБД), и они настаивают на том, что Neo4j обеспечивает «бесконтактную смежность» для данных графика.
В противоположность этому, AgensGraph использует для нахождения вершины (узла) или ребра (отношения). Поэтому люди могут почувствовать, что подход AgensGraph не так быстро, как Neo4j, потому что асимптотическая сложность O (log n) по сравнению с O (1) Neo4j.
В теории это правда. Но на самом деле есть несколько моментов для рассмотрения. Во-первых, в СУБД, база журнала очень большая. Таким образом, высота Btree (log n) очень мала (в большинстве случаев < = 3), а внутренние страницы Btree в основном кэшируются в памяти.
И что еще более важно, на самом деле это не так просто, учитывая необходимость ввода/вывода реального диска при обработке обхода графика.
Когда запрос находит грани, смежные с вершиной (идентификатор которого равен v1), в AgensGraph он ищет Btree и может извлекать идентификатор всех соседних границ с одним петлей Btree и последовательно считывать записи листа ВТКЕЕ. Края «сгруппированы в записи листьев Btree», поэтому они быстро восстанавливают смежные ребра. Хотя есть серверные смежные грани, AgensGraph нуждается в одном поиске Btree. Но в Neo4j отношения могут храниться на разных страницах массива фиксированного размера. Смежные отношения связаны с помощью двусвязного списка. Поэтому, если они разбросаны по файлу, ему требуется более случайный ввод-вывод.
На самом деле мы обнаруживаем, что AgensGraph быстрее Neo4j, и он более эффективен для обновлений даже в многоклиентском сеансе, поскольку Btree также разработан для оптимизации для этих параллельных доступов.