一種關(guān)系—圖數(shù)據(jù)庫(kù)混合存儲(chǔ)系統(tǒng)設(shè)計(jì)

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

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

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1 全局模式定義

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

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

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

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

以在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ù)源、表的類(lèi)型、數(shù)據(jù)域4種屬性。其中表名與MySQL中對(duì)應(yīng)的表名相同，數(shù)據(jù)源為該表所在的數(shù)據(jù)庫(kù)，表的類(lèi)型表示了該表為關(guān)聯(lián)表還是數(shù)據(jù)表，數(shù)據(jù)域中為該表所包含的字段，針對(duì)數(shù)據(jù)域中的字段，給出了“字段名稱(chēng)”、“字段特征”兩個(gè)屬性，其中“字段特征”定義該字段是主鍵、外鍵或普通字段。

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

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

2.2 C-SQL定義

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

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

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

表1 C-SQL的擴(kuò)展巴科斯范式

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

//父查詢(xún)

parent_query->select("id")->

from("case")->

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

//子查詢(xún)

sub_query->select("*")->

from("suspects")->

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

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

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

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

在混合存儲(chǔ)系統(tǒng)中進(jìn)行查詢(xún)時(shí)，如何將查詢(xún)?nèi)蝿?wù)合理地分配到每一個(gè)數(shù)據(jù)庫(kù)中直接決定了查詢(xún)的效率。優(yōu)化器的目的是在接收到用戶(hù)的查詢(xún)請(qǐng)求以后，根據(jù)查詢(xún)的成本，找到一個(gè)最佳的查詢(xún)計(jì)劃，將查詢(xún)請(qǐng)求推向合適的數(shù)據(jù)庫(kù)，以達(dá)到提升查詢(xún)性能的目的。優(yōu)化器主要由計(jì)劃枚舉器和成本模型兩個(gè)部分組成。

2.3.1 計(jì)劃枚舉器

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

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

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

表2 查詢(xún)示例Q2.1的枚舉查詢(xún)

查詢(xún)示例：

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的查詢(xún)都是包含連接操作和引用表的條件查詢(xún)。q6～q8的查詢(xún)中只包含了單個(gè)表的查詢(xún)，不包含任何查詢(xún)條件，因此后續(xù)處理中，將會(huì)刪除枚舉查詢(xún)中類(lèi)似的查詢(xún)。

2.3.2 成本模型

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

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

為了提高查詢(xún)效率，本文基于動(dòng)態(tài)模型，構(gòu)建了以響應(yīng)時(shí)間為測(cè)量標(biāo)準(zhǔn)的動(dòng)態(tài)成本模型。

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

2.4 連接器實(shí)現(xiàn)

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

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

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

C-SQL中的別名，類(lèi)似于SQL中的別名，是表的臨時(shí)名稱(chēng)。而Cypher中的別名是節(jié)點(diǎn)或者邊的臨時(shí)名稱(chēng)。C-SQL查詢(xún)中多次提及一個(gè)表時(shí)，需要對(duì)表提供別名，同理，在Cypher中多次引用節(jié)點(diǎn)或者邊時(shí)，需要對(duì)節(jié)點(diǎn)或者邊提供別名。

當(dāng)查詢(xún)語(yǔ)句中每個(gè)表只被引用一次的時(shí)候，C-SQL在編寫(xiě)用戶(hù)查詢(xún)的過(guò)程中，不需要為表提供別名，但轉(zhuǎn)化成Cypher后，根據(jù)Cypher的使用規(guī)則，需要對(duì)表對(duì)應(yīng)的節(jié)點(diǎn)提供一個(gè)別名。這種情況下，可以使用C-SQL中的表名來(lái)解決Cypher中的別名問(wèn)題；但當(dāng)查詢(xún)語(yǔ)句中多次提及一個(gè)表或多個(gè)表的時(shí)候，需要按照C-SQL查詢(xún)語(yǔ)句中表的別名將其轉(zhuǎn)換成Cypher中節(jié)點(diǎn)與邊的別名。

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

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

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

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

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

因?yàn)镃-SQL是參照SQL進(jìn)行定義的，所以將C-SQL語(yǔ)句轉(zhuǎn)換成SQL語(yǔ)句的過(guò)程較為簡(jiǎn)單。

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

SELECT {selectItems}

FROM {fromItems}

WHERE {conditions}

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

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

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

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

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

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

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

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

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

操作復(fù)現(xiàn)模塊將日志解析模塊轉(zhuǎn)換的JSON數(shù)據(jù)按照操作類(lèi)型轉(zhuǎn)換成對(duì)應(yīng)的Cypher語(yǔ)句，將數(shù)據(jù)插入圖數(shù)據(jù)庫(kù)。

4 實(shí)驗(yàn)

為了驗(yàn)證混合存儲(chǔ)系統(tǒng)的可行性，測(cè)試了混合存儲(chǔ)系統(tǒng)、MySQL和Neo4j對(duì)于相同查詢(xún)的查詢(xún)效率。

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

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

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

為盡可能地涉及分組、聚合、排序、連接等多種查詢(xún)類(lèi)型，挑選了下列查詢(xún)來(lái)分別對(duì)MySQL、Neo4j和混合存儲(chǔ)系統(tǒng)進(jìn)行實(shí)驗(yàn)：

Q1：查找案件編號(hào)000001的案件。

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

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

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

Q5：查找審判長(zhǎng)1審判的縱火罪的犯罪嫌疑人信息。

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

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

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

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

以查詢(xún)的響應(yīng)時(shí)間為測(cè)量標(biāo)準(zhǔn)，實(shí)驗(yàn)結(jié)果如圖4所示。

圖4 MySQL、Neo4j、AgensGraph和混合存儲(chǔ)系統(tǒng)的查詢(xún)響應(yīng)時(shí)間

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

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

5 結(jié)束語(yǔ)

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