圖資料庫選型：問題、方法與工具

圖資料庫是知識圖譜系統的核心。在實際的應用中，為什麼要做圖資料庫選型，圖資料庫選型應該怎麼做?螞蟻集團圖資料庫負責人洪春濤，在知識分享社群Datafun的演講中，對這些問題進行了分析和解答。以下是演講原文整理。

1、為什麼要做圖資料庫選型

圖資料庫是知識圖譜系統的核心。在典型的知識圖譜系統中，資料會在知識抽取、整理和推理之後，被存放到圖資料庫中，然後圖資料庫會支撐知識圖譜的查詢、更新、推斷等任務。因此圖資料的選型決定了圖譜系統的規模、效能、穩定性，對整個圖譜系統應用非常重要。

目前行業內圖資料庫型別非常多，常見的有Neo4j、JanusGraph，以及螞蟻集團研發的圖資料庫TuGraph等，整體數量在幾十種左右。但他們之間的差異非常大，比如查詢語言上Neo4j用的是Cypher，JanusGraph用的是Gremlin。

圖資料庫的圖模型也有很大差異。圖資料庫目前大部分以屬性圖為主，也有另外一類是RDF圖，這兩種圖資料庫從資料抽象上不一樣，其它很多特性，比如有沒有使用者許可權，有沒有多圖、有沒有超圖，這些特徵也都非常不一樣。

使用圖資料主要的問題在於，它不像關係型資料庫是一個標準的關係代數的抽象，上面有標準的SQL語言。目前圖資料庫沒有完全標準化下來，所以對於很多使用者造成了很大的困擾，在選圖資料庫的時候，不知道應該怎麼選。

另外一個主要的問題是，圖資料庫現在很多應用場景其實是偏探索類的，在具體場景當中，會用到哪些演算法，需要哪些特性，使用者事先並不知道，因此更難選擇圖資料庫的型別。

那麼我們該如何做圖資料庫系統選型呢?

圖資料庫系統的選型，一個非常重要的工具就是基準測試程式，英文叫Benchmark，它會模擬真實的場景對系統進行測試，是比較標準的測試程式。

以TPC-C為例，這是個很標準的對關係型資料庫進行測試的基準測試程式，它模擬的是連鎖商店對資料庫的使用，會在資料庫建訂單管理系統、庫存管理系統、物流管理。這個程式本身會規定事務性應該支援到什麼地步，應該有多併發，每一個查詢的延遲應該有什麼樣的要求。如果一個關聯式資料庫能夠正確地透過TPC-C這個測試，並且得到一個值，那麼對使用者來說，就可以大致估計在正常的真實的情況下，它的功能，效能大致如何，進一步估計在真實場景下的功能性、穩定性等。

所以Benchmark可以指導我們對資料庫系統的設計，同時它對加速整個行業的發展是很重要的。

2、我們需要什麼樣的基準測試程式

一個好的Benchmark有以下特性。

首先要貼合實際，它選擇的場景必須是比較符合實際情況的。比如說TPC-C要模擬一個商店的管理系統，那麼這個資料特徵、操作特徵就必須跟商店差不多，以做庫存管理、訂單管理為例，這些查詢有多少讀、有多少寫，它們之間的混合比例，都需要符合實際。

效能特徵上，要滿足一定的延遲要求。讀寫比例併發有一定的要求，比如同時會有多少使用者在這上面用，它的延遲要求是多少，必須要求查詢應該是在幾十毫秒，都是有一定的要求。查詢跑出來的時間如果太長，肯定不符合正常的需求。

另外它必須具備可擴充套件性。實際測試中，商店大小是有差異的，如果說一個Benchmark只規定了一種資料大小，那就很難讓使用者感覺到在自己的場景下面會是什麼情況。比如說使用者要開一個商店，希望選一個資料庫，但Benchmark的測試資料可能只限制了1GB資料，而實際使用者的資料有1TB，那這個Benchmark就沒有參考價值，所以大部分好的Benchmark都具備可擴充套件性，想測1GB、100GB、1TB甚至10TB都有辦法去實現。

還有一點是標準必須要嚴謹，這是非常重要的。圖資料測試，不能用TPC-C的資料來隨意完成，比如只測讀不測寫，測試的時候把其中所有的寫操作都去掉，跑出來一個結果看似很高，實際上卻沒有意義，因為並不符合實際的測試標準。所以這個標準本身必須要很嚴謹，它必須有審計規則，要有對資料的驗證。

現在圖資料庫常用的幾個測試程式，一個是Twitter，即把Twitter公佈的資料集拿來跑K跳，從一個點出發去找K度的鄰居，以及去跑圖演算法，這種測試的方法有很大的問題。一是推特本身的圖非常有限，不具有可擴充套件性。圖上面的點和邊是沒有屬性，這其實是不符合真實情況的。另外它是一個社交圖，跟其他很多常用的金融圖等都不太一樣，所以只能作為一個簡單的參考。最致命的是它只有讀沒有寫，測試的時候就沒法去測它的寫操作，或者要測寫操作也只能加幾條邊加幾個點，這是非常不嚴謹的。

