1. 圖論

1.1. 起源於萊昂哈德·歐拉在1736年發表的一篇關於“哥尼斯堡七橋問題”的論文

1.2. 要解決這個問題，該圖需要零個或兩個具有奇數連接的節點

1.3. 任何滿足這一條件的圖都被稱為歐拉圖

1.4. 如果路徑只訪問每條邊一次，則該圖具有歐拉路徑

1.5. 如果路徑起點和終點相同，則該圖具有歐拉迴路，或稱為歐拉環

2. 圖

2.1. 頂點和邊的集合

2.2. 示例

2.2.1. 路線圖

2.2.2. 組織結構圖

2.3. 當要思考的數據集含有大量高度相互關聯的項時，也可以將該數據集描述為一個由相關事物組成的網路，這也是圖的另一種說法

3. 頂點

3.1. 圖中零條、一條或多條邊經過的點

3.2. 節點或實體

4. 邊

4.1. 圖中兩個頂點之間的關係

4.2. 關係、鏈接或連接

5. 圖資料庫

5.1. 一種數據存儲引擎

5.1.1. 將包含頂點和邊的基本圖結構與持久化技術和遍歷（查詢）語言相結合

5.1.2. 以創建針對高度關聯數據的存儲和快速檢索進行優化的資料庫

5.2. 實體之間的關係與數據中的實體同等重要，甚至比後者更加重要

5.2.1. 用開發人員的話來說，邊和頂點一樣，都是“一等公民”

5.3. 可以用於更準確、更容易地表示和推理現實世界中的關係

5.4. 將數據存儲為頂點（節點、組件）和邊（關係）

5.5. Neo4j、Apache TinkerPop的Gremlin Server、JanusGraph和TigerGraph

5.6. 預設情況下，只有關係資料庫和圖資料庫才具有將數據中的實體關聯起來的功能

5.7. 優勢

5.7.1. 遞歸查詢

5.7.1.1. 組織中員工的彙報層次結構或者組織結構圖

5.7.1.2. 會連續執行多次，反覆調用自己，直到滿足某種終止條件

5.7.1.3. 關係資料庫不能很好地處理遞歸操作

5.7.1.4. 圖資料庫能夠利用其表示豐富關係的能力，乾凈、高效地處理無邊界遞歸查詢

5.7.1.5. 嵌套查詢和遞歸查詢（如前面的層次結構示例所示）是圖資料庫擅長解答的疑問類型

5.7.2. 複合結果類型

5.7.2.1. 訂單和產品報告示例

5.7.2.2. 能夠返回包含不同數據類型的結果集

5.7.2.3. 關係資料庫指定聯合返回的結果集必須包含一致的列

5.7.2.3.1. 在稀疏數據的情況下，這不僅增加了返回的數據量，還降低了數據結構的描述性

5.7.3. 路徑

5.7.3.1. 過河問題

5.7.3.2. 一組頂點和邊的序列，描述遍歷如何在圖中移動

5.8. 請把註意力集中在圖資料庫如何優雅地處理關係資料庫里的UNION操作上

5.9. 可以把圖資料庫設計得能夠容忍不斷發展變化的數據

5.10. 使用

5.10.1. 並不一定全部使用圖資料庫，也並不一定全部不使用圖資料庫

5.10.2. 不要害怕嘗試用圖資料庫來解決問題的一部分

5.10.3. 使用圖資料庫的多模型方法（即混合使用關係資料庫和圖資料庫）很常見

6. 比較

6.1.  鍵值資料庫

6.1.1. 所有數據都由唯一標識符（鍵）和關聯的數據對象（值）表示

6.1.2. Berkeley DB、RocksDB、Redis和Memcached

6.2. 列存儲資料庫

6.2.1. 面向列、寬列式資料庫

6.2.2. 數據按列來存儲

6.2.2.1. 可能每行有大量的列

6.2.2.2. 可能每行的列數不一樣

6.2.3. Apache HBase、Azure Table Storage、Apache Cassandra和Google Cloud Bigtable

6.3. 文檔資料庫

6.3.1. 面向文檔資料庫

6.3.2. 將數據存儲到帶有唯一鍵的文檔中

6.3.3. 該文檔可以具有不同的模式，也可以包含嵌套數據

6.3.4. MongoDB和Apache CouchDB

6.4. 關係資料庫

6.4.1. 將數據存儲在包含具有嚴格模式行結構的表中，允許在表之間連接行來建立關係

6.4.2. 關係資料庫中的查找表或鏈接表使用的不是查詢時的指針結構，而是存儲了有關關係屬性的結構，類似於圖資料庫中的邊結構

6.4.3. PostgreSQL、Oracle Database和Microsoft SQL Server

6.5. 數據複雜性

7. Apache TinkerPop

