在許多企業(yè)場景中，擁有一個分布式和可擴(kuò)展的圖數(shù)據(jù)庫系統(tǒng)是非常受歡迎的。一方面，這很大程度上受到大數(shù)據(jù)處理框架的持續(xù)興起和流行的影響，包括但不限于Hadoop、Spark和NoSQL數(shù)據(jù)庫；另一方面，隨著越來越多的數(shù)據(jù)以相關(guān)和多維的方式進(jìn)行分析，將所有數(shù)據(jù)打包到一個實(shí)例的一個圖中變得越來越困難，擁有一個真正分布式和水平可擴(kuò)展的圖數(shù)據(jù)庫是必須的 -有。

不要被誤導(dǎo)

設(shè)計和實(shí)現(xiàn)可擴(kuò)展的圖形數(shù)據(jù)庫系統(tǒng)從來都不是一項簡單的任務(wù)。有無數(shù)的企業(yè)，尤其是互聯(lián)網(wǎng)巨頭，已經(jīng)探索了使圖形數(shù)據(jù)處理可擴(kuò)展的方法。盡管如此，大多數(shù)解決方案要么僅限于其私有和狹窄的用例，要么通過硬件加速以垂直方式提供可擴(kuò)展性，這再次證明大型機(jī)架構(gòu)計算機(jī)在 90 年代被 PC 架構(gòu)計算機(jī)確定性取代的原因主要是與水平可擴(kuò)展性相比，垂直可擴(kuò)展性通常被認(rèn)為是劣質(zhì)的且可擴(kuò)展性較差。分布式數(shù)據(jù)庫通過添加廉價PC來實(shí)現(xiàn)可擴(kuò)展性（存儲和計算），并試圖按需一勞永逸地存儲數(shù)據(jù)，這已成為一種常態(tài)。但是，如果不大量犧牲圖形系統(tǒng)上的查詢性能，這樣做就無法實(shí)現(xiàn)同等的可擴(kuò)展性。

為什么圖形（數(shù)據(jù)庫）系統(tǒng)的可擴(kuò)展性如此難以（獲得）？主要原因是圖系統(tǒng)是高維的；這與傳統(tǒng)的 SQL 或 NoSQL 系統(tǒng)形成鮮明對比，傳統(tǒng)的 SQL 或 NoSQL 系統(tǒng)主要以表為中心，本質(zhì)上是列式和行式存儲（以及更簡單的 KV 存儲），并且已被證明通過水平可擴(kuò)展設(shè)計相對容易實(shí)現(xiàn)。

一個看似簡單直觀的圖查詢可能會導(dǎo)致大量圖數(shù)據(jù)的深度遍歷和滲透，否則往往會導(dǎo)致典型的BSP（Bulky Synchronous Processing）系統(tǒng)在其眾多分布式實(shí)例之間進(jìn)行大量交換，從而導(dǎo)致重大（和難以忍受的）延遲。

另一方面，大多數(shù)現(xiàn)有的圖形系統(tǒng)更愿意在提供可擴(kuò)展性（存儲）的同時犧牲性能（計算）。這將使此類系統(tǒng)在處理許多現(xiàn)實(shí)世界的業(yè)務(wù)場景時變得不切實(shí)際和無用。描述此類系統(tǒng)的更準(zhǔn)確的方法是，它們可能可以存儲大量數(shù)據(jù)（跨越許多實(shí)例），但不能提供足夠的圖形計算能力——換句話說，這些系統(tǒng)在被超出范圍的查詢時無法返回結(jié)果元數(shù)據(jù)（節(jié)點(diǎn)和邊）。

本文旨在揭開圖形數(shù)據(jù)庫的可擴(kuò)展性挑戰(zhàn)的神秘面紗，同時重點(diǎn)關(guān)注性能問題。簡而言之，您將對任何圖形數(shù)據(jù)庫系統(tǒng)的可伸縮性和性能有更好、更通暢的理解，并在選擇您未來的圖形系統(tǒng)時更有信心。

市場上有很多關(guān)于圖數(shù)據(jù)庫可擴(kuò)展性的聲音；一些供應(yīng)商聲稱他們具有無限的可擴(kuò)展性，而其他供應(yīng)商則聲稱他們是第一個企業(yè)級可擴(kuò)展圖形數(shù)據(jù)庫。你應(yīng)該相信或跟隨誰？唯一的出路是讓自己對圖形數(shù)據(jù)庫系統(tǒng)的可擴(kuò)展性有足夠的了解，這樣你就可以自己驗(yàn)證它，而不必被所有那些營銷炒作所誤導(dǎo)。

