導讀：本文由香港中文大學James Cheng教授團隊貢獻，James Cheng教授長期從事分布式系統、分布式計算、圖計算與圖數據管理等方向的研究工作。曾與阿里巴巴、華為、騰訊、字節跳動等多家公司在大數據計算系統、存儲系統、調度系統、深度學習系統等方向上展開項目合作，曾獲得香港青年科學家稱號，ATC'21最佳論文獎。

接下來，大家一起來了解下圖數據庫技術發展的前世今生吧：

一、背景介紹

圖（Graph）是一種由點（Vertex）和邊（Edge）及其屬性（Property）構成的通用數據結構，以表達自然世界中實體間的關聯關系，被廣泛應用于知識圖譜、社交網絡、金融網絡、生物蛋白質分析等各種垂直領域。隨著各行各業生產的數據規模增長，大規模圖數據管理在近十年來受到了越來越多的重視，圖數據庫系統也正在被廣泛的開發和研究，以實現高效的圖狀數據存儲和查詢。為了存儲圖數據，一些圖數據庫利用傳統的數據庫模型（如關系型數據庫，文檔數據庫，列存數據庫）來轉換圖數據；而還有一些圖原生的數據庫（比如Neo4j、TigerGraph等），則專門為圖數據結構設計了高效的存儲格式。

與傳統數據庫相比，圖數據庫的本質區別在于可以更高效的存儲和查詢圖數據。不同的存儲模型導致了不同的查詢執行策略和對圖的具體操作行為，這將最終導致各種性能。例如，在原生的圖數據庫中，可以通過掃描無索引的鄰接列表來執行遍歷操作，在基于關系型表而設計的圖數據庫中，則需要通過對多個表的Join操作來執行。隨著遍歷跳數的增加，對于冪律分布的圖數據來說，用于Join的表的大小可能呈指數級增長，這將導致嚴重的性能瓶頸。而另一方面，關聯型的數據以Table的形式存儲在關系型數據庫中，可以實現更好的數據平衡和定位。對于一些原生的圖數據庫來說，由于圖結構的不規則性，不規則的數據模式導致了較差的數據局部性，并為數據檢索帶來了額外的開銷。

本文將梳理圖數據庫發展的歷史脈絡與技術演進，并簡單討論筆者認為圖數據庫今后的發展方向。

二、圖數據庫的發展歷史

從Google分別于2003、2004、2006年在SOSP'03、OSDI'04、OSDI'06發表經典三駕馬車（GFS，MapReduce，BigTable）論文開始，以Hadoop開源生態為中心的大數據體系得到了蓬勃的發展，數據模型逐步由以表（Table）的主流形式來存儲和查詢關系型數據慢慢發展到以鍵值、寬列、文檔、圖等各種形式來存儲和查詢海量數據的NoSQL體系。

日益膨脹和快速發展的各類應用所產生的數據使得NoSQL體系對數據存儲與查詢的要求變得多種多樣：高吞吐、高可用、低時延、強一致等等。因此在大數據時代下，各類組件百花齊放，迭代升級也非常迅速。圖數據存儲作為NoSQL體系中的一種數據建模方式，主要用以表達現實世界中實體間的關聯關系；圖數據庫則是與之對應的存儲系統，用以存儲和管理（增刪改查）圖狀數據。

圖數據庫是一種非關系型數據庫，以解決現有關系數據庫的局限性。圖模型明確地列出了數據節點之間的依賴關系，而關系模型和其他NoSQL數據庫模型則通過隱式連接來鏈接數據。圖數據庫從設計上，就是可以簡單快速地檢索難以在關系系統中建模的復雜層次結構的。圖數據庫的底層存儲機制可能各有不同。有些依賴于關系引擎并將圖數據“存儲”到表中（雖然表是一個邏輯元素，但是這種方法在圖數據庫、圖數據庫管理系統和實際存儲數據的物理設備之間施加了另一層抽象）。另一些則使用鍵值存儲或文件導向的數據庫進行存儲，使它們具有固有的NoSQL結構。大多數基于非關系存儲引擎的圖數據庫還添加了標記或屬性的概念，這些標記或屬性本質上是具有指向另一個文檔的指針的關系。這樣就可以對數據元素進行分類，以便于集中檢索。

