圖資料庫——大資料時代的高鐵

如果把傳統關係型資料庫比做火車的話，那麼到現在大資料時代，圖資料庫可比做高鐵。它已成為NoSQL中關注度最高，發展趨勢最明顯的資料庫。

簡介

在眾多不同的資料模型裡，關係資料模型自20世紀80年代就處於統治地位，而且出現了不少巨頭，如Oracle、MySQL和MSSQL，它們也被稱為關聯式資料庫管理系統（RDBMS）。然而，隨著關聯式資料庫使用範圍的不斷擴大，也暴露出一些它始終無法解決問題，其中最主要的是資料建模中的一些缺陷和問題，以及在大資料量和多伺服器之上進行水平伸縮的限制。同時，網際網路發展也產生了一些新的趨勢變化：

使用者、系統和感測器產生的資料量呈指數增長，其增長速度因大部分資料量集中在Amazon、Google和其他雲服務的分散式系統上而進一步加快；

資料內部依賴和複雜度的增加，這一問題因網際網路、Web2.0、社交網路，以及對大量不同系統的資料來源開放和標準化的訪問而加劇。

而在應對這些趨勢時，關聯式資料庫產生了更多的不適應性，從而導致大量解決這些問題中某些特定方面的不同技術出現，它們可以與現有RDBMS相互配合或代替它們——亦被稱為混合持久化（Polyglot Persistence）。資料庫替代品並不是新鮮事物，它們已經以物件資料庫（OODBMS）、層次資料庫（如LDAP）等形式存在很長時間了。但是，過去幾年間，出現了大量新專案，它們被統稱為NoSQL資料庫（NoSQL-databases）。

NoSQL資料庫

NoSQL（Not Only SQL，不限於SQL）是一類範圍非常廣泛的持久化解決方案，它們不遵循關聯式資料庫模型，也不使用SQL作為查詢語言。其資料儲存可以不需要固定的表格模式，也經常會避免使用SQL的JOIN操作，一般有水平可擴充套件的特徵。

簡言之，NoSQL資料庫可以按照它們的資料模型分成4類：

鍵-值儲存庫（Key-Value-stores）

BigTable實現（BigTable-implementations）

文件庫（Document-stores）

圖形資料庫（Graph Database）

在NoSQL四種分類中，圖資料庫從最近十年的表現來看已經成為關注度最高，也是發展趨勢最明顯的資料庫型別。圖1就是db-engines.com對最近三年來所有資料庫種類發展趨勢的分析結果。

圖1 db-engines.com對最近三年來所有資料庫種類發展趨勢的分析

圖資料庫

圖資料庫源起尤拉和圖理論，也可稱為面向/基於圖的資料庫，對應的英文是Graph Database。圖資料庫的基本含義是以“圖”這種資料結構儲存和查詢資料，而不是儲存圖片的資料庫。它的資料模型主要是以節點和關係（邊）來體現，也可處理鍵值對。它的優點是快速解決複雜的關係問題。

圖具有如下特徵：

包含節點和邊；

節點上有屬性（鍵值對）；

邊有名字和方向，並總是有一個開始節點和一個結束節點；

邊也可以有屬性。

說得正式一些，圖可以說是頂點和邊的集合，或者說更簡單一點兒，圖就是一些節點和關聯這些節點的聯絡（relationship）的集合。圖將實體表現為節點，實體與其他實體連線的方式表現為聯絡。我們可以用這個通用的、富有表現力的結構來建模各種場景，從宇宙火箭的建造到道路系統，從食物的供應鏈及原產地追蹤到人們的病歷，甚至更多其他的場景。

通常，在圖計算中，基本的資料結構表達就是：

G=(V, E)

V=vertex（節點）

E=edge（邊）

如圖2所示。

圖2 簡單的圖資料庫模型

當然，圖模型也可以更復雜，例如圖模型可以是一個被標記和標向的屬性多重圖（multigraph）。被標記的圖每條邊都有一個標籤，它被用來作為那條邊的型別。有向圖允許邊有一個固定的方向，從末或源節點到首或目標節點。

屬性圖允許每個節點和邊有一組可變的屬性列表，其中的屬性是關聯某個名字的值，簡化了圖形結構。多重圖允許兩個節點之間存在多條邊，這意味著兩個節點可以由不同邊連線多次，即使兩條邊有相同的尾、頭和標記。如圖3所示。

圖3 較為複雜的圖模型

圖資料庫儲存一些頂點和邊與表中的資料。他們用最有效的方法來尋找資料項之間、模式之間的關係，或多個資料項之間的相互作用。

一張圖裡資料記錄在節點，或包括的屬性裡面，最簡單的圖是單節點的，一個記錄，記錄了一些屬性。一個節點可以從單屬性開始，成長為成千上億，雖然會有一點麻煩。從某種意義上講，將資料用關係連線起來分佈到不同節點上才是有意義的。

圖計算是在實際應用中比較常見的計算類別，當資料規模大到一定程度時，如何對其進行高效計算即成為迫切需要解決的問題。大規模圖資料，例如支付寶的關聯圖，僅好友關係已經形成超過1600億節點、4000億邊的巨型圖，要處理如此規模的圖資料，傳統的單機處理方式顯然已經無能為力，必須採用由大規模機器叢集構成的並行圖資料庫。

