王 寧，張 偉,2，王佳慧，馬利民,2

(1.北京信息科技大學 計算機學院，北京 100101；2.北京信息科技大學 北京材料基因工程高精尖創(chuàng)新中心，北京 100101；3.國家信息中心信息與網(wǎng)絡安全部，北京 100045)

0 引言

關系型數(shù)據(jù)模型最早在1970年由E.F.Codd[1]提出，逐漸成為主流數(shù)據(jù)庫的常用模型。同時，隨著互聯(lián)網(wǎng)的發(fā)展，在社交、金融、物流、新零售等多個領域中，多表連接查詢應用越來越普遍，涉及決策支持和復雜數(shù)據(jù)的數(shù)據(jù)庫應用程序通常根據(jù)多表連接查詢來得到其期望的結(jié)果。在關系數(shù)據(jù)庫中進行復雜的多表連接查詢會導致兩種結(jié)果：一是數(shù)據(jù)庫需要通過關聯(lián)表間接地維護實體間的關系，導致數(shù)據(jù)庫的執(zhí)行效率低下,同時因此產(chǎn)生的關聯(lián)表的數(shù)量急劇上升；二是面對大量實體之間的關系描述，傳統(tǒng)的關系型數(shù)據(jù)庫達到性能瓶頸。

在這種背景下，圖數(shù)據(jù)庫應運而生，且因其善于處理大量復雜、互連接、低結(jié)構(gòu)化的數(shù)據(jù)受到了廣泛的關注。但圖數(shù)據(jù)庫也存在缺點。Cheng等[2]經(jīng)過大量的實驗表明，相較于關系數(shù)據(jù)庫，在處理多表連接、模式匹配、路徑識別等查詢方面，圖數(shù)據(jù)庫擁有更高的性能；但是，在分組、排序、聚合等查詢方面，關系數(shù)據(jù)庫的執(zhí)行效率明顯優(yōu)于圖數(shù)據(jù)庫。而在處理包含多表連接、分組、排序、聚合等多種操作的復雜查詢時，無論是關系數(shù)據(jù)庫還是圖數(shù)據(jù)庫，都存在著一定的局限性。

為了解決這一問題，當前的研究方向主要可以分為兩種：一種是以關系數(shù)據(jù)庫為基礎，結(jié)合圖數(shù)據(jù)庫潛在的可擴展性，使得關系數(shù)據(jù)庫可以有效地存儲和查詢圖結(jié)構(gòu)的數(shù)據(jù)[3-4]；另一種是將關系數(shù)據(jù)庫和圖數(shù)據(jù)庫進行結(jié)合，構(gòu)建多數(shù)據(jù)庫的混合存儲系統(tǒng)，以此充分發(fā)揮各個數(shù)據(jù)庫的優(yōu)勢，掩蓋單一數(shù)據(jù)庫的不足。

A.Lentz[5]提出的OQGraph通過模仿存儲引擎將用戶查詢代理表的操作解釋為圖遍歷指令。盡管通過提供更多以圖為中心的界面可以在某種程度上改善用戶的體驗，但是性能卻無法與單一的圖數(shù)據(jù)庫相比。Sun等[6]提出的SQLGraph將關系存儲用于存儲鄰接信息，并用JSON文件存儲頂點和邊的屬性等信息，盡管這種方法確實提高了以圖為中心的查詢的性能，但是會損害常規(guī)查詢的性能。Christopher J.O.Little[7]通過對關系數(shù)據(jù)庫進行擴展提出了Grapht模型，該模型設計了一個內(nèi)置的內(nèi)存存儲，通過查詢處理器會將用戶的查詢分為針對關系數(shù)據(jù)庫的以行為中心的子查詢和針對圖處理程序的以圖為中心的子查詢。

Jeff Shute等[8]研究的混合數(shù)據(jù)庫F1，結(jié)合了NoSQL系統(tǒng)的高可用性和可伸縮性以及傳統(tǒng)SQL數(shù)據(jù)庫的一致性和可用性。Martin Grund等[9]提出了一種特定于企業(yè)應用程序的數(shù)據(jù)庫系統(tǒng)，該系統(tǒng)將語義數(shù)據(jù)和圖數(shù)據(jù)直接包含在同一個存儲引擎中，并結(jié)合了在單個內(nèi)存數(shù)據(jù)庫引擎中處理關系數(shù)據(jù)和圖數(shù)據(jù)的優(yōu)點。