圖片來源自：https://k21academy.com/dba-to-cloud-dba/nosql-database-service-in-oracle-cloud/

從大約2010年開始，各種構建于NoSQL體系或者關系型數據庫之上的圖數據庫便涌現而出，比如：Titan, JanusGraph, RedisGraph, Sparksee, AgensGraph, OrientDB 等等, 當然同一時間也出現了Neo4j這種為圖數據而專門設計的圖原生存儲數據庫，其現今已經發展成為了圖數據庫領域商業化的領頭羊。我們下面將根據存儲模型的不同對這些圖數據庫做一個簡單的歸類和討論。但由于篇幅有限，詳細的分析和性能對比不會在本文展開，我們今后將會在arXiv上提交一篇Experimental Track的學術論文來系統性地分析這些圖數據庫的設計方案和性能測試報告。

1、圖數據庫的存儲設計?

如何存儲圖數據以實現高效查詢和更新是圖數據庫的一個重要問題。對于一個圖模型G，應該考慮的存儲數據包括點（V）、邊（E）、頂點屬性（VP）和邊屬性（EP）。一個圖通常又可以用三種常見的方法來表示：鄰接表、鄰接矩陣和邊列表。鄰接表通常將一個頂點的所有鄰居作為一個數組來存儲。因此，一條邊從兩個方向上會出現在兩個不同頂點的鄰接表中。鄰接矩陣選擇用一個矩陣來表示兩個頂點之間是否有一條邊，而邊表會獨立存儲所有的邊集合，并使用指針讓每個頂點記錄它與自己鄰居的關系。

2、圖原生數據庫

（1）Neo4j

Neo4j定制化的分別將四種對象（即點、邊、點屬性和邊屬性）作為記錄來存儲，并利用指針將它們連接起來。圖1展示了Neo4j如何在物理存儲上組織所有對象。一個頂點/邊的所有屬性都以鏈表的形式連接起來，其頭部由相關頂點/邊的實例的指針指向。與屬性類似，一個頂點所有相鄰的邊也被連接在一起，但用雙鏈接列表來呈現。每個邊的實例將只存儲一次，但由兩個鄰接表連接。因此，要找到邊的實例，唯一的方法就是遍歷頂點上的雙向鏈表，這就會產生對邊集的掃描開銷。然而，Neo4j中的遍歷可以通過雙鏈表的形式來加速。具體來說，考慮到沒有頂點屬性訪問的兩跳遍歷，Neo4j需要：1）從起始頂點開始遍歷雙向鏈表，找到第一條邊；2）迭代步驟（1）中找到的所有邊上連接的其他雙向鏈表，完成下一跳。這種兩跳遍歷可以擺脫在兩個步驟之間加載頂點記錄，以減少磁盤I/O。

圖1 - Neo4j的存儲模型

圖2說明了Neo4j如何將所有記錄存儲在磁盤上。我們可以看到，每條記錄都有自己固定大小的塊，相同類型的記錄被連續地存儲在一起，形成一張表。因此，表中的每條記錄都可以根據其偏移量進行有效定位，其中偏移量是根據記錄的ID計算的。對于屬性值，如果它的長度大于一個記錄塊的默認長度，那么Neo4j將把這個屬性值的超出部分存儲在另一個由若干固定大小的槽組成的分離數據塊中。

圖2 - Neo4j不同類型的數據記錄在磁盤上的組織形式

（2）RedisGraph

RedisGraph是一個基于Redis的圖存儲，Redis是一個基于內存的鍵值存儲系統。然而，RedisGraph沒有將圖數據建模為適合Redis存儲模型的鍵值存儲，而是利用鄰接矩陣設計了自己的存儲模型，只利用了Redis的內存分配和索引管理。這就是我們將RedisGraph列為圖原生存儲數據庫的原因。

圖2展示了RedisGraph是如何建模和存儲圖的。點和邊的屬性被存儲到一個頂點/邊緣容器的數組中。每個頂點/邊容器都有一個header來記錄當前容器的元數據，包括存儲的頂點/邊的數量，容器的容量，以及使用的內存大小。對于每個頂點/邊，其屬性被存儲在一個鏈表中，鏈表里的每個節點是一個具有固定大小的數據塊。屬性的鍵值對被按順序存儲在數據塊中。當前一個數據塊滿了之后，一個新的數據塊將被追加到鏈表的尾部。此外，RedisGraph將具有相同標簽的頂點/邊放到同一個容器中，以獲得更好的數據局部性。由于RedisGraph需要為每個頂點/邊和數據塊從Redis存儲層調用內存分配，它根據容器的容量預先分配了容器所需的所有內存，以避免頻繁且昂貴的內存分配調用。