誠然，圖數(shù)據(jù)庫可擴(kuò)展性有很多術(shù)語；有些可能非常令人困惑，僅舉幾例：HA、RAFT 或分布式共識、HTAP、聯(lián)合、結(jié)構(gòu)、分片、分區(qū)等。

你真的能分辨出所有這些術(shù)語的區(qū)別嗎？我們會解開它們。

3 分布式圖系統(tǒng)架構(gòu)設(shè)計流派

首先，確保您了解從獨(dú)立（圖形數(shù)據(jù)庫）實(shí)例到完全分布式且可水平擴(kuò)展的圖形數(shù)據(jù)庫實(shí)例集群的演進(jìn)路徑。

圖 1：分布式（圖）系統(tǒng)的演變。

分布式系統(tǒng)可能有多種形式，這種豐富的多樣化可能會導(dǎo)致混亂。一些供應(yīng)商誤導(dǎo)性地（諷刺地）聲稱他們的數(shù)據(jù)庫系統(tǒng)均勻分布在單個基礎(chǔ)硬件實(shí)例上，而其他供應(yīng)商則聲稱他們的分片圖形數(shù)據(jù)庫集群可以處理數(shù)以萬計的圖形數(shù)據(jù)集，而實(shí)際上，集群不能甚至可以處理反復(fù)遍歷整個數(shù)據(jù)集的典型多跳圖查詢或圖算法。

簡而言之，只有三種可擴(kuò)展圖形數(shù)據(jù)庫架構(gòu)設(shè)計流派，如表所示：

表 1：三種分布式圖譜系統(tǒng)流派的比較。

多環(huán)芳烴架構(gòu)

第一種學(xué)派被認(rèn)為是主從模型的自然擴(kuò)展，我們稱之為分布式共識集群，通常三個實(shí)例組成一個圖數(shù)據(jù)庫集群。在同一集群中擁有三個或奇數(shù)個實(shí)例的唯一原因是更容易投票選出集群的領(lǐng)導(dǎo)者。

如您所見，這種集群設(shè)計模型可能有很多變化；例如，Neo4j 的企業(yè)版 v4.x 支持原始的 RAFT 協(xié)議，只有一個實(shí)例處理工作負(fù)載，而其他兩個實(shí)例被動地從主實(shí)例同步數(shù)據(jù)——當(dāng)然，這是讓 RAFT 協(xié)議工作的一種天真方式. 一種更實(shí)用的處理工作負(fù)載的方法是擴(kuò)充 RAFT 協(xié)議以允許所有實(shí)例以負(fù)載均衡的方式工作。例如，讓領(lǐng)導(dǎo)實(shí)例處理讀寫操作，而其他實(shí)例至少可以處理讀取類型的查詢，以確保整個集群的數(shù)據(jù)一致性。

在這種分布式圖形系統(tǒng)設(shè)計中，一種更復(fù)雜的方法是允許 HTAP（混合事務(wù)和分析處理），這意味著將在集群實(shí)例之間分配不同的角色；領(lǐng)導(dǎo)者將處理 TP 操作，而追隨者將處理 AP 操作，這些操作可以進(jìn)一步細(xì)分為圖算法等角色。

利用分布式共識的圖系統(tǒng)的優(yōu)缺點(diǎn)包括：

• 硬件占用空間?。ǜ阋耍?/li>
• 數(shù)據(jù)一致性好（更容易實(shí)現(xiàn)）。
• 復(fù)雜和深度查詢的最佳性能。
• 可擴(kuò)展性有限（依賴垂直可擴(kuò)展性）。
• 難以處理超過一百億個節(jié)點(diǎn)和邊的單個圖。

下面展示的是來自 Ultipa 的新型 HTAP 架構(gòu)，其主要功能如下：

• 高密度并行圖計算。
• 多層存儲加速（存儲與計算非常接近）。
• 動態(tài)修剪（通過動態(tài)修剪機(jī)制加速圖形遍歷）。
• 超線性性能（即當(dāng)CPU核數(shù)等計算資源增加一倍時，性能提升可達(dá)一倍以上）。

圖 2：Ultipa Graph 的 HTAP 架構(gòu)圖。

