多數據模型資料庫

來這裡找志同道合的小夥伴！

作者簡介

呂信，京東商城技術架構部資深架構師，擁有多年數據產品研發及架構經驗。在京東及國內主導過多種數據產品的開發及社區建設，積極活躍於數據產品領域，對資料庫及大數據領域各個產品具有豐富經驗，目前在京東商城主導彈性資料庫研發及推廣使用。

聲明：本文大部分是基於ArangoDB的論文的翻譯，在翻譯過程中加入了自己的一些理解和說明。

無論是為一個新的項目或者正在開發的功能模塊又或者某一次系統升級去選擇技術方案的時候，我們很難做出一個從始至終都非常match的技術方案或者工具，尤其是在為項目選擇合適的資料庫時，我們更是難以選擇。是文檔型資料庫？K-V資料庫？RDMS？還是圖資料庫？

在軟體領域一直存在一種理論：「one size does not always fit all」，但是該理論是否正確，業界的眾多專家一直爭論不休。該理論建議大型的軟體中不同的模塊應該採用不同的數據模型進行數據管理。這也就意味著在同一個工程中，你不得不採用多個資料庫，但這樣做又引入了新的問題：運維和管理的複雜、數據一致性和數據重複的問題等。

機遇與問題總是伴生，這也就是出現原生多模型資料庫的原因。本文將會解釋什麼是多模型資料庫，為什麼要使用多模型資料庫以及多模型資料庫應該運用在什麼地方。本文將會基於飛機維護保障團隊管理的實例，說明如何使用多模型資料庫。

隨著多模型資料庫與NO-SQL變得越來越流行，很多資料庫廠商都標榜自己是「多數據模型」。所以僅僅從市面上現存的多模型資料庫產品（有些真的是多模型資料庫，有些僅僅將自己炒作成多模型資料庫）去總結，很難對多模型資料庫有明確的定義，這也導致那些為自己的產品或者項目尋求多模型解決方案的人員對多模型資料庫產品的理解不清晰。

對於多模型資料庫的理解，最重要的一點就是：我們一定要認識到疊加的多模型方案（例如基於document或者k-v存儲之上的Graph層，這其實也算是多模型）與native多模型方案是不同的。

什麼是原生多模型資料庫呢？

簡單來說，原生多模型資料庫就是將多種數據存儲組合在一起。在多模型資料庫中，數據可以存儲為鍵/值對、圖形或文檔，並且可以使用一種聲明式查詢語言進行訪問，也有可能在一次查詢中涉及到的數據會跨越多個數據模型。

通過native多模型資料庫，您可以構建高性能應用程序並且可以很自然的將規模和處理問題的領域範圍水平擴展到三種數據模型cover到的所有外延領域。與很多資料庫廠商採用的「分層的方法」相比，native多數據模型提供了更大的靈活性和性能優勢。簡而言之，native多數據模型資料庫有一個內核、一種查詢語言和多種數據模型。

近年來，「多語言持久性」的概念已經變得非常流行。所謂的「多語言持久性」就是在同一個項目或者產品中，同時採用多種不同的資料庫。然而，如上所述，一些業界專家對「在大型軟體項目中，針對持久層的不同部分採用不同的數據模型」的理論的正確性一直存在極大的爭議。

按照這種理論的說法，人們應該使用RDBMS存儲表結構的數據；使用document存儲非結構化的對象數據；使用k/v存儲hash表；使用圖資料庫存儲相互之間有複雜引用關係的數據。凡有收益，必有代價。這樣所的代價就是：在同一個項目中採用多種資料庫，這也就引入了運維的複雜和繁瑣（部署更複雜、升級更頻繁）、數據一致性問題和數據冗餘問題。

結構化表、文檔、K-V和圖：不同的數據模型

這就是多模型資料庫需要解決的問題，你可以通過使用多模型資料庫（由文檔模型、K-V模型和圖模型組成的單一資料庫引擎）來解決該問題。多模型資料庫具有統一的查詢語言和API，查詢語言和API可以涵蓋所有三種數據模型，並且允許在單個查詢中混合查詢三種模型。

