Analyse comparative RedisGraph 1.0 |  Redis

Analyse comparative RedisGraph 1.0 | Redis

Présentation de RedisGraph

Icône RedisGraph

Aujourd’hui, nous sommes heureux d’annoncer la disponibilité générale de RedisGraph v1.0. RedisGraph est un module Redis développé par Redis pour ajouter une fonctionnalité de base de données graphique à Redis. Nous avons publié RedisGraph en mode aperçu/bêta il y a plus de six mois, et apprécions tous les excellents commentaires et suggestions que nous avons reçus de la communauté et de nos clients alors que nous travaillions ensemble sur notre première version GA.

Contrairement aux implémentations de bases de données de graphes existantes, RedisGraph représente les données connectées comme matrices d’adjacence à la place de listes de contiguïté par point de données. En représentant les données sous forme de matrices creuses et en utilisant la puissance de GraphiqueBLAS (une bibliothèque hautement optimisée pour les opérations de matrice creuse), RedisGraph offre un moyen rapide et efficace de stocker, gérer et traiter des graphiques. En fait, nos benchmarks initiaux montrent déjà que RedisGraph est six à 600 fois plus rapide que les bases de données de graphes existantes ! Ci-dessous, je vais partager comment nous avons comparé RedisGraph v1.0, mais si vous souhaitez plus d’informations sur la façon dont nous utilisons les matrices creuses, consultez ces liens en attendant :

Paralléliser les requêtes dans RedisGraph

Avant d’entrer dans notre benchmark, je dois souligner que Redis est un processus monothread par défaut. Dans RedisGraph 1.0, nous n’avons pas publié de fonctionnalité pour partitionner les graphiques sur plusieurs partitions, car le fait d’avoir toutes les données dans une seule partition nous permet d’exécuter des requêtes plus rapides tout en évitant la surcharge du réseau entre les partitions. RedisGraph est lié au thread unique de Redis pour prendre en charge toutes les requêtes entrantes et inclut un pool de threads qui prend un nombre configurable de threads au moment du chargement du module pour gérer un débit plus élevé. Chaque requête de graphe est reçue par le thread Redis principal, mais calculée dans l’un des threads du pool de threads. Cela permet aux lectures de s’adapter et de gérer facilement un débit important. Chaque requête, à un moment donné, ne s’exécute que dans un seul thread.

Lecteurs et rédacteurs RedisGraph

Cela diffère des autres implémentations de bases de données graphiques, qui exécutent généralement chaque requête sur tous les cœurs disponibles de la machine. Nous pensons que notre approche est plus adaptée aux cas d’utilisation réels en temps réel où un débit élevé et une faible latence dans le cadre d’opérations simultanées sont plus importants que le traitement d’une seule demande sérialisée à la fois.

Alors que RedisGraph peut exécuter plusieurs requêtes de lecture simultanément, une requête d’écriture qui modifie le graphique de quelque manière que ce soit (par exemple, en introduisant de nouveaux nœuds ou en créant des relations et en mettant à jour des attributs) doit être exécutée de manière totalement isolée. RedisGraph applique la séparation écriture/lecteurs en utilisant un verrou de lecture/écriture (R/W) afin que plusieurs lecteurs puissent acquérir le verrou ou un seul écrivain. Tant qu’un écrivain s’exécute, personne ne peut acquérir le verrou, et tant qu’il y a un lecteur en cours d’exécution, aucun écrivain ne peut obtenir le verrou.

Analyse comparative RedisGraph

Maintenant que nous avons préparé le terrain avec ce contexte important, passons aux détails de notre dernier benchmark. Dans l’espace de la base de données graphique, plusieurs outils d’analyse comparative sont disponibles. Le plus complet est Graphalytics LDBCmais, pour cette version, nous avons opté pour un benchmark plus simple publié par TigreGraph dans Septembre 2018. Il a évalué les principales bases de données de graphes telles que TigerGraph, Neo4J, Amazon Neptune, JanusGraph et ArangoDB, et a publié le temps d’exécution moyen et le temps d’exécution global de toutes les requêtes sur toutes les plateformes. Le benchmark TigerGraph couvre les éléments suivants :

  • Temps de chargement des données
  • Taille de stockage des données chargées
  • Temps de réponse à la requête pour le nombre de voisinages k-hop
  • Temps de réponse aux requêtes pour les composants faiblement connectés et le rang de page

Le benchmark TigerGraph a rapporté que TigerGraph était 2 à 8000 fois plus rapide que toute autre base de données de graphes, nous avons donc décidé de contester cela (bien documenté) expérimentez et comparez RedisGraph en utilisant exactement la même configuration. Étant donné que TigerGraph a comparé toutes les autres bases de données de graphes, nous avons utilisé les résultats publiés par leur référence plutôt que de répéter ces tests.

Étant donné que RedisGraph est v1.0 et que nous prévoyons d’ajouter plus de fonctionnalités dans une future version, pour notre benchmark actuel, nous avons décidé de nous concentrer principalement sur la requête de comptage de voisinage k-hop. Bien entendu, nous publierons prochainement les résultats d’autres requêtes.