RedisGraph中的所有邊都以鄰接矩陣的格式存儲。如果兩個頂點之間存在一條邊，就會在鄰接矩陣的對應位置上存儲一個指向該邊實例的指針，否則就不存儲。由于圖的性質，鄰接矩陣大多是一個稀疏矩陣。因此，RedisGraph選擇使用了壓縮稀疏行（CSR）的格式來實現對矩陣的存儲。而多跳遍歷可以通過RedisGraph中的矩陣乘法來計算。然而，在CSR格式下，圖拓撲結構的變化對CSR的更新是很昂貴的，而且會給遍歷操作帶來嚴重的開銷。

圖3 - RedisGraph的存儲Layout設計

（3）Sparksee

Sparksee以前被稱作DEX，也是一個圖數據庫。它利用基于位圖的索引bitmap來減少存儲開銷，并通過基于位（bit）的邏輯操作來加速與圖相關的工作負載。

為了存儲一個圖，Sparksee首先將所有的數據分為不同的值集（value set）。具體來說，一個值集是由以下一種鍵值對組成的：1.（頂點/邊ID，Label）；2.（邊ID, 頭/尾頂點ID）; 3.（頂點/邊ID, 屬性鍵的屬性值）。對于每個值集，Sparksee用兩個map來存儲所有的對：一個map記錄每個對象（即頂點/邊）到一個值（即Label、頭/尾頂點或屬性值），而另一個map則是將不同的值映射到一個位圖（如圖4所示）。因此，圖的拓撲信息是以邊列表和鄰接表（即位圖）的形式存儲在值集中的。

位圖結構是一個具有可變長度的bits序列，它由第一個和最后一個非零元素定義。位圖中的每個位都與一個對象的標識符oid相關（即頂點/邊ID）。如果該對象有相關的值，相應的位置就被設置為1，否則為0。通過使用位圖結構，Sparksee可以將一些基于圖的操作轉化為位運算操作。由于位圖的長度是由第一個和最后一個非零元素定義的，所以位圖不可避免地會變得很大，這就造成了數據檢索的開銷。為了壓縮位圖，Sparksee將一個位圖分割成多個長度為32位的子序列。每個子序列都與一個給定的ID配對，并存儲在一個排序的樹中。為了減少空間的使用，只有非零的子序列會被存儲并被排序樹索引。由于bits是以連續的方式分割的，Sparksee可以在數據檢索時快速定位到某個bits的子序列ID。

圖4：Sparksee中的值集與位圖

3、基于RDBMS構建的圖數據庫?

由于關系型數據庫有相對成熟的技術和性能優化，許多圖數據庫都是建立在RDBMS或關系型數據模型之上的（比如SQLGraph, AgensGraph, etc.）。AgensGraph就是一個構建于PostgreSQL之上的圖數據庫，Oracle Spatial and Graph則是Oracle中支持圖數據存儲的一個組件。為了在關系數據庫中建立圖數據模型，頂點和邊通常被存儲為表中的記錄，其中的每一列代表一種屬性。除屬性外，邊記錄還將其源點和目標點作為兩個外鍵存儲，以支持遍歷操作，這可以通過表的Join來完成。而連續的Join會嚴重損害多跳遍歷的性能，特別是當表內有大量頂點時。

（1）AgensGraph

我們以AgensGraph為例來介紹在關系型數據庫中存儲圖數據的方案。由于頂點/邊的屬性在圖中并不總是有固定的Schema，AgensGraph用基于JSON的表來存儲屬性，所有的屬性都以JSON格式存儲在一列。具體來說，AgensGraph表中的一行記錄，對于頂點是按照（VertexID, Label, Properties in JSON）的格式來存儲的，對于邊則是按照（EdgeID, Source VertexID, Destination VertexID, Properties in JSON）的格式存儲的。圖5顯示了AgensGraph是如何管理磁盤上的表數據的。表文件首先被切成具有固定大小的多個頁。每頁的頁頭存儲了本頁的元數據，包括存儲的記錄數和這一頁的使用空間。為了更好地在頁中進行順序掃描，每條記錄都有一個固定大小的指針塊，包含相關記錄數據的偏移量和長度。指針塊以正向方式從頁頭開始存儲，而記錄數據則以反向方式從頁尾開始存儲。

