1 概述
1.1 名詞、術語
圖形數據庫是NoSQL數據庫的一種類型，它應用圖形理論存儲實體之間的關系信息。圖形數據庫是一種非關系型數據庫，它應用圖形理論存儲實體之間的關系信息。最常見例子就是社會網絡中人與人之間的關系。關系型數據庫用于存儲“關系型”數據的效果并不好，其查詢復雜、緩慢、超出預期，而圖形數據庫的獨特設計恰恰彌補了這個缺陷。
直觀感受圖如下：
1.1.1 圖數據庫
圖數據庫即Graph DBMS，簡稱GDBMS。
圖數據庫是基于圖論或圖數據模型的NoSQL數據庫類型。這些數據庫由表示實體的節點和表示節點之間關系或連接的邊組成。每個節點都有一個唯一的標識符、傳出和/或傳入邊緣，以及屬性或鍵值對。
圖的概念中存在點、邊、屬性等概念。
1.1.2 Vertex/Node
Vertex：節點/頂點。用于表示現實世界中的實體對象。
Vertex Label：節點的類型，用于表示現實世界中的實體類型，比如“人”，“電話”。
1.1.3 Edge/Replationship
Edge：邊，用于表示頂點間的聯系。
Edge Label：邊的類型，用于表示現實世界中的關系類型，比如“屬于關系”、 “認識/朋友關系”等。目前大部分圖數據庫的邊都是帶方向的，分單向邊和雙向邊。
1.1.4 Property
Property：屬性，用于表示頂點的附加信息，采用KeyValue結構。Key就是 Property Key，Value就是具體的值。
1.1.5 Lable
Lable：標簽，標簽指一組擁有相同屬性的節點，但是不強制要求相同，一個節點可以有多個標簽。
1.1.6 Path
Path：路徑，指圖中任意兩個節點都存在由關系組成的路徑，路徑有長短之分。
1.2 閱讀對象
本說明書的預期讀者包括：
（1）參與開發的項目人員；
（2）大數據技術人員；
（3）數據挖掘技術人員；
（4）上級領導；
（5）技術經理。
2 圖數據庫的誕生及基本特征
2.1 誕生
圖數據庫依托圖論為理論基礎，描述并存儲了圖中節點與其之間的關系，隨著社交網絡Facebook、電子商務以及資源檢索等領域的發展，急需一種可以處理復雜關聯的存儲技術，而采用圖形數據庫組織存儲、計算分析挖掘低結構化且互連接的數據則更為有效，因此圖形數據庫得W逐漸從實驗室走出,同時反過來也極大地推動了圖形數據庫的飛速發展。
2.2 數據庫存儲引擎
圖存儲是所有圖數據庫最重要的功能之一。此功能允許數據庫用戶以圖的形式存儲信息。數據庫引擎為快速存儲、查詢、索引和檢索提供處理和索引功能。具有高級索引功能的圖數據庫允許用戶從大型數據庫中快速檢索圖信息。
2.3 查詢
這是所有數據庫管理系統中的一個基本功能。圖數據庫通常使用關聯的圖模型，最簡單的查詢技術稱為無索引鄰接。查詢功能允許用戶查找節點、掃描相鄰節點、檢索邊緣和檢索屬性值。用戶還可以執行更復雜的查詢。
2.4 可伸縮性/分區/分片
盡管很難在多個服務器之間擴展圖數據，但可以針對大型數據集、讀取性能和寫入性能進行擴展。此功能的可用性和擴展能力取決于您使用的產品。
2.5 ACID事務
所有數據庫系統都具有事務處理功能。圖數據庫包括創建、讀取、修改和刪除信息所需的工具。它們還包括實時分析和報告等功能。圖數據庫還實現ACID（原子性、一致性、隔離性和持久性）功能，以確保持久、一致和完整的事務。
2.6 深度關聯分析
原生并行圖設計提供的最重要優勢之一就是能夠在超大圖上實時處理遍歷多步（10 步以上）的查詢。原生圖存儲（加快每次數據訪問速度）和并行處理（同時處理多個操作）相結合，可將許多用例從不可能變為可能。
2.7 高級聚合及分析
除了傳統的按組劃分聚合之外，原生并行圖數據庫還可以執行更復雜的聚合，這些聚合在關系型數據庫中是不可想象或不切實際的。由于采用表模型，關系型數據庫上的聚合查詢受到數據分組方式的極大限制。與此相反，圖的多維度性質和新型圖數據庫的并行處理功能可讓用戶高效地分割、切分、匯總、轉換甚至更新數據，而無需預處理數據或使數據進入強模式。
3 圖數據庫 VS 關系型數據庫
3.1 性能
大數據時代，人類社會的數據量呈爆發式增長。任何業務或產品所積累的數據一定是快速增長的，這沒有疑義，但更重要的是，數據與數據之間的關系數目將呈現平方級增長：3個點最多有6條有向邊，4個點最多有12個有向邊，N個節點最多有N * (N-1)個有向邊。
在傳統的數據庫中，隨著關系的數量和深度的增加，關系查詢的效率將急劇衰減，甚至崩潰。然而圖形數據庫的性能將幾乎不變，即使數據每天都在增長。
為了有直接的效果，下圖將不同的關聯深度，圖形數據庫與關系型數據庫執行時間對比如下表。
3.2 靈活性
圖形數據模型的結構和模式隨著解決方案和行業的變化而變化。開發團隊不必提前對未來的需求進行詳盡的建模（然后在某些業務/產品人員要求更改后徹底地推翻重做）；相反，新的節點、關系、節點的屬性還有關系的屬性都可以后期添加到現有結構中，完全不會危及當前的功能。
3.3 敏捷性
使用圖形技術開發完全符合當今的敏捷、測試驅動的開發實踐，它允許數據層支持的應用程序隨著業務需求的發展而快速迭代更新。
3.4 面向對象的思維
在圖中，每個點和邊都是自包含對象實例。在基于模式的圖數據庫中，用戶定義點類型和邊類型，就像對象類一 樣。此外，將點關聯至其他點的邊有點類似于對象方法，因為邊說明點可以“做”什么。要處理圖中的數據，需要 “遍歷”邊，在概念上是指從一個點遍歷到相鄰點，保持數據的完整性。比較而言，在關系型數據庫中，要關聯兩個記錄， 必須將它們相連并創建新的數據記錄類型。
4 圖數據庫應用案例
4.1 互聯網應用
在移動互聯網時代，面對龐大的社交關系，媒體傳播網絡，幫助客戶快速、有效地發現海量數據中隱含的信息：
l 推薦好友、商品或資訊
通過好友關系、用戶畫像、行為相似性、商品相似性、資訊傳播路徑等，實現好友、商品或資訊的個性化精準推薦。
l 用戶分群
通過對用戶畫像、行為相似度以及好友關系等，進行用戶分群，實現用戶群體精準管理。
l 輿情&****社會化聆聽
通過對資訊傳播、好友關系分析，識別意見領袖及熱點話題，分析傳播路徑，增強輿情分析質量。
4.2 知識圖譜應用
基于圖引擎服務的知識圖譜，融合各種異構異質數據，可以支持更大的規模以及更高的性能。
l 存儲海量知識
融合各種異構異質數據，方便治理，規模可達千億級
l 知識梳理
通過圖上分析計算，合并相似本體，進行知識消歧
l 學習路徑識別及推薦
通過知識點的先修關系，識別學習路徑，針對薄弱知識點進行學習路徑推薦
4.3 金融風控應用
面對層出不窮、復雜多樣的個人和群體行為，幫助客戶挖掘出潛在的風險，為客戶保駕護航。
l 實時欺詐檢測
提供實時的用戶行為檢測，識別敏感用戶，信息不一致的用戶，及時識別欺詐風險
l 群體發現
根據錯綜復雜的人物關系分析，進行用戶分群，識別異常群體
l 失聯人員追蹤
可以輕松發現多人之間的關系，通過蛛絲馬跡尋找失聯人員
4.4 企業IT應用
網絡&IT基礎設備規模龐大、結構復雜，幫助客戶深入了解設備狀態、設備之間的關系，實現全網絡設備智能監控與管理。
l 合理規劃網絡
快速確定故障節點對網絡的影響，并在依賴的節點周圍推薦備用路由，在新節點規劃時精確規劃網絡位置
l 分析故障根因
快速輕松地識別任何網絡或基礎設施問題的根本原因，也讓您能更好地了解構成IT基礎架構的所有組件和關系。
l IT****基礎設施管理
通過圖形化網絡設備關聯關系，讓您更好地了解設備、資產的狀態，極大降低設備管理成本
5 常見開源圖數據庫
目前市場上主流的圖數據庫有： Neo4j、Arangob、Orientdb、Allegrograph、Ontotext Graphdb、Graph Story、Titan、Stardog、Graphbase、Dgraph、Oracle Space And Graph、Hypergraphdb、Blazegraph、Aster、Sparksee、Velocitygraph、Sqrrl Enterprise、Ibm System G Native Store、Graph Engine、Thingspan、Bitsy、Apache Giraph、Flockdb、Infogrid、Grapholytic，Weaver 等
根據https://db-engines.com/en/ranking_trend/graph+dbms調研分析，各個開源圖數據庫的活躍程度。見圖****圖數據庫活躍折線圖 ，下面依次簡單介紹活躍指數前5的圖數據庫以及分布式的兩個數據庫JanusGraph、Dgraph（主要關注其：開源、成熟度、可擴展性、文檔豐富度、性能、穩定性、運維成本、易用性）。
圖 圖數據庫活躍折線圖
5.1 Neo4j
Neo4j是一個流行的圖形數據庫，它是開源的。最近，Neo4j的社區版已經由遵循AGPL許可協議轉向了遵循GPL許可協議。盡管如此，Neo4j的企業版依然使用AGPL許可。Neo4j基于Java實現，兼容ACID特性，也支持其他編程語言，如Ruby和Python。
Neo4J使用原生的圖存儲，以高度自由且規范的方式管理和存儲數據。它可以明快地顯示數據每個相關部分之間的鏈接，也可以在數據庫查詢中忽略不必要的細節。對比非原生圖解決方案中，隨著信息量的增加，使用面向對象的數據庫存儲數據庫使數據操作變得越來越慢。Neo4J可以以每秒一百萬條的驚人速度提供結果，因為數據中的鏈接部分或實體在物理上是已經相互連接的。（性能瓶頸）
l Cypher****圖查詢語言
Cypher是Neo4j的圖形查詢語言，允許用戶存儲和檢索圖形數據庫中的數據。類似關系數據庫中的SQL，Cypher設計借鑒了基于SQL、Python語言慣用做法。
舉例，我們要查找Joe的所以二度好友：
查詢語句如下：
MATCH
(person:Person)-[:KNOWS]-(friend:Person)-[:KNOWS]-
(foaf:Person)
WHERE
person.name = "Joe"
AND NOT (person)-[:KNOWS]-(foaf)
RETURN
Foaf
Joe認識Sally，Sally認識Anna。 Bob被排除在結果之外，因為除了通過Sally成為二級朋友之外，他還是一級朋友。
l Gremlin
Gremlin是Apache TinkerPop框架下的圖遍歷語言。Gremlin是一種函數式數據 流語言，用戶可以使用簡潔的方式實現對復雜的屬性圖（property graph）的遍歷或查詢。每個Gremlin遍歷由一系列步驟（可能存在嵌套）組成，每一步都在數 據流（data stream）上執行一個原子操作。
5.2 Microsoft Azure Cosmos DB
Azure Cosmos DB 是 Microsoft 提供的全球分布式多模型數據庫服務。 只需單擊一個按鈕，即可通過 Cosmos DB 跨任意數量的全球 Azure 區域彈性且獨立地縮放吞吐量和存儲。 你可以彈性縮放吞吐量和存儲，并通過以下常用 API 利用個位數毫秒級的快速數據訪問：SQL、MongoDB、Cassandra、表或 Gremlin。 Cosmos DB 為吞吐量、延遲、可用性和一致性保證提供綜合服務級別協議 (SLA)，這是其他數據庫服務無法提供的。
Azure Cosmos DB通過自動縮放吞吐量、計算和存儲來提供多主數據庫功能。
5.3 ArangoDB
Arangodb以一種非常創造性和靈活的方式安排數據。數據可以存儲為鍵或值對、圖或文檔，所有這些都可以通過一種查詢語言訪問。為了更安全的選擇，查詢中可以使用聲明性模型。用戶可以在一個查詢中組合不同的模型及其特性的原因是，ArangoDB對所有數據模型都使用相同的核心和相同的查詢語言。
Arangodb獨特的特性是它能夠在一個查詢中組合不同的數據模型。這使得其展示方式令人印象深刻且美觀。它比其他數據庫具有更靈活的擴展性、增強的容錯性、大容量的存儲能力和更低的成本。arangodb最突出的特性是foxx，這是一個用于編寫數據庫中以數據為中心的javascript框架。
5.4 OrientDB
OrientDB是第二代分布式圖數據庫,以混合數據模型為特點，它包括可以在最復雜的場景中使用復制和分片，并以Apache2許可證提供開放源代碼。ORIENTDB工作速度快，能夠在最常見的硬件上每秒存儲220000條記錄，并且支持無模式、完整和混合模式，可以使用SQL作為查詢語言之一。ORIENTDB使用身份驗證、密碼和靜態數據加密等方式為所有機密數據提供安全保護。
l ArangoDB、OrientDB、Neo4J之間的對比。
表 ArangoDB、OrientDB、Neo4J之間的對比
5.5 Virtuoso
RDF數據庫，運用于知識圖譜的知識存儲，國外比較火熱。官方文檔也不是很友好。國內做關聯數據的感覺也不熱，相關的資源不太好找。
5.6 JanusGraph（分布式）
JanusGraph 是一個高度可擴展的分布式圖數據庫，專門用于存儲和查詢包含數千億個分布在多機群集中的極點和邊緣的圖形。 JanusGraph 是一個事務處理型數據庫，可以支持數千個并發用戶實時執行復雜的圖遍歷。
l 支持海量的圖數據。 JanusGraph所支持的圖的大小取決于集群中機器的數量。
l 支持大并發下圖的事務和操作處理。 JanusGraph的事務處理能力與集群中的機器數量成正比，并且能夠毫秒級的響應在海量圖數據上的復雜的遍歷查詢操作。
l 通過Hadoop框架支持全量圖分析和批量圖處理。
l 支持對大圖的頂點和邊進行地理位置，數值范圍和全文的檢索。
l 原生支持圖形遍歷語言Gremlin
JanusGraph的存儲系統依賴于像Cassandra、HBase、BerkelyDB等等這樣的存儲系統，索引系統依賴于Elasticsearch、Solr、Lucene等等。也基于這些原因，它和大數據生態結合的非常好，可以很好地和Spark結合做一些大型的圖計算；但缺點就是它的維護成本會非常高，依賴于這么多的外部系統，搭建一套JanusGraph系統的同時需要搭建好幾套依賴系統；另一方面就是穩定性，根據經驗來看，系統越復雜，依賴系統越多，整體可控性就越差，穩定性風險就越大，學習成本高。
下圖為JanusGraph架構：
5.7 Dgraph（分布式）
Dgraph是分布式，支持事務，快速的圖形數據庫，谷歌開發，DGraph 的目標是提供 Google 生產水平的規模和吞吐量，在超過TB的結構數據里，為用戶提供足夠低延遲的實時查詢。DGraph 支持 GraphQL 作為查詢語言，響應 JSON。
Dgraph是一個真正的分布式圖數據庫，而不是以master-slave模式復制數據全集的。它根據謂語分片，并在集群中備份謂語，查詢可以在任何節點上執行，連接是基于分布式的數據執行的。
Dgraph架構圖如下：
從開源、成熟度、可擴展性、文檔豐富度、性能、穩定性、運維成本、易用性，分布式圖數據庫Dgraph、JanusGraph與單機版本的圖數據庫進行對比，詳見下圖。
6 技術選型分析
單機 Neo4j
開源社區老大，毋庸置疑，資源多技術成熟。學習成本低。單機首選。
分布式 JanusGraph
分布式對比：
總結一下兩種圖數據庫特性的對比：
l 架構方面：JanusGraph構建在大數據組件之上，數據管理更方便。Dgraph是分布式的，但是獨自成立一套分布式系統，數據需要通過其它手段寫入集群中。
l 副本方面：JanusGraph需要依賴底層的存儲DB，HDFS。Dgraph是強一致性的。
l 數據均衡方面： JanusGraph也是依賴底層的存儲HDFS，Dgraph支持自動均衡。
l 語言方面：JanusGraph使用了比較常用的Gremlin，而Dgraph使用基于GraphQL改進的GraphQL。
l 可視化方面：JanusGraph依賴外部系統展示，Dgraph有自己的可視化系統。
l 維護成本方面：由于不依賴其他系統，Dgraph遠低于JanusGraph。
附錄 Neo4j. 常見問題
l neo4j數據庫支持最大多少個節點？最大支持多少條邊？
目前累積統計它有34.4億個節點，344億的關系，和6870億條屬性。
l 在數據庫中，讀/寫性能跟節點/邊的數量有關嗎？
這個問題意味著兩個不同的問題。單次讀/寫操作不依賴數據庫的大小。不管數據庫是有10個節點還是有1千萬個都一樣。 — 然而，有一個事實是如果數據庫太大，你的內存可能無法完全緩存住它，因此，你需要頻繁的讀寫磁盤。雖然很多用戶沒有這樣大尺寸的數據庫，但有的人卻有。如果不巧你的數據庫達到了這個尺寸，你可以擴展到多臺機器上以減輕緩存壓力。
l neo4j數據庫支持的讀/寫并發請求最大數量是多少呢？
在并發請求上面沒有任何限制。服務器的并發量更多的是依賴于操作本身的性能（高壓寫操作，簡單讀，復雜的遍歷等等），以及使用的硬件性能。據粗略估計，在遍歷最簡單路徑時每毫秒可以達到1000次請求。在討論了指定的用戶案例后，我們能得到更好的性能優化方案。
l 如何進行數據庫查詢？
核心 API, Traversal API, REST API, Cypher
l 官方文檔鏈接
