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

不要被誤導(dǎo)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 線性性能增益：一個(gè) 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)勢(shì)。

圖 4：Ultipa 和 Neo4j 的 TPS 比較。

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

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

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

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

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

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

僅僅因?yàn)樽詣?dòng)分片涉及較少的人為干預(yù)就聲稱自動(dòng)分片比功能分區(qū)更智能是不明智的。

你覺(jué)得這里有什么不對(duì)嗎？隨著人工智能的不斷興起，這正是我們正在經(jīng)歷的，我們?cè)试S機(jī)器代表我們做出決定，而且它并不總是智能的?。ㄔ诹硪黄恼轮校覀儗⒂懻搹娜斯ぶ悄艿皆鰪?qiáng)智能的全球轉(zhuǎn)變的主題，以及為什么圖形技術(shù)在戰(zhàn)略上定位于推動(dòng)這種轉(zhuǎn)變。）

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

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

參考表1，網(wǎng)格架構(gòu)設(shè)計(jì)的優(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í)行并在返回給客戶端之前在其上具有簡(jiǎn)單的合并和聚合功能方面至關(guān)重要且復(fù)雜。
• 可能需要業(yè)務(wù)邏輯配合分區(qū)和查詢。

分片架構(gòu)

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

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

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

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

分片架構(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í)例中。然而，在它們?cè)谀抢锉惶幚碇?，它們需要被提升并轉(zhuǎn)移到名稱服務(wù)器。

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

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

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

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

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

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

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

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

敬請(qǐng)關(guān)注

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

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

國(guó)王公式：

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