圖5 - AgensGraph中圖數據在Table中以頁的方式的存儲格式

4、基于文檔構建的圖數據庫?

文檔存儲的基本單元是一個以某種標準格式（如JSON、XML或BSON等二進制格式）編碼的文檔。通過這些半結構化的格式，文檔可以靈活地以鍵值對的形式存儲頂點/邊的屬性，且沒有固定的Schema。因此，在基于文檔的圖數據庫中，一組頂點/邊被存儲為一個文檔。為了連接頂點和與之關聯的鄰接邊，頂點文檔會包含該點的鄰接表，其以一組嵌套的鍵值來表示，對應的值是一個List或者是一組記錄了label的鍵值對。

（1）OrientDB

OrientDB是一個典型的基于文檔的圖數據庫。圖6展示了OrientDB是如何存儲頂點和邊文件的。頂點和邊首先被它們的標簽分離成類。一個類可以為存儲的文檔定義一個屬性集。雖然一個文檔不一定包含所有定義的屬性，但類仍然可以幫助在訪問實際數據前對不存在的屬性進行預過濾。每個類可以進一步分割成多個cluster，以便根據CPU核數實現并行數據訪問。每個頂點/邊分配了一個唯一的RID，以便快速定位，RID由類ID、Cluster ID和在Cluster中的位置構成。

除了RID和屬性，頂點文件還存儲了兩種不同格式的鄰接表（即regular Edgelist和lightweight Edgelist）。Regular Edgelist存儲了相鄰邊的RID，而Lightweight Edgelist包含了入向頂點的RID。因此在遍歷時，如果查詢不需要訪問邊屬性，OrientDB可以使用Lightweight Edgelist來直接獲得目標頂點。否則，OrientDB將通過RID找到邊文檔來訪問邊屬性，最后獲得存儲在邊文檔中的頂點RID（即源點和目標點）。

圖6 - OrientDB的數據存儲格式

5、基于寬列構建的圖數據庫?

寬列存儲是由表組成的，表是行的集合。與關系型數據庫不同，寬列存儲沒有要求固定的Schema。每一列的名稱因行而異，每一行的鍵值對都存儲在這一列中。因此，寬列存儲也可以被視為二維鍵值存儲。Google的BigTable和Hadoop生態體系下的HBase就是典型的寬列存儲。其表中的每一行都包含任意數量的單元格，每個單元格都存儲一個鍵值對。利用寬列模型來存儲圖數據的典型圖數據庫有Titan和JanusGraph。

（1）JanusGraph

JanusGraph的底層存儲就是HBase, 在HBase中每一行都是一個由ID唯一識別的頂點。如圖7(a)所示，JanusGraph將點的每個屬性和鄰接邊都存儲到行中的一個單元格中。為了快速檢索，屬性按屬性ID排序，邊按邊的標簽排序。圖7(b)顯示了JanusGraph中邊和屬性存儲的詳細格式。一條邊的key是由label和direction的復合ID、排序鍵、相鄰頂點ID和邊ID組成的。排序鍵可以由邊的label和其他邊的屬性來組成，以便加快遍歷。

由于JanusGraph沒有將邊組織成Row，所有的屬性都被序列化并存儲在表示邊的列單元中。為了避免在屬性過濾時對屬性列單元中的值進行頻繁的反序列化，JanusGraph存儲了signature key，其包括了所有的屬性ID，以便快速檢查屬性是否存在。屬性列單元的結構比邊列單元相對簡單，屬性單元的key字段只存儲一個由屬性key編碼的ID，而value字段包含一個為每個屬性鍵和屬性值分配的唯一ID。

圖7 - JanusGraph的圖數據存儲格式

三、圖數據庫的現狀