選擇這三種模型（文檔、K-V和圖）是因為通過長期的不斷嘗試，我們發現將這三種模型組合在一起形成的架構可以在任意單一數據模型領域的專門產品（文檔型數據、K-V資料庫或者圖資料庫）在查詢性能和內存使用率上一較高低。通過使用三種數據模型組合形成的多模型資料庫，您可以在不需要使用多種資料庫的前提下就可以實現「多語言持久性」。

那麼，native多模型資料庫的實現機制是什麼？在document集合中的每份document都會有一個唯一主鍵，用來唯一標示一份document。這樣就可以將一份document存儲在K/V存儲中，當存儲在K/V存儲中的時候，key是每個document的唯一標示（也就是每個document的唯一主鍵），通常是字元串，value的內容是json字元串，json字元串其實就是document的實際內容。實際上以json字元串作為value不但沒有導致性能下降，還提供了很大的靈活性。

圖數據模型可以以這樣的方式實現：以json的方式來存儲vertices和edge的數據。edge被保存在特定的edge集合中，每條edge都必須含有from和to屬性，這兩個屬性分別指向該edge的開始和結束的vertices。

通過上面的的方式實現了三種數據模型的統一。即：通過document的唯一主鍵作為key，以json形式表示的document的內容作為value，存儲在K-V存儲中，因此一個K-V對應一個Document；以json形式的document來存儲圖中的vertices和edge，從而將圖數據存儲在document中。多模型資料庫的層次結構看起來像這樣：

KV-DOC-Graph層次結構

我們還需要實現一種通用的查詢語言，用戶可以通過這種語言不僅完成單獨的document、KV和graph的查詢，也可以完成跨任意的2個或者3個模型的數據的混合查詢。「圖查詢」是指涉及到對edge的特定連接特性的查詢，例如：最短路徑、圖遍歷和模式匹配。多模型資料庫中的模式匹配會根據任意查詢條件的複雜組合，查詢出符合該組合條件的所有路徑。這些查詢條件包括：單個document或者edge上的某些過濾條件以及整個圖上的過濾條件。

native多模型資料庫非常適合於大規模多層級數據的管理，例如：飛機維保團隊管理。一個飛機維保團隊由幾架飛機組成，典型的飛機由數百萬個部件組成，而每個大的部件又有很多小的部件組成。我們在腦海中對這些數據大致產生了一個層次關係。為了對團隊的數據進行管理，我們必須對不同層次的數據採用不同的存儲方式。

每個零件或組件都有名稱，序列號，製造商信息，維護間隔，維護日期，分包商信息，手冊和文檔的鏈接，聯繫人，保修和服務合同信息等。每份數據都是其上層數據的一部分。我們可以通過回答下面的問題（包括但不限於），來對數據進行整理和採集：

一個組件總共包含哪些部分？

對於某一（破損）部件，包含該部件並且被維修過的最小組件是什麼？

哪些組件需要在下一周進行維修？

如果我們擁有一個多模型資料庫，我們如何對這些飛機維保數據進行建模？

建模方式有多種，但是若想支持快速查詢，就應該按照如下方式進行建模：

雖然數據分為不同的層級，但是我們可以對不同層級中的每一項數據都使用JSON格式的document進行存儲。由於JSON天生具有靈活性和嵌套性，因此我們可以採用JSON文檔存儲任意數據。另外由於文檔存儲是schemaless的，因此即使存儲的數據的屬性和結構完全不一樣，也沒有問題，例如你可以使用JSON文檔同時存儲發動機數據、螺絲釘數據和飛機數據。

除此之外，我們使用圖模型來存儲不同數據之間的層次和關聯關係。具體如下：整個飛機維保團隊是一個vertices，每個飛機也是一個vertices，飛機的每個大型組件，如：發動機也是一個vertices。團隊vertices與每個飛機vertices之間都有一條edge相連，每個飛機vertices都與飛機的發動機vertices之間也有一條edge，表示發送機是飛機的一部分。每個發動機vertices又會和發動機的子組件對應的vertices之間存在edge。以此類推，直到每個小組件都與它包含的每個單獨部分都有edge相連。如下圖所示：

我們可以將所有數據放在一個（vertices）集合中，也可以將它們分成不同的集合 - 例如分別對飛機，部件和各個部件進行分類，每類數據一個集合。其實數據存儲在一個集合還是多個集合中，對於圖來說無關緊要，但是對數據按照分類組合成多個不同的集合，更利於定義和構建二級索引，而二級索引可以使我們的某些特定條件的查詢性能更高。

