今天，我試着簡要綜述幾類不同的圖數據庫的分佈式與切圖的設計，希望可以幫助大家瞭解不同項目、產品的設計差異。如果有理解不對的地方，歡迎留言討論。
什麼是分佈式系統
一般來說，分佈式系統是一組計算機程序的集合，這些程序利用跨多個獨立節點的資源來實現共同的目標；這裏的獨立節點，硬件上大多是指商用服務器（Commodity Servers）而不是大型主機（Mainframe）；這裏的跨節點協同，硬件上大多是基於以太網設備或者更高端的 RMDA 設備。
爲什麼我們需要分佈式系統？
使用分佈式技術的主要目的，本質上是用軟件技術+廉價硬件來換取昂貴硬件設備（比如主機）的成本；特別是在大多數私有機房環境——而不是公有云端或者超算條件下，此時採購成本是商業決策的重要依據。
除了降低硬件成本外，分佈式技術帶來的另一個好處是其“擴展性”，通過在原有商用服務器的數量基礎上，增加幾臺服務器，再結合分佈式軟件的調度和分發能力，使得新加入的這幾臺服務器也再額外提供更多的服務；
相比於每次擴容都要 1 比 1 採購更多的等數量服務器，或者購買更高配置的服務器；分佈式技術這一方面使得采購計劃可以按需擴容，降低了一次性的大額資本支出；另一方面也使得業務容量可以更加容易規劃。
分佈式系統的基礎問題
在分佈式技術中，由於數據的存儲和計算需要跨多個獨立節點來實現，因此不得不涉及到一系列基礎技術。在本文中我們只討論兩個：一是提供數據（和服務）的拷貝或者副本的問題；二是對於那些龐大數據的存儲和計算該如何分發到各個獨立節點上完成？
一、數據的副本問題
由於是商用服務器，其硬件上的可靠性和可維護性遠遠低於主機，網線鬆動、硬盤損壞、電源故障在大型機房中幾乎每小時都在發生，是常態；處理屏蔽這些硬件問題是分佈式軟件系統要解決的基本問題。一個常用的方式是爲數據（和其服務）提供更多的拷貝或者副本，這些副本存在於多臺商用服務器上。當一些副本發生故障時，由正常的副本繼續提供服務；並且當訪問壓力增加時，還可以增加更多的副本來增強服務能力。此外，還需要通過一定的技術手段來保證這些副本的“一致性”，也就是每個服務器上各個副本的數據是一樣的。
當然，在圖數據庫中，副本問題也存在；其處理方式和大多數大數據、RDBMS 會較爲類似。
二、是數據的切分問題
單臺服務器的硬盤、內存、CPU 都是有限的，TB、PB 級別的數據通過一定的辦法分發到各個服務器上，這稱爲”切片”。當一些請求要訪問多個切片時，分佈式系統要能夠將這些請求拆散分發到各個正確的分片上，並將各分片的返回重新“拼裝”成完整的結果。
圖數據中的切分問題：切圖
在圖數據庫中，這個分發過程被形象的稱爲“切圖”：就是把一個大圖切成很多的小圖，把對於這些小圖的存儲或者計算再放置在不同的服務器上。相比大數據、RDBMS 的大多數方案，值得一些特別的說明。
我們先考慮一個靜態的（不會發生變化的）圖結構，比如“CiteSeer 數據集”，這裏面記錄了 3,312 篇論文，以及這些論文之間的引用關係；這是一個很小規模的數據集，因此工程上，我們可以基本相信對於這個數據集的處理是可以交給單個服務器。
再對於 twitter2010 這個數據集，其中有 1,271 萬個頂點和 2.3 億條邊，對於今天（2023 年）的主流服務器來說，相對可以輕鬆處理；但對於 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 的因果集羣架構
https://medium.com/neo4j/querying-neo4j-clusters-7d6fde75b5b4
2. 分佈式，由用戶來”切圖”
這個典型的代表是 Neo4j 4.x Fabric。根據業務情況，用戶指定將每個部分的子圖放在一個(組)服務器上，例如在一個集羣內，E 號產品的圖放在 E 號服務器上，N 號產品的圖放在 N 號服務器上。當然，爲了服務本身的可用性，這些服務器還可以採用上文中 Causal Cluster 的方案。
在這個過程中，不論是查詢還是寫入，都需要用戶指定要訪問哪個服務。Fabric 輔助用戶代理路由。這個方案和 RDBMS 的分表非常類似，用戶在使用過程中自己指定要使用那個分區或者分表，“切分”這個動作，用戶是有着完全的掌控。
可以看到對於前面的三個問題，這種方案在產品層面完全交給了用戶來決定。當然，這樣的方案也可以稱爲“分佈式”。
多說一句，雖然可以保證 E 服務器內部的 ACID。但因爲存在一定數量的邊”橫跨”兩個服務器，技術上不保證這些”橫跨”邊操作的 ACID。
Neo4j Fabric 架構
https://neo4j.com/developer/neo4j-fabric-sharding/
3. 非對等分佈式，”切圖”， 粗顆粒度的副本
在這種方案中，既有多副本，也有“切圖”，這兩個過程也都需要少量用戶的介入。
Tigergraph 的切圖方案，可訪問視頻查看：https://www.youtube.com/watch?v=pxtVJSpERgk
在 TigerGraph 的方案中，點和邊（在編碼後），會分散到多個分片上。
上面的三個問題，第 1 和 2 可以通過編碼部分的技巧來部分緩解，並將部分查詢或者計算的決策（單機還是分佈式模型）交給用戶決定來實現權衡。
TigerGraph 的單機查詢模式和並行計算模式
多說一句，這樣一組分片必需要完整並一模一樣的複製多份（因此擴容顆粒度是整個圖，而不是某個分片）。相對擴容時的單次支出較大。
4. 全對等分佈式，”切圖”，細顆粒度的副本
還有一些方案的架構設計目的中，相對把圖的擴展性/彈性排在整個系統設計最高的優先級。其假設是數據產生的速度快於摩爾定律，而數據之間的交互與關係又指數級高於數據產生的速度。因此，必須要能夠處理這樣爆炸增長的數據，並快速提供服務。
在這種架構中，通常的顯著特點是把存儲層和計算層物理上分開，各自實現細顆粒度的擴容能力；
數據分片由存儲層負責，通常用 hash 或者一致性 hash 的方案進行切分，根據點的 ID 或者主鍵進行散列。（回答第一個問題）
NebulaGraph 的架構圖如上，引用自論文：Wu, Min, et al. "Nebula Graph: An open source distributed graph database." arXiv preprint arXiv:2206.07278 (2022).
圖引用自：Li C, Chen H, Zhang S, et al. ByteGraph: A High-Performance Distributed Graph Database in ByteDance[J].
爲了處理超級節點和負載均衡（第二個問題），再引入一層數據結構 B+tree，將大的超級節點拆分成更多小的處理單元，並工程上實現線程間的負載切換，和獨立擴容計算層。對於第三個問題，通過引入細顆粒度的切片，單獨實現部分切片的擴容
當然，這種方案也可以稱爲“分佈式”。
以上四種方案，在產品和技術層面做了不同的權衡，各種側重以適合各自的用戶業務場景。但它們都可以稱爲“分佈式”。
擴展閱讀
- 圖的切分問題：在單機上如何進行切圖，已經得到了大量的研究。這裏推薦工具 METIS （http://glaros.dtc.umn.edu/gkhome/metis/metis/overview）在分佈式環境的切圖是一個比(fei)較(chang)困難的問題。這裏推薦一些業界的討論：
關於“僞分佈式”(Pseudo-Distrubuted Mode)
一般來說，這是用單服務器上的運行模擬在多個服務器的運行；特別適合於學習或者調試。
- 關於圖領域的綜述
- Sahu, S., Mhedhbi, A., Salihoglu, S., Lin, J., ¨Ozsu, M.T.: The ubiquity of large graphs and surprising challenges of graph processing: extended survey. VLDB J. 29(2-3), 595–618 (2020)
- Sakr, S., Bonifati, A., Voigt, H., Iosup, A., Ammar, K., Angles, R., Yoneki: The future is big graphs: a community view on graph processing systems. Communications of the ACM 64(9), 62–71 (2021)
Disclaimer
1.以上提到的技術方案，是作者的理解和分享，如有錯誤歡迎指出，並沒有商業競爭目的。
2.爲了降低讀者理解難度,做了很大程度的簡化，並不表示原方案是如此簡單。
謝謝你讀完本文 (///▽///)
NebulaGraph Desktop，Windows 和 macOS 用戶安裝圖數據庫的綠色通道，10s 拉起搞定海量數據的圖服務。通道傳送門：http://c.nxw.so/6TWJ0
想看 nebula-br 源碼的小夥伴可以前往 GitHub 閱讀、使用、(з)-☆ star 它 -> GitHub；和其他的 NebulaGraph 用戶一起交流圖數據庫技術和應用技能，留下「你的名片」一起玩耍呢~