隨著大數據基礎設施的不斷發展與完善， 數據庫產品的研發方向也正在從不斷提升經典存儲系統的性能與穩定性逐步轉向為針對各種垂直類場景的特定性能要求而定制化設計。例如，隨著物聯網時代的到來，各類傳感器、汽車、基站等端設備產生的數據規模正不斷增大，該場景具有典型的存量數據大、新增數據多（采集頻率高、設備量多）的特點，對數據庫的實時性能要求也比較高，通常需支持千萬級QPS的寫入，以及毫秒級的查詢響應時間。傳統的數據庫架構很難再滿足這種特定場景下的讀寫需求，用戶已不再考慮一招能解決所有問題（one-size-fits-all）的方案，而逐漸轉向針對不同工作負載給出特定數據庫選型方案的思路。由此，各種垂直類型的數據庫不斷被提出，例如圖數據庫、時序數據庫、流式數據庫、向量數據庫等等。

圖數據庫的架構和性能需求也在不斷與時俱進，進入"2.0時代"。一方面圖數據的規模越來越大，一套成熟的分布式高可用方案已經變成對圖數據庫的基本需求，另一方面對圖數據的查詢復雜度也在進一步提升，人們越來越想從高階的多跳查詢（>3跳）中挖掘出關聯關系數據的深層價值。而圖數據本來天生就具有數據傾斜的特點，出入度大的點往往占比很少，而與之相關聯的查詢卻需要訪問很大比例的全圖數據才能返回最終結果，因此需要更多的算力。然而，在圖上對度數大的點的訪問是很難預測的，如何在不影響吞吐的情況下，降低查詢的平均延時以保證服務的P99能滿足在線要求？單是這一點就是件挑戰力十足的事情。

而隨著圖數據的價值不斷被認可，越來越多的應用場景也開始使用圖模型來表達業務數據（例如，金融網絡中的反洗錢、反套現，電商交易網絡中的商品推薦，短視頻中的點贊關注記錄等）。數據從產出之初，就被業務寫入到了圖數據庫中，并期望可以做到寫后的實時可見，因此在高可用的前提下，圖數據庫對數據的一致性、事務性也開始有了要求。新一代的圖數據庫架構在時間和業務需求的催化下，被自然衍生了出來。圖數據庫的熱度也一路水漲船高，如DB-Engines網站所示，從2013年開始至今，圖數據庫的流行趨勢變化是所有垂類數據庫中最高的，且看趨勢至少未來5年也依然會保持最高。2023年，圖數據庫的標準查詢語言GQL也會發布，各種類型的圖數據庫查詢語言（e.g., Gremlin, Cypher, GSQL, nGQL）相信終將迎來統一，這可以進一步促進圖數據庫生態的發展。

接下來，本文將盤點近幾年有代表性的若干個現代圖數據庫的架構設計，簡單講解下圖數據庫2.0時代對高可用性和高性能的業界實現方案。

1、NebulaGraph

NebulaGraph是一款開源的高性能分布式圖數據庫，一個完整的 Nebula 部署集群包含三個服務，Query Service， Storage Service 和 Meta Service， 如圖8所示：

圖8 - NebulaGraph的系統架構

圖片來源自：https://www.nebula-graph.com.cn/posts/nebula-graph-architecture-overview

Meta Service集群基于raft協議保證了數據的一致性和高可用。Meta Service不僅負責存儲和提供圖數據的meta信息，如schema、partition信息等，還同時負責指揮數據遷移及 leader 的變更等運維操作。左側主要服務采用了存儲與計算分離的架構，虛線以上為計算，以下為存儲。計算層和存儲層可以根據各自的情況彈性擴容、縮容，也使水平擴展成為可能。此外，存儲計算分離使得 Storage Service 可以為多種類型的計算層或者計算引擎提供服務。

Nebula的每個計算節點都運行著一個無狀態的查詢計算引擎，而節點彼此間無任何通信關系。計算節點從Meta Service讀取meta信息然后將請求發送到對應的Storage Service實例上。這樣設計使得計算層更容易使用 K8s 管理或部署在云上。每個查詢計算引擎都能接收客戶端的請求，解析查詢語句，生成抽象語法樹（AST）并將 AST 傳遞給執行計劃器和優化器，最后再交由執行器執行。

