目錄
儘管本書中有很多是關於圖形數據模型的，但它不是一本關於圖形理論的書。我們不需要太多理論來利用圖形數據庫：只要我們瞭解圖形是什麼，我們就可以在那裏使用。 考慮到這一點，讓我們回顧一下一般的圖表。
1.什麼是圖？
從形式上講，圖只是頂點(vertices)和邊(edges)的集合，或者在不那麼嚇人的局域網中語言，一組節點(nodes)和連接它們的關係圖形表示實體作爲節點的聯繫以及這些實體作爲關係與世界聯繫的方式。這種通用的表達結構允許我們模擬各種場景，從太空火箭的建造，到道路系統，再到補給系統-食物的鏈或來源，到人口的醫學史，甚至更遠。
形式上，圖只是頂點(vertices)和邊(edges)的集合，或者用較少威脅性的語言表示的是一組節點(nodes)和連接它們的關係(relationships)。 圖將實體表示爲節點，並將這些實體與世界的關係表示爲關係。這種通用的表達結構使我們能夠對各種情況進行建模，從建造太空火箭到道路系統，從食品的供應鏈或食品來源到人口的醫療史等等。
圖無處不在
圖對於理解字段中的各種數據集非常有用，例如科學，政府和商業。 真實世界-與基於表單的世界不同，關係數據庫背後的模型是豐富且相互關聯的：部分統一且受規則約束，其他部分則異常且不規則。 一旦瞭解了圖，我們開始在各種各樣的地方見到他們。 例如，Gartner會識別出五個圖形商業世界-社會，意圖，消費，興趣和移動性，利用這些圖表的能力提供了“可持續的競爭優勢”。
例如，Twitter的數據很容易表示爲圖形。 在圖1-1中，我們看到了一個由Twitter用戶組成的小型網絡。 每個節點都標記爲User，指示其在網絡中的角色。 然後將這些節點與關係聯繫起來，這有助於進一步建立語義上下文：即，比利（Billy）跟隨哈利( Harry )，而( Harry )哈利轉跟着比利（Billy）。 露絲（Ruth）和哈利（Harry）也互相追隨，但可悲的是，儘管露絲（Ruth）跟着比利（Billy），但比利（Billy）沒有做出回報。
當然，Twitter的真實圖形比圖1-1中的示例大數億倍，但是它的工作原理完全相同。 在圖1-2中，我們將圖形擴展爲包括Ruth發佈的消息。
儘管簡單，但圖1-2顯示了圖模型的表達能力。 很容易看出露絲（Ruth）已發佈了一連串消息。 通過遵循標記爲CURRENT的關係可以找到她的最新消息。 然後，上一個關係創建了露絲的時間表。
標記的屬性圖模型
在討論圖1-2時，我們還非正式地介紹了圖模型的最流行形式，即標記的屬性圖（在附錄A中，我們更詳細地討論了替代圖數據模型）。 帶標籤的屬性圖具有以下特徵：
- 它包含節點和關係。
- 節點包含屬性（鍵值對）。
- 節點可以用一個或多個標籤標記。
- 關係是命名和定向的，並且始終具有起點和終點。
- 關係也可以包含屬性。
多數人認爲屬性圖模型直觀易懂，儘管它很簡單，但它可以用來描述絕大多數圖用例，從而對我們的數據產生有用的見解。
2.圖空間的高級視圖
近年來，用於管理，處理和分析圖形的許多項目和產品迅速出現。 龐大的技術使跟蹤這些工具及其不同之處變得困難，即使對於我們這個領域活躍的人來說也是如此。 本節提供了一個高級框架，使您可以瞭解新興的圖形環境。 從10,000英尺開始，我們可以將圖形空間分爲兩部分： .
- 主要用於交易在線圖持久性的技術，通常直接從應用程序實時訪問
- 這些技術稱爲圖形數據庫，是本書的重點。 它們相當於關係世界中的“常規”在線事務處理（OLTP）數據庫。
- 主要用於離線圖形分析的技術，通常作爲一系列批處理步驟執行
- 這些技術可以稱爲圖形計算引擎。 可以認爲它們與其他用於批量數據分析的技術屬於同一類別，例如數據挖掘和在線分析處理（OLAP）。
劃分圖空間的另一種方法是查看各種技術採用的圖模型。 有三種主要的圖數據模型：屬性圖（property graph），資源描述框架（RDF）三元組和超圖（hypergraphs）。 我們在附錄A中對此進行了詳細描述。市場上大多數流行的圖形數據庫都使用屬性圖模型的變體，因此，在本書的其餘部分中將使用該模型。
2.1.圖數據庫
圖形數據庫管理系統（以下稱爲圖形數據庫）是一種在線數據庫管理系統，具有創建，讀取，更新和刪除（CRUD）方法，這些方法公開圖形數據模型。 圖形數據庫通常是爲與事務（OLTP）系統一起使用而構建的。 因此，它們通常針對事務性能進行優化，並且在設計時要考慮事務的完整性和操作可用性。
研究圖數據庫技術時，應考慮圖數據庫的兩個屬性：
- 基礎存儲
- 一些圖形數據庫使用本機圖形存儲，該存儲已針對存儲和管理圖形進行了優化和設計。 但是並非所有的圖形數據庫技術都使用本機圖形存儲。 有些將圖形數據序列化爲關係數據庫，面向對象的數據庫或某些其他通用數據存儲。
- 處理引擎
- 一些定義要求圖形數據庫使用無索引（index-free）的鄰接關係，這意味着連接的節點在數據庫中在物理上彼此“指向”。 在這裏，我們從一個更寬泛的角度來看：從用戶的角度來看，任何行爲類似於圖形數據庫（即通過CRUD操作公開圖形數據模型）的數據庫都可以視爲圖形數據庫。 但是我們確實承認無索（index-free）引鄰接的顯着性能優勢，因此使用術語本機圖形處理來描述利用無索引鄰接的圖數據庫。
請務必注意，本機圖形存儲和本機圖形處理既不是好事也不是壞事，它們只是經典的工程折衷。 本機圖存儲的好處是其專門構建的堆棧旨在提高性能和可伸縮性。相比之下，非本機圖存儲的好處是它通常依賴於成熟的非圖後端（例如MySQL），該後端的生產被運營團隊理解特性很好。本機圖形處理（無索引鄰接）可提高遍歷性能，但以使一些不使用遍歷的查詢困難或佔用大量內存爲代價。
關係是圖數據模型的一等公民。 在其他數據庫管理系統中則不是這種情況，在其他數據庫管理系統中，我們必須使用諸如外鍵之類的東西或諸如map-reduce之類的帶外處理來推斷實體之間的連接。通過將節點和關係的簡單抽象組裝到連接的結構中，圖形數據庫使我們能夠構建任意複雜的模型，這些模型緊密地映射到我們的問題域。與使用傳統關係數據庫和其他NOSQL（不僅是SQL）存儲庫生成的模型相比，生成的模型更簡單，同時更具表現力。
圖1-3顯示了基於存儲和處理模型的當今市場上某些圖形數據庫的圖形概述。
2.2.圖計算引擎
圖形計算引擎是一項使全局圖形計算算法能夠針對大型數據集運行的技術。 圖形計算引擎旨在執行諸如識別數據中的羣集或回答“社交網絡中的每個人平均多少關係”之類的問題。
由於它們強調全局查詢，因此通常對圖計算引擎進行了優化，以批量掃描和處理大量信息，並且在這方面，它們類似於關係分析中使用的其他批處理分析技術，例如在關係世界中使用數據挖掘和OLAP。 一些圖形計算引擎包括圖形存儲層，而其他（可能是大多數）圖形引擎則嚴格地處理自己從外部源輸入的數據，然後將結果返回以存儲在其他地方。
存在多種不同類型的圖計算引擎。 最值得注意的是，內存/單機圖形計算引擎（如Cassovary）和分佈式圖形計算引擎（如Pegasus或Giraph）。 大多數分佈式圖形計算引擎都基於Google撰寫的Pregel白皮書，該白皮書描述了Google用於對頁面進行排名的圖形計算引擎。
本書着重於圖數據庫
上一節提供了整個圖空間的粗粒度概述。本書的其餘部分着重於圖數據庫。 我們的目標始終是描述圖形數據庫的概念。 在適當的情況下，我們將舉例說明這些概念，這些示例來自我們使用標記的屬性圖模型和Neo4j數據庫開發解決方案的經驗。 但是無論示例中使用的是圖形模型還是數據庫，重要的概念都會轉移到其他圖形數據庫中。
3.圖數據庫的力量
儘管幾乎所有事物都可以建模爲圖表，但我們生活在務實的預算，項目時間表，企業標準和商品化技能世界中。 圖數據庫提供了強大而新穎的數據建模技術，但它本身並不能提供足夠的理由來取代公認的，易於理解的數據平臺； 還必須立即產生非常重大的實際收益。 在圖數據庫的情況下，這種動機以一組用例和數據模式的形式存在，當在圖中實現時，它們的性能提高一個或多個數量級，並且其效率遠低於批處理聚集體 。 除了這種性能優勢之外，圖形數據庫還提供了非常靈活的數據模型，並且提供了與當今敏捷軟件交付實踐一致的交付模式。
3.1.性能
因此選擇圖形數據庫的一個令人信服的原因是，與關係數據庫和NOSQL存儲相比，在處理連接數據時性能得到了極大提高。 與關係數據庫相反，關係數據庫的聯接密集型查詢性能隨着數據集的變大而降低，而圖數據庫的性能往往保持相對恆定，即使數據集增長也是如此。 這是因爲查詢被本地化到圖的一部分。 結果，每個查詢的執行時間僅與滿足該查詢所遍歷的圖的一部分的大小成正比，而不與整個圖的大小成正比。
3.2.靈活性
當我們最不瞭解數據的真實形狀和複雜性時，作爲開發人員和數據架構師，我們希望根據領域的要求連接數據，從而使結構和架構隨着對問題空間的日益瞭解而串聯出現，而不是先行提出。 圖形數據庫直接解決了這個需求。 正如我們在第3章中所展示的，圖形數據模型以使IT能夠以業務速度移動的方式來表達和適應業務需求。
圖自然是可加的，這意味着我們可以在現有結構中添加新類型的關係，新節點，新標籤和新子圖，而不會干擾現有查詢和應用程序功能。 這些因素通常對開發人員的生產力和項目風險產生積極影響。 由於圖形模型具有靈活性，因此我們不必提前詳盡地爲我們的域建模-面對不斷變化的業務需求，這種做法幾乎是非常困難的。 圖的可加性也意味着我們傾向於執行較少的遷移，從而減少了維護開銷和風險。
3.3.敏捷
我們希望能夠使用與當今的增量和迭代軟件交付慣例保持一致的技術來與我們的其他應用程序同步地發展數據模型。 現代圖形數據庫使我們能夠執行無摩擦開發和正常系統維護。 尤其是，圖形數據模型的無模式性質，再加上圖形數據庫的應用程序編程接口（API）和查詢語言的可測試性質，使我們能夠以受控方式開發應用程序。
同時，正因爲它們沒有架構，圖數據庫缺乏我們在關係世界中熟悉的那種面向架構的數據治理機制。 但這不是風險。 相反，它提出了一種更爲可見和可操作的治理方式。 正如我們在第4章中所展示的那樣，治理通常以編程方式應用，使用測試驅逐數據模型和查詢，以及斷言依賴於圖形的業務規則。 這不再是一個有爭議的做法：圖形數據庫開發比關係開發更重要，它與當今的敏捷和測試驅動的軟件開發實踐完全吻合，允許圖形數據庫支持的應用程序隨着不斷變化的業務環境而不斷髮展。
4.摘要
在本章中，我們回顧了圖屬性模型，它是一種簡單但可表示表情的表示連接數據的工具。 屬性圖以富有表現力和靈活性的方式捕獲複雜的域，而圖數據庫使開發可操縱圖模型的應用程序變得容易。
在下一章中，我們將更詳細地介紹幾種不同的技術如何解決連接數據的難題，從關係數據庫開始，轉移到聚集的NOSQL存儲，再到圖數據庫結束。 在討論過程中，我們將瞭解爲什麼圖形和圖形數據庫爲建模，存儲和查詢關聯數據提供了最佳方法。 隨後的各章繼續說明如何設計和實現基於圖形數據庫的解決方案。