7.1. TinkerPop是Apache軟體基金會的頂級項目

7.2. 提供了一個與廠商無關的開源圖計算框架

7.3. 具有事務（OLTP）能力和分析（OLAP）能力

7.4. 有廣泛的第三方庫可供使用

8. TinkerGraph

8.1. 一個記憶體圖引擎

8.2. 支持OLTP負載和OLAP負載

8.3. TinkerPop Gremlin Server和Gremlin Console的一部分

8.4. TinkerPop的全功能開源實現

8.4.1. 被作為TinkerPop API的參考實現構建出來的

8.5. 並非一個你能下載的軟體

8.5.1. 可下載軟體（如Gremlin Server 和Gremlin Console）里的核心引擎

9. Gremlin

9.1. Gremlin遍歷語言是TinkerPop項目的圖查詢語言

9.2. 支持命令式語法和聲明式語法

9.2.1. 首選方式是命令式語法

9.3. Gremlin Console

9.3.1. 用於TinkerPop支持圖資料庫的交互終端應用程式

9.3.2. 允許用戶連接到本地或遠程的資料庫，將數據載入到圖中，並互動式地在圖上進行遍歷

9.3.3. 能作為自帶記憶體圖數據的獨立應用程式使用

9.3.4. 能作為圖資料庫伺服器的客戶端使用

9.4. Gremlin Server

9.4.1. 允許非JVM客戶端與基於JVM的圖資料庫進行通信

9.4.2. 提供能讓部署在不同伺服器上的資料庫相互通信的機制

9.5. Gremlin語言變體

9.5.1. 允許開發人員既使用Gremlin作為查詢語言，又能通過他們選擇的開發語言方言來實現

9.5.2. 主張以應用程式編程語言的風格來編寫Gremlin遍歷

9.5.2.1. Java開發人員使用Java語法

9.5.2.2. .NET開發人員使用.NET語法

10. 用例/場景

10.1. 從社交網路分析、推薦引擎、依賴性分析、欺詐檢測和主數據管理，到搜索問題和互聯網上的研究，你很快就能列出一個適合使用圖資料庫的用例列表

10.2. 判斷一個用例是好還是壞的最重要因素是對要解答的疑問有深入的瞭解

10.3. 選擇/搜索

10.3.1. 側重於尋找一組具有共同屬性（如姓名、位置或雇主）的實體

10.3.2. 不需要數據中豐富的關係

10.3.3. 建議使用諸如PostgreSQL之類的本地資料庫或諸如Apache Solr和Elasticsearch之類的搜索技術

10.3.4. 使用RDBMS或搜索技術

10.4. 獲取數據相關性或遞歸數據

10.4.1. 圖資料庫比任何其他類型數據引擎都能更好地利用這些信息

10.4.2. 圖資料庫查詢語言更適用於推斷數據內部的關係

10.4.3. 使用圖資料庫

10.5. 聚合

10.5.1. 數據聚合查詢是關係資料庫的一個優秀用例

10.5.2. 關係資料庫經過優化，能以最小的開銷快速執行複雜的聚合查詢

10.5.3. 可以在圖資料庫中執行，但是圖遍歷的本質要求接觸更多的數據。這會導致更高的查詢延遲和更多的資源消耗

10.5.4. 使用RDBMS

10.6. 模式匹配

10.6.1. 基於實體關聯方式的模式匹配是充分利用圖資料庫功能的一個主要例子

10.6.2. 推薦引擎、欺詐檢測和入侵檢測

10.6.3. 使用圖資料庫

10.7. 中心性、聚集性和影響力

10.7.1. 一個實體相對於另一個實體的影響力或重要性是圖資料庫的典型用例

10.7.2. 識別基礎設施的關鍵部分，或者定位數據中的實體組

10.7.3. 要考慮實體、實體之間的關係、事件關係和鄰近關係

10.7.4. 使用圖資料庫

10.8. 數據結構的靈活性不能作為選擇圖資料庫的充分理由，但與其他功能相結合，很可能足以使你轉而使用圖資料庫

10.9. 即使業務領域模型天生適合使用圖資料庫，但是如果你的具體技術問題並不依賴於圖中的關係來求解，那麼也應該考慮其他選擇

11. SQL

11.1. SQL查詢中包含大量join可能表明圖資料庫是一個很好的選擇，但並不能確定

11.2. SQL查詢中的大量join通常是數據模型規範化的良好標誌

11.3. 當這些join並非用於檢索引用數據（如關係資料庫中的第三個範式所做的那樣），而是用於將記錄項鏈接在一起（就像父子關係那樣）時，就可能需要考慮使用圖資料庫了

11.4. 當我們不知道要執行的join數量時，使用圖資料庫的遞歸查詢模式更好

11.5. 命令查詢責任分離（CQRS）模式