Question

Contexte: est la suite du livre Graphique des bases de données , qui couvre une performance essai mentionné dans le livre Neo4j en action :

  

Les relations dans un graphique forment naturellement des chemins. Interrogation, ou   traversant, le graphique implique des chemins suivants. En raison de l   fondamentalement la nature orientée chemin du datamodel, la majorité des   les opérations de base de données de graphique en fonction route sont fortement alignées avec le chemin   dans lequel les données sont disposées, ce qui les rend extrêmement efficace. Dans   leur livre Neo4j en action, associé et Vukotic réaliser une expérience   en utilisant un magasin relationnel et Neo4j.

     

comparaison montre que la base de données graphique est sensiblement plus rapide   pour les données connectées qu'un store.Partner relationnel et Vukotic de   expérience cherche à trouver des amis-des-amis dans un réseau social, à un   profondeur maximale de cinq. Compte tenu des deux personnes choisies au hasard, est   il un chemin qui les relie est au plus cinq relations   longue? Pour un réseau social contenant 1.000.000 personnes, chacun   environ 50 amis, les résultats suggèrent fortement que le graphique   bases de données 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 par rapport conclusion 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-de-amis) à la fois la base de données relationnelle et la base de données de graphique assez bien un pour nous d'envisager de les utiliser dans un système en ligne. Alors que les courses de Neo4j dans les deux tiers du temps du relationnel, un utilisateur final remarqueraient à peine la différence en millisecondes entre les deux. Au moment où nous atteignons la profondeur de trois (ami-de-ami-de-ami), cependant, il est clair que la base de données relationnelle ne peut plus traiter avec la requête dans un délai raisonnable: les trente secondes qu'il faut pour compléter serait tout à fait inacceptable pour un système en ligne. En revanche, le temps de réponse de Neo4j reste relativement plat: une fraction de seconde pour effectuer suffisamment rapide pour certainement requête d'un système en ligne

.      

En profondeur quatre expositions de bases de données relationnelles paralysant latence,   ce qui rend pratiquement inutile pour un système en ligne. Les horaires de Neo4j   se sont détériorées un peu trop, mais le temps d'attente est ici au   périphérie d'être acceptable pour un système en ligne sensible. Finalement,   à une profondeur de cinq ans, la base de données relationnelle prend simplement trop de temps à   compléter la requête. Neo4j, en revanche, renvoie un résultat dans environ deux   secondes. En profondeur cinq, il apparaît presque l'ensemble du réseau est notre   ami: pour de nombreux cas d'utilisation-world réel, nous aurions probablement TRIM les résultats,   et les timings.

Les questions sont:

  • Est-ce un test raisonnable à imiter ce que l'on peut trouver, sauf pour un réseau social? (ce qui signifie faire des réseaux sociaux réels ont normalement noeuds avec environ 50 amis, par exemple, semble être le « riches deviennent plus riches » modèle serait plus naturel pour les réseaux sociaux, mais peut-être tort.)
  • Quelle que soit la naturalité de l'émulation, est-il une raison de croire que les résultats sont éteints, ou non reproductible?
Était-ce utile?

La solution

En regardant ce document intitulé Anatomie de Facebook Je note que la médiane est de 100. en regardant la courbe de fonction cumulée je parie que la moyenne est plus élevée, près de 200. donc, 50 semble ne pas être le meilleur numéro ici. Cependant, je pense que ce n'est pas la principale question ici.

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

Il semble raisonnable qu'un stockage de données conçu spécialement pour les structures de graphique pour être plus efficaces que SGBDR traditionnels. Cependant, même si les SGBDR ne sont pas les dernières tendances en tant que stockage de données de choix, ces systèmes ont évolué de façon continue dans une course avec les dimensions du jeu de données. Il existe différents types de conceptions possibles, différentes manières de données d'indexation, les améliorations liées à la simultanéité et ainsi de suite.

Pour conclure, je pense qu'en ce qui concerne la reproductibilité, l'étude manque une bonne description de la façon dont a été conçu le schéma de base de données. Je ne pense pas qu'une base de données Dominer sur ce roi des interrogatoires, mais j'attendre à ce que avec un design bien réglé les différences de ne pas être telles massives.

Autres conseils

Il y a de bonnes / moyens rapides aux graphiques de modèles dans SGBDR, et les moyens muets / lents.

  • Certains utilisent l'indexation intelligente et stockées procs, la négociation charge CPU et des tables temporaires sur les disques de l'écoute RAM pour le graphique plus rapide vitesse de récupération.

  • Certains utilisent des chemins graphique précalculées (cela peut être moins possible dans le scénario de réseau social, mais dans un arbre à la majorité des noeuds étant des noeuds de feuille, il est un très bon espace pour temps compromis entre

  • Certains calculer simplement dans une boucle, en utilisant un-réglé table temporaire dans indexée. Des #s jetés dans l'article, qui sent comme ce qu'ils ont fait (30 performances de deuxième sur assez peu petite ensemble de données)

    Par exemple, j'ai mon propre calcul de l'arbre.

    • Il est encapsulée dans une procédure stockée hautement calibrée

    • Alors qu'il est en cours d'exécution dans un Sybase taille-matériel d'entreprise ASE15 dataserver, ce serveur est partagé avec un couple téraoctets de données de tous les autres des applications d'entreprise, des données beaucoup plus faim que le mien ; et est non seulement dédié à l'exécution de mes requêtes.

    • J'ai fait pas ont accès au principal outil d'accélération, une table temporaire sur un disque RAM.

    • Un ensemble représentatif de données que je récupérait qui semble correspondre à peu leur devenais un sous-arbre de noeud 150 000 de jeu de données forêt pleine 2.5M noeud (profondeur illimitée de l'arbre, qui varie entre 5 et 15, mais plus petit < em> moyenne arité d'un noeud donné que les 50 amis répertoriés dans l'expérience)

    • Je l'écoute à point que cette requête ~ 30-45 secondes. Il certainement ne présente pas le ralentissement exponentiel que les chiffres de la question semblent indiquer sur leur performance SGBDR, ce qui est extra à double étrange étant donné qu'il n'y a pas une croissance exponentielle dans le jeu de résultats (qui me pue l'indice de non-écoute sur un table temporaire de son expérience personnelle).

Alors, cette comparaison est très probablement incorrecte et basée sur la conception de côté SGBDR pauvres, bien que la réponse précédente note, il est impossible de vérifier sans les ouvrir l'approvisionnement 100% de leurs définitions de code et de table .

Licencié sous: CC-BY-SA avec attribution
scroll top