導讀： 本次講座從圖數據庫中的核心查詢算子——子圖匹配入題，介紹了圖數據庫的基本概念、子圖匹配的算法，以及在圖數據庫環境下的子圖匹配查詢優化等內容。具體包括下面三個方面：
-
什麼是圖數據庫
-
子圖匹配查詢及其優化方法
-
我們的工作
--
01 什麼是圖數據庫
1. 數據庫
數據庫研究的核心就是將物理世界映射到信息世界，在數據庫學習課程中會學到一個概念模型E-R圖。E-R圖表示實體與實體之間的關係，也會將實體的屬性包含在內。
2. 回顧-關係型數據庫（RDBMS）
我們再回顧一下關係型數據庫是怎麼實現E-R關係映射的。E-R圖是一個概念模型，是在對信息世界、物理世界建模的時候需要一個概念模型（Conceptual Model）。那麼，如何將一個概念模型進行一個物理實現呢？如果底層用的是關係數據庫，需要將E-R圖結構映射到一個二維的關係表中，如“學生選修課程”的E-R圖，映射到學生表、課程表和選修表這樣的二維關係表中，這是關係數據庫設計的基本思路。
3. 圖數據庫-Game Changer
如果採用圖數據庫作爲底層的物理實習，就是把E-R圖表示的概念模型映射成圖數據庫中的節點和邊，因爲E-R圖和圖數據庫均採用“圖”的形式進行表達，因此這樣的映射更加直接。那麼，E-R圖與圖數據庫的模型有什麼區別呢？
首先，兩類模型定位不一樣。E-R圖是概念模型，更像類（class）圖，定義的是類之間的邏輯關係，不是數據的實例（Instance）之間的關聯；而圖數據庫的模型是物理實現的數據模型，圖數據庫中的每個點和邊表示實例（也稱爲實體）的屬性與實例之間的關聯。
其次，兩類模型作用不同。作爲概念模型，E-R圖用於幫助用戶和數據庫開發者對於應用需求和所涉及到的數據的含義進行正確理解的工具；而圖數據庫中的圖模型是數據庫系統的物理實現模型。
關係數據庫需要完成從E-R圖到關係表結構，以及關係表之間主外鍵的映射，圖數據庫則需要把E-R圖（Conceptual Model）映射成用點和邊表示實體與實體之間關係的數據模型。
4. 關係數據庫 VS 圖數據庫
關係數據庫與圖數據庫兩者之間有什麼區別呢？
首先，我想強調的是兩者不是替代關係，至少就目前的技術和研究的發展狀態而言；但是兩者確實有很多區別，因此造成了在使用場景和內核系統設計中的巨大區別。
這裏認爲最核心的區別是，關係數據庫是Schema-First（模式優先），圖數據庫是Schema-Less（少模式）。使用關係數據庫第一步是先建表結構以及定義表之間主外鍵關係，這個表結構和表之間主外鍵關係稱爲Schema。關係數據庫特點是Schema-First，意思是先有表結構纔有數據；圖數據庫有時候稱爲Schema-Less，甚至有人認爲是Non-Schema，是Schema-Less的數據，意思是導入的數據並不是完全與預先設計的Schema完全符合。
例如，假設描述人物信息時，有些人有10個屬性，另外一些人只有5個屬性，如果在關係數據庫中只能取兩者屬性的合集才能定義表結構；在圖數據庫當中每個人按需（on-demand）分配屬性值就可以，以及邊表示的關係也可以是不一樣。
關係數據庫是Schema-First，也就是首先要有表結構，才能灌入數據；而圖數據庫跟NoSQL有點兒相似，只要有數據來，哪怕數據並不符合前置定義的Schema，數據仍然可以灌入。
兩者的區別帶來了在實現和使用上的兩個大的區別：
在實現方面，即DBMS（數據庫管理系統）內核實現層面。傳統關係數據庫RDBMS的很多查詢優化策略（即查詢引擎的執行策略）、數據劃分和分佈式的處理，以及事務的併發處理都是定義在表結構上的，因此關係數據庫的很多技術是依賴於Schema的；而在圖數據庫中，因爲沒有像關係數據庫一樣的Schema，相關的技術都需要重新考慮。這是從實現角度帶來的數據庫系統DBMS本身帶來的技術挑戰。
在使用方面，即用戶如何使用DBMS系統層面。對於使用者來說，使用關係數據庫到使用圖數據庫最重要的是概念和思維方式的轉變，關係數據庫是用表結構理解數據，圖數據庫則是以圖的思路來理解數據和數據質量管理。另外，兩者查詢語句也不一樣，和現有工具鏈也存在銜接的問題。因爲兩者定位不同，所以不能說圖數據庫和關係數據庫是一個替代關係，但從工具鏈角度、生態來說圖數據庫是一個新的變化。
5. 圖數據庫
隨着研究與實踐應用的進行，我們越來越發現，雖然IT技術發展有內在的推動因素，但是經濟和社會發展也是“無形的手”。這裏我們不去詳細討論從數據管理系統（DBMS）早期從層次、網狀數據庫到關係數據庫轉變的過程。其實這個早期過程的核心解決的是如何將數據庫系統的應用程序開發人員與數據庫系統的內核開發人員進行有效隔離，以提高生產效率的問題，這是一個軟件系統演化的過程：完成了從最原始的文件系統管理數據，到構建起一個獨立的數據庫系統軟件來管理數據。
這裏，我們重點觀察一下從關係數據庫到近些年NoSQL再到Graph Database。這一步一步轉變，並不是說完全替代，只是隨着經濟和社會發展出現了NoSQL、出現了Graph Database。這裏我們也不從軟件系統演化的技術邏輯去做分析，而是從市場主體的企業的數據觀角度去試圖理解這點變化。前面已經提到關係數據庫是Schema-First，其特點是需要有一個表結構，表結構來自E-R圖，E-R圖從需求來，需求來自企業本身對這個任務有一個很清晰的業務邏輯，它適合傳統經濟場景，解決的是傳統企業的信息化問題。傳統企業只有把問題信息化纔有業務邏輯，纔有需求，才能明確地畫出E-R圖。有了E-R圖後纔可以映射成表和表結構，通常情況下這個表結構不會做太大變化，因爲關係數據庫表結構或Schema做變化是一個非常耗時的任務。
在互聯網經濟時代，數據不僅僅是企業內部業務系統產生的，有很多數據的產生也不滿足提前預設的Schema，這類數據通常稱爲Users Generate Content（UGC）。這樣的數據存儲需求催生了 Key-Value爲代表的NoSQL數據庫系統，以解決在線經濟中互聯網情景下用戶產生的數據不規則、不滿足預設Schema的數據存儲問題。
前面提到的NoSQL關注的是用戶及相關數據，傳統關係數據庫關注的是企業的內部業務數據；而圖數據庫關注的是外部數據。在大數據、數據經濟時代講究的是數據之間融合和關聯。因爲一個企業在做業務執行、決策判定的時候，需要大量的外部數據。在企業經營時，需要跟其他單位做一些數據的交換，獲取一些外部數據，而外部數據獲得與企業本身掌握的數據之間要完成數據的關聯，而這種數據關聯以“圖”的形式表示是最爲合適的；圖的點和邊之間的關聯，是能夠表達數據之間深層次的語義相關性的，因此認爲圖數據庫是數字經濟和大數據時代的一種重要的數據模型。
從上面的分析可以看出，技術的發展通常是有着經濟和社會發展作爲背後的推動和選擇因素。
目前看，圖數據庫通常有兩大類，一種是屬性圖，另一種是RDF圖。
其中，屬性圖在節點和邊上有屬性表，從某種角度上講，它仍帶有關係數據庫的基本特性，類似表結構的形式，實際是採用Key-Value形式來存儲的。針對屬性圖的節點和邊上的屬性表的定義，各個廠商的差別也比較大。例如有些模型中不允許同一個節點分屬不同的類別。因各個廠商有自己的查詢語言，其中查詢語言使用比較多，用戶規模比較大、有一定影響力的查詢語言包括Cypher、Apache開源項目的Gremlin等。
RDF圖全稱是Resource-Description-Framework，是從語義網演變來的，借用了很多語義網的協議標準，具體就是語義網框架下的數據語言與查詢語言的標準，包括RDF三元組和SPARQL。RDF三元組表示其圖結構是用主謂賓的形式來表達的，查詢語言是SPARQL，當然早期語言還有RQL、RDQL等。這類圖數據庫系統最大的好處是協議統一，從數據模型到查詢語言的模型都有一套嚴格的規範標註。代表性的系統包括我們北京大學數據管理實驗室（PKUMOD）的gStore系統、Apache開源項目Jena等。
這兩個模型孰優孰劣，現在還不是很好討論，因爲兩個模型各有各的優劣。例如，語義網特點是比較容易支持後期的推理，而且其標準化做得比較好。而目前圖數據庫也正在做標準化的事情。評判兩個模型的優劣也不應該僅從技術角度做評判，因此認爲還不是評判的時候。下面我們簡單介紹一下相關模型。
6. RDF圖數據模型
RDF圖的特點是主、謂、賓表示方式，無論是表示實體、屬性還是實體與實體的關係，都用主謂賓的表示。
那爲什麼是圖的形式呢？因爲主語和賓語就是兩個點，它們之間的關係就是一條邊，因此是RDF Graph；不是把RDF數據看成Graph圖，而是它本身就是Graph圖，只是它不僅可以表示成三列表的形式，也可以表示成Graph圖的形式。
7. SPARQL查詢語言
查詢語言SPARQL與SQL很像，也是一種描述性語言，具體如何執行依賴數據庫引擎。
此爲SPARQL查詢語言的語法示例。
除基本的圖模式外，還有複雜的圖模式，如帶有OPTIONAL、UNION等的語句，見以上示例，這裏不再贅述。
8. 屬性圖模型
屬性圖如之前所講，其點和邊都是有屬性表的，如Person，Person的名字name、Person的birthDate；如邊r7上目前只畫了標籤influencedBy，但實際也可以是屬性表的。這是屬性圖的一個非常好的優勢。
9. Cypher查詢語言
屬性圖的查詢語言Cypher，如示例簡單解釋一下Cypher查詢語言的含義，找到屬性圖中任務的出生地點以及受多少人影響，這個查詢語言是：
MATCH（r:Person），首先是找一個人，類型是Person，將所有的Person複製到一張中間表中，中間表的名字爲r；
OPTIONAL MATCH（r）-[:birthPlace]->（pl:Person），r表中的每個記錄是否有birthPlace，左連接方式，如果有birthPlace，則找出；
MATCH（r）-[:influencedBy]->（p:Person），再看這些人受哪些人影響，因爲帶，則把直接影響或多跳即間接影響的人都找到。
Cypher查詢語言的執行見上圖，這裏不再贅述。
--
02 子圖匹配查詢及其優化方法
前面講了數據模型、數據模型的查詢語言，那與本期主題“子圖匹配”有什麼關係呢？
1. 子圖匹配
子圖匹配核心概念是給到一個查詢圖Q和一個數據圖G，Q裏的每一個點通過一個單射函數映射到G當中去，即單射函數f:V（Q）→V（G）。Q中的每一個點在單射函數Function（f）作用下唯一映射到G的每個點上去，如上圖中Q的1、2、3在G的中的第一個子圖匹配是（1、2、3），第二個子圖匹配是（2、3、4）。子圖匹配的本質就是給一個Q，找到Q在G中的所有匹配，如示例中找到所有的二叉結構。
2. 問題的複雜性
從計算複雜性來講，子圖匹配是一個非常複雜的問題。如果對查詢圖Q不加限制，子圖匹配的判定是NP-Complete的；列舉所有的子圖匹配出現的位置是NP-Hard。雖然匹配算法本身是指數的，但在實踐中，可以採用大量的過濾策略來檢索搜索空間，從而提高查詢的性能。
3. 子圖匹配與圖數據庫
子圖匹配與圖數據庫有什麼關係？
上面的SPARQL查詢的WHERE子句部分，可以表達爲一個查詢圖，如這頁中的左下圖。其中帶有“？”的“？p”表示變量的含義。我們在這個例子中可以找到圖G中的子圖匹配，如紅色表示的部分。執行上述SPARQL語句，本質上就是Q到G的子圖匹配問題。其中，Q可能會更復雜，它不僅僅是Basic Graph Pattern（基礎圖模式），這個後面有機會再闡述。
對於Cypher查詢語言也是一個子圖匹配。如上圖中OPTIONAL MATCH和MATCH語句，其可以表現爲上圖中左下角的Q，在匹配右側G時，“birthPlace”是匹配到節點的屬性值上去了，僅此而已，其實也是一個子圖匹配的過程。
那子圖匹配如何解呢？子圖匹配問題用關係數據庫也可以解。如上圖G存在邊表裏，表示邊的起點和終點。回答Q在G中的子圖匹配查詢，則分別先找到匹配查詢圖Q中的AB邊的是T1表、匹配AC邊的是T2表和匹配BC邊的是T3表，然後T1、T2、T3做自然連接（Join）操作，如果結構非空，就找到Q的子圖匹配了。所以，如果用關係代數來解決子圖匹配的問題，則等同於關係數據庫的Conjunctive Query。
4. 子圖匹配的算法
在一篇SIGMOD 2020實驗論文中指出，做子圖匹配可以有兩類算法，一類爲基於深度搜索加回溯的方式（Backtracking Search），一類爲基於廣度優先的Multi-way Join方法。
5. 子圖匹配的搜索空間
這裏對子圖匹配的兩類算法形象化解釋一下。假設有個Q和一個G，找到Q在G的子圖匹配，實際就是在搜索空間查找。這裏把搜索空間定義成一個搜索樹（如上圖左下角的屬性圖），Backtracking Search搜索的策略是深度優先（DFS搜索），再回溯回來；Multi-way Join搜索的策略則是寬度優先（BFS搜索），即在搜索樹上一層一層去找。
6. 帶有回溯的搜索算法（Backtracking Search）
帶有回溯的搜索算法（Backtracking Search），有1976年最早開始的Ullmann算法，2000年的Ullmann Algorithm算法，2004年的VF2 Algorithm算法等，這裏就不再具體介紹算法本身了，有興趣的同學們可以參考給出的參考文獻。
這裏採用通用的算法框架（Common Framework）來講講帶有回溯的搜索算法。給一個查詢圖Q，首先定義一個節點被匹配的順序，即最先匹配哪個點，然後是哪個點（generate a matching order），然後每次試圖按節點匹配順序進行一個點一個點的匹配；如果當前狀態匹配不了，則回溯；如果要找全部的解集，也得做回溯。其優點是可避免產生大量的中間結果，因採用深度優先，僅有遞歸調用棧的空間，沒有什麼中間結果。其缺點是難以並行執行，會有大量的遞歸開銷，因此適合做LIMIT K和TOP-K的子圖匹配查詢，即只返回K個或TOP K個結果（K很小的情況下）。
7. 基於多路連接的算法 （Multiway Join）
對於寬度優先的算法，實際關係數據庫每次的Join就是寬度優先。子圖匹配從邏輯來說是T1、T2、T3的Join操作。Join怎麼執行呢？從Join執行角度來說，有兩種不同的執行方案，一種是Binary Join，即第一張表T1和第二張表T2作Join，結果再與第三張表T3作一次Join，是以邊爲中心。
還有一種是Worst Case Optimal Join（具體可以查看給出的參考文獻）。例如，假設已經匹配了BC這條邊，即G中的v2和v3匹配了Q中的u2和u3，那麼要找查詢圖Q的ABC的匹配，則查找G中是否有一個三角形恰好能夠匹配Q的ABC，並且三角形包含v2和v3。例如考慮中間結果表的第一行，把v2和v3的鄰居N（v2）和N（v3）找出來，然後兩個集合做一個交集set intersection，再和A點的候選集合C（u1）做個交集，N（v2）、N（v3）、C（u1）三個集合的交集不爲空，在這個例子中交集爲{ v1, v4}；將其分別串聯到v2和v3後面，得到v1、v2、v3和v4、v2、v3這兩個匹配。在上面的例子中，可以對每一行都執行該操作，因此該算法很容易做並行。
請注意上面給出的WOJ算法中，有一個很重要的操作，就是集合求交。
之所以稱之爲Worst Case Optimal Join，是針對Binary Join而言，其複雜性是和它在worst case情況下的輸出結果數量相匹配的。以ABC三角形查詢圖爲例，其最多有N1.5個三角形，N是邊的數目。如果用Binary Join，有可能會產生N2的中間結果。如果採用Worst Case Optimal Join算法，則永遠不可能產生超過N1.5的中間結果，其運行時間的複雜性也是N1.5。對於其他的查詢圖，Worst Case Optimal Join也表現出該種特點。
8. Binary Join + Worst Case Optimal Join
但並不意味着Worst Case Optimal Join算法一定比Binary Join算法好。Worst Case Optimal Join算法只是保證在最差情況下比Binary Join算法好。
滑鐵盧大學做的圖數據庫系統GraphFlow，就提出把Worst Case Optimal Join和Binary Join相結合，在子圖匹配的執行選擇中既考慮Binary Join，又考慮Worst Case Optimal Join。
啓發式地講，Worst Case Optimal Join和Binary Join各有好處。Binary Join比較適合沒有環或者是樹形或者環比較稀少的查詢圖。Worst Case Optimal Join比較適合密集環形的查詢圖。因此，比較好的Join方法是依賴於查詢圖的圖結構。
--
03 我們的工作
1. RDF圖數據庫
RDF圖數據庫，查詢語言是SPARQL。
SPARQL語句也可以用關係數據庫來解。可以將SPARQL轉化爲SQL語句。
然後用SQL語句去執行，或者可以把一張大表的表結構劃分成不同的表，仍然採用轉化成SQL語句，類似關係數據庫一樣去查詢，如Oracle、DB2最新的版本支持RDF，就是用這種方法去做的。但該方法的Join會很多，性能會非常低。
2. gStore[Zou et al.，2011]
給一個SPARQL，把它Match到一個查詢圖Q，那麼回答SPARQL就是在Data Graph中找到查詢圖Q的匹配，如果能找到，那麼就能很快回答SPARQL，這是gStore系統最核心的思路。
gStore系統思路從技術層面，在索引的方式、Join的策略和Join順序的選擇提出了三種查詢優化方式。在原來的系統版本中，採用的是以點爲中心的策略，類似Worst Case Optimal Join，沒有用Worst Case Optimal Join和Binary Join合在一起的。但在即將發佈的1.0版本，則考慮了Worst Case Optimal Join 加 Binary Join合在一起的策略。
gStore的開源項目官網裏有詳細的使用文檔，在gitHub和gitee（碼雲在線）上面都有gStore的源碼。
- 分佈式gStore[Pengu et al.，2016]
下面提到的是分佈式gStore系統，解決的是單機存儲不下一個大的RDF圖，需要分佈式存儲在多個機器上，而查詢結果跨在多臺機器上的問題。
4. 優化原子操作-Set Intersection
前面提到在做 Worst Case Optimal Join 時最重要的是集合求交操作。集合求交是子圖匹配中很重要的算子操作，那麼集合求交怎麼加速呢？
我們提出了一種利用 CPU 的 SIMD（單指令多數據流）向量計算方法，通過設計一種精巧的數據佈局（Data Layout）策略，可以降低對集合求交中CPU運行的Cycles的數目。
Stanford做的開源的圖處理引擎（graph processing）系統，也是用Worst Case Optimal Join做的，在其系統中，將我們研究的集合求交優化算法替換之後，發現性能有比較明顯的提升。
5. 硬件加速
剛纔提到，Worst Case Optimal Join算法，每一行是完全獨立的查詢操作，非常容易做並行。所以會想到使用在GPU上運行操作。但在GPU上執行操作，其每個線程或每個wrap做計算沒有問題，但中間結果如何寫回去，如何避免寫衝突是需要考慮的。我們提出一種方案使得每一個wrap獨立地去執行，並且可以獨立地去寫，在不需要加鎖的方式下不會產生寫衝突。
以上是一些參考文獻。
今天的分享就到這裏，謝謝大家。
閱讀更多技術乾貨文章，請關注微信公衆號“DataFunTalk”
關於我們：
DataFun：專注於大數據、人工智能技術應用的分享與交流。發起於2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峯會，已邀請近1000位專家和學者參與分享。其公衆號 DataFunTalk 累計生產原創文章500+，百萬+閱讀，13萬+精準粉絲。
注：歡迎轉載，轉載請留言或私信。