Cette comparaison Neo4j avec le temps d'exécution du SGBDR est-elle correcte?

Contexte: Ce qui suit est tiré du livre Graph Databases , qui couvre un test de performance mentionné dans le livre Neo4j in Action :

Les relations dans un graphique forment naturellement des chemins. L'interrogation ou la traversée du graphique implique de suivre les chemins. En raison de la nature fondamentalement orientée chemin du modèle de données, la majorité des opérations de base de données de graphiques basées sur le chemin sont très alignées sur la façon dont les données sont disposées, ce qui les rend extrêmement efficaces. Dans leur livre Neo4j in Action, Partner et Vukotic effectuent une expérience en utilisant un magasin relationnel et Neo4j.

La comparaison montre que la base de données graphique est beaucoup plus rapide pour les données connectées qu'un magasin relationnel.L'expérience de Partner et Vukotic cherche à trouver des amis d'amis dans un réseau social, jusqu'à une profondeur maximale de cinq. Étant donné deux personnes choisies au hasard, y a-t-il un chemin qui les relie qui est au maximum de cinq relations? Pour un réseau social contenant 1 000 000 de personnes, chacune avec environ 50 amis, les résultats suggèrent fortement que les bases de données graphiques sont le meilleur choix pour les données connectées, comme nous le voyons dans le tableau 2-1.

Tableau 2-1. Trouver des amis étendus dans une base de données relationnelle contre une recherche efficace dans 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 profondeur deux (amis d'amis), la base de données relationnelle et la base de données graphique fonctionnent assez bien pour que nous puissions envisager de les utiliser dans un système en ligne. Alors que la requête Neo4j s'exécute aux deux tiers du temps de la relationnelle, un utilisateur final remarquerait à peine la différence en millisecondes entre les deux. Au moment où nous atteignons la profondeur trois (ami-ami-ami-ami), cependant, il est clair que la base de données relationnelle ne peut plus traiter la requête dans un délai raisonnable: les trente secondes qu'il faut pour terminer seraient complètement inacceptables pour un système en ligne. En revanche, le temps de réponse de Neo4j reste relativement plat: juste une fraction de seconde pour effectuer la requête - certainement assez rapide pour un système en ligne.

À la profondeur quatre, la base de données relationnelle présente une latence rédhibitoire, la rendant pratiquement inutile pour un système en ligne. Le timing de Neo4j s'est un peu détérioré aussi, mais la latence ici est à la périphérie d'être acceptable pour un système en ligne réactif. Enfin, à la profondeur cinq, la base de données relationnelle prend simplement trop de temps pour terminer la requête. Neo4j, en revanche, renvoie un résultat en environ deux secondes. À la profondeur cinq, il apparaît que presque tout le réseau est notre ami: pour de nombreux cas d'utilisation réels, nous couperions probablement les résultats et les délais.

Les questions sont:

• Est-ce un test raisonnable pour émuler ce que l'on pourrait, sauf pour trouver dans un réseau social? (Cela signifie que les vrais réseaux sociaux ont normalement des nœuds avec environ 50 amis par exemple; il semble que le modèle " riche devient plus riche " serait plus naturel pour les réseaux sociaux, bien qu'il puisse être faux.)
• Indépendamment du caractère naturel de l'émulation, y a-t-il une raison de croire que les résultats sont erronés ou non reproductibles?

En regardant ce document intitulé Anatomie de Facebook, je note que la médiane est de 100. En regardant le graphique de la fonction cumulative, je peux parier que la moyenne est plus élevée, près de 200. Donc, 50 ne semble pas être le meilleur nombre ici. Cependant, je pense que ce n'est pas le problème principal ici.

Le principal problème est le manque d'informations sur la façon dont la base de données a été utilisée.

Il semble raisonnable qu'un stockage de données spécialement conçu pour les structures de graphe soit plus efficace que les RDBM traditionnels. Cependant, même si les RDBM ne sont pas dans les dernières tendances en tant que stockage de données de choix, ces systèmes ont évolué en permanence dans une course aux dimensions de l'ensemble de données. Il existe différents types de conceptions possibles, différentes manières d'indexer les données, des améliorations liées à la concurrence, etc.

Pour conclure, je pense qu'en ce qui concerne la reproductibilité, l'étude manque d'une description correcte de la façon dont le schéma de base de données a été conçu. Je ne m'attends pas à ce qu'une base de données domine un tel roi d'interrogations, mais je m'attendrais à ce qu'avec un design bien réglé les différences ne soient pas si énormes.

Il existe des moyens bons / rapides pour modéliser des graphiques dans SGBDR et des moyens stupides / lents.

• Certains utilisent une indexation intelligente et des processus stockés, échangeant la charge du processeur et des tables temporaires ajustées sur les disques RAM pour une vitesse de récupération plus rapide des graphiques.

• Certains utilisent des chemins de graphique précalculés (cela peut être moins faisable dans le scénario de réseau social, mais dans un arbre avec la majorité des nœuds étant des nœuds feuilles, c'est un assez bon compromis espace-temps

• Certains calculent simplement en boucle, en utilisant une table temporaire non ajustée et indexée. D'après les # jetés dans l'article, cela sent comme ce qu'ils ont fait (30 secondes de performances sur un ensemble de données assez petit)

  Par exemple, j'ai mon propre calcul d'arbre.

  • Il est encapsulé dans un proc stocké hautement réglé

  • Bien qu'il s'exécute dans un serveur de données Sybase ASE15 de matériel de taille entreprise, ce serveur est partagé avec quelques téraoctets de données de toutes les autres applications d'entreprise, certaines étant beaucoup plus gourmandes que les miennes; et n'est pas dédié uniquement à l'exécution de mes requêtes.

  • Je n'avais pas accès à l'outil d'accélération principal, une table temporaire sur un disque RAM.

  • Un ensemble représentatif de données que je recherchais et qui semble correspondre quelque peu aux leurs obtenait un sous-arbre de 150 000 nœuds sur un ensemble complet de données de forêt de 2,5 millions de nœuds (profondeur d'arbre illimitée, qui varie entre 5 et 15, mais arité moyenne plus petite d'un nœud donné que les 50 amis répertoriés dans l'expérience)

  • Je l'ai réglé au point que cette requête ~ 30-45 secondes. Il ne présente certainement pas le ralentissement exponentiel que les chiffres de la question semblent indiquer sur leurs performances SGBDR, ce qui est extrêmement double étant donné qu'il n'y a pas de croissance exponentielle dans l'ensemble de résultats (ce qui me semble un indice non ajusté sur un table temporaire de l'expérience personnelle).

Ainsi, cette comparaison est très probablement incorrecte et basée sur une mauvaise conception du côté du SGBDR, bien que, comme indiqué dans la réponse précédente, il soit impossible de vérifier sans eux un sourcing ouvert à 100% de leurs définitions de code et de table.