基于以上研究背景，本文結(jié)合MySQL和Neo4j的特點，設計了一個混合存儲系統(tǒng)：定義了一種類SQL語言C-SQL用來連接MySQL和Neo4j，為用戶提供統(tǒng)一的數(shù)據(jù)庫訪問接口，以完成混合系統(tǒng)的查詢工作；使用動態(tài)成本模型，來判斷查詢在MySQL和Neo4j中的執(zhí)行時間，以挑選最優(yōu)的查詢計劃，完成對復雜查詢的優(yōu)化；最后，為保證MySQL和Neo4j之間的一致性，通過解析MySQL的Binlog日志中的變更操作信息，獲取增量數(shù)據(jù)實現(xiàn)數(shù)據(jù)從MySQL到Neo4j的同步工作。實驗結(jié)果證明，與單一的MySQL和Neo4j的查詢效率相比，本文提出的混合存儲系統(tǒng)在保證查詢結(jié)果正確及不降低性能的情況下，復雜查詢的效率有了明顯提升。

1 系統(tǒng)結(jié)構(gòu)

混合存儲系統(tǒng)主要用來提高在集成MySQL和Neo4j的系統(tǒng)中復雜查詢的效率。混合存儲系統(tǒng)主要包括查詢解析器、優(yōu)化器、連接器3個模塊。系統(tǒng)結(jié)構(gòu)如圖1所示。

圖1 混合存儲系統(tǒng)結(jié)構(gòu)

統(tǒng)一查詢接口用來接受客戶端傳送過來的查詢請求，然后由查詢解析器將接收到的查詢轉(zhuǎn)換為由類SQL語言C-SQL定義的查詢語句，并將其傳遞給優(yōu)化器。

優(yōu)化器中包含計劃枚舉器和成本模型等多個模塊。它將收到的查詢進行分解，并確定最優(yōu)查詢計劃，隨后將最優(yōu)查詢計劃中的子查詢傳送到對應的與數(shù)據(jù)庫連接的連接器中。如果最終的查詢計劃同時分布在MySQL和Neo4j兩個數(shù)據(jù)庫中，優(yōu)化器會將兩個數(shù)據(jù)庫中的查詢結(jié)果進行合并，并將合并后的查詢結(jié)果發(fā)送給用戶。

連接器模塊直接與目標數(shù)據(jù)庫連接，在連接器接收到來自優(yōu)化器的子查詢后，首先使用全局模式進行驗證，隨后將查詢翻譯成對應數(shù)據(jù)庫的查詢語言并發(fā)送到數(shù)據(jù)庫，數(shù)據(jù)庫執(zhí)行查詢并返回結(jié)果，連接器將查詢結(jié)果轉(zhuǎn)換為通用的格式，然后將其發(fā)送給優(yōu)化器。

2 系統(tǒng)功能模塊

本節(jié)主要闡述混合存儲系統(tǒng)中各個模塊的功能和實現(xiàn)細節(jié)。

2.1 全局模式定義

在混合存儲系統(tǒng)中，每個數(shù)據(jù)庫都定義了自己獨有的數(shù)據(jù)存儲模式，在進行查詢的過程中，開發(fā)人員還需要了解不同數(shù)據(jù)庫中的數(shù)據(jù)劃分，且需要針對不同的數(shù)據(jù)庫進行數(shù)據(jù)查詢。為了解決這一問題，設計了一個存儲著關系數(shù)據(jù)庫和圖數(shù)據(jù)庫數(shù)據(jù)模式的全局模式，其中存放了數(shù)據(jù)庫中所有表的相關信息。通過全局模式的定義，可以簡化對接收到的查詢進行驗證的過程。