Détails du benchmark

Matériel utilisé

Type d’instance cloud processeur virtuel Mémoire (Gio) Réseau SSD
AWS r4.8xlarge 32 244 10 gigabits EBS uniquement

Ensembles de données

Versions

  • RedisGraph 1.0.0 GA
  • TigerGraph Developer Edition 2.1.4

Requête de comptage de quartier K-hop

La requête de voisinage k-hop est un type local de requête de graphe. Il compte le nombre de nœuds auxquels un nœud de départ unique (graine) est connecté à une certaine profondeur, et ne compte que les nœuds qui sont à k-sauts.

Ci-dessous le code Cypher :

CORRESPONDANCE (n : nœud) -[*$k]->(m) où n.id=$root retour count(m)

Ici, $root est l’ID du nœud de départ à partir duquel nous commençons à explorer le graphe, et $k représente la profondeur à laquelle nous comptons les voisins. Pour accélérer l’exécution, nous avons utilisé un index sur l’ID du nœud racine.

Résultats

Bien que nous ayons suivi exactement le même benchmark que TigerGraph, nous avons été surpris de voir qu’ils ne comparaient qu’un seul temps de réponse à une requête. Le benchmark n’a pas réussi à tester le débit et la latence sous une charge parallèle simultanée, ce qui est représentatif de presque tous les scénarios réels en temps réel. Comme je l’ai mentionné précédemment, RedisGraph a été conçu à partir de zéro pour un parallélisme extrêmement élevé, chaque requête étant traitée par un seul thread qui utilise la bibliothèque GraphBLAS pour traiter les opérations matricielles avec l’algèbre linéaire. RedisGraph peut ensuite ajouter des threads et mettre à l’échelle le débit de manière presque linéaire.

Pour tester l’effet de ces opérations simultanées, nous avons ajouté des requêtes parallèles au benchmark TigerGraph. Même si RedisGraph n’utilisait qu’un seul cœur, alors que d’autres bases de données de graphes utilisaient jusqu’à 32 cœurs, il obtenait des temps de réponse plus rapides (et parfois beaucoup plus rapides) que toute autre base de données de graphes (à l’exception de TigerGraph dans la requête unique k-hop tests de requêtes sur le jeu de données Twitter).

Un benchmark de requête unique

Les tests de référence de requête unique sont basés sur 300 graines pour les requêtes à un et deux sauts, et sur 10 graines pour les requêtes à trois et six sauts. Ces graines sont exécutées séquentiellement sur toutes les bases de données de graphes. La ligne “time (msec)” représente les temps de réponse moyens de toutes les graines par base de données pour un ensemble de données donné. La ligne « normalisée » par ensemble de données représente ces temps de réponse moyens normalisés à RedisGraph.

Il est important de noter que TigerGraph a appliqué un délai d’attente de trois minutes pour les requêtes à un et deux sauts et de 2,5 heures pour les requêtes à trois et six sauts pour toutes les requêtes sur toutes les bases de données (voir Rapport de référence de TigerGraphs pour plus de détails sur le nombre de requêtes ayant expiré pour chaque base de données). Si toutes les requêtes pour un ensemble de données donné et une base de données donnée ont expiré, nous avons marqué le résultat comme “N/A”. Lorsqu’un temps moyen est présenté, cela ne s’applique qu’aux requêtes exécutées avec succès (graines), ce qui signifie que la requête n’a pas expiré ou n’a pas généré d’exception de mémoire insuffisante. Cela fausse parfois les résultats, car certaines bases de données n’ont pas été en mesure de répondre aux requêtes les plus difficiles, ce qui a entraîné un meilleur temps moyen de requête unique et donné une fausse impression des performances de la base de données.Dans tous les tests, RedisGraph n’a jamais expiré ou généré hors de exceptions de mémoire.

Temps de requête de chemin à 1 saut

Base de données Mesure RedisGraph TigreGraph Néo4j Neptune JanusGraph ArangoDB
graph500 temps (ms) 0,39 6.3 21.0 13.5 27.2 91,9
normalisé 1 16.2 53,8 34,6 69,7 235.6
Twitter temps (ms) 0,8 24.1 205,0 289.2 394.8 1 674,7
normalisé 1 30.1 256.3 361,5 493.5 2 093,4

Temps de réponse de demande unique normalisé : requête de chemin à un saut

Temps de requête de chemin à 2 sauts

Base de données Mesure RedisGraph TigreGraph Néo4j Neptune1 JanusGraph ArangoDB2
graph500 temps (ms) 30,7 71 4 180,0 8 250,0 24 050,0 16 650,0
normalisé 1 2.3 136.2 268.7 783.4 542.3
Twitter temps (ms) 503.0 460,0 18 340,0 27 400,0 27 780,0 28 980,0
normalisé 1 0,9 36,5 54,5 55.2 57,6

Temps de réponse de demande unique normalisé : requête de chemin à 2 sauts

Temps de requête de chemin à 3 sauts