在處理圖資料時，其內部儲存結構往往採用鄰接矩陣或鄰接表的方式，圖4就是這兩種儲存方式的簡單例子。在大規模並行圖資料庫場景下，鄰接表的方式更加常用，大部分圖資料庫和處理框架都採用了這一儲存結構。

圖4 大規模並行圖資料庫場景下的圖資料庫儲存結構

圖資料庫架構

在研究圖資料庫技術時，有兩個特性需要多加考慮。

1、底層儲存

一些圖資料庫使用原生圖儲存，這類儲存是最佳化過的，並且是專門為了儲存和管理圖而設計的。不過並不是所有圖資料庫使用的都是原生圖儲存，也有一些會將圖資料序列化，然後儲存到關係型資料庫或物件導向資料庫，或是其他通用資料儲存中。

原生圖儲存的好處是，它是專門為效能和擴充套件性設計建造的。但相對的，非原生圖儲存通常建立在非常成熟的非圖後端（如MySQL）之上，運維團隊對它們的特性爛熟於心。原生圖處理雖然在遍歷查詢時效能優勢很大，但代價是一些非遍歷類查詢會比較困難，而且還要佔用巨大的記憶體。

2、處理引擎

圖計算引擎技術使我們可以在大資料集上使用全域性圖演算法。圖計算引擎主要用於識別資料中的叢集，或是回答類似於“在一個社交網路中，平均每個人有多少聯絡？”這樣的問題。

圖5展示了一個通用的圖計算引擎部署架構。該架構包括一個帶有OLTP屬性的記錄系統（SOR）資料庫（如MySQL、Oracle或Neo4j），它給應用程式提供服務，請求並響應應用程式在執行中傳送過來的查詢。每隔一段時間，一個抽取、轉換和載入（ETL）作業就會將記錄系統資料庫的資料轉入圖計算引擎，供離線查詢和分析。

圖5 一個典型的圖計算引擎部署架構

圖計算引擎多種多樣。最出名的是有記憶體的、單機的圖計算引擎Cassovary和分散式的圖計算引擎Pegasus和Giraph。大部分分散式圖計算引擎基於Google釋出的Pregel白皮書，其中講述了Google如何使用圖計算引擎來計算網頁排名。

一個成熟的圖資料庫架構應該至少具備圖的儲存引擎和圖的處理引擎，同時應該有查詢語言和運維模組，商業化產品還應該有高可用HA模組甚至容災備份機制。一個典型的圖資料庫架構如圖6所示。

圖6 一個成熟的圖資料庫設計架構

各模組功能說明如下：

查詢和計算：終端使用者用於在此語言基礎之上進行圖的遍歷和查詢，最終返回執行結果，如能提供RESTful API則能給開發者提供不少便利之處。

操作和運維：用於系統實時監控，例如系統配置、安裝、升級、執行時監控，甚至包括視覺化介面等。

資料載入：包括離線資料載入和線上資料載入，既可以是批次的資料載入，也可以是流資料載入方式。

圖資料庫核心：主要包括圖儲存和圖處理引擎這兩個核心。圖處理引擎負責實時資料更新和執行圖運算；圖儲存負責將關係型資料及其他非結構化資料轉換成圖的儲存格式；HA服務負責處理處理資料容錯、資料一致性以及服務不間斷等功能。

在圖資料庫和對外的介面上，圖資料庫應該也具有完備的對外資料介面和完善的視覺化輸出介面，如圖7所示。

圖7 一個完整的圖資料庫對外介面及部署模式

圖資料庫不僅可以匯入傳統關係型資料庫中的結構化資料，也可以是文字資料、社交資料、機器日誌資料、實時流資料等。

同時，計算結果可以透過標準的視覺化介面展現出來，商業化的圖資料庫產品還應該能將圖資料庫中的資料進一步匯出至第三方資料分析平臺做進一步的資料分析。

圖資料庫的應用

我們可以將圖領域劃分成以下兩部分：

用於聯機事務圖的持久化技術（通常直接實時地從應用程式中訪問）。這類技術被稱為圖資料庫，它們和“通常的”關係型資料庫世界中的聯機事務處理（Online Transactional Processing，OLTP）資料庫是一樣的。

用於離線圖分析的技術（通常都是按照一系列步驟執行）。

這類技術被稱為圖計算引擎。它們可以和其他大資料分析技術看做一類，如資料探勘和聯機分析處理（Online Analytical Processing，OLAP）。

圖資料庫一般用於事務（OLTP）系統中。圖資料庫支援對圖資料模型的增、刪、改、查（CRUD）方法。相應地，它們也對事務效能進行了最佳化，在設計時通常需要考慮事務完整性和操作可用性。

目前圖資料庫的巨大用途得到了認可，它跟不同領域的很多問題都有關聯。最常用的圖論演算法包括各種型別的最短路徑計算、測地線（Geodesic Path）、集中度測量（如PageRank、特徵向量集中度、親密度、關係度、HITS等）。那麼，什麼樣的應用場景可以很好地利用圖資料庫？

目前，業內已經有了相對比較成熟的基於圖資料庫的解決方案，大致可以分為以下幾類。

金融行業應用

反欺詐多維關聯分析場景

透過圖分析可以清楚地知道洗錢網路及相關嫌疑，例如對使用者所使用的帳號、發生交易時的IP地址、MAC地址、手機IMEI號等進行關聯分析。

作者：熵談電商
連結：