系統(tǒng)全局模式的定義參照了關系數(shù)據(jù)庫的模式定義。同時，為了方便在圖數(shù)據(jù)庫上進行數(shù)據(jù)查詢，根據(jù)Neo4j官網(wǎng)[10]提供的從關系數(shù)據(jù)轉(zhuǎn)換成圖數(shù)據(jù)的方法，將全局模式中的所有表定義為關聯(lián)表和數(shù)據(jù)表兩種結(jié)構(gòu)，以方便將全局模式中的表和圖數(shù)據(jù)庫中的節(jié)點和邊進行一一對應。

定義1關聯(lián)表是另一個表未引用的關系，它恰好包含兩個外鍵，并且可以具有其他的相關屬性。

定義2數(shù)據(jù)表是一個關系，其中包含關聯(lián)表以外的任何其他情況。這意味著該關系可以不包含任何外鍵，也可以包含多個外鍵，并且可以被另一個表引用。

以在MySQL中的案件信息表case(id,casename,judge)為例，以下為case表在全局模式的定義：

{

"tableName":"case",

"dataSource":"MySQL",

"tableType":"dataTable",

"fields":[{

"fieldName":"id",

"characteristic":"primaryKey"}，

{

" fieldName ":"casename",

" characteristic ":"ordinary"

},

{

" fieldName ":"judge",

" characteristic ":" ordinary "

}]

}

在以上全局模式中，定義了表名、數(shù)據(jù)源、表的類型、數(shù)據(jù)域4種屬性。其中表名與MySQL中對應的表名相同，數(shù)據(jù)源為該表所在的數(shù)據(jù)庫，表的類型表示了該表為關聯(lián)表還是數(shù)據(jù)表，數(shù)據(jù)域中為該表所包含的字段，針對數(shù)據(jù)域中的字段，給出了“字段名稱”、“字段特征”兩個屬性，其中“字段特征”定義該字段是主鍵、外鍵或普通字段。

從全局模式轉(zhuǎn)換成圖結(jié)構(gòu)，每個數(shù)據(jù)表都可以轉(zhuǎn)化成一個節(jié)點，其中表名為節(jié)點的標簽，外鍵轉(zhuǎn)換成與節(jié)點相連的邊，普通字段轉(zhuǎn)換為節(jié)點的屬性。每個關聯(lián)表轉(zhuǎn)換成兩個外鍵引用的兩個節(jié)點之間的邊，關聯(lián)表中的其他字段轉(zhuǎn)換成兩個節(jié)點之間邊的屬性。通過這種方法，使數(shù)據(jù)表涵蓋了所有實體，關聯(lián)表涵蓋了節(jié)點與節(jié)點之間的關系。圖2展示了案件信息、嫌疑人、人員信息相關數(shù)據(jù)在關系數(shù)據(jù)庫、圖數(shù)據(jù)庫和全局模式中的表示及對應關系。

圖2 案件信息、嫌疑人、人員信息在關系模型、全局模式、圖模型中的表示

2.2 C-SQL定義

對于多個異構(gòu)數(shù)據(jù)庫，沒有統(tǒng)一的數(shù)據(jù)庫訪問接口，通常情況下，對象關系映射(object relational mapping，ORM)僅僅連接到單個數(shù)據(jù)庫上，開發(fā)人員需要學習多種查詢語言。

因此，為了提供統(tǒng)一的查詢接口，也為了簡化SQL語句和Cypher語句之間的轉(zhuǎn)化過程，本文結(jié)合SQL的語法規(guī)則和圖數(shù)據(jù)模式，定義了一種簡化的類SQL查詢語言C-SQL。

C-SQL通過系統(tǒng)中的查詢解析器生成，目前僅支持讀取操作。本文使用擴展巴科斯范式(extended Backus-Naur form,EBNF)來定義C-SQL的語法規(guī)則，如表1所示。

表1 C-SQL的擴展巴科斯范式

表1中定義了帶子查詢的讀取查詢的結(jié)構(gòu)。在C-SQL中，子查詢作為父查詢的一個額外查詢定義，其目的是在圖數(shù)據(jù)庫上進行查詢時，方便將C-SQL格式的查詢語句轉(zhuǎn)換為Cypher格式的查詢語句。帶子查詢的C-SQL查詢示例如下：

//父查詢

parent_query->select("id")->

from("case")->

where("judge","="，"張三");

//子查詢

sub_query->select("*")->

from("suspects")->

whereIn("id",parent-query->result());

