聲明

本文的內容完全來自于TigerGraph官方文檔及說明，不代表本人實際測試和主觀觀點

緣起

一切源自于TigerGraph的官方測試文檔：https://cdn2.hubspot.net/hubfs/4114546/Collateral/TigerGraph%20Benchmark%20Report.pdf?__hstc=3506223.df3da7db83ea26f0c65b13ba83b36a7f.1530072272958.1530072272958.1530072272958.1&__hssc=3506223.3.1530072272959&__hsfp=318508839
該benchmark測試報告中，說明TigerGraph完爆各種圖數據庫，因此對其感興趣，研究之。

概述

TigerGraph之所以如此犀利，根本原因在于NPG（NATIVE PARALLEL GRAPH）：并行圖處理技術。TigerGraph聲稱NPG技術綜合考慮了存儲和計算的性能，能夠提供實時圖更新并提供了內置的并行計算機制。除此之外TigerGraph還提供了特有的查詢語言GSQL（SQL like graph query language），通過GSQL可以實現ad-hoc查詢和交互式的大數據分析計算。 通過配合使用NPG和GSQL，可以進行深度關聯分析（Deep Link Analytics）：可以發現其他圖數據庫由于過于繁瑣或不切實際而無法發現的關聯。
因此我們主要針對TigerGraph的兩大法寶：NPG和GSQL進行調研說明。

架構

NPG（Native Parallel Graph）

自主研發

NPG是TigerGraph的核心組件，采用C++完全自主研發。除此之外還開發了本次圖存儲引擎是（GSE：Graph Storage Engine）與圖處理引擎（GPE:Graph Processing Engine）協作，從而高效完成數據和算法的處理。GPE旨在基于Map-Reduce計算模型提供內置并行性。

高壓縮率

TigerGraph提供高效的數據壓縮，從而進一步高效的使用內存和CPU Cache。數據的壓縮率與數據本身與數據的結構相關，但是一般情況下都能夠達到10倍以上的壓縮率。例如1TB的數據經過壓縮之后，只有100G。壓縮不僅減少了內存占用，還提高了CPU Cache命中率，從而提高了整體查詢性能。

MPP計算模型

TigerGraph中的每個點和邊可以同時作為計算和存儲的并行處理單元。通過這種方式，圖不再是靜態的數據存儲集合，而是一個大規模并行處理引擎。圖中的所有的頂點都可以通過相互之間連接的邊發送和接收消息。圖中的一個點或者邊可以存儲任意信息，TigerGraph通過充分利用多核CPU和內存計算，在每個點和邊上執行并行計算。

圖分區

支持一系列的圖分區算法。在大多數情況下，對input的數據執行自動分區可以取得不錯的效果，而且不需要進行特定的調整和優化。TigerGraph的靈活性允許基于應用特性使用特定的以及混合分區策略，從而達到更高的性能。TigerGraph可以將多個圖形引擎作為Active-Active的網絡架構并行運行。其中每個圖引擎都可以針對不同的應用查詢方式采用不同的圖形分區算法來服務于同一份數據，從而對每種查詢模式都能提供不錯的性能。前端服務器（通常是REST服務器）可以根據查詢類型將應用程序查詢路由到不同的圖形引擎。

實時深度分析與操作

目前大部分的圖技術將大圖的遍歷限制在兩跳之內，而TigerGraph可以支持到3到10跳，每增加一跳都需要遍歷更多的聯系和屬性。TigerGraph可以達到單臺服務器每秒遍歷1億個頂點/邊，并且單臺服務器每秒可以完成10W次更新。

優勢

傳統的圖數據庫是單機模式的，不能集群化部署TigerGraph是世界上第一個也是唯一一個可擴展到多個節點的分布式的并行圖數據庫。因此從理論上來說TigerGraph是沒有數據量的限制的，并且可以通過簡單的添加服務器來實現橫向擴容。由于TigerGraph本身內置的并行計算特性，因此可以輕松在單臺服務器上實現10倍甚至100倍的性能提升，并且可以輕松實現3層到10層深度的關系分析，常規數據庫在進行3到10層深度關系探索時會出現超時的情況。NPG可以輕松將數據loading速度提升10倍。

GSQL（SQL like Graph Query Language）

