¿Es correcta esta comparación de Neo4j con el tiempo de ejecución de RDBMS?

Antecedentes: el siguiente es del libro Graph Databases , que cubre una prueba de rendimiento mencionada en el libro Neo4j en acción :

Las relaciones en un gráfico naturalmente forman caminos. Consultar o recorrer el gráfico implica seguir caminos. Debido a la naturaleza fundamentalmente orientada a la ruta del modelo de datos, la mayoría de las operaciones de bases de datos de gráficos basadas en rutas están altamente alineadas con la forma en que se presentan los datos, lo que los hace extremadamente eficientes. En su libro Neo4j in Action, Partner y Vukotic realizan un experimento utilizando una tienda relacional y Neo4j.

La comparación muestra que la base de datos de gráficos es sustancialmente más rápida para los datos conectados que una tienda relacional. El experimento de Partner y Vukotic busca encontrar amigos de amigos en una red social, hasta una profundidad máxima de cinco. Dadas dos personas elegidas al azar, ¿hay un camino que las conecte que tenga como máximo cinco relaciones? Para una red social que contiene 1,000,000 de personas, cada una con aproximadamente 50 amigos, los resultados sugieren fuertemente que las bases de datos de gráficos son la mejor opción para los datos conectados, como vemos en la Tabla 2-1.

Tabla 2-1. Encontrar amigos extendidos en una base de datos relacional versus encontrar eficientemente en Neo4j

Depth   RDBMS Execution time (s)    Neo4j Execution time (s)     Records returned
2       0.016                       0.01                         ~2500    
3       30.267                      0.168                        ~110,000 
4       1543.505                    1.359                        ~600,000 
5       Unfinished                  2.132                        ~800,000

En profundidad dos (amigos de amigos), tanto la base de datos relacional como la base de datos de gráficos funcionan lo suficientemente bien como para que consideremos usarlas en un sistema en línea. Si bien la consulta Neo4j se ejecuta en dos tercios del tiempo de la relacional, un usuario final apenas notaría la diferencia en milisegundos entre los dos. Cuando llegamos a la profundidad tres (amigo-de-amigo-de-amigo), sin embargo, está claro que la base de datos relacional ya no puede manejar la consulta en un plazo razonable: los treinta segundos que tarda en completarse serían completamente inaceptables para un sistema en línea. En contraste, el tiempo de respuesta de Neo4j permanece relativamente plano: solo una fracción de segundo para realizar la consulta, definitivamente lo suficientemente rápido para un sistema en línea.

En la profundidad cuatro, la base de datos relacional exhibe latencia paralizante, haciéndola prácticamente inútil para un sistema en línea. Los tiempos de Neo4j también se han deteriorado un poco, pero la latencia aquí está en la periferia de ser aceptable para un sistema en línea receptivo. Finalmente, en la profundidad cinco, la base de datos relacional simplemente toma demasiado tiempo para completar la consulta. Neo4j, por el contrario, devuelve un resultado en unos dos segundos. En la profundidad cinco, transpira casi toda la red es nuestro amigo: para muchos casos de uso del mundo real, probablemente recortaríamos los resultados y los tiempos.

Las preguntas son:

• ¿Es esta una prueba razonable para emular lo que uno podría excepto encontrar en una red social? (Es decir, las redes sociales reales normalmente tienen nodos con aproximadamente 50 amigos, por ejemplo; parece que el modelo de "los ricos se vuelven más ricos " sería más natural para las redes sociales, aunque podría estar equivocado).
• Independientemente de la naturalidad de la emulación, ¿hay alguna razón para creer que los resultados son incorrectos o irreproducibles?

Mirando este documento llamado Anatomía de Facebook , noto que la mediana es 100. Mirando la gráfica de función acumulativa, puedo apostar que el promedio es más alto, cerca de 200. Entonces 50 parece no ser el mejor número aquí. Sin embargo, creo que este no es el problema principal aquí.

El problema principal es la falta de información sobre cómo se utilizó la base de datos.

Parece razonable que un almacenamiento de datos diseñado especialmente para estructuras gráficas sea más eficiente que los RDBM tradicionales. Sin embargo, incluso si los RDBM no están en las últimas tendencias como almacenamiento de datos de elección, estos sistemas evolucionaron continuamente en una carrera con las dimensiones del conjunto de datos. Existen varios tipos de diseños posibles, varias formas de indexar datos, mejoras relacionadas con la concurrencia, etc.

Para concluir, creo que con respecto a la reproducibilidad, el estudio carece de una descripción adecuada de cómo se diseñó el esquema de la base de datos. No espero que una base de datos domine a tal rey de interrogatorios, sin embargo, esperaría que con un diseño bien ajustado las diferencias no sean tan masivas.

Hay formas buenas / rápidas de modelar gráficos en RDBMS, y formas tontas / lentas.

• Algunos usan indexación inteligente y Procs almacenados, intercambian la carga de la CPU y las tablas temporales ajustadas en los discos RAM para una velocidad de recuperación de gráficos más rápida.

• Algunos usan rutas gráficas precalculadas (esto puede ser menos factible en un escenario de red social, pero en un árbol con la mayoría de los nodos siendo nodos hoja, es una muy buena compensación de espacio por tiempo

• Algunos simplemente calculan en un bucle, utilizando una tabla temporal indexada no ajustada. De los #s lanzados en el artículo, eso huele a lo que hicieron (rendimiento de 30 segundos en un conjunto de datos bastante pequeño)

  Por ejemplo, tengo mi propio cálculo de árbol.

  • Está encapsulado en un proceso almacenado altamente sintonizado

  • Mientras se ejecuta en un servidor de datos Sybase ASE15 de hardware de tamaño empresarial, ese servidor se comparte con un par de terabytes de datos de todas las demás aplicaciones empresariales, algunos con mucha más información que la mía; y no se dedica únicamente a ejecutar mis consultas.

  • Yo no tengo acceso a la herramienta de aceleración principal, una tabla temporal en un disco RAM.

  • Un conjunto representativo de datos que estaba recuperando que parece coincidir con el de ellos estaba obteniendo un subárbol de 150,000 nodos del conjunto de datos de bosque completo de 2.5M nodos (profundidad ilimitada del árbol, que varía entre 5 y 15, pero menor arity promedio de un nodo dado que los 50 amigos que figuran en el experimento)

  • Lo sintonicé hasta el punto de que esta consulta ~ 30-45 segundos. Ciertamente NO exhibe la desaceleración exponencial que las cifras en la pregunta parecen indicar en su desempeño RDBMS, lo cual es extra doblemente extraño dado que no hay crecimiento exponencial en el conjunto de resultados (lo que para mí apesta a índice no sintonizado en un tabla temporal de la experiencia personal).

Por lo tanto, es muy probable que esta comparación sea incorrecta y se base en un diseño secundario deficiente de RDBMS, aunque como se señaló en la respuesta anterior, es imposible determinar sin ellos abrir el 100% de sus definiciones de código y tabla.