Base de données Mesure RedisGraph TigreGraph Néo4j Neptune1 JanusGraph ArangoDB*2
graph500 temps (ms) 229 410 51 380,0 2 270,0 1 846 710,0 3 461 340,0
normalisé 1 1.8 224.4 9.9 8 064,2 15 115,0
Twitter temps (ms) 9301 6730 298 000,0 38 700,0 4 324 000,0 3 901 600,0
normalisé 1 0,7 32,0 4.2 464.9 419.5

Temps de réponse de demande unique normalisé : requête de chemin à 3 sauts

Temps de requête de chemin à 6 sauts

Base de données Mesure RedisGraph TigreGraph Néo4j Neptune1 JanusGraph ArangoDB2
graph500 temps (ms) 1614 1780 1 312 700,0 N / A N / A N / A
normalisé 1 1.1 813.3 N / A N / A N / A
Twitter temps (ms) 78730 63000 N / A N / A N / A N / A
normalisé 1 0,8 N / A N / A N / A N / A

Normaliser les temps de réponse des requêtes uniques : requête de chemin à 6 sauts

Benchmark des requêtes parallèles

Pour le test des requêtes parallèles, nous avons uniquement comparé RedisGraph et TigerGraph. Cette configuration comprenait 22 threads clients s’exécutant sur la même machine de test, ce qui a généré 300 requêtes au total. Les résultats ci-dessous montrent combien de temps (en msec) il a fallu à chaque base de données de graphes pour répondre à toutes les requêtes combinées, à chaque profondeur (un, deux, trois et six sauts).

Pour TigerGraph, nous avons extrapolé les résultats en multipliant les temps de réponse moyens des temps de requête unique par 300, pour chaque profondeur. Nous pensons que c’est le meilleur scénario, puisque TigerGraph consommait déjà entièrement les 32 cœurs pour les requêtes uniques. La prochaine fois, nous répéterons ces tests avec TigerGraph sous la même charge de 22 clients et nous espérons (compte tenu des lois du parallélisme et de la surcharge que cela générera pour l’exécution de requêtes parallèles) que nos résultats seront encore meilleurs.

Un saut Deux sauts Trois sauts Six sauts
Base de données Mesure RediGraph Tigre RedisGraph Tigre RedisGraph Tigre RedisGraph Tigre
graph500 temps (ms) 29 1 890 772 21 000 5 554 123 000 24 388 534 000
normalisé 1 65.2 1 27.2 1 22.1 1 21.9
Twitter temps (ms) 117 7 200 12 923 138 000 286 018 2 019 000 3 117 964 18 900 000
normalisé 1 61,5 1 10.7 1 7.1 1 6.1

Temps de réponse aux requêtes parallèles normalisés

Conclusion

Nous sommes très fiers de ces résultats de référence préliminaires pour notre version v1.0 GA. RedisGraph a été lancé il y a à peine deux ans par Roi Lipman (notre propre expert en graphes) lors d’un hackathon chez Redis. À l’origine, le module utilisait une implémentation hexastore, mais au fil du temps, nous avons vu beaucoup plus de potentiel dans l’approche de la matrice creuse et l’utilisation de GraphBlas. Nous avons maintenant une validation formelle de cette décision et RedisGraph est devenu une solide base de données de graphes qui montre des améliorations de performances sous charge de 6 à 60 fois plus rapides que les solutions de graphes existantes pour un grand ensemble de données (twitter) et 20 à 65 fois plus rapides sur des données normales. ensemble (graph500).

En plus de cela, RedisGraph surpasse Neo4j, Neptune, JanusGraph et ArangoDB sur un temps de réponse à une seule demande avec des améliorations 36 à 15 000 fois plus rapides. Nous avons obtenu des temps de réponse à une demande unique 2 fois et 0,8 fois plus rapides par rapport à TigerGraph, qui utilise les 32 cœurs pour traiter la demande unique, par rapport à RedisGraph qui n’utilise qu’un seul cœur. Il est également important de noter qu’aucune de nos requêtes n’a expiré sur le grand ensemble de données et qu’aucune d’entre elles n’a été créée à partir d’exceptions de mémoire.

Au cours de ces tests, nos ingénieurs ont également profilé RedisGraph et trouvé des fruits à portée de main qui amélioreront encore nos performances. Entre autres choses, notre feuille de route à venir comprend :

  • Améliorations des performances pour les agrégations et les grands ensembles de résultats
  • Une nouvelle version (encore plus rapide) de GraphBLAS
  • Plus de clauses/fonctionnalités Cypher pour prendre en charge des requêtes encore plus diverses
  • Intégration pour logiciel de visualisation graphique
  • Tests d’analyse comparative LDBC

Bon graphisme !

Équipe RedisGraph


17 janvier 2019

Après avoir publié ces résultats d’analyse comparative RedisGraph, les gens de TigerGraph ont répondu avec quelques réflexions. Bien que nous apprécions d’entendre le point de vue de nos concurrents, nous aimerions répondre à leur accusation de fausses nouvelles. Lisez notre blog de mise à jour de référence ici.

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *