gDown Rendimiento

Durabilidad de las bases medidas

Todas las bases se miden en modo persistente (datos escritos en disco, reproducidos al reiniciar).

Bases medidas

Cómo corre el banco

Arranque, memoria, CPU y tamaño

Sin índice

Con índices en los identificadores

Arranque: desde docker run hasta la primera respuesta a RETURN 1, mediana de varios intentos, medido una vez y repetido en las dos configuraciones; las demás filas cubren toda la ejecución de las cargas. La CPU y el disco no se clasifican: una base que no escribe nada duradero tiene 0 MB en disco.

Lecturas complejas: latencia mediana — LDBC SNB Interactive

Las 29 consultas de la carga Interactive del Social Network Benchmark del LDBC (14 lecturas complejas, 7 lecturas cortas, 8 actualizaciones; Apache 2.0, sin cambios) se ejecutan todas sobre un grafo generado con el esquema SNB.

• 29 / 29 consultas ejecutadas: 14 lecturas complejas, 7 cortas, 8 actualizaciones
• 3 / 3 miembros de un clúster de 3 nodos devuelven el mismo número de filas en las 21 lecturas
• 18 ms mediana de una escritura mientras el líder confirma 1.365 (3.000 personas)
• 0 ms mediana de una lectura en un seguidor durante esas escrituras (percentil 95: 30 ms)

Todas las bases, 3,000 personas

Un guion: la base rechaza la consulta, supera su tiempo límite o devuelve un número de filas distinto al de Neo4j (su tiempo no significaría nada). Caso por caso:

Todas las bases, 30,000 personas

• complex-1 : gDown 12.9 ms, Neo4j 51.5 ms
• complex-2 : gDown 2.8 ms, Neo4j 2 ms
• complex-3 : gDown 15.1 ms, Neo4j 13.3 ms
• complex-4 : gDown 1.6 ms, Neo4j 1.7 ms
• complex-5 : gDown 19.5 ms, Neo4j 16.9 ms
• complex-6 : gDown 6.7 ms, Neo4j 7 ms
• complex-7 : gDown 1.4 ms, Neo4j 1.4 ms
• complex-8 : gDown 0.8 ms, Neo4j 1 ms
• complex-9 : gDown 15.1 ms, Neo4j 8.5 ms
• complex-10 : gDown 4.4 ms, Neo4j 4.2 ms
• complex-11 : gDown 1.9 ms, Neo4j 1.8 ms
• complex-12 : gDown 2 ms, Neo4j 2.4 ms
• complex-13 : gDown 0.9 ms, Neo4j 1 ms
• complex-14 : gDown 4 ms, Neo4j 3.3 ms

Mediana sobre 5 personas tras una vuelta de calentamiento, una pasada por base, en contenedores limitados como en la tabla de propiedades; cada base se consulta por su propio transporte (Bolt en ambos lados para gDown y Neo4j: el viaje de ida y vuelta cuenta en los dos lados). «< 1 ms»: la mediana se redondea a cero milisegundos. Lecturas cortas: mediana por debajo del milisegundo para gDown (0,5 a 0,7 ms) frente a 0,7 a 1 ms para Neo4j, mismo protocolo en ambos lados.

Con 3.000 personas (90.000 nodos y 470.000 relaciones, cargados por Raft en 16 s), las medianas quedan por debajo de 60 ms. Dos optimizaciones descubiertas por esta prueba: complex-1 pasó de 0,6 s a 34 ms y complex-14 de 2 s a 8 ms.

Resultados no oficiales: estas cifras se derivan de la carga LDBC SNB Interactive y no han sido auditadas por el LDBC (Linked Data Benchmark Council). Los datos los genera la prueba, no el Datagen del LDBC: los tiempos no son comparables con los resultados publicados del LDBC. Una sola ejecución por configuración. La prueba también encontró dos defectos, ya corregidos.

Fuente: gluonify-gdown, README e informes de LdbcSnbTest y LdbcClusterTest.

