今天，我試著簡要綜述幾類不同的圖資料庫的分散式與切圖的設計，希望可以幫助大家瞭解不同專案、產品的設計差異。如果有理解不對的地方，歡迎留言討論。

什麼是分散式系統

一般來說，分散式系統是一組計算機程式的集合，這些程式利用跨多個獨立節點的資源來實現共同的目標。這裡的獨立節點，硬體上大多是指商用伺服器 (Commodity Servers) 而不是大型主機(Mainframe)。這裡的跨節點協同，硬體上大多是基於乙太網裝置或者更高階的 RMDA 裝置。

為什麼我們需要分散式系統?

使用分散式技術的主要目的，本質上是用軟體技術+廉價硬體來換取昂貴硬體裝置(比如主機)的成本;特別是在大多數私有機房環境——而不是公有云端或者超算條件下，此時採購成本是商業決策的重要依據。

除了降低硬體成本外，分散式技術帶來的另一個好處是其“擴充套件性”。透過在原有商用伺服器的數量基礎上，增加幾臺伺服器，再結合分散式軟體的排程和分發能力，使得新加入的這幾臺伺服器也再額外提供更多的服務;

相比於每次擴容都要 1 比 1 採購更多的等數量伺服器，或者購買更高配置的伺服器;分散式技術這一方面使得采購計劃可以按需擴容，降低了一次性的大額資本支出;另一方面也使得業務容量可以更加容易規劃。

>>>>

分散式系統的基礎問題

在分散式技術中，由於資料的儲存和計算需要跨多個獨立節點來實現，因此不得不涉及到一系列基礎技術。在本文中我們只討論兩個：一是提供資料(和服務)的複製或者副本的問題;二是對於那些龐大資料的儲存和計算該如何分發到各個獨立節點上完成。

資料的副本問題

由於是商用伺服器，其硬體上的可靠性和維護遠遠低於主機，網線鬆動、硬碟損壞、電源故障在大型機房中幾乎每小時都在發生，是常態;處理遮蔽這些硬體問題是分散式軟體系統要解決的基本問題。一個常用的方式是為資料(和其服務)提供更多的複製或者副本，這些副本存在於多臺商用伺服器上，當一些副本發生故障時，由正常的副本繼續提供服務;並且當訪問壓力增加時，還可以增加更多的副本來增加服務能力。此外，還需要透過一定的技術手段來保證這些副本的”一致性”，也就是每個伺服器上各個副本的資料是一樣的。當然，在圖資料庫中，副本問題也存在;其處理方式和大多數大資料、RDBMS 會較為類似。

資料的切分問題

單臺伺服器的硬碟、記憶體、CPU 都是有限的，TB、PB 級別的資料透過一定的辦法分發到各個伺服器上，這稱為“切片”。當一些請求要訪問多個切片時，分散式系統要能夠將這些請求拆散分發到各個正確的分片上，並將各分片的返回重新“拼裝”成完整的結果。

圖資料中的切分問題：切圖

在圖資料庫中，這個分發過程被形象的稱為”切圖”：就是把一個大圖切成很多的小圖，把對於這些小圖的儲存或者計算再放置在不同的伺服器上。相比大資料、RDBMS 的大多數方案，值得一些特別的說明。

我們先考慮一個靜態的(不會發生變化的)圖結構，比如“CiteSeer 資料集”，這裡面記錄了 3312 篇論文，以及這些論文之間的引用關係。這是一個很小規模的資料集，因此工程上，我們可以基本相信對於這個資料集的處理，基本可以交給單個伺服器。

再對於 twitter 2010 這個資料集，其中有 1271 萬個頂點和2.3 億條邊，對於今天 (2022) 的主流伺服器來說，相對可以輕鬆處理;但對於 10 年前的伺服器來說，可能就需要選購非常昂貴的高階伺服器才行。

但對於 WDC 資料集 (Web Data Commons)，其中有 17 億個頂點和 640 億條邊，這樣規模的計算對於當前單臺主流伺服器來說也相當困難了。

另一方面，由於人類社會資料產生的速度快於摩爾定律，而資料之間的互動與關係又指數級高於資料產生的速度;“切圖”似乎是一個不可避免的問題;但這聽上去似乎和各種主流分散式技術裡面的資料分片和雜湊的方式沒啥區別。畢竟那麼多大資料系統，不都要”切”嗎