請注意，這種 HTAP 架構(gòu)在小于 10B 節(jié)點(diǎn) + 邊的圖形數(shù)據(jù)大小上運(yùn)行良好。因?yàn)楹芏嘤嬎慵铀俣际峭ㄟ^內(nèi)存計算來完成的，如果每十億個節(jié)點(diǎn)和邊消耗大約100GB的DRAM，那么單個實(shí)例可能需要1TB的DRAM來處理一個百億個節(jié)點(diǎn)和邊的圖。

這種設(shè)計的好處是該體系結(jié)構(gòu)可以滿足大多數(shù)真實(shí)場景的要求。即使對于 G-SIB（全球系統(tǒng)重要性銀行），典型的欺詐檢測、資產(chǎn)負(fù)債管理或流動性風(fēng)險管理用例也會消耗大約 10 億個數(shù)據(jù)；一個合理大小的虛擬機(jī)或 PC 服務(wù)器可以很好地容納這樣的數(shù)據(jù)規(guī)模，并且可以通過 HTAP 設(shè)置非常高效。

這種設(shè)計的缺點(diǎn)是缺乏水平（和無限）的可擴(kuò)展性。而這一挑戰(zhàn)在分布式圖形系統(tǒng)設(shè)計的第二和第三流派中得到解決（見表 1）。

下面兩張圖展示了 HTAP 架構(gòu)的性能優(yōu)勢。有兩點(diǎn)需要注意：

1. 線性性能增益：一個 3 實(shí)例 Ultipa HTAP 集群的吞吐量可以達(dá)到獨(dú)立實(shí)例的 ~300%。增益主要反映在 AP 類型的操作中，例如元數(shù)據(jù)查詢、路徑/k-hop 查詢和圖形算法，但不反映在 TP 操作中，例如元數(shù)據(jù)的插入或刪除，因?yàn)檫@些操作主要是在與輔助實(shí)例同步之前的主實(shí)例。
2. 更好的性能 = 更低的延遲和更高的吞吐量（TPS 或 QPS）。

圖 3：HTAP 架構(gòu)的性能優(yōu)勢。

圖 4：Ultipa 和 Neo4j 的 TPS 比較。

網(wǎng)格架構(gòu)

在第二流派中，這種類型的分布式和可擴(kuò)展圖系統(tǒng)設(shè)計也有相當(dāng)多的命名變體（有些是誤導(dǎo)性的）。僅舉幾例：代理、名稱服務(wù)器、MapReduce、網(wǎng)格或聯(lián)合。忽略命名差異；中學(xué)和第一學(xué)校之間的主要區(qū)別在于名稱服務(wù)器充當(dāng)客戶端和服務(wù)器端之間的代理。

作為代理服務(wù)器時，名稱服務(wù)器僅用于路由查詢和轉(zhuǎn)發(fā)數(shù)據(jù)。最重要的是，除了運(yùn)行圖算法外，名稱服務(wù)器還具有從基礎(chǔ)實(shí)例聚合數(shù)據(jù)的能力。此外，在聯(lián)合模式下，可以針對多個基礎(chǔ)實(shí)例運(yùn)行查詢（查詢聯(lián)合）；然而，對于圖算法，聯(lián)邦的性能很差（由于數(shù)據(jù)遷移，就像 map-reduce 的工作原理一樣）。請注意，第二所學(xué)校與第三所學(xué)校在一個方面有所不同：數(shù)據(jù)在功能上進(jìn)行了分區(qū)，但在該設(shè)計學(xué)校中并未分片。

對于圖數(shù)據(jù)集，功能分區(qū)是圖數(shù)據(jù)的邏輯劃分，例如按時間序列（水平分區(qū)）或按業(yè)務(wù)邏輯（垂直分區(qū)）。

另一方面，分片旨在實(shí)現(xiàn)自動化，業(yè)務(wù)邏輯或時間序列無知。分片通?？紤]基于網(wǎng)絡(luò)存儲的數(shù)據(jù)分區(qū)位置；它利用各種冗余數(shù)據(jù)和特殊的數(shù)據(jù)分布來提高性能，例如一方面對節(jié)點(diǎn)和邊緣進(jìn)行切割，另一方面復(fù)制部分切割數(shù)據(jù)以獲得更好的訪問性能。事實(shí)上，sharding 非常復(fù)雜且難以理解。根據(jù)定義，自動分片旨在以最小到零的人為干預(yù)和業(yè)務(wù)邏輯無知來處理不可預(yù)測的數(shù)據(jù)分布，但是當(dāng)面臨與特定數(shù)據(jù)分布糾纏在一起的業(yè)務(wù)挑戰(zhàn)時，這種無知可能會帶來很大問題。