La cobertura de Cypher (el TCK de openCypher en cada base) está en la página de comparación.

Latencia y rendimiento, carga por carga

Mismo grafo, mismas consultas y misma máquina para cada base de la tabla de arriba: las cifras siguientes son la mediana de las rondas de la tabla de propiedades, medidas en arm64.

La latencia es la mediana (p50) en milisegundos, cuanto menos mejor; las cargas con varios clientes están en peticiones por segundo, cuanto más mejor. El mejor valor de cada fila está en negrita. No se ajusta nada más allá de los valores por defecto de cada imagen; gDown corre en la JVM con un heap de 6 GB y una caché de páginas de 2 GB, Neo4j con un heap de 4 GB y una caché de páginas de 2 GB. Cada ejecución parte de un contenedor nuevo, carga el grafo por lotes UNWIND, comprueba que las bases coinciden en los resultados y luego mide.

Sin índice

ArcadeDB (indexado) se mide siempre con índice: sus identificadores internos impiden la búsqueda por id() de las demás columnas. Su columna está aquí para que no falte nada, pero sus relaciones sin índice comparan un índice con un recorrido: véase la tabla con índices para la comparación en igualdad de condiciones.

Con índices en los identificadores

Carga del grafo

Sin índice

Con índices en los identificadores

Qué conclusiones sacar

• FalkorDB es el más rápido en operaciones cortas (lecturas por identificador, saltos, escritura de un nodo) y en rendimiento con varios clientes, con el camino de cliente más corto (RESP). Mire «escrituras durante un recorrido largo»: sus escrituras esperan detrás de una lectura larga; no escribe nada duradero por defecto y su carga con índices es la más lenta.
• gDown es más rápido que Neo4j en la mayoría de las cargas (media geométrica por debajo de 1 en las dos configuraciones), carga más rápido y guarda sus datos en mucho menos espacio en disco. Está igual o más lento en las primeras filas de un resultado grande y en la escritura de un nodo: vea esas filas.
• Frente a Memgraph, gDown gana en agrupaciones, conteos de etiqueta y rendimiento con 8 clientes, y pierde en lecturas cortas, saltos y escrituras. Memgraph no fuerza sus confirmaciones a disco cada vez, a diferencia de gDown y Neo4j.
• ArcadeDB, medido siempre con índice, es competitivo en lectura pero lento en rangos y en escrituras con varios clientes.
• Memoria: las bases que lo guardan todo en RAM (Memgraph, FalkorDB) usan menos. gDown y Neo4j corren aquí con heaps generosos, y gDown necesita mucho menos con un heap más pequeño para las mismas latencias (véase la medida nativa más arriba).

Lo que esta comparación no dice

• La durabilidad difiere: gDown y Neo4j sincronizan el disco en cada confirmación; Memgraph solo cada 100 000 transacciones; FalkorDB no escribe nada duradero por defecto; no se comprobaron los ajustes de las demás bases. Las filas de escritura no comparan, pues, la misma garantía.
• Las bases que hablan Bolt comparten el mismo controlador Java; FalkorDB se mide con un cliente RESP mínimo escrito para el banco, que acorta su camino en lectura (véase la columna de transporte).
• ArcadeDB se mide siempre con índice, en las dos tablas (sus identificadores internos impiden la búsqueda por id()); una base sin valor en una configuración no se midió en ella.
• El grafo cabe en memoria en todas. No se miden un grafo mayor que la RAM, la replicación, la recuperación ante fallos, la búsqueda vectorial, los algoritmos de grafos ni las lecturas durante escrituras concurrentes. Un solo nodo de cada base.
• ArcadeDB corre con un heap sin límite: su cifra de memoria no es comparable. Su imagen es una instantánea de desarrollo.
• Una máquina que no estaba en reposo, pocas rondas: cuente con ±10 % en cada celda.

Fuente: gluonify-gdown, los resultados en bruto de cada ronda (docs/bench) y scripts/bench-compare.py, ensamblados por un script de este sitio; el script del banco está en el mismo repositorio.