Storage Service采用shared-nothing的分布式架構設計，每個存儲節點都有多個本地 KV 存儲實例作為物理存儲。Nebula同樣用Raft來保證這些 KV 存儲之間的一致性，并在KV語義之上封裝了一層圖語義層，用于將圖操作轉換為下層的KV操作。圖數據（點和邊）通過Hash的方式存儲在不同Partition中，這些Partition分布在所有的存儲節點上，分布信息則存儲在Meta Service中。

2、ByteGraph

ByteGraph是字節跳動基礎架構團隊自研的分布式圖數據庫產品，并在字節內部的近一百條業務線上得到了廣泛的落地，包括抖音上的好友關系，用戶-視頻點贊關系等。ByteGraph的架構（如圖9所示）整體上跟Nebula較為類似，也采用計算-存儲分離的架構，不同的地方在于ByteGraph的存儲層進一步劃分成了內存存儲層和磁盤存儲層。

圖9 - ByteGraph的系統架構

圖片來源自：https://zhuanlan.zhihu.com/p/109401046

ByteGraph的查詢層同樣沒有狀態，可以水平擴容，主要工作是做讀寫請求的解析和處理（將數據請求基于一致性哈希規則分發給存儲層實例并收集返回的請求結果）。內存存儲層的實現和功能有點類似內存數據庫，提供高性能的數據讀寫功能，具體提供點邊的讀寫接口并支持算子下推：通過把計算(算子)移動到存儲層實例上執行，以有效提升讀性能。內存存儲層整體上作為了磁盤存儲層的緩存，提供緩存管理的功能，支持緩存加載、換出、緩存和磁盤同步異步sync等功能。磁盤存儲層是一個單獨部署的分布式鍵值對存儲服務，將圖數據以KV pairs的形式持久化存儲在磁盤上。

ByteGraph針對熱點數據訪問做了自己的存儲優化，從系統角度當然希望存儲在KVS中的KV pairs大小控制在KB量級且大小均勻。其將頂點的所有出度鄰居平均拆分成多個KV對，所有KV對形成一棵邏輯上的B-Tree，數據結構如下圖所示。值得一提的是，ByteGraph在今年的VLDB'22 Industrial Track上發表了一篇論文，對其設計動機和性能分析都做了比較詳細的描述，具體可參考論文地址：

https://vldb.org/pvldb/vol15/p3306-li.pdf

圖片來源自：https://zhuanlan.zhihu.com/p/109401046

3、EasyGraph

EasyGraph是騰訊TEG數據平臺部自研的分布式圖數據庫產品，目前已在騰訊內部如企業微信、微信支付、王者榮耀、和平精英、QQ、廣告等諸多關鍵產品線落地，并且作為騰訊云KonisGraph圖數據庫對外輸出。

圖片來源自：https://zhuanlan.zhihu.com/p/450584880

EasyGraph整體上采用存儲計算分離架構，在KV存儲組件上適配了開源的TiKV及內部分布式KV；TiKV基于rocksdb實現了分區和副本管理，并在TiDB上有成熟的解決方案，適配TiKV可以實現存儲層的可擴展性，TiKV基于Raft算法實現了數據多副本之間的一致性。EasyGraph也自研了圖可視化分析引擎，在可視化效果及規模上都有明顯的提升，支持幾十萬級點邊渲染分析，以及用戶級靈活的布局展示和可視化分析。

EasyGraph也支持AngelGraph圖計算引擎，其包括幾十種傳統圖算法、Embedding及GNN算法，如社區發現、標簽傳播、隨機游走等算法，這些算法進一步提升對圖數據的挖掘分析能力。

4、Neo4j latest?

最新版本的Neo4j已經支持了分布式模式以完善對高可用性和可擴展性的支持，其通過多副本的方式來防止數據丟失，如下圖所示：

圖片來源自：https://neo4j.com/docs/operations-manual/current/clustering/introduction/

