圖數據庫——大數據時代的高鐵

J若是把傳統關係型數據庫比作火車的話，那麼到如今大數據時代，圖數據庫可比作高鐵。它已成爲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 大規模並行圖數據庫場景下的圖數據庫存儲結構

圖數據庫架構

在研究圖數據庫技術時，有兩個特性須要多加考慮。

一、底層存儲

一些圖數據庫使用原生圖存儲，這類存儲是優化過的，而且是專門爲了存儲和管理圖而設計的。不過並非全部圖數據庫使用的都是原生圖存儲，也有一些會將圖數據序列化，而後保存到關係型數據庫或面向對象數據庫，或是其餘通用數據存儲中。

原生圖存儲的好處是，它是專門爲性能和擴展性設計建造的。但相對的，非原生圖存儲一般創建在很是成熟的非圖後端（如MySQL）之上，運維團隊對它們的特性爛熟於心。原生圖處理雖然在遍歷查詢時性能優點很大，但代價是一些非遍歷類查詢會比較困難，並且還要佔用巨大的內存。

二、處理引擎

圖計算引擎技術使咱們能夠在大數據集上使用全局圖算法。圖計算引擎主要用於識別數據中的集羣，或是回答相似於「在一個社交網絡中，平均每一個人有多少聯繫？」這樣的問題。

圖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號等進行關聯分析。