部分廠商在選型時會加一些自己的測試，比如說希望能夠測一些讀寫混合，然後就從自己的資料裡選一些示例資料，做讀寫的操作。這個做法實際上不符合標準，如果很明確地知道在一個場景下面要用什麼資料，然後做什麼操作，那麼做這個測試是可以的。但是絕大多數情況下，我們並不知道以後會用在哪些場景下，它測試的時候只能測非常有限的幾個場景，但是以後可能還要增加很多其他的業務，有可能這個資料以後也會增長。

所以這些只能作為簡單的參考，它不具擴充套件性，也不具有嚴謹的效果。

這也是為什麼我們想要去做Benchmark這件事情。

3、 金融圖資料庫benchmark怎麼做

LDBC(The Linked Data Benchmark Council)是全球知名的非盈利性技術協會，目前有三個Benchmark，一個是基於語義網路的RDF圖，一個是圖分析，另外就是社交網路的圖SNB。

目前國際上做得比較標準的圖資料庫測試程式是LDBC的SNB的測試。SNB測試是模擬社交網站對於圖資料庫的應用場景，按照社交網站的資料特性生成資料，它允許生成各種各樣大小的資料，同時操作上有讀寫混合，讀也有各種豐富的語義，有一個非常標準的文件，也有第三方審計。

SNB測試模擬的是社交的場景，裡面有14類的點20類的邊，點跟邊上面會有一些屬性，可以設定資料規模最小的資料是SF1，大概生成出來是1GB的資料，最大可以SF100，SF300，SF1000，SF30000都有。

從操作上它有兩類，一類是Interactive，即模擬線上的查詢，它上面有七種簡單的讀，14類複雜的讀。有八種寫的操作，實際測試的時候，會要求把這些讀寫混合的併發的發到這個圖資料庫上面。另外一類是BI的Workload。BI的查詢裡邊，它是複雜的只讀查詢，就比上面這個複雜讀還要更復雜，基本上是全域性掃描的類似OLAP的應用。它的寫是批次寫，所以這個跟上面的Interactive是很不一樣的。

在一些驗證上面，它會要求讀寫混合，會有正確性的驗證，這些讀寫做完了以後，需要驗一下目前這個資料庫的正確性，然後有事務隔離性的要求，最重要的是它有延遲的要求，每一個查詢規定大概只有千分之一的請求是可以超時的，如果延遲超過100毫秒的查詢超過千分之一。那麼這個比例太高了，這個資料庫就是不透過的。

SNB模擬的是一個社交網站的資料，裡邊有人的節點，有論壇的節點，論壇裡邊有很多帖子，然後大家可以去轉載這些帖子，同時這個人會有各種各樣的資料，有他的公司、大學、城市，透過邊會把這些資訊連起來，在上面去做查詢。是一個比較典型的圖查詢。

我們發現在螞蟻自己的應用場景下面，有很多跟SNB不一樣的地方，因此決定跟LDBC一起做一個金融圖的Benchmark。金融Benchmark跟SNB的主要差別是什麼呢?

首先是場景上的差別，SNB是一個社交場景，我們是金融風控等不同型別的場景，從資料上就會有比較大的差別。社交網路的圖，有它的特殊性，首先它往往會有很多大點，比如一個微博大V賬號，會有很多關注，它就是個大點;然後它裡面的點，平均出度會比較高，如每個微博賬號，平均會有300個左右的關注。這些特性導致社交圖跟其它圖都不一樣，相對而言金融圖相對出度會小一些。

SNB上面的模型點跟點之間是沒有重複邊的，但是金融圖裡邊就非常多重邊的情況，比如說兩個人之間會經常轉賬，那麼他們之間就會有非常多的重邊出現。金融圖的查詢跟計算區別也很大，且查詢對於延遲的要求更高一些。如果20毫秒之內返回不回來，那麼整個使用者體驗就會很糟糕。

SNB裡邊讀跟寫是分開的。在金融圖裡讀寫是有可能在同一個Query裡邊的。我們會找很多的環狀的結構三角的結構，這些都是跟SNB不一樣的地方。所以這也是促使我們去做金融圖Benchmark的一個主要動力。

目前我們的金融圖Benchmark還在設計階段，主要是線上查詢，對延遲要求比較高。另外我們會設計負載的波峰波谷，因為一般來說半夜流量比較小;我們會對資料有TTL，會對過期的資料進行清理。比如說一般系統裡邊放三個月的資料，超過三個月就自動回收掉了。

以下是一個比較簡單的又讀又寫的Query的示例。

除此之外，我們還會做一些反欺詐的、反套現的操作，這也是金融場景中經常需要解決的問題。我們會把金融圖資料庫Benchmark當做一個標準來做。

結語

綜合以上，我們認為圖資料庫是圖譜應用系統的核心，所以它的選型很重要，而Benchmark作為選型最有力的工具非常重要。Benchmark如果做得好，它可以成為一種事實標準，指導系統的設計。我們也倡議更多的人來跟我們一起參與Benchmark的開發以及制定，推進圖資料庫系統的標準化，共建行業生態。