在以上示例中，使用查詢查找了姓名為“張三”的法官所辦理的案件中犯罪嫌疑人的信息。其中parent_query和sub_query為解析器中定義的變量名稱。

除了以上的定義外，為了滿足不同類型的用戶查詢需求，對where關鍵字的功能進行了擴充，定義了不同類型的where函數(shù)以滿足不同查詢的條件。包括orWhere，whereIn，orWhereIn，whereLike，orWhereLike，whereExist，orwhereExist等。由此，除了可以通過C-SQL創(chuàng)建單一條件的查詢、條件中包含子查詢的查詢以外，同時還可以創(chuàng)建多種類型的條件查詢。

2.3 查詢優(yōu)化策略

在混合存儲系統(tǒng)中進行查詢時，如何將查詢?nèi)蝿蘸侠淼胤峙涞矫恳粋€數(shù)據(jù)庫中直接決定了查詢的效率。優(yōu)化器的目的是在接收到用戶的查詢請求以后，根據(jù)查詢的成本，找到一個最佳的查詢計劃，將查詢請求推向合適的數(shù)據(jù)庫，以達到提升查詢性能的目的。優(yōu)化器主要由計劃枚舉器和成本模型兩個部分組成。

2.3.1 計劃枚舉器

優(yōu)化器在接收到查詢解析器發(fā)送過來的用戶查詢請求后，首先將其發(fā)送到計劃枚舉器中。計劃枚舉器的作用是根據(jù)接收到的查詢請求構(gòu)造枚舉查詢，包括查詢內(nèi)容、查詢的目標表信息以及查詢的過濾條件等。使用計劃枚舉器不僅是為了構(gòu)建一組從用戶的查詢請求中派生出的枚舉查詢，而且是為了對枚舉查詢進行維護，包括從枚舉查詢中重構(gòu)原始的用戶查詢。計劃枚舉器構(gòu)造枚舉查詢后，將其發(fā)送至成本模型進行成本計算。

計劃枚舉器的原理如下：首先，計劃枚舉器檢查輸入查詢中是否有多個表，如果存在多個表，則為所有可能的連接組合創(chuàng)建一個新查詢，同時為具有條件語句和選擇語句的每個表創(chuàng)建一個新查詢。其次，如果存在多個條件，將為每個條件創(chuàng)建一個新查詢，并將所有選擇語句添加到新查詢中。如果查詢中沒有上述兩種情況，計劃枚舉器將使用一個表和select語句創(chuàng)建一個新查詢，不包含查詢條件。如果查詢中沒有條件且沒有連接操作，算法將停止并返回輸入查詢。在對輸入查詢進行枚舉后，對于創(chuàng)建的新查詢，將會以每一個新查詢作為枚舉對象再次調(diào)用計劃枚舉器，進行遞歸枚舉，最后返回所有的枚舉結(jié)果。

計劃枚舉器的結(jié)果是查詢的枚舉，類似于樹結(jié)構(gòu)，樹的根節(jié)點是用戶的查詢請求，每個子節(jié)點都是從根節(jié)點派生出來的子查詢。以查詢Q2.1為例，經(jīng)過計劃枚舉器處理后的枚舉查詢?nèi)绫?所示。

表2 查詢示例Q2.1的枚舉查詢

查詢示例：

Q2.1->select("*")->from("case","c")->from("suspects","s")->from("person","p")->where("c.id"," ="," s.id")->where("s.identity-id","p.identity-id")

由表2可知，q1～q5的查詢都是包含連接操作和引用表的條件查詢。q6～q8的查詢中只包含了單個表的查詢，不包含任何查詢條件，因此后續(xù)處理中，將會刪除枚舉查詢中類似的查詢。

2.3.2 成本模型

在多數(shù)據(jù)庫混合存儲系統(tǒng)中，查詢可能會在部分或者全部數(shù)據(jù)庫上執(zhí)行，執(zhí)行計劃并不是唯一確定的，為了優(yōu)化查詢執(zhí)行的性能，需要成本模型來控制查詢的成本。常見的成本模型有3種：黑盒模型[11]、自定義模型[12]和動態(tài)模型[13]。