讓我們用具體的例子來說明這一點(diǎn)。假設(shè)您有 12 個月的信用卡交易數(shù)據(jù)。在人工分區(qū)模式下，您自然地將數(shù)據(jù)網(wǎng)絡(luò)劃分為 12 個圖形集，一個圖形集在每個包含三個實(shí)例的集群上包含一個月的事務(wù)，并且此邏輯由數(shù)據(jù)庫管理員預(yù)定義。它強(qiáng)調(diào)通過數(shù)據(jù)庫的元數(shù)據(jù)來劃分?jǐn)?shù)據(jù)，而忽略了不同圖集之間的連接性。它對業(yè)務(wù)友好，不會減慢數(shù)據(jù)遷移速度，并且具有良好的查詢性能。另一方面，在自動分片模式下，由圖系統(tǒng)決定如何劃分（切割）數(shù)據(jù)集，分片邏輯對數(shù)據(jù)庫管理員是透明的。但是開發(fā)人員很難立即弄清楚數(shù)據(jù)存儲在哪里，

僅僅因?yàn)樽詣臃制婕拜^少的人為干預(yù)就聲稱自動分片比功能分區(qū)更智能是不明智的。

你覺得這里有什么不對嗎？隨著人工智能的不斷興起，這正是我們正在經(jīng)歷的，我們允許機(jī)器代表我們做出決定，而且它并不總是智能的?。ㄔ诹硪黄恼轮?，我們將討論從人工智能到增強(qiáng)智能的全球轉(zhuǎn)變的主題，以及為什么圖形技術(shù)在戰(zhàn)略上定位于推動這種轉(zhuǎn)變。）

在 Graph-5 中，展示了屬于第二設(shè)計學(xué)院的網(wǎng)格架構(gòu)；在 Graph-2 的 HTAP 架構(gòu)之上添加的兩個額外組件是名稱服務(wù)器和元服務(wù)器?；旧纤械牟樵兌际峭ㄟ^名稱服務(wù)器代理的，名稱服務(wù)器與元服務(wù)器共同工作以確保網(wǎng)格的彈性；服務(wù)器集群實(shí)例在很大程度上與原始 HTAP 實(shí)例相同（如圖 2 所示）。

圖 5：帶有名稱服務(wù)器和元服務(wù)器的網(wǎng)格架構(gòu)。

參考表1，網(wǎng)格架構(gòu)設(shè)計的優(yōu)缺點(diǎn)可以歸納如下：

• 保留了典型 HTAP 架構(gòu)的所有優(yōu)點(diǎn)/優(yōu)點(diǎn)。
• 可擴(kuò)展性是在性能不變的情況下實(shí)現(xiàn)的（與 HTAP 架構(gòu)相比）。
• 可擴(kuò)展性受限——服務(wù)器集群在 DBA/管理員干預(yù)下進(jìn)行分區(qū)。
• 引入名稱服務(wù)器/元服務(wù)器，使集群管理更加復(fù)雜。
• 名稱服務(wù)器在確保業(yè)務(wù)邏輯在服務(wù)器集群上分布式執(zhí)行并在返回給客戶端之前在其上具有簡單的合并和聚合功能方面至關(guān)重要且復(fù)雜。
• 可能需要業(yè)務(wù)邏輯配合分區(qū)和查詢。

分片架構(gòu)

現(xiàn)在，我們可以迎來具有無限可擴(kuò)展性的分布式圖系統(tǒng)設(shè)計的第三個流派——分片（shard）（見表1）。

從表面上看，分片系統(tǒng)的水平可擴(kuò)展性也像第二種設(shè)計一樣利用名稱服務(wù)器和元服務(wù)器，但主要區(qū)別在于：

• 分片服務(wù)器是真正共享的。
• 名稱服務(wù)器不直接了解業(yè)務(wù)邏輯（如第二所學(xué)校）。間接地，它可以通過自動統(tǒng)計來粗略判斷業(yè)務(wù)邏輯的類別。這個解耦很重要，在二流不可能優(yōu)雅的實(shí)現(xiàn)。

分片架構(gòu)有一些變化；有的叫fabric（其實(shí)更像中學(xué)的grid architecture），有的叫map-reduce，但還是要深入核心的數(shù)據(jù)處理邏輯來揭開謎底。

分片架構(gòu)中只有兩類數(shù)據(jù)處理邏輯：

