ホームページ >バックエンド開発 >Python チュートリアル >CMDB 用のグラフDB
この調査では、スパインリーフ ネットワーク アーキテクチャを表すデータをクエリする際の 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 つのシナリオがテストされました。
データ モデリングはデータベース間で異なりました:
has_parent
と has_child
の関係を持つデバイスを表しました。 シナリオ 1 のサンプル クエリ:<code class="language-cypher">CREATE (ssw1: SpineSwitch {name: "ssw1"}) CREATE (ssw2: SpineSwitch {name: "ssw2"}) ... CREATE (ssw1)-[:has_child]->(lsw1) ...</code>
nodes
と relationships
が使用されました。<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 が大幅に効率的であり、複雑な関係を横断する際のグラフ データベースの固有の強みと一致していることを示しています。 データセットが小さい場合、パフォーマンスの差はそれほど顕著ではありません。
さらに、PostgreSQL の同等の SQL クエリの複雑さと比較した、Neo4j の Cypher クエリの単純さは、考慮すべき重要な要素です。 クエリの複雑さのこの違いは、グラフのようなデータ構造を扱う場合の GraphDB の全体的な優先度に影響します。
以上がCMDB 用のグラフDBの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。