黑盒模型將每個數(shù)據(jù)庫視為一個黑盒，通過在每個數(shù)據(jù)庫上運行大量的測試查詢，以收集每個數(shù)據(jù)庫的成本模型所需要的信息。自定義模型根據(jù)每個數(shù)據(jù)庫構(gòu)建單獨的成本模型，然后匯總不同成本模型的結(jié)果來創(chuàng)建系統(tǒng)總體的成本模型。動態(tài)模型通過監(jiān)視每個數(shù)據(jù)庫運行時的實時數(shù)據(jù)來構(gòu)建成本模型。相較于黑盒模型和自定義模型，動態(tài)模型可以選擇更加準確的查詢計劃。

為了提高查詢效率，本文基于動態(tài)模型，構(gòu)建了以響應時間為測量標準的動態(tài)成本模型。

成本模型的執(zhí)行流程如下：第一步，在MySQL和Neo4j中并行執(zhí)行枚舉查詢中的每個查詢，并將查詢響應時間記錄保存。第二步，遍歷枚舉查詢的樹結(jié)構(gòu)，在遍歷的過程中，比較每個節(jié)點的枚舉查詢在不同數(shù)據(jù)庫上的響應時間，找到響應時間最短的數(shù)據(jù)庫，將查詢響應時間記錄并標記為查詢成本cost(v)。第三步，在樹的每層匯總所有查詢成本，并將匯總的查詢成本與父查詢的查詢成本進行比較。如果查詢成本低于父查詢的90%，表明有優(yōu)化的空間，遍歷繼續(xù)；如果查詢成本高于父查詢的90%，停止遍歷；同時，當查詢成本高于父查詢的95%時，父查詢?yōu)樽詈笠徊絻?yōu)化查詢。通過以上方法，可以找到在數(shù)個數(shù)據(jù)庫上執(zhí)行的查詢計劃。最后，成本模型返回選擇出的最佳查詢計劃，并執(zhí)行該計劃，得到符合用戶查詢請求的結(jié)果。

2.4 連接器實現(xiàn)

連接器連接底層的數(shù)據(jù)庫，在接收到優(yōu)化器傳送過來的枚舉查詢后，連接器會與目標數(shù)據(jù)庫建立連接，然后將查詢翻譯成目標數(shù)據(jù)庫定義的查詢語言，也就是Cypher和SQL，將其發(fā)送至數(shù)據(jù)庫，并在數(shù)據(jù)庫執(zhí)行完查詢后接收返回結(jié)果并將結(jié)果發(fā)送給優(yōu)化器。因此，準確地將C-SQL格式的查詢語句翻譯成Cypher語句和SQL語句是保證系統(tǒng)正確查詢的前提。

2.4.1 從C-SQL到Cypher的轉(zhuǎn)換

大多數(shù)情況下，查詢中都包含where語句用來過濾查詢結(jié)果，在Cypher中，同樣也有類似的WHERE子句進行條件過濾。但是將C-SQL語句轉(zhuǎn)換成Cypher語句并不容易，一方面，Cypher中使用別名的方式不同于C-SQL，另一方面，需要對C-SQL中的外鍵等字段進行識別判斷。

C-SQL中的別名，類似于SQL中的別名，是表的臨時名稱。而Cypher中的別名是節(jié)點或者邊的臨時名稱。C-SQL查詢中多次提及一個表時，需要對表提供別名，同理，在Cypher中多次引用節(jié)點或者邊時，需要對節(jié)點或者邊提供別名。

當查詢語句中每個表只被引用一次的時候，C-SQL在編寫用戶查詢的過程中，不需要為表提供別名，但轉(zhuǎn)化成Cypher后，根據(jù)Cypher的使用規(guī)則，需要對表對應的節(jié)點提供一個別名。這種情況下，可以使用C-SQL中的表名來解決Cypher中的別名問題；但當查詢語句中多次提及一個表或多個表的時候，需要按照C-SQL查詢語句中表的別名將其轉(zhuǎn)換成Cypher中節(jié)點與邊的別名。

將C-SQL轉(zhuǎn)化成Cypher的另一個問題是對外鍵的處理。在本文對以下格式的where條件語句進行定義。