TigerGraph提供了GSQL，GSQL是一種用于進行圖形分析的高級且功能完備的查詢語言。 GSQL具有類似SQL的語法，可以減少SQL程序員的學習成本，同時也提供NoSQL開發人員首選的MapReduce用法，使用MapReduce的方式，可以實現大規模的并行計算。
GSQL查詢的主要對象是頂點和邊塊。多個查詢之間的輸入節點、關聯以及相鄰的節點之間都是相互獨立的，這種獨立性為TigerGraph的并行性提供了極大的可能性。
為了實現并行計算，TigerGraph將由頂點/邊緣計算生成的數據存儲在累加器中，可以并行地將聚合計算的結果寫入到累加器中。累加器有兩種形式。全局累加器將結果收集到一個集中位置，而頂點累加器將某一次塊計算中涉及的節點上的計算結果進行累加匯總，除此之外還包括其id為計算已知的任何其他遠程節點的計算結果。
GSQL還提供標準的控制流原語，包括if else語句，以及while循環語句等，當然還會包含condition條件，在condition條件中可能會引用到全局累加器中的一些數值，這也就意味著condition中以來的值可能需要在整個查詢過程中進行動態的計算。每條GSQL語句都會被拆分成一系列的首尾具有相互關聯關系的Blocks，一個Block的輸出會成為后續的一個或者多個Block的輸入，最終一個GSQL語句生成的所有的Blocks最終會被組織成為一個有向無環圖。
GSQL的一個非常強大的功能是它能夠定義命名參數化查詢，這些命名參數可以作為其他查詢的參數而被其他查詢引用（支持遞歸調用和引用）。GSQL的query-calling query功能類似于Oracle PL / SQL和Microsoft SQL Server存儲過程功能。

GSQL示例

假設我們有一張圖，圖中的頂點包含兩種類型：Product和Customer。 頂點Product上的屬性包括：product name, category和單價。頂點Customer的屬性包括：用戶SSN，name和地址。在本示例中，customer c 買了一個product p，這個行為在圖中的建模方式就是：從C指向P的一條邊，邊的類型是Bought。 Bought類型的邊還帶有一些價格和購買數量等屬性。
假設我們想要計算出通過出售"toy"類別的商品，總共賺了多少錢，我們需要找到所有類型為bought的邊，這些邊的源頂點是Customer，目標頂點是Product，且目標頂點的類別為“toy”。針對于找到的每條邊，我們通過計算每個產品單位的折扣價來確定銷售價格：（（1- b.discount/100.0)p.price），算出來價格之后，再乘以購買的數量。請注意如何為每個邊緣獨立（并行）執行此計算。收入是通過將所有b邊緣的銷售價格相加得到的，這是通過將c的每個邊寫入位于c的頂點累加器來實現的。 下面的查詢打印出每個用戶的名字和賺得的利潤：
SumAccum<float> @revenue; ????????????????????(1)
Start = {Customer.}; ??????????????????????? ? (2)
Cust = select c ??????????????????????? ? ??(3)
from Start:c -(Bought:b)-> Product:p ????????????????? (4)
where p.category == “toy” ??????????????????????(5)
accum c.@revenue += p.price(1-b.discount/100.0)b.quantity; ?????? (6)
print Cust.name, Cust.@revenue; ?????????????????? (7)
該查詢開始首先定義一個頂點累加器，該累加器將會一直持有計算的收益。從（1）中可以看到，每個頂點將配備一個名為'revenue'的累加器，它將浮點值聚合成一個總和（實現為算術+函數）。
第（3）行到第（6）行定義了一系列的邊，在FROM子句（第4行）指定了這些邊的條件：以Start頂點的集合（在Line（2）中初始化以包含所有Customer頂點）為起點，以Product頂點為終點，并且被標記了‘bought’的所有邊。
FROM子句還引入了變量：b綁定到edge本身，c綁定到b的源頂點，p綁定到b的目標頂點。
WHERE子句（第5行）指定一個布爾條件，它確定哪些edge參與計算（即那些指向'toy'類別的Product頂點的edge。我們稱這些edge為：allowed edges。
對每個allowed edge執行ACCUM子句（第6行）。它向收入累加器寫入右側表達式的值，該值表示對應于edge的單個銷售的收入。
針對每個allowed edge都會執行SELECT子句（第3行）。它指定要添加到查詢的輸出頂點集合的頂點。示例中輸出頂點集分配給變量Cust。