我們將使用ArangoDB查詢語言（AQL）來完成某些特定的查詢。現在我們來看下我們可以使用AQL來完成哪些查詢。

1、給定一個組件，查看該組件的所有組成部分是什麼

要回答該問題，需要從圖中的特定vertices（某個給定的組件）開始，首先找到指定的組件，並找到與該「組件」vertices通過edge相連的所有的下層的vertices - 所有vertices都可以通過edge，按照edge的方向遍歷到，這是典型的圖遍歷。

查看某個組件的所有組成部分

以下是此查詢的示例代碼，該查詢通過圖遍歷，從查找「components / Engine765」頂點開始，返回可以在4步以內訪問到的所有下層vertices：

在ArangoDB中，你可以通過給graph指定一個名稱，並且指定哪些document集合包含vertices，哪些document集合包含edge，來定義一個graph。無論document代表的是vertices還是edge，都是通過它的_id屬性唯一標識，_id是一個字元串，由集合名稱，「/」和主鍵組成。

上面所示的遍歷只需要圖形名稱「FleetGraph」，起始vertices，以及邊的方向：OUTBOUND，這三個條件就可以得到所需要查詢的數據，AQL可以支持這種類型的圖查詢。當然，您可以指定更多的選項，這裡我們不做深入討論。

2、對於某個指定的（孤立的）部件，找到包含該部件並且有維護程序的飛機的最小部件

這種查詢涉及從葉子vertices在樹中反向向上搜索，直到找到有維護記錄的組件vertices。所有數據都可以從相應的JSON文檔中讀取。由於要經過多少步才能找到符合條件的組件，我們先前是不知道的，因此這是一個典型的圖遍歷。這種查詢相對來說是非常簡單的，因為總會有一個唯一的edge從上層的vertices指向下層的vertices。具體的查詢過程如下所示：

下面的AQL語句就可以完成該查詢：從頂點「parts/Screw56744」：a開始，順著edge的「inbound」方向的進行查找，直到找到維護屬性為true的vertices：component，然後返回找到的頂點：component

從上面的查詢語句中，我們指定了graph的名稱、起始頂點的_id和目標頂點的過濾規則。由於我們只對第一個頂點感興趣，因此我們添加了limit 1。我們看到AQL可以直接支持這種查詢。

3、飛機的哪些組件在下周需要保養或者維修

這是一個完全不涉及圖的查詢：而結果往往與圖是正交的。具有正確的二級索引的文檔數據模型非常適合此查詢。

查詢結果與圖結構正交的查詢

使用純粹的圖資料庫執行這種查詢，會比較麻煩，因為我們的查詢無法明確的對圖結構進行過濾，所以我們不得不求助於二級索引。例如，下次維護日期會存儲在組件的某個屬性上。為了得到我們想要的答案，我們應該使用document查詢，這種查詢不會考慮到圖的結構和聯繫。下面的查詢語句用於完成這個查詢：

上面查詢語句中看起來像循環的部分是AQL語言用於進行集合迭代的方式。查詢優化器能夠識別nextMaintenance屬性上的二級索引的存在，這樣執行引擎不必執行完整的集合掃描來進行filter條件的過濾。可以看到，AQL在RETURN語句中以JSON文檔的形式，返回查詢到的數據的相關屬性內容。

為了說明多模型資料庫的強大潛力，最後將會演示一個覆蓋三種數據模型數據的AQL查詢。以下查詢首先查找維護到期的組件，為每個到期的組件計算最短路徑，然後與contacts集合執行JOIN操作，進而向結果中添加具體的聯繫信息：

在查詢語句的最後，我們使用到了AQL的join功能。第二個FOR語句會遍歷聯繫人集合。查詢優化器會自動通過執行JOIN操作來優化FILTER語句，這種優化措施使得查詢非常高效，因為它可以利用聯繫人集合的主索引進行快速哈希查找。

這是一個涉及多個數據模型查詢的典型示例。本次查詢會涉及到三種數據模型：具有二級索引的文檔，圖查詢以及由快速鍵/值查找提供支持的JOIN。想像一下，如果三個數據模型沒有在同一個資料庫引擎中，或者如果無法在同一個查詢中混用這三種數模型，我們就必須採用三種資料庫引擎，並且需要通過應用程序對從不同數據引擎中查詢出來的數據進行加工、聚合和處理。

