CMDB 的 GraphDB

GraphDB 與 RDB：Spine-Leaf 架構搜尋速度比較

本研究對 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>

基於脊葉和虛擬化架構的變化，測試了三種場景：

• 場景 1： 一個簡單的架構（19 個節點，深度 4）。

• 場景 2： 更複雜的架構，增加了伺服器密度以及葉交換器和伺服器之間的全網狀連接（273 個節點，深度 4）。

• 場景3：最深的架構，為每個虛擬機器引入pod（417個節點，深度5）。

資料庫之間的資料建模不同：

• Neo4j: 節點代表設備，具有 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>

• PostgreSQL： 使用了兩個表，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 的 GraphDB的詳細內容。更多資訊請關注PHP中文網其他相關文章！