CMDB 用のグラフDB

Susan Sarandon
Susan Sarandonオリジナル
2025-01-14 08:45:45183ブラウズ

GraphDB と RDB: スパインリーフ アーキテクチャの検索速度の比較

この調査では、スパインリーフ ネットワーク アーキテクチャを表すデータをクエリする際の GraphDB (Neo4j) と RDB (PostgreSQL) の検索速度をベンチマークします。 結果は、多数のノードと深い深さを持つデータセットでは、GraphDB が RDB よりも優れたパフォーマンスを発揮することを示しています。

実験セットアップ

テスト環境では、Neo4j (バージョン 5.26.0) と PostgreSQL (バージョン 15) の Docker コンテナを利用しました。 Docker Compose ファイルは次のとおりです:

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

スパイン/リーフおよび仮想化アーキテクチャのバリエーションに基づいた 3 つのシナリオがテストされました。

  • シナリオ 1: 単純なアーキテクチャ (19 ノード、深さ 4)。

GraphDB for CMDB

  • シナリオ 2: サーバー密度が増加し、リーフ スイッチとサーバー間のフル メッシュ接続 (273 ノード、深さ 4) を備えた、より複雑なアーキテクチャ。

GraphDB for CMDB

  • シナリオ 3: 各仮想マシンにポッドを導入する最も深いアーキテクチャ (417 ノード、深さ 5)。

GraphDB for CMDB

データ モデリングはデータベース間で異なりました:

  • Neo4j: ノードは、has_parenthas_child の関係を持つデバイスを表しました。 シナリオ 1 のサンプル クエリ:
<code class="language-cypher">CREATE (ssw1: SpineSwitch {name: "ssw1"})
CREATE (ssw2: SpineSwitch {name: "ssw2"})
...
CREATE (ssw1)-[:has_child]->(lsw1)
...</code>
  • PostgreSQL: 2 つのテーブル、nodesrelationships が使用されました。
<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>

特定のサービス (「srv1」) からスパイン スイッチへのパスを見つけることを目的とした検索クエリ。 Neo4j の GraphDatabase ドライバーと psycopg2 を備えた Python スクリプトは、クエリの実行とタイミングに使用されました。

結果

シナリオ間の検索速度の比較を以下にまとめます:

GraphDB for CMDB

ディスカッション

結果は、多数のノードとかなりの深さを持つデータセットに対して GraphDB が大幅に効率的であり、複雑な関係を横断する際のグラフ データベースの固有の強みと一致していることを示しています。 データセットが小さい場合、パフォーマンスの差はそれほど顕著ではありません。

さらに、PostgreSQL の同等の SQL クエリの複雑さと比較した、Neo4j の Cypher クエリの単純さは、考慮すべき重要な要素です。 クエリの複雑さのこの違いは、グラフのようなデータ構造を扱う場合の GraphDB の全体的な優先度に影響します。

以上がCMDB 用のグラフDBの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。