Neo4J Performance Benchmarking
kundera (3)
Una forma de probar el rendimiento es usar, por ejemplo, http://gatling-tool.org/ . Se está trabajando en la creación de marcos de referencia en http://ldbc.eu . De lo contrario, la evaluación comparativa depende en gran medida de su conjunto de datos de dominio y las consultas que está tratando de hacer. ¿Tal vez podría comenzar en https://github.com/neo4j/performance-benchmark y mejorarlo?
He creado una implementación básica de cliente de alto nivel sobre Neo4J ( https://github.com/impetus-opensource/Kundera/tree/trunk/kundera-neo4j ) y quiero comparar su rendimiento con el controlador nativo neo4j (y tal vez SpringData también ) De esta manera, podría determinar los gastos generales que mi biblioteca está poniendo sobre el controlador nativo.
Planeo crear una extensión de YCSB para Neo4J.
Mi pregunta es: ¿qué se debe considerar como una unidad básica de objeto que se escribirá en neo4j (debería ser un nodo único o un par de nodos unidos por un borde). ¿Cuál es la práctica actual en el mundo Neo4J? Cómo lo están haciendo las personas evaluando el desempeño de neo4j.
Ya ha habido algún trabajo para la evaluación comparativa de Neo4J con Gatling: http://maxdemarzi.com/2013/02/14/neo4j-and-gatling-sitting-in-a-tree-performance-test-ing/
Quizás puedas adaptarlo.
El proyecto graphdb-benchmarks es un punto de referencia entre las dataases de gráficos populares. Actualmente, el marco es compatible con Titan, OrientDB, Neo4j y Sparksee. El objetivo de este punto de referencia es examinar el rendimiento de cada base de datos de gráficos en términos de tiempo de ejecución. El índice de referencia se compone de cuatro cargas de trabajo, Agrupación, Inserción masiva, Inserción única y Carga de trabajo de consulta. Cada carga de trabajo ha sido diseñada para simular operaciones comunes en sistemas de base de datos de gráficos.
Carga de trabajo en clúster (CW): CW consiste en un conocido algoritmo de detección de la comunidad para la optimización de la modularidad, el Método de Louvain. Adaptamos el algoritmo sobre las bases de datos de gráficos de referencia y empleamos técnicas de caché para aprovechar las capacidades de la base de datos de gráficos y la velocidad de ejecución en memoria. Medimos el tiempo que el algoritmo necesita para converger.
Carga de trabajo de inserción masiva (MIW): cree la base de datos de gráficos y configúrela para una carga masiva, luego la llenaremos con un conjunto de datos particular. Medimos el tiempo para la creación del gráfico completo.
Carga de trabajo de inserción única (SIW): cree la base de datos de gráficos y cárguela con un conjunto de datos particular. Cada inserción de objeto (nodo o borde) se compromete directamente y el gráfico se construye de forma incremental. Medimos el tiempo de inserción por bloque, que consiste en mil bordes y los nodos que aparecen durante la inserción de estos bordes.
Query Workload (QW): ejecuta tres consultas comunes: FindNeighbours (FN): busca los vecinos de todos los nodos. FindAdjacentNodes (FA): encuentra los nodos adyacentes de todos los bordes. FindShortestPath (FS): encuentra la ruta más corta entre el primer nodo y 100 nodos seleccionados al azar.