1. 類型 1：數(shù)據(jù)主要在名稱服務(wù)器（或代理服務(wù)器）上處理
2. 類型 2：數(shù)據(jù)在分片或分區(qū)服務(wù)器以及名稱服務(wù)器上處理。

類型 1 是典型的，正如您在大多數(shù) map-reduce 系統(tǒng)（例如 Hadoop）中看到的那樣；數(shù)據(jù)分散在高度分布式的實(shí)例中。然而，在它們在那里被處理之前，它們需要被提升并轉(zhuǎn)移到名稱服務(wù)器。

類型 2 的不同之處在于，分片服務(wù)器有能力在數(shù)據(jù)被聚合并在名稱服務(wù)器上進(jìn)行二次處理之前在本地處理數(shù)據(jù)（這稱為：在存儲附近計算或與存儲或以數(shù)據(jù)為中心的計算并置）。

正如您所想象的那樣，類型1更容易實(shí)現(xiàn)，因?yàn)樗窃S多大數(shù)據(jù)框架的成熟設(shè)計方案；但是，類型 2 通過更復(fù)雜的集群設(shè)計和查詢優(yōu)化提供更好的性能。type-2 中的分片服務(wù)器提供計算能力，而 type-1 沒有這種能力。

下圖顯示了 type-2 分片設(shè)計：

圖 6：帶有名稱服務(wù)器和元服務(wù)器的分片架構(gòu)。

從傳統(tǒng) SQL 或 NoSQL 大數(shù)據(jù)框架設(shè)計的角度來看，分片并不是什么新鮮事。然而，圖數(shù)據(jù)的分片可能是潘多拉魔盒，原因如下：

• 多個分片將提高 I/O 性能，尤其是數(shù)據(jù)攝取速度。
• 但是多個分片將顯著增加任何跨越多個分片的圖查詢的周轉(zhuǎn)時間，例如路徑查詢、k-hop 查詢和大多數(shù)圖算法（延遲增加可能是指數(shù)級的?。?。
• 圖查詢計劃和優(yōu)化可能非常復(fù)雜，如今大多數(shù)供應(yīng)商在這方面做得很淺，并且有大量的機(jī)會可以即時深化查詢優(yōu)化：
• 級聯(lián)（啟發(fā)式與成本）
• 分區(qū)修剪（實(shí)際上是碎片修剪）
• 索引選擇
• 統(tǒng)計（智能估計）
• 下推（使計算盡可能靠近存儲）等等。

在 Graph-7 中，我們捕獲了一些關(guān)于 Ultipa HTAP 集群和 Ultipa Shard 集群的初步發(fā)現(xiàn)；如您所見，數(shù)據(jù)攝取速度提高了四倍（超線性），但其他一切往往會慢五倍或更多（PageRank 慢 10 倍，LPA 慢 16 倍，等等）

圖 7：HTAP 和分片架構(gòu)之間性能差異的初步發(fā)現(xiàn)。

敬請關(guān)注

有很多機(jī)會可以不斷提高分片架構(gòu)的性能。Ultipa 的團(tuán)隊已經(jīng)意識到，在水平可擴(kuò)展系統(tǒng)上擁有真正先進(jìn)的集群管理機(jī)制和更深入的查詢優(yōu)化是實(shí)現(xiàn)無限可擴(kuò)展性和令人滿意的性能的關(guān)鍵。

最后，分布式圖系統(tǒng)體系結(jié)構(gòu)的第三流派說明了設(shè)計復(fù)雜且有能力的圖系統(tǒng)時所涉及的多樣性和復(fù)雜性。當(dāng)然，鑒于成本、主觀偏好、設(shè)計理念、業(yè)務(wù)邏輯、復(fù)雜性容忍度、可服務(wù)性和許多其他因素，很難說一種架構(gòu)絕對優(yōu)于另一種架構(gòu)——明智的做法是得出架構(gòu)演進(jìn)的方向從長遠(yuǎn)來看，顯然是從第一所學(xué)校到第二所學(xué)校，最后到第三所學(xué)校。然而，大多數(shù)客戶場景可以滿足前兩種流派，人類智能（DBA 干預(yù)）在幫助實(shí)現(xiàn)性能和可擴(kuò)展性的平衡方面仍然具有關(guān)鍵意義，特別是在第二和第三種設(shè)計流派中。

國王公式：

圖增強(qiáng)智能=人類智能+機(jī)器圖算力