更重要的是，本示例表明，多模型資料庫確實可以極大地提升應用程序的查詢的性能。在沒有圖資料庫的情況下，要根據路徑長度進行圖查詢（查詢的路徑及步驟並不是預知的），只能轉變為繁瑣的、低效的join查詢。但是，純圖資料庫又不能通過二級索引來提高查詢的性能。我們可以將鍵/值查找與圖查找進行Join，來提供多模型資料庫的靈活性。例如，在上述情況下，我們不必將整個聯繫信息嵌入到每個路徑中，只在最後一個查詢中執行JOIN操作即可。

1、JSON對於非結構化和結構化數據都非常通用

JSON的遞歸特性允許嵌入子文檔和可變長度列表。您甚至可以將表的行存儲為JSON文檔。現代數據存儲非常擅長壓縮數據，與關係資料庫相比，沒有內存開銷。對於結構化數據，可以使用可擴展的HTTP API根據需要實現schema驗證。

2、圖適用於關係建模

在很多實例中，圖可以最自然的反應實際的數據模型，而不需要進行反模式處理。圖不僅可以存儲關係數據，還可以存儲vertices和edge的標籤信息。JSON天生就非常適合存儲這些vertices和關係數據。

3、圖資料庫特別適用於圖查詢

通過圖資料庫可以非常容易的實現「最短路徑」和「圖形遍歷」。而這些的基本功能中涉及到的對某個vertices的outgoing和incoming的邊的反覆頻繁遍歷，均由圖資料庫為你實現，你使用的只是這些基本功能的介面，而不需要關注底層實現細節。

4、多模型資料庫可以與專業解決方案相媲美

我們可以將多種數據模型組合在一個資料庫引擎中。這種組合不是妥協，它可以作為文檔存儲，K-V存儲，也可以作為圖資料庫。並且可以與專業的解決方案一樣高效。

5、多模型資料庫可以同時提供多種數據模型，而不需要引入過多的運維和研發成本

多模型資料庫引擎可以極大地降低同時使用多種資料庫模型的複雜性。雖然是多數據模型，但是你也可以將多個數據模型中的數據都存儲在一個資料庫存儲引擎中。在單個查詢中混合使用不同的數據模型，可以極大的提升應用程序和設計的性能。即使您選擇將多模型資料庫部署成多個資料庫實例，但是你仍然只需要部署一種技術（只需要學習一種資料庫產品即可）。

6、多數據模型可以解決的問題領域更加廣泛

由於多模型資料庫優點包括：支持豐富的查詢語句、數據建模更加靈活以及各個模型之間相對獨立的持久化特性等，多模型資料庫與各單一領域的傳統資料庫相比可以解決的問題領域更加廣泛。

1、內容管理

文本內容是schema less的，這種數據更適合適用document來存儲。但是在不同的內容數據之間往往存在著各種聯繫，這些聯繫又可以由圖來進行最自然的表現。

2、用戶定義的複雜數據結構

任何處理用戶定義的複雜數據結構的程序都可以從document存儲的靈活性中受益，並且可以通過圖對這些複雜的數據結構和關係進行管理。

3、電子商務系統

電子商務系統，比如京東，需要存儲客戶和產品數據（JSON），購物車數據（鍵/值），訂單和銷售（JSON或圖）數據以及推薦數據（圖），這些不同的數據都需要不同的數據模型進行存儲，但是又需要針對所有這些數據執行大量的join查詢，因此使用多模型資料庫是最合適不過的了。

4、企業組織架構管理

企業組織結構的自然表現就是圖，而基於組織架構的許可權管理又需要圖形和文檔的混合使用。

5、欺詐檢測

在這種場景中，通常需要存儲大量的日誌數據，這些數據涉及到帳戶，IP地址，機器等不同的類型。這可以通過圖進行數據建模。檢測欺詐會使用到圖資料庫中複雜的模式匹配（例如，與單個主機或帳戶建立的異常連接數），但有時也會同時使用二級索引與圖數據進行join查詢，從而獲得所需要的數據。

6、身份與許可權管理

