在衆多不同的數據模型裏，關係數據模型自20世紀80年代就處於統治地位，而且出現了不少巨頭，如Oracle、MySQL和MSSQL，它們也被稱爲關係數據庫管理系統（RDBMS）。然而，隨着關係數據庫使用範圍的不斷擴大，也暴露出一些它始終無法解決問題，其中最主要的是數據建模中的一些缺陷和問題，以及在大數據量和多服務器之上進行水平伸縮的限制。同時，互聯網發展也產生了一些新的趨勢變化：
- 用戶、系統和傳感器產生的數據量呈指數增長，其增長速度因大部分數據量集中在Amazon、Google和其他雲服務的分佈式系統上而進一步加快；
- 數據內部依賴和複雜度的增加，這一問題因互聯網、Web2.0、社交網絡，以及對大量不同系統的數據源開放和標準化的訪問而加劇。
而在應對這些趨勢時，關係數據庫產生了更多的不適應性，從而導致大量解決這些問題中某些特定方面的不同技術出現，它們可以與現有RDBMS相互配合或代替它們——亦被稱爲混合持久化（Polyglot Persistence）。數據庫替代品並不是新鮮事物，它們已經以對象數據庫（OODBMS）、層次數據庫（如LDAP）等形式存在很長時間了。但是，過去幾年間，出現了大量新項目，它們被統稱爲NoSQL數據庫（NoSQL-databases）。
1. NoSQL數據庫
NoSQL數據庫大致可以分爲四類：
-
鍵值(key/value)數據庫
-
列存儲數據庫
-
文檔型數據庫
-
圖數據庫
NoSQL數據庫
在NoSQL四種分類中，圖數據庫從最近十年的表現來看已經成爲關注度最高，也是發展趨勢最明顯的數據庫類型。圖1就是db-engines.com對最近三年來所有數據庫種類發展趨勢的分析結果。
db-engines.com對最近三年來所有數據庫種類發展趨勢的分析
2. 圖數據庫
圖數據庫源起歐拉和圖理論，也可稱爲面向/基於圖的數據庫，對應的英文是Graph Database。圖數據庫的基本含義是以“圖”這種數據結構存儲和查詢數據，而不是存儲圖片的數據庫。它的數據模型主要是以節點和關係（邊）來體現，也可處理鍵值對。它的優點是快速解決複雜的關係問題。
2.1 特徵
圖具有如下特徵：
- 包含節點和邊；
- 節點上有屬性（鍵值對）；
- 邊有名字和方向，並總是有一個開始節點和一個結束節點；
- 邊也可以有屬性。
說得正式一些，圖可以說是頂點和邊的集合，或者說更簡單一點兒，圖就是一些節點和關聯這些節點的聯繫（relationship）的集合。圖將實體表現爲節點，實體與其他實體連接的方式表現爲聯繫。我們可以用這個通用的、富有表現力的結構來建模各種場景，從宇宙火箭的建造到道路系統，從食物的供應鏈及原產地追蹤到人們的病歷，甚至更多其他的場景。
通常，在圖計算中，基本的數據結構表達就是：
G=(V, E)
V=vertex（節點）
E=edge（邊）
如圖2所示。
當然，圖模型也可以更復雜，例如圖模型可以是一個被標記和標向的屬性多重圖（multigraph）。被標記的圖每條邊都有一個標籤，它被用來作爲那條邊的類型。有向圖允許邊有一個固定的方向，從末或源節點到首或目標節點。
屬性圖允許每個節點和邊有一組可變的屬性列表，其中的屬性是關聯某個名字的值，簡化了圖形結構。多重圖允許兩個節點之間存在多條邊，這意味着兩個節點可以由不同邊連接多次，即使兩條邊有相同的尾、頭和標記。如圖3所示。
圖數據庫存儲一些頂點和邊與表中的數據。他們用最有效的方法來尋找數據項之間、模式之間的關係，或多個數據項之間的相互作用。
一張圖裏數據記錄在節點，或包括的屬性裏面，最簡單的圖是單節點的，一個記錄，記錄了一些屬性。一個節點可以從單屬性開始，成長爲成千上億，雖然會有一點麻煩。從某種意義上講，將數據用關係連接起來分佈到不同節點上纔是有意義的。
2.2 與關係型數據庫對比
關係查詢性能對比
在數據關係中心，圖形數據庫在查詢速度方面非常高效，即使對於深度和複雜的查詢也是如此。在《Neo4j in Action》這本書中，作者在關係型數據庫
和圖數據庫(Neo4j)之間進行了實驗。
他們的實驗試圖在一個社交網絡裏找到最大深度爲5的朋友的朋友。他們的數據集包括100萬人，每人約有50個朋友。實驗結果如下：
在深度爲2時（即朋友的朋友），兩種數據庫性能相差不是很明顯；深度爲3時(即朋友的朋友的朋友)，很明顯，關係型數據庫的響應時間30s，已經變得不可接受了；深度到4時，關係數據庫需要近半個小時才能返回結果，使其無法應用於在線系統；深度到5時，關係型數據庫已經無法完成查詢。而對於圖數據庫Neo4J，深度從3到5，其響應時間均在3秒以內。
可以看出，對於圖數據庫來說，數據量越大，越複雜的關聯查詢，約有利於體現其優勢。從深度爲4/5的查詢結果我們可以看出，圖數據庫返回了整個社交網絡一半以上的人數。
總結：
圖數據庫在處理關聯關係上具有完全的優勢，特別是在我們這個社交網絡得到極大發展的互聯網時代。例如我們希望知道誰LIKES（喜歡）誰（喜歡可以是單向或雙向），也想知道誰是誰的FRIEND_OF（朋友），誰是所有人的LEADER_OF（領導）。除了在關聯查詢中尤爲明顯的優越性，圖數據庫還有如下優勢：
a) 用戶可以面向對象的思考，用戶使用的每個查詢都有顯式語義；
b) 用戶可以實時更新和查詢圖數據庫；
c) 圖數據庫可以靈活應對海量的關係變化，如增加刪除關係、實體等；
d) 圖數據庫有利於實時的大數據挖掘結果可視化。
圖數據庫雖然彌補了很多關係型數據庫的缺陷，但還有一些不足地方，如：
a) 不適合記錄大量基於事件的數據（例如日誌條目）；
b) 二進制數據存儲。
c) 併發性能要求高的項目。
d) 目前相關圖查詢語言比較多，尚未有很好統一。
e) 圖數據庫相關的一些書籍文檔偏少，相關生態還在不斷完善。
2.3 圖數據庫架構
在研究圖數據庫技術時，有兩個特性需要多加考慮。
1、底層存儲
一些圖數據庫使用原生圖存儲，這類存儲是優化過的，並且是專門爲了存儲和管理圖而設計的。不過並不是所有圖數據庫使用的都是原生圖存儲，也有一些會將圖數據序列化，然後保存到關係型數據庫或面向對象數據庫，或是其他通用數據存儲中。
原生圖存儲的好處是，它是專門爲性能和擴展性設計建造的。但相對的，非原生圖存儲通常建立在非常成熟的非圖後端（如MySQL）之上，運維團隊對它們的特性爛熟於心。原生圖處理雖然在遍歷查詢時性能優勢很大，但代價是一些非遍歷類查詢會比較困難，而且還要佔用巨大的內存。
2、處理引擎
圖計算引擎技術使我們可以在大數據集上使用全局圖算法。圖計算引擎主要用於識別數據中的集羣，或是回答類似於“在一個社交網絡中，平均每個人有多少聯繫？”這樣的問題。
圖5展示了一個通用的圖計算引擎部署架構。該架構包括一個帶有OLTP屬性的記錄系統（SOR）數據庫（如MySQL、Oracle或Neo4j），它給應用程序提供服務，請求並響應應用程序在運行中發送過來的查詢。每隔一段時間，一個抽取、轉換和加載（ETL）作業就會將記錄系統數據庫的數據轉入圖計算引擎，供離線查詢和分析。
圖計算引擎多種多樣。最出名的是有內存的、單機的圖計算引擎Cassovary和分佈式的圖計算引擎Pegasus和Giraph。大部分分佈式圖計算引擎基於Google發佈的Pregel白皮書，其中講述了Google如何使用圖計算引擎來計算網頁排名。
一個成熟的圖數據庫架構應該至少具備圖的存儲引擎和圖的處理引擎，同時應該有查詢語言和運維模塊，商業化產品還應該有高可用HA模塊甚至容災備份機制。一個典型的圖數據庫架構如圖6所示。
各模塊功能說明如下：
-
查詢和計算：最終用戶用於在此語言基礎之上進行圖的遍歷和查詢，最終返回運行結果，如能提供RESTful API則能給開發者提供不少便利之處。
-
操作和運維：用於系統實時監控，例如系統配置、安裝、升級、運行時監控，甚至包括可視化界面等。
-
數據加載：包括離線數據加載和在線數據加載，既可以是批量的數據加載，也可以是流數據加載方式。
-
圖數據庫核心：主要包括圖存儲和圖處理引擎這兩個核心。圖處理引擎負責實時數據更新和執行圖運算；圖存儲負責將關係型數據及其他非結構化數據轉換成圖的存儲格式；HA服務負責處理處理數據容錯、數據一致性以及服務不間斷等功能。
在圖數據庫和對外的接口上，圖數據庫應該也具有完備的對外數據接口和完善的可視化輸出界面，如圖7所示。
圖數據庫不僅可以導入傳統關係型數據庫中的結構化數據，也可以是文本數據、社交數據、機器日誌數據、實時流數據等。
同時，計算結果可以通過標準的可視化界面展現出來，商業化的圖數據庫產品還應該能將圖數據庫中的數據進一步導出至第三方數據分析平臺做進一步的數據分析。
3. 應用場景
我們可以將圖領域劃分成以下兩部分：
- 用於聯機事務圖的持久化技術（通常直接實時地從應用程序中訪問）。這類技術被稱爲圖數據庫，它們和“通常的”關係型數據庫世界中的聯機事務處理（Online Transactional Processing，OLTP）數據庫是一樣的。
- 用於離線圖分析的技術（通常都是按照一系列步驟執行）。
3.1 金融行業應用
反洗錢模型
通過圖分析可以清楚地知道洗錢網絡及相關嫌疑，例如對用戶所使用的帳號、發生交易時的IP地址、MAC地址、手機IMEI號等進行關聯分析。
金融反欺詐關聯分析模型
反欺詐已經是金融行業一個核心應用，通過圖數據庫可以對不同的個體、團體做關聯分析，從人物在指定時間內的行爲，例如去過地方的IP地址、曾經使用過的MAC地址（包括手機端、PC端、WIFI等）、社交網絡的關聯度分析，同一時間點是否曾經在同一地理位置附近出現過，銀行賬號之間是否有歷史交易信息等。
3.2社交網絡
社交關係網絡模型
在社交網絡中，公司、員工、技能的信息，這些都是節點，它們之間的關係和朋友之間的關係都是邊，在這裏面圖數據庫可以做一些非常複雜的公司之間關係的查詢。比如說公司到員工、員工到其他公司，從中找類似的公司、相似的公司，都可以在這個系統內完成。
企業關係圖譜
圖數據庫可以對各種企業進行信息圖譜的建立，包括最基本的工商信息，包括何時註冊、誰註冊、註冊資本、在何處辦公、經營範圍、高管架構。圍繞企業的經營範圍，繼續細化去查詢企業究竟有哪些產品或服務，例如通過企業名稱查詢到企業的自媒體，從而給予其更多關注和了解。另外也包括對企業的產品和服務的數據關聯，查看該企業有沒有令人信服的自主知識產權和相關資質來支撐業務的開展。
企業在日常經營中，與客戶、合作伙伴、渠道方、投資者都會打交道，這也決定了企業對社會各個領域都廣有涉獵，呈現面錯綜複雜，因此可以通過企業數據圖譜來查詢，層層挖掘信息。基於圖數據的企業信息查詢可以真正瞭解企業的方方面面，而不再是傳統單一的工商信息查詢。
4. 開源圖數據庫選型
4.1各大開源圖數據庫優勢
對比了幾家業界常用的開源圖數據庫，得到如下表格
針對使用便捷性：
neo4j有幾種強大且便利的第三方python包供使用，導入數據有自帶的csv格式導入工具。orientdb自帶有一種ETL工具，支持多種格式導入，數據操作是自研的python包，只提供全面的基礎功能，使用相比neo4j強大的第三方python包來說略麻煩。dgraph僅支持GraphQL+-查詢語言，一種JSON通信方法，python需構建出JSON語句進行交互，並且返回結果也需要用JSON語句，導入格式支持rdf。
針對數據插入性能：
經測試，neo4j單條插入每分鐘千條左右，單條插入很慢，批量導入數據需要藉助csv導入工具。orientdb有自研ETL工具，導入速度較快。dgraph使用自帶工具批量導入數據，可達到每秒近2k條數，支持壓縮包導入（.gz）。
4.2 neo4j 和 JanusGraph
根據DB-Engines最新發布的圖數據庫排名，Neo4J仍然大幅領先排在第一位：
Neo4J是由Java實現的開源圖數據庫。自2003年開始開發，直到2007年正式發佈第一版，並託管於GitHub上。
Neo4J支持ACID，集羣、備份和故障轉移。目前Neo4J最新版本爲3.5，分爲社區版和企業版，社區版只支持單機部署，功能受限。企業版支持主從複製和讀寫分離，包含可視化管理工具。
JanusGraph是一個Linux基金會下的開源分佈式圖數據庫
。JanusGraph提供Apache2.0軟件許可證。該項目由IBM、Google、Hortonworks支持。JanusGraph是由TitanDB
圖數據庫修改而來，TitanDB從2012年開始開發。目前最新版本爲0.3.1。
JanusGraph支持多種儲存後端（包括Apache Cassandra、Apache HBase、Bigtable、Berkeley
DB）。JanusGraph的可擴展性取決於與JanusGraph一起使用的基礎技術。例如，通過使用Apache
Cassandra作爲存儲後端，可以將JanusGraph簡單地擴展到多個數據中心。
JanusGraph通過與大數據平臺（Apache Spark，Apache Giraph，Apache
Hadoop）集成，支持全局圖數據的分析、報告和ETL。
JanusGraph通過外部索引存儲（Elasticsearch，Solr，Lucene）支持地理、數字範圍和全文搜索。
5. 小結
圖數據庫應對的是當今一個宏觀的商業世界的大趨勢：憑藉高度關聯、複雜的動態數據，獲得洞察力和競爭優勢。國內越來越多的公司開始進入圖數據庫領域，研發自己的圖數據庫系統。對於任何達到一定規模或價值的數據，圖數據庫都是呈現和查詢這些關係數據的最好方式。而理解和分析這些圖的能力將成爲企業未來最核心的競爭力。
參考:
https://blog.csdn.net/weixin_45727359/article/details/106045615
https://www.cnblogs.com/mantoudev/p/10414495.html
https://www.iteye.com/news/32186