寫在前面
聲明：本文大部分是基于ArangoDB的論文的翻譯解阅，在翻譯過程中加入了自己的一些理解和說明亥啦。
無論是為一個新的項目或者正在開發(fā)的功能模塊又或者某一次系統(tǒng)升級去選擇技術方案的時候寿烟，我們很難做出一個從始至終都非常match的技術方案或者工具乐设，尤其是在為項目選擇合適的數(shù)據(jù)庫時，我們更是難以選擇，是文檔型數(shù)據(jù)庫远搪？K-V數(shù)據(jù)庫？RDMS逢捺？還是圖數(shù)據(jù)庫谁鳍？ 在軟件領域一直存在一種理論：“one size does not always fit all”，但是該理論是否正確劫瞳，業(yè)界的眾多專家一直爭論不休倘潜。該理論建議大型的軟件中不同的模塊應該采用不同的數(shù)據(jù)模型進行數(shù)據(jù)管理。這也就意味著在同一個工程中志于，你不得不采用多個數(shù)據(jù)庫涮因，但這樣做又引入了新的問題：運維和管理的復雜、數(shù)據(jù)一致性和數(shù)據(jù)重復的問題等恨憎。
機遇與問題總是伴生蕊退。這也就是出現(xiàn)原生多模型數(shù)據(jù)庫的原因。本文將會解釋什么是多模型數(shù)據(jù)庫憔恳，為什么要使用多模型數(shù)據(jù)庫以及多模型數(shù)據(jù)庫應該運用在什么地方瓤荔。本文將會基于飛機維護保障團隊管理的實例，說明如何使用多模型數(shù)據(jù)庫钥组。
什么是多模型數(shù)據(jù)庫
隨著多模型數(shù)據(jù)庫與NO-SQL變得越來越流行谍失，很多數(shù)據(jù)庫廠商都標榜自己是“多數(shù)據(jù)模型”次伶。所以僅僅從市面上現(xiàn)存的多模型數(shù)據(jù)庫產(chǎn)品（有些真的是多模型數(shù)據(jù)庫，有些僅僅將自己炒作成多模型數(shù)據(jù)庫）去總結(jié)，很難對多模型數(shù)據(jù)庫有明確的定義枣察，這也導致那些為自己的產(chǎn)品或者項目尋求多模型解決方案的人員對多模型數(shù)據(jù)庫產(chǎn)品的理解不清晰个扰。 對于多模型數(shù)據(jù)庫的理解斑芜，最終要的一點就是：我們一定要認識到疊加的多模型方案（例如基于document或者k-v存儲之上的Graph層壤玫，這其實也算是多模型）與native多模型方案是不同的。
那么什么是原生多模型數(shù)據(jù)庫呢挺份？
簡單來說褒翰，原生多模型數(shù)據(jù)庫就是將多種數(shù)據(jù)存儲組合在一起。在多模型數(shù)據(jù)庫中匀泊，數(shù)據(jù)可以存儲為鍵/值對优训，圖形或文檔，并且可以使用一種聲明式查詢語言進行訪問各聘。也有可能在一次查詢中涉及到的數(shù)據(jù)會跨越多個數(shù)據(jù)模型揣非。通過native多模型數(shù)據(jù)庫，您可以構(gòu)建高性能應用程序并且可以很自然的將規(guī)模和處理問題的領域范圍水平擴展到三種數(shù)據(jù)模型cover到的所有外延領域躲因。與很多數(shù)據(jù)庫廠商采用的“分層的方法”相比早敬，native多數(shù)據(jù)模型提供了更大的靈活性和性能優(yōu)勢忌傻。簡而言之，native多數(shù)據(jù)模型數(shù)據(jù)庫有一個內(nèi)核搞监、一種查詢語言和多種數(shù)據(jù)模型芯勘。
為什么使用多數(shù)據(jù)模型
近年來，“多語言持久性”的概念已經(jīng)變得非常流行腺逛。所謂的“多語言持久性”就是在同一個項目或者產(chǎn)品中，同時采用多種不同的數(shù)據(jù)庫衡怀。然而棍矛，如上所述，一些業(yè)界專家對“在大型軟件項目中抛杨，針對持久層的不同部分采用不同的數(shù)據(jù)模型”的理論的正確性一直存在極大的爭議够委。按照這種理論的說法，人們應該使用RDBMS存儲表結(jié)構(gòu)的數(shù)據(jù)怖现；使用document存儲非結(jié)構(gòu)化的對象數(shù)據(jù)茁帽；使用k/v存儲hash表；使用圖數(shù)據(jù)庫存儲相互之間有復雜引用關系的數(shù)據(jù)屈嗤。凡有收益潘拨，必有代價。這樣所的代價就是：在同一個項目中采用多種數(shù)據(jù)庫饶号，這也就引入了運維的復雜和繁瑣（部署更復雜铁追、升級更頻繁）、數(shù)據(jù)一致性問題和數(shù)據(jù)冗余問題茫船。
這就是多模型數(shù)據(jù)庫需要解決的問題算谈。你可以通過使用多模型數(shù)據(jù)庫（由文檔模型涩禀、K-V模型和圖模型組成的單一數(shù)據(jù)庫引擎）來解決該問題。多模型數(shù)據(jù)庫具有統(tǒng)一的查詢語言和API然眼，查詢語言和API可以涵蓋所有三種數(shù)據(jù)模型艾船，并且允許在單個查詢中混合查詢?nèi)N模型。選擇這三種模型（文檔罪治、K-V和圖）是因為通過長期的不斷嘗試丽声，我們發(fā)現(xiàn)將這三種模型組合在一起形成的架構(gòu)可以在任意單一數(shù)據(jù)模型領域的專門產(chǎn)品（文檔型數(shù)據(jù)、K-V數(shù)據(jù)庫或者圖數(shù)據(jù)庫）在查詢性能和內(nèi)存使用率上一較高低觉义。通過使用三種數(shù)據(jù)模型組合形成的多模型數(shù)據(jù)庫雁社，您可以在不需要使用多種數(shù)據(jù)庫的前提下就可以實現(xiàn)“多語言持久性”。
那么晒骇，native多模型數(shù)據(jù)庫的實現(xiàn)機制是什么霉撵？在document集合中的每份document都會有一個唯一主鍵磺浙，用來唯一標示一份document。 這樣就可以將一份document存儲在K/V存儲中徒坡，當存儲在K/V存儲中的時候撕氧，key是每個document的唯一標示（也就是每個document的唯一主鍵），通常是字符串喇完，value的內(nèi)容是json字符串伦泥，json字符串其實就是document的實際內(nèi)容。實際上以json字符串作為value不但沒有導致性能下降锦溪，還提供了很大的靈活性不脯。圖數(shù)據(jù)模型可以以這樣的方式實現(xiàn)：以json的方式來存儲vertices和edge的數(shù)據(jù)。edge被保存在特定的edge集合中刻诊，每條edge都必須含有from和to屬性防楷，這兩個屬性分別指向該edge的開始和結(jié)束的vertices。
通過上面的的方式實現(xiàn)了三種數(shù)據(jù)模型的統(tǒng)一则涯。即：通過document的唯一主鍵作為key复局，以json形式表示的document的內(nèi)容作為value，存儲在K-V存儲中粟判，因此一個K-V對應一個Document亿昏；以json形式的document來存儲圖中的vertices和edge，從而將圖數(shù)據(jù)存儲在document中档礁。多模型數(shù)據(jù)庫的層次結(jié)構(gòu)看起來像這樣：
我們還需要實現(xiàn)一種通用的查詢語言龙优，用戶可以通過這種語言不僅完成單獨的document、KV和graph的查詢事秀，也可以完成跨任意的2個或者3個模型的數(shù)據(jù)的混合查詢彤断。“圖查詢”是指涉及到對edge的特定連接特性的查詢易迹，例如：最短路徑宰衙、圖遍歷和模式匹配。多模型數(shù)據(jù)庫中的模式匹配會根據(jù)任意查詢條件的復雜組合睹欲，查詢出符合該組合條件的所有路徑供炼。這些查詢條件包括：單個document或者edge上的某些過濾條件以及整個圖上的過濾條件。
native多模型數(shù)據(jù)庫的數(shù)據(jù)模型
實際案例：飛機維保團隊管理
native多模型數(shù)據(jù)庫非常適合于大規(guī)模多層級數(shù)據(jù)的管理窘疮，例如：飛機維保團隊管理袋哼。一個飛機維保團隊由幾架飛機組成，典型的飛機由數(shù)百萬個部件組成闸衫，而每個大的部件又有很多小的部件組成涛贯。我們在腦海中對這些數(shù)據(jù)大致產(chǎn)生了一個層次關系。為了對團隊的數(shù)據(jù)進行管理蔚出，我們必須對不同層次的數(shù)據(jù)采用不同的存儲方式弟翘。
每個零件或組件都有名稱虫腋，序列號，制造商信息稀余，維護間隔悦冀，維護日期，分包商信息睛琳，手冊和文檔的鏈接盒蟆，聯(lián)系人，保修和服務合同信息等师骗。每份數(shù)據(jù)都是其上層數(shù)據(jù)的一部分茁影。我們可以通過回答下面的問題（包括但不限于），來對數(shù)據(jù)進行整理和采集：
● 一個組件總共包含哪些部分丧凤？
● 對于某一（破損）部件，包含該部件并且被維修過的最小組件是什么步脓？
● 哪些組件需要在下一周進行維修愿待？
飛機維保團隊的數(shù)據(jù)模型
如果我們擁有一個多模型數(shù)據(jù)庫，我們?nèi)绾螌@些飛機維保數(shù)據(jù)進行建模靴患？
建模方式有多種仍侥，但是若想支持快速查詢，就應該按照如下方式進行建模：
雖然數(shù)據(jù)分為不同的層級鸳君，但是我們可以對不同層級中的每一項數(shù)據(jù)都使用JSON格式的document進行存儲农渊。由于JSON天生具有靈活性和嵌套性，因此我們可以采用JSON文檔存儲任意數(shù)據(jù)或颊。另外由于文檔存儲是schemaless的砸紊，因此即使存儲的數(shù)據(jù)的屬性和結(jié)構(gòu)完全不一樣，也沒有問題囱挑，例如你可以使用JSON文檔同時存儲發(fā)動機數(shù)據(jù)醉顽、螺絲釘數(shù)據(jù)和飛機數(shù)據(jù)。
除此之外平挑，我們使用圖模型來存儲不同數(shù)據(jù)之間的層次和關聯(lián)關系游添。具體如下：整個飛機維保團隊是一個vertices，每個飛機也是一個vertices通熄，飛機的每個大型組件唆涝，如：發(fā)動機也是一個vertices。團隊vertices與每個飛機vertices之間都有一條edge相連唇辨，每個飛機vertices都與飛機的發(fā)動機vertices之間也有一條edge廊酣，表示發(fā)送機是飛機的一部分。每個發(fā)動機vertices又會和發(fā)動機的子組件對應的vertices之間存在edge赏枚。以此類推啰扛，直到每個小組件都與它包含的每個單獨部分都有edge相連嚎京。如下圖所示：
我們可以將所有數(shù)據(jù)放在一個（vertices）集合中，也可以將它們分成不同的集合 - 例如分別對飛機隐解，部件和各個部件進行分類鞍帝，每類數(shù)據(jù)一個集合。其實數(shù)據(jù)存儲在一個集合還是多個集合中煞茫，對于圖來說無關緊要帕涌，但是對數(shù)據(jù)按照分類組合成多個不同的集合，更利于定義和構(gòu)建二級索引续徽，而二級索引可以使我們的某些特定條件的查詢性能更高蚓曼。
飛機維護記錄查詢
我們將使用ArangoDB查詢語言（AQL）來完成某些特定的查詢。現(xiàn)在我們來看下我們可以使用AQL來完成哪些查詢钦扭。
● 給定一個組件纫版，查看該組件的所有組成部分是什么
要回答該問題，需要從圖中的特定vertices（某個給定的組件）開始客情，首先找到指定的組件其弊，并找到與該“組件”vertices通過edge相連的所有的下層的vertices - 所有vertices都可以通過edge，按照edge的方向遍歷到膀斋，這是典型的圖遍歷梭伐。
以下是此查詢的示例代碼，該查詢通過圖遍歷仰担，從查找“components / Engine765”頂點開始糊识，返回可以在4步以內(nèi)訪問到的所有下層vertices：
FOR? ?part? ?IN? ?1..4? OUTBOUND ?"components/Engine765"? GRAPH ?"FleetGraph" ?RETURN? ?part
在ArangoDB中，你可以通過給graph指定一個名稱摔蓝，并且指定哪些document集合包含vertices赂苗，哪些document集合包含edge，來定義一個graph贮尉。無論document代表的是vertices還是edge哑梳，都是通過它的_id屬性唯一標識，_id是一個字符串绘盟，由集合名稱鸠真，“/”和主鍵組成。
上面所示的遍歷只需要圖形名稱“FleetGraph”龄毡，起始vertices吠卷，以及邊的方向：OUTBOUND，這三個條件就可以得到所需要查詢的數(shù)據(jù)沦零，AQL可以支持這種類型的圖查詢祭隔。當然，您可以指定更多的選項， 這里我們不做深入討論疾渴。
●對于某個指定的（孤立的）部件千贯，找到包含該部件并且有維護程序的飛機的最小部件
這種查詢涉及從葉子vertices在樹中反向向上搜索，直到找到有維護記錄的組件vertices搞坝。所有數(shù)據(jù)都可以從相應的JSON文檔中讀取搔谴。由于要經(jīng)過多少步才能找到符合條件的組件，我們先前是不知道的桩撮，因此這是一個典型的圖遍歷敦第。這種查詢相對來說是非常簡單的，因為總會有一個唯一的edge從上層的vertices指向下層的vertices店量。具體的查詢過程如下所示：
下面的AQL語句就可以完成該查詢：從頂點“parts/Screw56744” ：a開始芜果，順著edge的“inbound”方向的進行查找，直到找到維護屬性為true的vertices：component融师，然后返回找到的頂點：component：
FOR? ?component? ?IN? ?0..4? INBOUND ?"parts/Screw56744"? GRAPH ?"FleetGraph" ?FILTER? ?component.isMaintainable? ?==? ?true
LIMIT ?1
?RETURN? ?component
從上面的查詢語句中右钾，我們指定了graph的名稱、起始頂點的_id和目標頂點的過濾規(guī)則旱爆。由于我們只對第一個頂點感興趣舀射，因此我們添加了limit 1。我們看到AQL可以直接支持這種查詢疼鸟。
● 飛機的哪些組件在下周需要保養(yǎng)或者維修？
這是一個完全不涉及圖的查詢：而結(jié)果往往與圖是正交的庙曙。具有正確的二級索引的文檔數(shù)據(jù)模型非常適合此查詢空镜。
使用純粹的圖數(shù)據(jù)庫執(zhí)行這種查詢，會比較麻煩捌朴，因為我們的查詢無法明確的對圖結(jié)構(gòu)進行過濾吴攒，所以我們不得不求助于二級索引。例如砂蔽，下次維護日期會存儲在組件的某個屬性上洼怔。為了得到我們想要的答案，我們應該使用document查詢左驾，這種查詢不會考慮到圖的結(jié)構(gòu)和聯(lián)系镣隶。下面的查詢語句用于完成這個查詢：
FOR? c ?IN? ?components
FILTER ?c.nextMaintenance? ?<=? ?"2016-12-15" ?RETURN? ?{id: c._id,
nextMaintenance: c.nextMaintenance}
上面查詢語句中看起來像循環(huán)的部分是AQL語言用于進行集合迭代的方式。查詢優(yōu)化器能夠識別nextMaintenance屬性上的二級索引的存在诡右，這樣執(zhí)行引擎不必執(zhí)行完整的集合掃描來進行filter條件的過濾安岂。可以看到帆吻，AQL在RETURN語句中以JSON文檔的形式域那，返回查詢到的數(shù)據(jù)的相關屬性內(nèi)容。
使用多模型查詢
為了說明多模型數(shù)據(jù)庫的強大潛力猜煮，最后將會演示一個覆蓋三種數(shù)據(jù)模型數(shù)據(jù)的AQL查詢次员。以下查詢首先查找維護到期的組件败许，為每個到期的組件計算最短路徑，然后與contacts集合執(zhí)行JOIN操作淑蔚，進而向結(jié)果中添加具體的聯(lián)系信息：
FOR? p ?IN? ?parts
FILTER ?p.nextMaintenance ?<=? ?"2016-12-15"
?FOR? c ?IN? ?0..4? INBOUND p GRAPH ?"FleetGraph"
FILTER ?c.isMaintainable ?==? ?true LIMIT ?1
?FOR? ?person? ?IN? ?contacts
?FILTER? ?person._key? ?==? ?c.?contact
?RETURN? ?{part: p._id, component: c, contact: person}
在查詢語句的最后市殷，我們使用到了AQL的join功能。第二個FOR語句會遍歷聯(lián)系人集合束倍。查詢優(yōu)化器會自動通過執(zhí)行JOIN操作來優(yōu)化FILTER語句被丧，這種優(yōu)化措施使得查詢非常高效，因為它可以利用聯(lián)系人集合的主索引進行快速哈希查找绪妹。
這是一個涉及多個數(shù)據(jù)模型查詢的典型示例甥桂。本次查詢會涉及到三種數(shù)據(jù)模型：具有二級索引的文檔，圖查詢以及由快速鍵/值查找提供支持的JOIN邮旷。想象一下黄选，如果三個數(shù)據(jù)模型沒有在同一個數(shù)據(jù)庫引擎中，或者如果無法在同一個查詢中混用這三種數(shù)模型婶肩，我們就必須采用三種數(shù)據(jù)庫引擎办陷，并且需要通過應用程序?qū)牟煌瑪?shù)據(jù)引擎中查詢出來的數(shù)據(jù)進行加工、聚合和處理律歼。
更重要的是民镜，本示例表明，多模型數(shù)據(jù)庫確實可以極大地提升應用程序的查詢的性能险毁。在沒有圖數(shù)據(jù)庫的情況下制圈，要根據(jù)路徑長度進行圖查詢（查詢的路徑及步驟并不是預知的），只能轉(zhuǎn)變?yōu)榉爆嵉呐峡觥⒌托У膉oin查詢鲸鹦。但是，純圖數(shù)據(jù)庫又不能通過二級索引來提高查詢的性能跷跪。我們可以將鍵/值查找與圖查找進行Join馋嗜，來提供多模型數(shù)據(jù)庫的靈活性。例如吵瞻，在上述情況下葛菇，我們不必將整個聯(lián)系信息嵌入到每個路徑中，只在最后一個查詢中執(zhí)行JOIN操作即可橡羞。
數(shù)據(jù)建模經(jīng)驗
● JSON對于非結(jié)構(gòu)化和結(jié)構(gòu)化數(shù)據(jù)都非常通用 JSON的遞歸特性允許嵌入子文檔和可變長度列表熟呛。您甚至可以將表的行存儲為JSON文檔。現(xiàn)代數(shù)據(jù)存儲非常擅長壓縮數(shù)據(jù)尉姨，與關系數(shù)據(jù)庫相比庵朝，沒有內(nèi)存開銷。對于結(jié)構(gòu)化數(shù)據(jù)，可以使用可擴展的HTTP API根據(jù)需要實現(xiàn)schema驗證九府。
● 圖適用于關系建模 在很多實例中椎瘟，圖可以最自然的反應實際的數(shù)據(jù)模型，而不需要進行反模式處理侄旬。圖不僅可以存儲關系數(shù)據(jù)肺蔚，還可以存儲vertices和edge的標簽信息。JSON天生就非常適合存儲這些vertices和關系數(shù)據(jù)儡羔。
●圖數(shù)據(jù)庫特別適用于圖查詢
通過圖數(shù)據(jù)庫可以非常容易的實現(xiàn)“最短路徑”和“圖形遍歷”宣羊。而這些的基本功能中涉及到的對某個vertices的outgoing和incoming的邊的反復頻繁遍歷，均由圖數(shù)據(jù)庫為你實現(xiàn)汰蜘，你使用的只是這些基本功能的接口仇冯，而不需要關注底層實現(xiàn)細節(jié)。
●多模型數(shù)據(jù)庫可以與專業(yè)解決方案相媲美 我們可以將多種數(shù)據(jù)模型組合在一個數(shù)據(jù)庫引擎中族操。這種組合不是妥協(xié)苛坚，它可以作為文檔存儲，K-V存儲色难，也可以作為圖數(shù)據(jù)庫泼舱。并且可以與專業(yè)的解決方案一樣高效。
●多模型數(shù)據(jù)庫可以同時提供多種數(shù)據(jù)模型枷莉，而不需要引入過多的運維和研發(fā)成本 多模型數(shù)據(jù)庫引擎可以極大地降低同時使用多種數(shù)據(jù)庫模型的復雜性娇昙。雖然是多數(shù)據(jù)模型，但是你也可以將多個數(shù)據(jù)模型中的數(shù)據(jù)都存儲在一個數(shù)據(jù)庫存儲引擎中笤妙。在單個查詢中混合使用不同的數(shù)據(jù)模型冒掌，可以極大的提升應用程序和設計的性能。即使您選擇將多模型數(shù)據(jù)庫部署成多個數(shù)據(jù)庫實例危喉，但是你仍然只需要部署一種技術（只需要學習一種數(shù)據(jù)庫產(chǎn)品即可）宋渔。
●多數(shù)據(jù)模型可以解決的問題領域更加廣泛 由于多模型數(shù)據(jù)庫優(yōu)點包括：支持豐富的查詢語句州疾、數(shù)據(jù)建模更加靈活以及各個模型之間相對獨立的持久化特性等辜限，多模型數(shù)據(jù)庫與各單一領域的傳統(tǒng)數(shù)據(jù)庫相比可以解決的問題領域更加廣泛。
多模型數(shù)據(jù)庫的適用場景
內(nèi)容管理
文本內(nèi)容是schema less的严蓖，這種數(shù)據(jù)更適合適用document來存儲薄嫡。但是在不同的內(nèi)容數(shù)據(jù)之間往往存在著各種聯(lián)系，這些聯(lián)系又可以由圖來進行最自然的表現(xiàn)颗胡。
用戶定義的復雜數(shù)據(jù)結(jié)構(gòu)
任何處理用戶定義的復雜數(shù)據(jù)結(jié)構(gòu)的程序都可以從document存儲的靈活性中受益毫深，并且可以通過圖對這些復雜的數(shù)據(jù)結(jié)構(gòu)和關系進行管理。
電子商務系統(tǒng)
電子商務系統(tǒng)毒姨，比如京東哑蔫，需要存儲客戶和產(chǎn)品數(shù)據(jù)（JSON），購物車數(shù)據(jù)（鍵/值），訂單和銷售（JSON或圖）數(shù)據(jù)以及推薦數(shù)據(jù)（圖）闸迷，這些不同的數(shù)據(jù)都需要不同的數(shù)據(jù)模型進行存儲嵌纲，但是又需要針對所有這些數(shù)據(jù)執(zhí)行大量的join查詢，因此使用多模型數(shù)據(jù)庫是最合適不過的了腥沽。
企業(yè)組織架構(gòu)管理
企業(yè)組織結(jié)構(gòu)的自然表現(xiàn)就是圖逮走，而基于組織架構(gòu)的權(quán)限管理又需要圖形和文檔的混合使用。
欺詐檢測
在這種場景中今阳，通常需要存儲大量的日志數(shù)據(jù)师溅，這些數(shù)據(jù)涉及到帳戶，IP地址盾舌，機器等不同的類型墓臭。這可以通過圖進行數(shù)據(jù)建模。檢測欺詐會使用到圖數(shù)據(jù)庫中復雜的模式匹配（例如矿筝，與單個主機或帳戶建立的異常連接數(shù)）起便，但有時也會同時使用二級索引與圖數(shù)據(jù)進行join查詢，從而獲得所需要的數(shù)據(jù)窖维。
身份與權(quán)限管理
與上述的企業(yè)組織結(jié)構(gòu)管理一樣榆综，身份和權(quán)限管理通常涉及到具有層次結(jié)構(gòu)的數(shù)據(jù)，并且通常層次結(jié)構(gòu)中較高層的人或者實體除了具有其下屬所擁有的所有權(quán)限之外铸史，還存在一些特權(quán)鼻疮。這種數(shù)據(jù)最好用樹或有向無環(huán)圖來描述。在判斷有沒有權(quán)限的時候琳轿，通常會涉及到對圖數(shù)據(jù)的檢索和分析判沟，但是在進行身份認證的時候，只是進行身份數(shù)據(jù)的核對和查詢崭篡，這個過程是不會涉及到圖數(shù)據(jù)的檢索和處理的挪哄。
物聯(lián)網(wǎng)
IoT（internet of things）物聯(lián)網(wǎng)產(chǎn)生大量的狀態(tài)數(shù)據(jù)，地理位置信息琉闪，傳感器數(shù)據(jù)等迹炼。物聯(lián)網(wǎng)中的實物都是分層次的。例如颠毙，同一房屋中的所有家庭設備都屬于房屋斯入，而房屋又屬于更高層級的物體。這意味著物聯(lián)網(wǎng)中有關設備的數(shù)據(jù)可以很自然地由圖建模蛀蜜，并且大量的傳感器數(shù)據(jù)具有不同的結(jié)構(gòu)刻两，而且經(jīng)常需要進行關聯(lián)查詢。
知識圖譜
知識圖譜是大量數(shù)據(jù)的集合滴某，知識圖譜系統(tǒng)中的大多數(shù)查詢僅使用圖數(shù)據(jù)模型磅摹，但通常也只需要對圖數(shù)據(jù)中的vertices進行常規(guī)過濾查詢滋迈。
物流系統(tǒng)
在物流系統(tǒng)中，會產(chǎn)生大量的數(shù)據(jù)：地理位置信息户誓，任務杀怠，任務依賴關系，任務所需的資源等厅克。這些數(shù)據(jù)的結(jié)構(gòu)多種多樣赔退，相互之間的關聯(lián)性很強。因此對這些數(shù)據(jù)的查詢包括：針對依賴關系的圖形查詢和忽略依賴關系的基于標準索引的傳統(tǒng)查詢证舟。
基礎設施運維和管理
計算機網(wǎng)絡及相關聯(lián)的計算機主機一起構(gòu)成一張圖硕旗，因此對這些基礎設施的管理會頻繁的對這張圖進行查詢和操作。包括：基于關聯(lián)關系的圖操作女责，以及對單一vertices的查詢和設置漆枚。
實時推薦引擎
電子商務系統(tǒng)中實時推薦引擎會為客戶提供合理有效的實時購買建議，這實質(zhì)上是對圖數(shù)據(jù)庫中的路徑進行模式匹配查詢抵知，比如系統(tǒng)希望向客戶A推薦已經(jīng)被另一個與客戶A存在某種聯(lián)系的客戶B已經(jīng)購買的東西墙基。不僅如此，推薦系統(tǒng)還會使用產(chǎn)品目錄上的二級索引進行查詢刷喜，例如將產(chǎn)品類目的銷售排名以及銷售數(shù)據(jù)考慮進行綜合查詢残制。
社交網(wǎng)絡
社交網(wǎng)絡是大規(guī)模高度關聯(lián)的圖數(shù)據(jù)的主要使用場景，在社交網(wǎng)絡中典型查詢就是圖查詢掖疮，但是初茶，實際應用程序還需要其他的常規(guī)查詢，因此也需要二級索引浊闪，并且可能需要根據(jù)連接鍵進行join查詢恼布。
交通管理系統(tǒng)
街道網(wǎng)絡可以非常自然地被建模為圖。交通流量數(shù)據(jù)產(chǎn)生大量基于時間的數(shù)據(jù)搁宾，這與街道網(wǎng)絡密切相關折汞。想要做出有關交通管理的優(yōu)秀決策，涉及到對所有這些數(shù)據(jù)的聚合盖腿，圖遍歷和join查詢爽待，并使用算法進行建模和計算。
版本管理系統(tǒng)
版本管理系統(tǒng)典型的案例就是github奸忽。系統(tǒng)通常使用有向無環(huán)圖進行數(shù)據(jù)存儲堕伪，查詢涉及到：圖查詢和其他查詢揖庄。
工作流管理系統(tǒng)
工作流管理系統(tǒng)通常使用圖來模擬任務之間的依賴關系栗菜，管理系統(tǒng)需要同時涉及到圖查詢和常規(guī)檢索查詢。
結(jié)語
時代在發(fā)展蹄梢、技術在進步疙筹。我相信現(xiàn)有的技術終將成為歷史富俄，目前多模型數(shù)據(jù)庫引擎處于起步階段，我們站在技術革新的十字路口而咆，需要看清方向霍比，不斷嘗試新的技術，才能在未來享受自己的正確技術選擇帶來的紅利暴备。京東商城tig團隊在浪潮之巔悠瞬，我們認定多模型數(shù)據(jù)庫將會下一代數(shù)據(jù)庫技術的新的趨勢，因此我們抓住機會涯捻，迎難而上浅妆，并自主研發(fā)多模型數(shù)據(jù)庫引擎ChuBaoDB,我們相信多模型數(shù)據(jù)庫引擎方向的正確性，并付諸實踐實現(xiàn)它障癌。請對ChuBaoDB拭目以待凌外。
參考
呂信原創(chuàng)，轉(zhuǎn)載請注明出處涛浙，尊重知識康辑，尊重別人的勞動
