GraphDB pour CMDB

GraphDB vs RDB : une comparaison de la vitesse de recherche de l'architecture Spine-Leaf

Cette étude compare la vitesse de recherche de GraphDB (Neo4j) et RDB (PostgreSQL) lors de l'interrogation de données représentant une architecture réseau spine-leaf. Les résultats révèlent que GraphDB surpasse RDB pour les ensembles de données comportant de nombreux nœuds et une profondeur significative.

Configuration expérimentale

L'environnement de test a utilisé des conteneurs Docker pour Neo4j (version 5.26.0) et PostgreSQL (version 15). Le fichier Docker Compose est le suivant :

version: '3'
services:
  postgres:
    image: postgres:15
    ports:
      - 5433:5432
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: postgres
  neo4j:
    image: neo4j:5.26.0
    ports:
      - 7474:7474
      - 7687:7687
  adminer:
    image: adminer
    restart: always
    ports:
      - 8080:8080

Trois scénarios, basés sur des variantes d'architectures spine-leaf et de virtualisation, ont été testés :

• Scénario 1 : Une architecture simple (19 nœuds, profondeur 4).

• Scénario 2 : Une architecture plus complexe avec une densité de serveurs accrue et des connexions entièrement maillées entre les commutateurs feuilles et les serveurs (273 nœuds, profondeur 4).

• Scénario 3 : L'architecture la plus profonde, introduisant des pods pour chaque machine virtuelle (417 nœuds, profondeur 5).

La modélisation des données différait selon les bases de données :

• Neo4j : Les nœuds représentaient des appareils, avec des relations has_parent et has_child. Un exemple de requête pour le scénario 1 :

CREATE (ssw1: SpineSwitch {name: "ssw1"})
CREATE (ssw2: SpineSwitch {name: "ssw2"})
...
CREATE (ssw1)-[:has_child]->(lsw1)
...

• PostgreSQL : Deux tables, nodes et relationships, ont été utilisées.

CREATE TABLE nodes (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255) NOT NULL UNIQUE,
    type VARCHAR(50) NOT NULL
);

CREATE TABLE relationships (
    id SERIAL PRIMARY KEY,
    parent_id INT NOT NULL,
    child_id INT NOT NULL,
    relationship_type VARCHAR(50) NOT NULL,
    FOREIGN KEY (parent_id) REFERENCES nodes (id),
    FOREIGN KEY (child_id) REFERENCES nodes (id)
);

Requêtes de recherche visant à trouver les chemins d'un service spécifique ("srv1") vers les commutateurs spine. Des scripts Python avec le pilote GraphDatabase et psycopg2 de Neo4j ont été utilisés pour l'exécution et le timing des requêtes.

Résultats

La comparaison de la vitesse de recherche selon les scénarios est résumée ci-dessous :

Discussion

Les résultats démontrent que GraphDB est nettement plus efficace pour les ensembles de données comportant un grand nombre de nœuds et une profondeur considérable, ce qui s'aligne sur les atouts inhérents des bases de données graphiques pour traverser des relations complexes. Pour les ensembles de données plus petits, la différence de performances est moins prononcée.

De plus, la simplicité des requêtes Cypher dans Neo4j, comparée à la complexité des requêtes SQL équivalentes dans PostgreSQL, est un facteur crucial à prendre en compte. Cette différence de complexité des requêtes contribue à la préférence globale pour GraphDB lorsqu'il s'agit de structures de données de type graphique.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!