GraphDB für CMDB

GraphDB vs. RDB: Ein Vergleich der Suchgeschwindigkeit der Spine-Leaf-Architektur

Diese Studie vergleicht die Suchgeschwindigkeit von GraphDB (Neo4j) und RDB (PostgreSQL) bei der Abfrage von Daten, die eine Spine-Leaf-Netzwerkarchitektur darstellen. Die Ergebnisse zeigen, dass GraphDB RDB bei Datensätzen mit zahlreichen Knoten und erheblicher Tiefe übertrifft.

Experimenteller Aufbau

In der Testumgebung wurden Docker-Container für Neo4j (Version 5.26.0) und PostgreSQL (Version 15) verwendet. Die Docker Compose-Datei lautet wie folgt:

<code class="language-yaml">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</code>

Drei Szenarien, basierend auf Variationen von Spine-Leaf- und Virtualisierungsarchitekturen, wurden getestet:

• Szenario 1:Eine einfache Architektur (19 Knoten, Tiefe 4).

• Szenario 2:Eine komplexere Architektur mit erhöhter Serverdichte und Full-Mesh-Verbindungen zwischen Leaf-Switches und Servern (273 Knoten, Tiefe 4).

• Szenario 3: Die tiefste Architektur, Einführung von Pods für jede virtuelle Maschine (417 Knoten, Tiefe 5).

Die Datenmodellierung unterschied sich zwischen den Datenbanken:

• Neo4j: Knoten repräsentierten Geräte mit has_parent- und has_child-Beziehungen. Eine Beispielabfrage für Szenario 1:

<code class="language-cypher">CREATE (ssw1: SpineSwitch {name: "ssw1"})
CREATE (ssw2: SpineSwitch {name: "ssw2"})
...
CREATE (ssw1)-[:has_child]->(lsw1)
...</code>

• PostgreSQL:Zwei Tabellen, nodes und relationships, wurden verwendet.

<code class="language-sql">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)
);</code>

Suchanfragen zielten darauf ab, Pfade von einem bestimmten Dienst („srv1“) zu Spine-Switches zu finden. Python-Skripte mit Neo4js GraphDatabase-Treiber und psycopg2 wurden für die Abfrageausführung und das Timing verwendet.

Ergebnisse

Der Vergleich der Suchgeschwindigkeit in verschiedenen Szenarien ist unten zusammengefasst:

Diskussion

Die Ergebnisse zeigen, dass GraphDB für Datensätze mit einer großen Anzahl von Knoten und beträchtlicher Tiefe deutlich effizienter ist und mit den inhärenten Stärken von Graphdatenbanken bei der Durchquerung komplexer Beziehungen übereinstimmt. Bei kleineren Datensätzen ist der Leistungsunterschied weniger ausgeprägt.

Darüber hinaus ist die Einfachheit von Cypher-Abfragen in Neo4j im Vergleich zur Komplexität entsprechender SQL-Abfragen in PostgreSQL ein entscheidender zu berücksichtigender Faktor. Dieser Unterschied in der Abfragekomplexität trägt dazu bei, dass GraphDB beim Umgang mit graphähnlichen Datenstrukturen insgesamt bevorzugt wird.

Das obige ist der detaillierte Inhalt vonGraphDB für CMDB. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!