Neo4j通過Primary Mode將一份數據備份到多個servers上并通過raft協議來保證一致性。與之相對應地，一次寫入需要保證至少在(N/2+1）個副本上寫成功才可以返回成功，因此在primary mode下服務實例數量越多，寫性能就越差。而為了實現可擴展性，Neo4j也支持了Secondary mode，即支持對多個只讀副本的部署以提高集群整體的讀能力，只讀副本是功能齊全的Neo4j數據庫，能夠完成任意（只讀）圖數據查詢和過程。只讀副本是通過事務日志shipping來完成對主副本的數據異步同步的。

Neo4j也支持了數據科學（Graph Data Science）庫，其包含了許多圖分析算法，比如社區發現，路徑搜索等，甚至也支持了少量的圖神經網絡算法（比如GraphSage， Node2Vec）。這些算法統一集成在了Neo4j的Cypher語言體系下，以提供給用戶統一的圖查詢/圖分析體驗。

5、TigerGraph?

TigerGraph如今已經發展成為了一個商業化程度僅次于Neo4j的圖數據庫產品，但由于其是一個閉源產品，很多技術實現我們無從知曉。從TigerGraph網站上的官方技術博客描述來看，TigerGraph 是一款分布式MPP圖數據庫，同時支持在線事務處理（OLTP）和在線分析查詢（OLAP），也集成了基于PyG的圖神經網絡訓練功能。

從架構上看，TigerGraph集成了較為完善的數據導入功能，可以在系統在線的情況下，將關系型數據或其他格式的半結構化數據導入到TigerGraph系統中。TigerGraph的Graph Storage Engine（GSE）負責了對數據的壓縮和存儲，其將數據編碼、轉換成一種對MPP處理友好的圖原生存儲格式后加載至Graph Processing Engine（GPE），而GPE則是具體負責響應查詢請求和圖計算分析的執行引擎。TigerGraph還包含一個可視化的客戶端以及 REST API，并集成了很多企業數據基礎設施服務。TigerGraph使用Apache Kafka讓GSE與GPE進行數據同步，邏輯上GPE可以理解為一個內存存儲層，而GSE是一個圖原生的持久化存儲層；數據的更新將先反應到GPE層，然后通過Kafka將Transaction Log交給GSE消費并完成持久化更新。

圖片來源自：https://docs.tigergraph.com/tigergraph-server/current/intro/internal-architecture

在OLTP功能上，TigerGraph支持完整的ACID特性，支持最高的serializability事務隔離級別。TigerGraph支持垂直擴展和水平擴展，且可以對集群中的圖數據自動分區。從這點來看，TigerGraph對大規模圖數據的存儲支持得比Neo4j要友好很多。TigerGraph使用自定義的GSQL語言來表達查詢邏輯，GSQL將SQL風格的查詢語法與Cypher風格的圖遍歷語法結合在了一起，并支持用戶自定義函數。

四、圖數據庫的未來

圖數據庫在經歷了最近幾年的蓬勃發展之后，無論是系統性能還是穩定性都得到了大幅提升，那接下來Graph Database Community再會往哪些方向發展呢？

筆者認為，一方面統一圖數據庫的查詢語言標準（GQL）是一件迫在眉睫的事情，標準的制定將有利于降低用戶的學習門檻，并使得圖數據庫的查詢優化技術可以得到更充分的發展，比如根據圖數據分布往往不均勻的特點提出定制化的基于規則和基于代價的優化策略，還比如可以將如今在OLAP領域大紅大紫的向量化執行技術和代碼生成技術引入到圖查詢引擎中，以提升Graph OLAP的執行效率。而另一方面，筆者認為圖數據庫之所以能在最近幾年大火的另一個原因是源于圖計算技術和圖AI技術的崛起。而這些技術能夠同時引起各界學者和工程師的關注也是因為圖狀數據的獨特之處 -- 特別是在這個數據互聯的時代，需要盡可能在低成本、短時間的前提下從海量數據中挖掘出關聯最深，價值最大的信息，圖就是非常理想的解決方案。除此以外，我們很難從其他種類的NoSQL模型、大數據框架或關系型數據庫中找到隱式數據關聯的解決辦法。

隨著算力的提升和大數據生態的日漸成熟，我們的目標正在從存儲系統的效率轉變為從存儲系統包含的數據中提取價值。圖數據庫需要與圖計算系統、圖AI系統，乃至流圖系統緊密地聯動起來，才能讓圖數據的價值在用戶手中得到充分的釋放。而如何打造一套可以讓不同目標的圖系統都集成到一起，提供統一DDL并簡單易用的graph infrastructure呢？我們能看到各個廠商和初創公司正在給出自己的答案...