定義3在由leftConf = rightConf構(gòu)成的過濾條件中，如果leftConf和rightConf都是屬性，其中一個必須是外鍵，另一個必須為引用屬性。

在查詢語句的過濾條件中，定義3中的過濾條件，在Cypher中表示為邊而不是WHERE中的過濾條件，所以，在查詢語句從C-SQL格式轉(zhuǎn)換成Cypher格式的過程中，無法將C-SQL定義3中的where模塊，轉(zhuǎn)換成Cypher中的WHERE模塊，所以在轉(zhuǎn)換的時候，需要對定義3中的條件語句進行識別并將其刪除。

在經(jīng)過上述的別名轉(zhuǎn)換和對C-SQL中where語句進行預處理后，便可以將C-SQL中的where語句轉(zhuǎn)換成為Cypher中的WHERE子句。同時，對select中涉及的查詢信息，經(jīng)過全局模式的驗證后，刪除對外鍵的引用，同時將通配符“*”轉(zhuǎn)換成相關屬性名后，就可以轉(zhuǎn)換成Cypher中的RETURN子句。

2.4.2 從C-SQL到SQL的轉(zhuǎn)換

因為C-SQL是參照SQL進行定義的，所以將C-SQL語句轉(zhuǎn)換成SQL語句的過程較為簡單。

參照SQL語句的格式，SQL中讀取操作主要包含以下幾部分：

SELECT {selectItems}

FROM {fromItems}

WHERE {conditions}

按照selectItems、fromItems、conditions各部分在SQL中的定義，對C-SQL格式的查詢語句進行提取整合就可以將C-SQL轉(zhuǎn)換成SQL。

3 數(shù)據(jù)同步策略

為了保證系統(tǒng)運行過程中MySQL和Neo4j中數(shù)據(jù)的一致性，采用日志解析的方法從MySQL中獲取數(shù)據(jù)變更操作并同步至Neo4j內(nèi)。

首先，基于MySQL的主從復制機制，將同步程序模擬成MySQL的從節(jié)點，就可以實時從MySQL數(shù)據(jù)庫中的Binlog日志中獲取數(shù)據(jù)變更操作信息；接著對獲取到的數(shù)據(jù)變更操作進行解析；然后將變更操作信息存入緩存隊列以緩解系統(tǒng)壓力；最后對數(shù)據(jù)變更操作進行復現(xiàn)，將數(shù)據(jù)存入Neo4j內(nèi)。整個數(shù)據(jù)同步流程如圖3所示。

圖3 從MySQL到Neo4j的數(shù)據(jù)同步流程

日志過濾模塊通過模擬MySQL的從節(jié)點連接MySQL數(shù)據(jù)庫，從Binlog日志中獲取事件信息并篩選出有效的變更操作信息。

日志解析模塊將過濾后的日志文件進行解析分類，隨后將解析結(jié)果轉(zhuǎn)換為JSON格式的數(shù)據(jù)存入緩存隊列中。

元數(shù)據(jù)模塊中存放了關系型數(shù)據(jù)庫中的表結(jié)構(gòu)信息。圖數(shù)據(jù)庫數(shù)據(jù)以節(jié)點和節(jié)點之間的關系進行存儲，在對日志進行解析后，通過元數(shù)據(jù)中的表結(jié)構(gòu)信息獲取操作的數(shù)據(jù)是否為主鍵或者外鍵，進而在操作復現(xiàn)時決定是對圖數(shù)據(jù)庫中的節(jié)點還是關系進行操作。另外，當關系型數(shù)據(jù)庫中的變更操作為DDL操作時，在對日志進行解析后，將更改后的表結(jié)構(gòu)信息更新至元數(shù)據(jù)模塊中，以保持與關系型數(shù)據(jù)庫中的表結(jié)構(gòu)信息一致。

緩存隊列模塊用以保證后續(xù)操作的順序，避免發(fā)生寫入操作的并發(fā)，同時緩解系統(tǒng)壓力。

操作復現(xiàn)模塊將日志解析模塊轉(zhuǎn)換的JSON數(shù)據(jù)按照操作類型轉(zhuǎn)換成對應的Cypher語句，將數(shù)據(jù)插入圖數(shù)據(jù)庫。