與上述的企業組織結構管理一樣，身份和許可權管理通常涉及到具有層次結構的數據，並且通常層次結構中較高層的人或者實體除了具有其下屬所擁有的所有許可權之外，還存在一些特權。這種數據最好用樹或有向無環圖來描述。在判斷有沒有許可權的時候，通常會涉及到對圖數據的檢索和分析，但是在進行身份認證的時候，只是進行身份數據的核對和查詢，這個過程是不會涉及到圖數據的檢索和處理的。

7、物聯網

IoT（internet of things）物聯網產生大量的狀態數據，地理位置信息，感測器數據等。物聯網中的實物都是分層次的。例如，同一房屋中的所有家庭設備都屬於房屋，而房屋又屬於更高層級的物體。這意味著物聯網中有關設備的數據可以很自然地由圖建模，並且大量的感測器數據具有不同的結構，而且經常需要進行關聯查詢。

8、知識圖譜

知識圖譜是大量數據的集合，知識圖譜系統中的大多數查詢僅使用圖數據模型，但通常也只需要對圖數據中的vertices進行常規過濾查詢。

9、物流系統

在物流系統中，會產生大量的數據：地理位置信息，任務，任務依賴關係，任務所需的資源等。這些數據的結構多種多樣，相互之間的關聯性很強。因此對這些數據的查詢包括：針對依賴關係的圖形查詢和忽略依賴關係的基於標準索引的傳統查詢。

10、基礎設施運維和管理

計算機網路及相關聯的計算機主機一起構成一張圖，因此對這些基礎設施的管理會頻繁的對這張圖進行查詢和操作。包括：基於關聯關係的圖操作，以及對單一vertices的查詢和設置。

11、實時推薦引擎

電子商務系統中實時推薦引擎會為客戶提供合理有效的實時購買建議，這實質上是對圖資料庫中的路徑進行模式匹配查詢，比如系統希望向客戶A推薦已經被另一個與客戶A存在某種聯繫的客戶B已經購買的東西。不僅如此，推薦系統還會使用產品目錄上的二級索引進行查詢，例如將產品類目的銷售排名以及銷售數據考慮進行綜合查詢。

12、社交網路

社交網路是大規模高度關聯的圖數據的主要使用場景，在社交網路中典型查詢就是圖查詢，但是，實際應用程序還需要其他的常規查詢，因此也需要二級索引，並且可能需要根據連接鍵進行join查詢。

13、交通管理系統

街道網路可以非常自然地被建模為圖。交通流量數據產生大量基於時間的數據，這與街道網路密切相關。想要做出有關交通管理的優秀決策，涉及到對所有這些數據的聚合，圖遍歷和join查詢，並使用演算法進行建模和計算。

14、版本管理系統

版本管理系統典型的案例就是github。系統通常使用有向無環圖進行數據存儲，查詢涉及到：圖查詢和其他查詢。

15、工作流管理系統

工作流管理系統通常使用圖來模擬任務之間的依賴關係，管理系統需要同時涉及到圖查詢和常規檢索查詢。

時代在發展、技術在進步。我相信現有的技術終將成為歷史，目前多模型資料庫引擎處於起步階段，我們站在技術革新的十字路口，需要看清方向，不斷嘗試新的技術，才能在未來享受自己的正確技術選擇帶來的紅利。京東商城tig團隊在浪潮之巔，我們認定多模型資料庫將會下一代資料庫技術的新的趨勢，因此我們抓住機會，迎難而上，並自主研發多模型資料庫引擎ChuBaoDB,我們相信多模型資料庫引擎方向的正確性，並付諸實踐實現它。請對ChuBaoDB拭目以待。

https://www.arangodb.com/wp-content/uploads/2017/01/ArangoDB-White-paper-What-is-a-multi-model-database-and-why-use-it.pdf?utm_source=hs_automation&utm_medium=email&utm_content=58567938&_hsenc=p2ANqtz--2Z-7SM1huRhEQLLisJ0qE3K7KrTaH-un8uY0W8PtIQoDQqgu5IhRmxdzzMdef_xTYstJhz6XNIxjS3TW7AfTbcHsa1g&_hsmi=58567938

了解更多相關信息，請持續關注京東商城技術架構（ID:TIGCHAT）