Сравнение производительности Neo4J

Я создал базовую реализацию высокоуровневого клиента поверх Neo4J (https://github.com/impetus-opensource/Kundera/tree/trunk/kundera-neo4j) и хотите сравнить его производительность с драйвером Native neo4j (и, возможно, со SpringData). Таким образом, я смогу определить накладные расходы, которые моя библиотека накладывает на собственный драйвер.

Я планирую создать расширение YCSB для Neo4J.

Мой вопрос: что следует рассматривать как базовую единицу объекта для записи в neo4j (должен ли это быть один узел или пара узлов, соединенных ребром). Какова текущая практика в мире Neo4J. Как это делают люди, тестирующие производительность neo4j.


neo4j kundera
person Amresh    schedule 01.03.2013    source источник
comment
немного OT, но я напоминаю себе несколько статей о бенчмаркинге графов в целом, возможно, это поможет: code.google.com/p/orient/wiki/GraphDBComparison и ups. savba.sk/~marek/gbench.html   -  person ulkas    schedule 01.03.2013

Ответы (3)


arrow_upward
4
arrow_downward

Уже проведена некоторая работа по сравнительному тестированию Neo4J с Gatling: http://maxdemarzi.com/2013/02/14/neo4j-and-gatling-sitting-in-a-tree-performance-test-ing/

Возможно, вы могли бы адаптировать его.

person Stephane Landelle    schedule 02.03.2013

arrow_upward
4
arrow_downward

См. graphdb-benchmarks.

Проект graphdb-benchmarks — это эталон между популярными графовыми базами данных. В настоящее время фреймворк поддерживает Titan, OrientDB, Neo4j и Sparksee. Целью этого эталонного теста является проверка производительности каждой графовой базы данных с точки зрения времени выполнения. Тест состоит из четырех рабочих нагрузок: кластеризация, массовая вставка, одиночная вставка и рабочая нагрузка запросов. Каждая рабочая нагрузка была разработана для имитации общих операций в системах графовых баз данных.

Рабочая нагрузка кластеризации (CW): CW состоит из известного алгоритма обнаружения сообщества для оптимизации модульности, метода Лувена. Мы адаптируем алгоритм поверх проверенных баз данных графов и используем методы кэширования, чтобы использовать преимущества как возможностей базы данных графов, так и скорости выполнения в памяти. Мы измеряем время, необходимое алгоритму для сходимости.

Massive Insertion Workload (MIW): создайте графовую базу данных и настройте ее для массовой загрузки, затем мы заполним ее определенным набором данных. Замеряем время создания всего графа.

Рабочая нагрузка с одной вставкой (SIW): создайте базу данных графиков и загрузите в нее определенный набор данных. Каждая вставка объекта (узел или ребро) фиксируется напрямую, а граф строится постепенно. Мы измеряем время вставки на блок, который состоит из тысячи ребер и узлов, появляющихся при вставке этих ребер.

Рабочая нагрузка запросов (QW): выполнение трех стандартных запросов: FindNeighbours (FN): поиск соседей всех узлов. FindAdjacentNodes (FA): находит соседние узлы всех ребер. FindShortestPath (FS): находит кратчайший путь между первым узлом и 100 случайно выбранными узлами.

person Somnath Muluk    schedule 09.03.2015

arrow_upward
1
arrow_downward

Одним из способов проверки производительности является использование, например. http://gatling-tool.org/. На сайте http://ldbc.eu ведется работа по созданию эталонных платформ. В противном случае бенчмаркинг сильно зависит от набора данных вашего домена и запросов, которые вы пытаетесь выполнить. Возможно, вы могли бы начать с https://github.com/neo4j/performance-benchmark и улучшить Это?

person Peter Neubauer    schedule 01.03.2013