等等——圖真的那麼好”切”嗎?

遺憾的是，並不是。圖領域裡面，”切圖”是一個在技術、產品和工程上需要仔細權衡的問題。

切圖面臨的三個問題

第一個問題，切在哪裡?在大資料或者 RDBMS 中，我們根據記錄或者欄位來進行行切 row-based 或者列切 column-based，也可以根據 ID 規則進行切分;這些在語義和技術都比較直觀。可是圖的特點是它的強連通性，一個點透過一些邊，關聯上了另外一些點，這些點又透過它們的鄰邊關聯上了更多的點，就像全世界的 web 網頁，幾乎都透過超連結關聯在一起，那對於圖來說，切在哪裡才是語義上直觀與自然的。(如果用 RDBMS 的術語，相當於有大量的外來鍵情況下，如何切分)。當然，也存在一些天然語義上的圖切片方式，例如在新冠疫情下，各種毒株在中國的傳染鏈條和國外的鏈條已經天然是兩個不同的網路結構。但此時，引入了第二個問題。

第二個問題，如何保證切了之後，各分片的負載是大致均衡的?天然形成的圖符合冪率定律——20% 的少數節點連線了 80% 的其他節點，這些少數節點也稱為“超級節點”或者“稠密點”。這意味著少數超級節點關聯了大多數其他的平平無奇的節點。因此可以預計含有超級節點的分片(伺服器)的負載和熱點會遠遠大於其他不含超級節點的分片。

網際網路上網站透過超連結形成的關聯網路可視效果，其中的超級網站(節點)清晰可見

第三個問題，當圖網路逐漸演化增長，圖的分佈和連通性也逐漸發生了改變，原有的切分方法逐漸失效，該如何評估和進行重分佈。下圖是人類大腦 860 億個神經元之間的連線可檢視，隨著學習、鍛鍊、睡眠、衰老，神經元連線甚至在周級別就會發生顯著的變化;原先得到的切片方式可能完全跟不上變化。

當然還有其他很多要考慮的問題細節，本文也儘量避免引入太多的技術術語。

遺憾的是，雖然有這些問題(當然其實還有更多)在技術角度並沒有一個通用的最優方案，各個產品針對其重點不得不進行取捨，下面是一些舉例。

不同圖資料庫的切圖方式

1. “分散式”但不”切圖”

這種思路的典型做法是 Neo4j 3.5 雖然採用了分散式的架構，但不進行圖切分。

採用分散式的目的，是為了保證寫入的多副本一致性和讀負載能力。

也就是說每個伺服器中都保留了”全量”的圖資料，因此圖資料不能大於單機的記憶體和硬碟容量;而透過增加寫副本，可以保證寫入過程中單機失效問題;透過增加讀副本，可以提供更多的讀請求能力(不能提高寫請求的能力)。

可以看到對於前面的三個問題，這種方案在產品層面直接避免。但是理論上，這樣的方案稱為“分散式”並沒有什麼問題。

多說一句，由於是單機，資料庫意義上的 ACID 在技術上較為簡單。

Neo4j 3.5 的因果叢集架構

2. 分散式，由使用者來”切圖”

這個典型的代表是 Neo4j 4.x Fabric。根據業務情況，使用者指定將每個部分的子圖放在一個(組)伺服器上，例如在一個叢集內，E號產品的圖放在E號伺服器上，N號產品的圖放在 N號伺服器上。(當然，為了服務本身的可用性，這些伺服器還可以採用上文中 Causal Cluster 的方案)。在這個過程中，不論是查詢還是寫入，都需要使用者指定要訪問哪個服務。Fabric 輔助使用者代理路由。這個方案和 RDBMS 的分表非常類似，使用者在使用過程中自己指定要使用那個分割槽或者分表，”切分”這個動作，使用者是有著完全的掌控。

可以看到對於前面的三個問題，這種方案在產品層面完全交給了使用者來決定。當然，這樣的方案也可以稱為“分散式”。

多說一句，雖然可以保證 E 伺服器內部的 ACID。但因為存在一定數量的邊”橫跨”兩個伺服器，技術上不保證這些”橫跨”邊操作的 ACID。