如果把傳統關係型數據庫比做火車的話，那麼到現在大數據時代，圖數據庫可比做高鐵。它已成爲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對最近三年來所有數據庫種類發展趨勢的分析結果。
圖數據庫
圖數據庫源起歐拉和圖理論，也可稱爲面向/基於圖的數據庫，對應的英文是Graph Database。圖數據庫的基本含義是以“圖”這種數據結構存儲和查詢數據，而不是存儲圖片的數據庫。它的數據模型主要是以節點和關係（邊）來體現，也可處理鍵值對。它的優點是快速解決複雜的關係問題。
圖具有如下特徵：
- 包含節點和邊；
- 節點上有屬性（鍵值對）；
- 邊有名字和方向，並總是有一個開始節點和一個結束節點；
- 邊也可以有屬性。
說得正式一些，圖可以說是頂點和邊的集合，或者說更簡單一點兒，圖就是一些節點和關聯這些節點的聯繫（relationship）的集合。圖將實體表現爲節點，實體與其他實體連接的方式表現爲聯繫。我們可以用這個通用的、富有表現力的結構來建模各種場景，從宇宙火箭的建造到道路系統，從食物的供應鏈及原產地追蹤到人們的病歷，甚至更多其他的場景。
通常，在圖計算中，基本的數據結構表達就是：
G=(V, E)
V=vertex（節點）
E=edge（邊）
如圖2所示。
當然，圖模型也可以更復雜，例如圖模型可以是一個被標記和標向的屬性多重圖（multigraph）。被標記的圖每條邊都有一個標籤，它被用來作爲那條邊的類型。有向圖允許邊有一個固定的方向，從末或源節點到首或目標節點。
屬性圖允許每個節點和邊有一組可變的屬性列表，其中的屬性是關聯某個名字的值，簡化了圖形結構。多重圖允許兩個節點之間存在多條邊，這意味着兩個節點可以由不同邊連接多次，即使兩條邊有相同的尾、頭和標記。如圖3所示。
圖數據庫存儲一些頂點和邊與表中的數據。他們用最有效的方法來尋找數據項之間、模式之間的關係，或多個數據項之間的相互作用。
一張圖裏數據記錄在節點，或包括的屬性裏面，最簡單的圖是單節點的，一個記錄，記錄了一些屬性。一個節點可以從單屬性開始，成長爲成千上億，雖然會有一點麻煩。從某種意義上講，將數據用關係連接起來分佈到不同節點上纔是有意義的。
圖計算是在實際應用中比較常見的計算類別，當數據規模大到一定程度時，如何對其進行高效計算即成爲迫切需要解決的問題。大規模圖數據，例如支付寶的關聯圖，僅好友關係已經形成超過1600億節點、4000億邊的巨型圖，要處理如此規模的圖數據，傳統的單機處理方式顯然已經無能爲力，必須採用由大規模機器集羣構成的並行圖數據庫。
在處理圖數據時，其內部存儲結構往往採用鄰接矩陣或鄰接表的方式，圖4就是這兩種存儲方式的簡單例子。在大規模並行圖數據庫場景下，鄰接表的方式更加常用，大部分圖數據庫和處理框架都採用了這一存儲結構。
圖數據庫架構
在研究圖數據庫技術時，有兩個特性需要多加考慮。
- 底層存儲
一些圖數據庫使用原生圖存儲，這類存儲是優化過的，並且是專門爲了存儲和管理圖而設計的。不過並不是所有圖數據庫使用的都是原生圖存儲，也有一些會將圖數據序列化，然後保存到關係型數據庫或面向對象數據庫，或是其他通用數據存儲中。
原生圖存儲的好處是，它是專門爲性能和擴展性設計建造的。但相對的，非原生圖存儲通常建立在非常成熟的非圖後端（如MySQL）之上，運維團隊對它們的特性爛熟於心。原生圖處理雖然在遍歷查詢時性能優勢很大，但代價是一些非遍歷類查詢會比較困難，而且還要佔用巨大的內存。
- 處理引擎
圖計算引擎技術使我們可以在大數據集上使用全局圖算法。圖計算引擎主要用於識別數據中的集羣，或是回答類似於“在一個社交網絡中，平均每個人有多少聯繫？”這樣的問題。
圖5展示了一個通用的圖計算引擎部署架構。該架構包括一個帶有OLTP屬性的記錄系統（SOR）數據庫（如MySQL、Oracle或Neo4j），它給應用程序提供服務，請求並響應應用程序在運行中發送過來的查詢。每隔一段時間，一個抽取、轉換和加載（ETL）作業就會將記錄系統數據庫的數據轉入圖計算引擎，供離線查詢和分析。
圖計算引擎多種多樣。最出名的是有內存的、單機的圖計算引擎Cassovary和分佈式的圖計算引擎Pegasus和Giraph。大部分分佈式圖計算引擎基於Google發佈的Pregel白皮書，其中講述了Google如何使用圖計算引擎來計算網頁排名。
一個成熟的圖數據庫架構應該至少具備圖的存儲引擎和圖的處理引擎，同時應該有查詢語言和運維模塊，商業化產品還應該有高可用HA模塊甚至容災備份機制。一個典型的圖數據庫架構如圖6所示。
各模塊功能說明如下：
- 查詢和計算：最終用戶用於在此語言基礎之上進行圖的遍歷和查詢，最終返回運行結果，如能提供RESTful API則能給開發者提供不少便利之處。
- 操作和運維：用於系統實時監控，例如系統配置、安裝、升級、運行時監控，甚至包括可視化界面等。
- 數據加載：包括離線數據加載和在線數據加載，既可以是批量的數據加載，也可以是流數據加載方式。
- 圖數據庫核心：主要包括圖存儲和圖處理引擎這兩個核心。圖處理引擎負責實時數
據更新和執行圖運算；圖存儲負責將關係型數據及其他非結構化數據轉換成圖的存儲格式；HA服務負責處理處理數據容錯、數據一致性以及服務不間斷等功能。
在圖數據庫和對外的接口上，圖數據庫應該也具有完備的對外數據接口和完善的可視化輸出界面，如圖7所示。
圖數據庫不僅可以導入傳統關係型數據庫中的結構化數據，也可以是文本數據、社交數據、機器日誌數據、實時流數據等。
同時，計算結果可以通過標準的可視化界面展現出來，商業化的圖數據庫產品還應該能將圖數據庫中的數據進一步導出至第三方數據分析平臺做進一步的數據分析。
圖數據庫的應用
我們可以將圖領域劃分成以下兩部分：
- 用於聯機事務圖的持久化技術（通常直接實時地從應用程序中訪問）。
- 這類技術被稱爲圖數據庫，它們和“通常的”關係型數據庫世界中的聯機事務處理（Online Transactional Processing，OLTP）數據庫是一樣的。
- 用於離線圖分析的技術（通常都是按照一系列步驟執行）。
這類技術被稱爲圖計算引擎。它們可以和其他大數據分析技術看做一類，如數據挖掘和聯機分析處理（Online Analytical Processing，OLAP）。
圖數據庫一般用於事務（OLTP）系統中。圖數據庫支持對圖數據模型的增、刪、改、查（CRUD）方法。相應地，它們也對事務性能進行了優化，在設計時通常需要考慮事務完整性和操作可用性。
目前圖數據庫的巨大用途得到了認可，它跟不同領域的很多問題都有關聯。最常用的圖論算法包括各種類型的最短路徑計算、測地線（Geodesic Path）、集中度測量（如PageRank、特徵向量集中度、親密度、關係度、HITS等）。那麼，什麼樣的應用場景可以很好地利用圖數據庫？
目前，業內已經有了相對比較成熟的基於圖數據庫的解決方案，大致可以分爲以下幾類。
金融行業應用
反欺詐多維關聯分析場景
通過圖分析可以清楚地知道洗錢網絡及相關嫌疑，例如對用戶所使用的帳號、發生交易時的IP地址、MAC地址、手機IMEI號等進行關聯分析。
反欺詐多維關聯分析場景
反欺詐已經是金融行業一個核心應用，通過圖數據庫可以對不同的個體、團體做關聯分析，從人物在指定時間內的行爲，例如去過地方的IP地址、曾經使用過的MAC地址（包括手機端、PC端、WIFI等）、社交網絡的關聯度分析，同一時間點是否曾經在同一地理位置附近出現過，銀行賬號之間是否有歷史交易信息等。
社交網絡圖譜
在社交網絡中，公司、員工、技能的信息，這些都是節點，它們之間的關係和朋友之間的關係都是邊，在這裏面圖數據庫可以做一些非常複雜的公司之間關係的查詢。比如說公司到員工、員工到其他公司，從中找類似的公司、相似的公司，都可以在這個系統內完成。
企業關係圖譜
圖數據庫可以對各種企業進行信息圖譜的建立，包括最基本的工商信息，包括何時註冊、誰註冊、註冊資本、在何處辦公、經營範圍、高管架構。圍繞企業的經營範圍，繼續細化去查詢企業究竟有哪些產品或服務，例如通過企業名稱查詢到企業的自媒體，從而給予其更多關注和了解。另外也包括對企業的產品和服務的數據關聯，查看該企業有沒有令人信服的自主知識產權和相關資質來支撐業務的開展。
企業在日常經營中，與客戶、合作伙伴、渠道方、投資者都會打交道，這也決定了企業對社會各個領域都廣有涉獵，呈現面錯綜複雜，因此可以通過企業數據圖譜來查詢，層層挖掘信息。基於圖數據的企業信息查詢可以真正瞭解企業的方方面面，而不再是傳統單一的工商信息查詢。
圖數據庫的優缺點
數十年來，開發者試圖使用關係型數據庫處理關聯的、半結構化的數據集。關係型數據庫設計之初是爲了處理紙質表格以及表格化結構，它們試圖對這種實際中的特殊聯繫進行建模。然而諷刺的是，關係型數據庫在處理聯繫上做得卻並不好。
關係數據庫是強大的主流數據庫，經過40年的發展和改進，已經非常可靠、強大並且很實用，可以保存大量的數據。如果你想查詢關係型數據庫裏的單一結構或對應數據信息的話，在任何時間內都可以查詢關於項目的信息，或者你想查詢許多項目在相同類型中的總額或平均值，也將會很快得到答案。
關係型數據庫不擅長什麼呢？當你尋找數據項、關係模式或多個數據項之間的關係時，它們常會以失敗告終。
關係確實存在於關係型數據庫自身的術語中，但只是作爲連接表的手段。我們經常需要對連接實體的聯繫進行語義區分，同時限制它們的使用，但是關聯關係什麼也做不了。更糟糕的是，隨着數據成倍地增加，數據集的宏觀結構將愈發複雜和不規整，關係模型將造成大量表連接、稀疏行和非空檢查邏輯。關係世界中連通性的增強都將轉化爲JOIN操作的增加，這會阻礙性能，並使已有的數據庫難以響應變化的業務需求。
而圖數據庫天生的特點決定了其在關聯關係上具有完全的優勢，特別是在我們這個社交網絡得到極大發展的互聯網時代。例如我們希望知道誰LOVES（愛着）誰（無論愛是否是單相思的），也想知道誰是誰的COLLEAGUE_OF（同事），誰是所有人的BOSS_OF（老闆）。我們想知道誰沒有市場了，因爲他們和別人是MARRIED_TO（結婚）聯繫。我們甚至可以通過數據庫在其他社交網絡中發現不善交際的元素，用DISLIKES（不喜歡）聯繫來表示即可。通過我們所掌握的這個圖，就可以看看圖數據庫在處理關聯數據時的性能優勢了。
例如在下面這個例子中，我們希望在一個社交網絡裏找到最大深度爲5的朋友的朋友。假設隨機選擇兩個人，是否存在一條路徑，使得關聯他們的關係長度最多爲5？對於一個包含100萬人，每人約有50個朋友的社交網絡，我們就以典型的開源圖數據庫Neo4j參與測試，結果明顯表明，圖數據庫是用於關聯數據的最佳選擇，如表1所示。
在深度爲2時（即朋友的朋友），假設在一個在線系統中使用，無論關係型數據庫還是圖數據庫，在執行時間方面都表現得足夠好。雖然Neo4j的查詢時間爲關係數據庫的2/3，但終端用戶很難注意到兩者間毫秒級的時間差異。當深度爲3時（即朋友的朋友的朋友），很明顯關係型數據庫無法在合理的時間內實現查詢：一個在線系統無法接受30s的查詢時間。相比之下，Neo4j的響應時間則保持相對平坦：執行查詢僅需要不到1s，這對在線系統來說足夠快了。
在深度爲4時，關係型數據庫表現出很嚴重的延遲，使其無法應用於在線系統。Neo4j所花時間也有所增加，但其時延在在線系統的可接受範圍內。最後，在深度爲5時，關係型數據庫所花時間過長以至於沒有完成查詢。相比之下，Neo4j則在2 s左右的時間就返回了結果。在深度爲5時，事實證明幾乎整個網絡都是我們的朋友，因此在很多實際用例中，我們可能需要修剪結果，並進行時間控制。
將社交網絡替換爲任何其他領域時，你會發現圖數據庫在性能、建模和維護方面都能獲得類似的好處。無論是音樂還是數據中心管理，無論是生物信息還是足球統計，無論是網絡傳感器還是時序交易，圖都能對這些數據提供強有力而深入的理解。
而關係型數據庫對於超出合理規模的集合操作普遍表現得不太好。當我們試圖從圖中挖掘路徑信息時，操作慢了下來。我們並非想要貶低關係型數據庫，它在所擅長的方面有很好的技術能力，但在管理關聯數據時卻無能爲力。任何超出尋找直接朋友或是尋找朋友的朋友這樣的淺遍歷查詢，都將因爲涉及的索引數量而使查找變得緩慢。而圖數據庫由於使用的是圖遍歷技術，所需要計算的數據量遠小於關係型數據庫，所以非常迅速。
不過，圖數據庫也並非完美，它雖然彌補了很多關係型數據庫的缺陷，但是也有一些不適用的地方，例如以下領域：
- 記錄大量基於事件的數據（例如日誌條目或傳感器數據）；
- 對大規模分佈式數據進行處理，類似於Hadoop；
- 二進制數據存儲；
- 適合於保存在關係型數據庫中的結構化數據。
雖然圖數據庫也能夠處理“大數據”，但它畢竟不是Hadoop、HBase或Cassandra，通常不會在圖數據庫中直接處理海量數據（以PB爲單位）的分析。但如果你樂於提供關於某個實體及其相鄰數據的關係（比如可以提供一個Web頁面或某個API返回其結果），那麼它是一種良好的選擇。無論是簡單的CRUD訪問，或是複雜的、深度嵌套的資源視圖都能夠勝任。
綜上所述，雖然關係型數據庫對於保存結構化數據來說依然是最佳的選擇，但圖數據庫更適合於管理半結構化數據、非結構化數據以及圖形數據。如果數據模型中包含大量的關聯數據，並且希望使用一種直觀、有趣並且快速的數據庫進行開發，那麼可以考慮嘗試圖數據庫。
在實際的生產環境下，一個真正成熟、有效的分析環境是應該包括關係型數據庫和圖數據庫的，根據不同的應用場景相互結合起來進行有效分析。
整體而言，圖數據庫還有很多問題未解決，許多技術還需發展，比如超級節點問題和分佈式大圖的存儲。可以預見的是，隨着互聯網數據的膨脹，圖數據庫將迎來發展契機，基於圖的各種計算和數據挖掘崗位也會越來越熱。
致謝
本文的部分內容參考了Ian Robinson所著的《圖數據庫》（第一版），在此表示感謝。
