GraphDB for CMDB

GraphDB vs. RDB: A Spine-Leaf Architecture Search Speed Comparison

This study benchmarks the search speed of GraphDB (Neo4j) and RDB (PostgreSQL) when querying data representing a spine-leaf network architecture. The results reveal that GraphDB outperforms RDB for datasets with numerous nodes and significant depth.

Experimental Setup

The testing environment utilized Docker containers for Neo4j (version 5.26.0) and PostgreSQL (version 15). The Docker Compose file is as follows:

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

Three scenarios, based on variations of spine-leaf and virtualization architectures, were tested:

• Scenario 1: A simple architecture (19 nodes, depth 4).

• Scenario 2: A more complex architecture with increased server density and full mesh connections between leaf switches and servers (273 nodes, depth 4).

• Scenario 3: The deepest architecture, introducing pods for each virtual machine (417 nodes, depth 5).

Data modeling differed between the databases:

• Neo4j: Nodes represented devices, with has_parent and has_child relationships. A sample query for Scenario 1:

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

• PostgreSQL: Two tables, nodes and relationships, were used.

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)
);

Search queries aimed to find paths from a specific service ("srv1") to spine switches. Python scripts with Neo4j's GraphDatabase driver and psycopg2 were used for query execution and timing.

Results

The search speed comparison across scenarios is summarized below:

Discussion

The results demonstrate that GraphDB is significantly more efficient for datasets with a large number of nodes and considerable depth, aligning with the inherent strengths of graph databases in traversing complex relationships. For smaller datasets, the performance difference is less pronounced.

Furthermore, the simplicity of Cypher queries in Neo4j, compared to the complexity of equivalent SQL queries in PostgreSQL, is a crucial factor to consider. This difference in query complexity contributes to the overall preference for GraphDB when dealing with graph-like data structures.

The above is the detailed content of GraphDB for CMDB. For more information, please follow other related articles on the PHP Chinese website!