4 實驗

為了驗證混合存儲系統(tǒng)的可行性，測試了混合存儲系統(tǒng)、MySQL和Neo4j對于相同查詢的查詢效率。

另外，本文還對混合存儲系統(tǒng)和圖數(shù)據(jù)庫AgensGraph進行了對比。AgensGraph是一種基于PostgreSQL的多模型數(shù)據(jù)庫，允許開發(fā)人員集成經(jīng)典的關系數(shù)據(jù)庫模型的同時能夠提供圖數(shù)據(jù)分析環(huán)境。

實驗平臺的設備參數(shù)為：8 GB內(nèi)存，4核CPU以及200 GB硬盤。

實驗數(shù)據(jù)為某市某區(qū)人員關系數(shù)據(jù)及刑事案件數(shù)據(jù)，這兩個數(shù)據(jù)集均為關系數(shù)據(jù)，存放在MySQL中，包括人員基本信息、人員關系信息、刑事案件基本信息、犯罪嫌疑人信息、判決信息等。通過實體、關系映射規(guī)則，將上述關系數(shù)據(jù)映射到Neo4j中，其中MySQL中的數(shù)據(jù)大小為1.6 GB，Neo4j中的數(shù)據(jù)大小為2.9 GB。

為盡可能地涉及分組、聚合、排序、連接等多種查詢類型，挑選了下列查詢來分別對MySQL、Neo4j和混合存儲系統(tǒng)進行實驗：

Q1：查找案件編號000001的案件。

Q2：統(tǒng)計所有類型案件的數(shù)量。

Q3：查找量刑最高的搶劫案。

Q4：查找犯罪嫌疑人1的父親。

Q5：查找審判長1審判的縱火罪的犯罪嫌疑人信息。

Q6：查找審判長1在2018年判決的縱火罪的犯罪嫌疑人信息。

Q7：查找既犯了搶劫罪又犯了盜竊罪的犯罪嫌疑人的親友信息。

Q8：查找2019年審判案件最多的審判長判決的案件中量刑最高的案件的犯罪嫌疑人信息。

上述查詢中，查詢Q1～Q3為比較常見的分組和聚合查詢，查詢Q4為簡單的join查詢，查詢Q5～Q8則包含了大量連接、聚合、排序操作的復雜查詢。

以查詢的響應時間為測量標準，實驗結(jié)果如圖4所示。

圖4 MySQL、Neo4j、AgensGraph和混合存儲系統(tǒng)的查詢響應時間

對Q1～Q8在混合系統(tǒng)中的查詢計劃進行分析發(fā)現(xiàn)，混合存儲系統(tǒng)在執(zhí)行上述查詢時，查詢Q1～Q4僅在MySQL上執(zhí)行，查詢Q5～Q8為混合查詢。

通過分析實驗結(jié)果，查詢Q1～Q4在混合存儲系統(tǒng)中執(zhí)行的響應時間近似于在MySQL上的執(zhí)行時間，遠優(yōu)于在Neo4j上的執(zhí)行時間。而復雜查詢Q5～Q8在混合系統(tǒng)中的查詢響應時間，顯著優(yōu)于單獨在MySQL和Neo4j上的響應時間，也優(yōu)于AgensGraph數(shù)據(jù)庫的響應時間。實驗結(jié)果表明，混合存儲系統(tǒng)在進行復雜查詢時，相比Neo4j查詢效率提高了50%以上，較AgensGraph數(shù)據(jù)庫也有較為明顯的優(yōu)勢。

5 結(jié)束語

本文基于MySQL和Neo4j，實現(xiàn)了一個混合存儲系統(tǒng)。通過C-SQL連接MySQL和Neo4j，為用戶提供統(tǒng)一的數(shù)據(jù)庫訪問接口，以完成混合系統(tǒng)的查詢處理；基于動態(tài)成本模型對查詢進行分解優(yōu)化，確定最優(yōu)查詢計劃，提高復雜查詢的效率。實驗結(jié)果表明，與MySQL、Neo4j和AgensGraph進行比較，本文提出的混合存儲系統(tǒng)在保證查詢結(jié)果正確的情況下，對于復雜查詢的效率有了明顯提升。