面向多源異構(gòu)數(shù)據(jù)庫的SQL解析與轉(zhuǎn)換方法研究

練金棟，陳 志，岳文靜，趙 培，3，呂偉初，3

（1.南京郵電大學(xué) 計(jì)算機(jī)學(xué)院；2.南京郵電大學(xué) 通信與信息工程學(xué)院，江蘇 南京 210003；3.金篆信科有限責(zé)任公司，江蘇 南京 210012）

0 引言

隨著數(shù)據(jù)量的爆發(fā)式增長(zhǎng)，傳統(tǒng)的單一數(shù)據(jù)庫模式愈發(fā)難以滿足存儲(chǔ)和查詢的實(shí)時(shí)性要求。數(shù)據(jù)結(jié)構(gòu)呈現(xiàn)多樣化趨勢(shì)，多種存儲(chǔ)類型的數(shù)據(jù)庫并行交互［1-2］，各行業(yè)內(nèi)部出現(xiàn)不同部門存在數(shù)據(jù)壁壘、數(shù)據(jù)共享消耗大量資源、數(shù)據(jù)流轉(zhuǎn)和融合處理成本上升、數(shù)據(jù)一致性難以保證等問題［3］。為了滿足各行各業(yè)對(duì)數(shù)據(jù)應(yīng)用的需求，企業(yè)開始根據(jù)自身業(yè)務(wù)特點(diǎn)，采用多種數(shù)據(jù)庫產(chǎn)品管理業(yè)務(wù)數(shù)據(jù)，形成了不同技術(shù)解決不同場(chǎng)景應(yīng)用問題的局面［4］：企業(yè)會(huì)以O(shè)racle、MySQL、PostgreSQL 等多個(gè)主流數(shù)據(jù)庫管理數(shù)據(jù)；各部門的數(shù)據(jù)會(huì)以CSV、XML、JSON 等不同文件類型分別進(jìn)行存儲(chǔ)；各類實(shí)時(shí)業(yè)務(wù)會(huì)采用HBase、MongoDB、Neo4J 等數(shù)據(jù)庫進(jìn)行數(shù)據(jù)處理與分析。研究表明［5］，每個(gè)企業(yè)應(yīng)用程序至少都涉及兩到三種不同類型的查詢系統(tǒng)，許多現(xiàn)實(shí)的分析業(yè)務(wù)也提出了便捷、高效地執(zhí)行跨平臺(tái)查詢的需求。針對(duì)這一情形，研究人員開展了大量針對(duì)多源異構(gòu)數(shù)據(jù)庫的跨平臺(tái)、統(tǒng)一操作技術(shù)的研究［6-7］。

然而，與數(shù)據(jù)庫系統(tǒng)的快速發(fā)展相對(duì)的，已有的異構(gòu)數(shù)據(jù)庫集成操作在易用性、統(tǒng)一性與高效性方面都存在一定的不足［8-10］。首先，現(xiàn)有工作尚未提供一個(gè)適用于跨平臺(tái)查詢的統(tǒng)一的SQL 查詢語言，易用性不高；其次，由于異構(gòu)數(shù)據(jù)庫不同的特性和各異的語法規(guī)則，數(shù)據(jù)庫之間的相互訪問需要通過編寫數(shù)據(jù)轉(zhuǎn)換接口來實(shí)現(xiàn)，學(xué)習(xí)成本高且工作量大，擴(kuò)展性不足。此外，現(xiàn)有工作大多只能針對(duì)單一的跨平臺(tái)SQL 査詢進(jìn)行優(yōu)化，可能嚴(yán)重影響跨平臺(tái)查詢性能。

為了解決以上問題，本文開發(fā)了一套高效、靈活且具有跨平臺(tái)特性的多源SQL 解析轉(zhuǎn)換方案。該方案設(shè)計(jì)了一種能描述異構(gòu)數(shù)據(jù)庫執(zhí)行邏輯的中間表示模型，通過該模型來隱藏底層庫的差異性，從而實(shí)現(xiàn)對(duì)異構(gòu)數(shù)據(jù)庫的統(tǒng)一解析建模和映射轉(zhuǎn)換，滿足多種數(shù)據(jù)集中存儲(chǔ)、查詢和修改的業(yè)務(wù)需求，提高數(shù)據(jù)處理效率和靈活性。

1 相關(guān)工作

SQL 和NoSQL 數(shù)據(jù)庫都有著各自的適用場(chǎng)景，并能滿足特定的數(shù)據(jù)需求與應(yīng)用目標(biāo)，因此將多種SQL 與NoSQL數(shù)據(jù)庫進(jìn)行集成，實(shí)現(xiàn)異構(gòu)數(shù)據(jù)庫的統(tǒng)一管理和互操作，可以讓不同數(shù)據(jù)庫系統(tǒng)在功能方面進(jìn)行有機(jī)結(jié)合，發(fā)揮各自的優(yōu)勢(shì)，從而利于提升數(shù)據(jù)處理效率，靈活應(yīng)對(duì)各種類型數(shù)據(jù)的查詢需求［11］。

目前的研究成果主要集中在SQL 與NoSQL 的集成融合系統(tǒng)以及支持?jǐn)?shù)據(jù)相互訪問的標(biāo)準(zhǔn)化API 上。文獻(xiàn)［12］通過將key-value 數(shù)據(jù)轉(zhuǎn)換合并到關(guān)系模型，實(shí)現(xiàn)利用PostgreSQL 對(duì)MongoDB 進(jìn)行操作，證明了在關(guān)系型和NoSQL 數(shù)據(jù)存儲(chǔ)上集成統(tǒng)一操作的可能性；文獻(xiàn)［13］提出基于SQL 模型的映射算法，通過SQL 查詢擴(kuò)充來實(shí)現(xiàn)每個(gè)SPARQL 代數(shù)運(yùn)算符，并生成高效的SQL 查詢；文獻(xiàn)［14-16］通過設(shè)計(jì)模式映射和查詢映射方法，實(shí)現(xiàn)了關(guān)系型數(shù)據(jù)庫與RDF 平臺(tái)的互操作。但此類研究只簡(jiǎn)單堆積了少數(shù)SQL 和NoSQL 數(shù)據(jù)庫，僅適用于涉及兩三類不同數(shù)據(jù)庫的小型業(yè)務(wù)，不具備通用性。另一些研究進(jìn)一步嘗試設(shè)計(jì)統(tǒng)一適配器的方式，通過向統(tǒng)一數(shù)據(jù)中間模型動(dòng)態(tài)提供適配數(shù)據(jù)，實(shí)現(xiàn)異構(gòu)數(shù)據(jù)庫的SQL 統(tǒng)一查詢。文獻(xiàn)［17］提出一種為每種SQL 語句定制正則表達(dá)式的方法解析SQL，并通過擴(kuò)展XQuery 實(shí)現(xiàn)對(duì)MongoDB 數(shù)據(jù)庫的操作；文獻(xiàn)［18-20］通過將關(guān)系表、鍵值對(duì)、CSV 文件、JSON 文件等結(jié)構(gòu)化與半結(jié)構(gòu)化數(shù)據(jù)轉(zhuǎn)換為臨時(shí)關(guān)系表結(jié)構(gòu)，以單一數(shù)據(jù)庫語法操作實(shí)現(xiàn)多數(shù)據(jù)源的統(tǒng)一查詢。此類方法的局限性在于要求在異構(gòu)數(shù)據(jù)庫之間設(shè)計(jì)數(shù)據(jù)轉(zhuǎn)換接口，以實(shí)現(xiàn)相互訪問，工作量大，擴(kuò)展性很差。

本文對(duì)上述方案的設(shè)計(jì)思想和方法進(jìn)行參考與總結(jié)，設(shè)計(jì)了一套通用的異構(gòu)數(shù)據(jù)庫解析轉(zhuǎn)換方案，通過設(shè)計(jì)統(tǒng)一中間表示模型來隱藏異構(gòu)數(shù)據(jù)庫在查詢語言和數(shù)據(jù)格式上的差異，實(shí)現(xiàn)多種關(guān)系型和NoSQL 數(shù)據(jù)庫的統(tǒng)一解析與轉(zhuǎn)換，生成統(tǒng)一的邏輯查詢計(jì)劃實(shí)現(xiàn)底層庫的操作請(qǐng)求，同時(shí)保證了較好的可擴(kuò)展性。

2 基于SQL語法的中間表示模型

由于Oracle、MySQL、DB2 等基于ANSI-SQL 標(biāo)準(zhǔn)開發(fā)的關(guān)系型數(shù)據(jù)庫仍被廣泛應(yīng)用。本文采用以SQL 語法為基礎(chǔ)、引入多種NoSQL 語法模型的模式設(shè)計(jì)異構(gòu)數(shù)據(jù)庫的中間表示模型。該模式降低了數(shù)據(jù)模型之間的開發(fā)和維護(hù)成本，并為滿足特定業(yè)務(wù)需求提供了更強(qiáng)的靈活性。

2.1 異構(gòu)語法轉(zhuǎn)換模式

由于不同數(shù)據(jù)庫系統(tǒng)的數(shù)據(jù)存儲(chǔ)模型不同，在數(shù)據(jù)命名、數(shù)據(jù)類型、數(shù)據(jù)結(jié)構(gòu)方面存在差異［21-22］，需要設(shè)計(jì)不同語法模型之間的轉(zhuǎn)換策略。如圖1（a）所示的傳統(tǒng)多對(duì)多轉(zhuǎn)換模式，兩個(gè)異構(gòu)數(shù)據(jù)庫之間直接進(jìn)行數(shù)據(jù)轉(zhuǎn)換，轉(zhuǎn)換效率高，但n 個(gè)異構(gòu)數(shù)據(jù)庫節(jié)點(diǎn)的雙向操作必須編寫n*（n-1）個(gè)數(shù)據(jù)轉(zhuǎn)換器。如果新增一個(gè)異構(gòu)數(shù)據(jù)庫類型，則需要開發(fā)2n 個(gè)轉(zhuǎn)換器，導(dǎo)致開發(fā)維護(hù)成本高、可擴(kuò)展性差。

Fig.1 Grammar conversion mode圖1 語法轉(zhuǎn)換模式

本文采取圖1（b）所示的中介轉(zhuǎn)換模式，即通過設(shè)計(jì)一種中間模型，為所有的數(shù)據(jù)庫指令提供統(tǒng)一的元數(shù)據(jù)描述格式，并通過轉(zhuǎn)換器實(shí)現(xiàn)從源庫數(shù)據(jù)轉(zhuǎn)換為中間模型、再由中間模型轉(zhuǎn)換為目標(biāo)庫數(shù)據(jù)的間接轉(zhuǎn)換模式。該方案僅需編寫2n 種轉(zhuǎn)換器，當(dāng)增加、修改一個(gè)數(shù)據(jù)庫存儲(chǔ)模型時(shí)，只需編寫新數(shù)據(jù)庫模型與通用模型的語法轉(zhuǎn)換器，其它同步節(jié)點(diǎn)的數(shù)據(jù)轉(zhuǎn)換模塊保持不變。該模式屏蔽了底層數(shù)據(jù)庫之間的差異，極大地降低了開發(fā)難度，并考慮了一定的擴(kuò)展性。

2.2 中間表示模型設(shè)計(jì)

中間表示模型在解析SQL 語句對(duì)數(shù)據(jù)集合的計(jì)算操作后，以結(jié)構(gòu)化形式描述SQL 各個(gè)子句語法塊。模型參考文獻(xiàn)［23-25］的設(shè)計(jì)框架，以實(shí)體（Entity）作為對(duì)所有SQL語法塊的統(tǒng)一描述，并將部分實(shí)體進(jìn)一步劃分為語句（Stmt）和表達(dá)式（Expr）。即：

Stmt 實(shí)體存儲(chǔ)SQL 語句執(zhí)行計(jì)劃的基本步驟，Expr 實(shí)體存儲(chǔ)執(zhí)行計(jì)劃的具體數(shù)據(jù)，其他實(shí)體負(fù)責(zé)對(duì)Stmt 和Expr作進(jìn)一步描述。統(tǒng)一的中間表示模型的形式化表示如下：

其中，Type 表示實(shí)體類型，Stmt 實(shí)體類型包括INSERT、SELECT、CREATE_TABLE，Expr 實(shí)體類型包括Numeric、Literal、Logical 等；Field 表示一系列實(shí)體集合，即當(dāng)前實(shí)體的所有子句類；Attribute 表示實(shí)體內(nèi)部屬性，即SQL請(qǐng)求的元數(shù)據(jù)信息；實(shí)體關(guān)系Relation∈（Entity×Entity）用于描述實(shí)體間的語義關(guān)聯(lián)，包括字符常量與數(shù)據(jù)表（Table）、數(shù)值與數(shù)據(jù)結(jié)構(gòu)（Datatype）；Map 表示此實(shí)體的映射轉(zhuǎn)換方法。

以查詢語句的From 子句為例，在標(biāo)準(zhǔn) SQL 語句中，F(xiàn)rom 子句既可以由單個(gè)引用表實(shí)體組成，又可以由多個(gè)引用表實(shí)體通過各種形式的連接（Join）構(gòu)成：

其中，tableSource 實(shí)體用于描述引用表，即參與數(shù)據(jù)查詢的關(guān)系表結(jié)構(gòu)，按連接關(guān)系分為tableSourceL和tableSourceR。joinType 是一個(gè)枚舉（Enum）屬性，代表Join連接操作類型，包括INNER_JOIN、LEFT_JOIN、RIGHT_JOIN 等。condition 是Expr 實(shí)體的子類，用于描述SQL 語句的可嵌套邏輯關(guān)系式，在fromClause 實(shí)體中用于指定tableSourceL和tableSourceR的連接條件。其形式化表示為：

其中，logicalExpr 和comparisonExpr 分別表示可嵌套的邏輯表達(dá)式與關(guān)系表達(dá)式，在SELECT、UPDATE、DELETE等操作中指定數(shù)據(jù)篩選條件，通過運(yùn)算符優(yōu)先級(jí)進(jìn)行劃分。一個(gè)logicalExpr 可以由一個(gè)comparisonExpr 組成，也可以由若干可嵌套邏輯表達(dá)式（nestedLogicalExpr）和邏輯運(yùn)算符號(hào)（AND、OR 和NOT）組合構(gòu)成，以篩選出符合指定邏輯規(guī)則的數(shù)據(jù)行。logicalExpr 的形式化表示如下：

其中，comparisonExpr 用于根據(jù)特定條件比較兩個(gè)值或列之間的大小關(guān)系以篩選數(shù)據(jù)。形式表達(dá)式如下：

其中，compOp 是關(guān)系運(yùn)算符（如=、<、>、<=、！=等）的集合，表示值或列的比較方式；unaryExpr 實(shí)體用于表示計(jì)算表達(dá)式以及對(duì)象名、變量、常量等，是SQL 標(biāo)準(zhǔn)語句中的基本參數(shù)。其形式化表示如下：

以上實(shí)體構(gòu)成了Expr 的形式化表示，其中一元表達(dá)式的value 代表整數(shù)、浮點(diǎn)數(shù)、字符串、標(biāo)識(shí)符等，用Java 包裝類型進(jìn)行存儲(chǔ)；unaryOp 是正負(fù)號(hào)、引號(hào)等常規(guī)符號(hào)的集合；dataType 表示literal存儲(chǔ)數(shù)據(jù)的數(shù)據(jù)類型。

3 面向多源異構(gòu)語法的統(tǒng)一SQL解析轉(zhuǎn)換器

面向多源異構(gòu)語法的統(tǒng)一SQL 解析轉(zhuǎn)換器參照傳統(tǒng)數(shù)據(jù)庫的編譯流程，將解析與轉(zhuǎn)換功能劃分為語法解析器、語義分析器、語法重構(gòu)器、查詢優(yōu)化器等組件，執(zhí)行流程如圖2所示。首先根據(jù)語法文件生成SQL 語法的詞法和語法分析器，組成語法解析器；然后將SQL 語句輸入對(duì)應(yīng)的語法解析器，生成抽象語法樹（Abstract Syntax Tree，AST）；接下來使用語義分析器遍歷訪問抽象語法樹，提取特征信息，封裝為中間表示模型并進(jìn)行語義分析；語法重寫器根據(jù)前臺(tái)指定的目標(biāo)庫類型，選取相應(yīng)轉(zhuǎn)化策略對(duì)中間模型進(jìn)行映射，使其轉(zhuǎn)換為能在目標(biāo)平臺(tái)執(zhí)行的邏輯執(zhí)行計(jì)劃；最后，執(zhí)行優(yōu)化器可以對(duì)邏輯執(zhí)行計(jì)劃作進(jìn)一步優(yōu)化處理，以提高可執(zhí)行性。

Fig.2 SQL parsing and conversion process圖2 SQL解析轉(zhuǎn)換流程

3.1 語法解析器

語法解析器（Syntax Parser）由ANTLR 工具生成的詞法分析器（Lexer）和語法分析器（Parser）組成，負(fù)責(zé)在語法規(guī)則的支持下，經(jīng)過詞法解析和語法解析將查詢語句編譯成AST 結(jié)構(gòu)。以SQL 語法為例［26］：詞法分析器負(fù)責(zé)分析詞法結(jié)果，即通過拆解SQL 語句將輸入的字符序列分解成詞法符號(hào)（token）序列。其中，token 是語法的基本詞匯符號(hào)，可分為5 種類型：①保留字（keyword）。由固定字符序列組成，如select、table、case 等；②標(biāo)識(shí)符（identifier）。如常量名、表名、屬性名；③文字常量（literal）。包括25、4.14、4e3等數(shù)字常量，以及“abc”“cid”字符串；④運(yùn)算符（operator）。常用的包括算術(shù)運(yùn)算符（+-*/）、關(guān)系運(yùn)算符（<，>，<=，！=）和邏輯運(yùn)算符（NOT、AND、OR）；⑤分隔符（separator）。如小括號(hào)、中括號(hào)、逗號(hào)等，負(fù)責(zé)對(duì)標(biāo)識(shí)符進(jìn)行規(guī)范。語法分析器則通過檢查token 的序列結(jié)構(gòu)是否符合語法規(guī)則，判斷語句是否合法，并把token 按照語法規(guī)則進(jìn)行模式匹配，組裝成AST 結(jié)構(gòu)。

3.2 語義分析器

語義分析是編譯過程中的一個(gè)邏輯階段，負(fù)責(zé)收集抽象語法樹標(biāo)識(shí)符的屬性信息并與節(jié)點(diǎn)綁定，審查SQL 查詢請(qǐng)求有無語義錯(cuò)誤，例如庫表、列名是否存在，列的數(shù)據(jù)類型是否正確，為邏輯計(jì)劃樹生成收集類型信息。

語義分析器（Semantic Analyzer）通過ANTLR 提供Visitor訪問模式按深度優(yōu)先順序遍歷語法分析樹，通過顯式的方法調(diào)用來獲取子節(jié)點(diǎn)信息，生成邏輯執(zhí)行樹結(jié)構(gòu)。具體算法如下：

算法1語義分析算法

算法1以深度優(yōu)先、自底向上的順序?qū)ST 進(jìn)行遍歷，將語法樹節(jié)點(diǎn)與元數(shù)據(jù)綁定，引入2.2 節(jié)建立的中間表示模型，同時(shí)結(jié)合上下文進(jìn)行語義分析。對(duì)于整數(shù)、字符串及復(fù)合表達(dá)式等Expr 實(shí)體，算法按類型判斷參數(shù)類型是否匹配、邏輯是否有歧義、是否超出變量范圍等，接著按照具體值域類型生成繼承表達(dá)式類；對(duì)于增刪改查等Stmt 實(shí)體及其內(nèi)部元素，算法先判斷是否存在重復(fù)聲明屬性、形參與實(shí)參不匹配、屬性不存在等語義錯(cuò)誤，再根據(jù)具體SQL語句類型和子句類型封裝語法塊的語義。最終邏輯執(zhí)行樹能完整描述SQL 的邏輯執(zhí)行步驟。

以查詢請(qǐng)求“SELECT * FROM people WHERE status="A" ORDER BY user_id DESC”為例，劃分SQL 各語法塊并通過分析可知：查詢實(shí)體為people 表，以status="A"為篩選條件獲取實(shí)體所有屬性，并將結(jié)果集根據(jù)user_id 列遞減排序。算法1 生成的中間表示對(duì)應(yīng)的JSON 格式化描述如下：

在語義分析與實(shí)體封裝過程中，模塊判斷people 表是否存在，以及是否存在status、user_id 等表屬性、status 屬性是否為varchar 類型數(shù)據(jù)等。此外還會(huì)檢查user_id 是否為people 表索引，若是，則在Query 語義樹中標(biāo)記其索引名為“user_id”以及對(duì)應(yīng)的索引類型。

3.3 語法重寫器

語法重寫器（Syntax Rewriter）負(fù)責(zé)接收語義分析器生成的邏輯執(zhí)行樹，若目標(biāo)數(shù)據(jù)庫為關(guān)系型數(shù)據(jù)庫，則可通過transform 轉(zhuǎn)換策略將中間表示內(nèi)部屬性、變量進(jìn)行修改，實(shí)現(xiàn)源實(shí)體entitysrc到目標(biāo)實(shí)體entitytarget的轉(zhuǎn)換。以O(shè)racle 到MySQL 的轉(zhuǎn)換為例，部分轉(zhuǎn)換策略如表1所示。

若目標(biāo)數(shù)據(jù)庫是NoSQL 類型，則將中間表示轉(zhuǎn)換為對(duì)應(yīng)的NoSQL 語法。SQL 與NoSQL 的部分對(duì)象映射關(guān)系如表2 所示。關(guān)系型數(shù)據(jù)庫的表、列、屬性和數(shù)據(jù)對(duì)象分別與NoSQL 數(shù)據(jù)庫MongoDB 的集合、文檔、字段、值等數(shù)據(jù)結(jié)構(gòu)對(duì)應(yīng)。

在分析器生成SQL 的邏輯查詢樹后，通過此映射關(guān)系將SQL 數(shù)據(jù)一一轉(zhuǎn)換為NoSQL 形式，以實(shí)現(xiàn)SQL 邏輯執(zhí)行樹的重構(gòu)。以MongoDB 為目標(biāo)對(duì)象，其轉(zhuǎn)換算法如下：

算法2模型轉(zhuǎn)換算法

3.4 查詢優(yōu)化器

若目標(biāo)數(shù)據(jù)庫是關(guān)系型，則調(diào)用查詢優(yōu)化器（Query Optimizer）對(duì)目標(biāo)SQL 請(qǐng)求進(jìn)行優(yōu)化。查詢優(yōu)化器采用基于規(guī)則的優(yōu)化（RBO）方式定義一系列優(yōu)化規(guī)則，包括列剪裁、最大最小消除、投影消除、謂詞下推、Join 消除等，優(yōu)化規(guī)則與表1 原理一致。優(yōu)化器搜索過程可視為根據(jù)指定的優(yōu)先順序循環(huán)判斷SQL 各語塊是否匹配優(yōu)化格式（Pattern），若符合則按照優(yōu)化規(guī)則（Rule）對(duì)SQL 語句進(jìn)行優(yōu)化，并重新進(jìn)入循環(huán)，直到?jīng)]有可以匹配的語塊，從而完成優(yōu)化。

以“獲得滿分成績(jī)的學(xué)生查詢”為例，常用的SQL 寫法為：SELECT * FROM Student t，Grade g WHERE t.S_id=g.S_id AND g.score=100。該Select語句對(duì)應(yīng)的關(guān)系代數(shù)為：

根據(jù)代數(shù)式可知，語句在執(zhí)行時(shí)數(shù)據(jù)庫會(huì)先全表掃描全部的Student 學(xué)生信息表和Grade 學(xué)生成績(jī)表，然后才根據(jù)where 條件進(jìn)行篩選，因而提高了查詢計(jì)算量。這種情況可以通過謂詞下推，將過濾條件表達(dá)式（如=、！=、like、in、between 等）盡量靠近待過濾的數(shù)據(jù)源（Student 表和Grade 表），即先將通過過濾條件“grade=100”篩選Grade 表中的數(shù)據(jù)，再進(jìn)行連接操作，以達(dá)到優(yōu)先過濾無用數(shù)據(jù)、提升SQL 執(zhí)行效率的目的。對(duì)應(yīng)關(guān)系代數(shù)為：

轉(zhuǎn)換成對(duì)應(yīng)語句為：SELECT * FROM Student t1 RIGHT JOIN（SELECT * FROM Grade WHERE grade=100 ）t2 ON t1.S_id=t2.S_id。轉(zhuǎn)換前和轉(zhuǎn)換后的關(guān)系表達(dá)樹如圖3所示。

Fig.3 Query optimization -predicate pushdown圖3 查詢優(yōu)化—謂詞下推

如圖3 所示，在數(shù)據(jù)庫執(zhí)行查詢操作時(shí)，邏輯執(zhí)行計(jì)劃根據(jù)關(guān)系表達(dá)樹中的操作符逐步向上計(jì)算，直到根節(jié)點(diǎn)（整個(gè)表達(dá)式）的計(jì)算完成。因此，通過謂詞下推，數(shù)據(jù)庫在內(nèi)查詢時(shí)就先過濾了Grade 表中的大部分無用數(shù)據(jù)，極大地減少了臨時(shí)表的空間開銷，提高了查詢效率。

4 實(shí)驗(yàn)與結(jié)果分析

為驗(yàn)證面向多源異構(gòu)數(shù)據(jù)庫的SQL 解析轉(zhuǎn)換器在實(shí)際開發(fā)環(huán)境中的應(yīng)用，本文基于方案實(shí)現(xiàn)了一個(gè)多源異構(gòu)數(shù)據(jù)庫的統(tǒng)一操作系統(tǒng)，旨在檢驗(yàn)解析轉(zhuǎn)換器在異構(gòu)數(shù)據(jù)庫間跨平臺(tái)訪問的可靠性、正確性和高效性。功能測(cè)試主要驗(yàn)證查詢系統(tǒng)在多源異構(gòu)、跨平臺(tái)環(huán)境下數(shù)據(jù)庫對(duì)基本操作的支持度，以及核心查詢業(yè)務(wù)的可靠性，性能測(cè)試主要驗(yàn)證解析轉(zhuǎn)換器基本增刪改查操作的性能。

4.1 環(huán)境配置

操作系統(tǒng)以Java 編程平臺(tái)作為運(yùn)行平臺(tái)，分別使用Oracle、MySQL 和MongoDB 存儲(chǔ)關(guān)系型和非關(guān)系型數(shù)據(jù)，并基于TPC-H 基準(zhǔn)測(cè)試數(shù)據(jù)集進(jìn)行功能測(cè)試和性能測(cè)試，實(shí)驗(yàn)中針對(duì)不同測(cè)試單元對(duì)數(shù)據(jù)集進(jìn)行相應(yīng)處理。具體實(shí)驗(yàn)環(huán)境參數(shù)如表3所示。

Table 3 Environmental configuration table表3 環(huán)境配置表

4.2 功能測(cè)試

4.2.1 數(shù)據(jù)類型支持度

為測(cè)試本系統(tǒng)對(duì)各結(jié)構(gòu)化、半結(jié)構(gòu)化數(shù)據(jù)的支持度，先導(dǎo)入完整的包含各種類型的測(cè)試數(shù)據(jù)集（所有數(shù)據(jù)均不包含NULL 和NAN 值）。為維護(hù)執(zhí)行效率，各底層庫隨機(jī)導(dǎo)入數(shù)據(jù)集數(shù)據(jù)1萬條，再使用簡(jiǎn)單的query操作語句對(duì)數(shù)值型、字符型和時(shí)間日期型數(shù)據(jù)進(jìn)行查詢與解析，檢驗(yàn)最終的返回結(jié)果是否與映射表相符，以及是否存在非法值或缺失。其中，數(shù)據(jù)類型映射基于SQLines 技術(shù)文檔（Oracle映射至MySQL 類型映射表：http：//www.sqlines.com/oracleto-mysql）進(jìn)行整合，部分映射如表4所示。

Table 4 Data types mapping表4 數(shù)據(jù)類型映射

經(jīng)自定義函數(shù)對(duì)查詢結(jié)果進(jìn)行數(shù)據(jù)統(tǒng)計(jì)和異常值檢驗(yàn)，最終的實(shí)驗(yàn)結(jié)果表明，系統(tǒng)支持對(duì)所有已集成數(shù)據(jù)庫的數(shù)據(jù)類型進(jìn)行解析、存儲(chǔ)和映射轉(zhuǎn)換。

4.2.2 操作類型支持度

本系統(tǒng)已集成的數(shù)據(jù)庫有Oracle、MySQL 和MongoDB，本節(jié)測(cè)試其對(duì)于SQL 各種操作類型的支持度。實(shí)驗(yàn)涉及的SQL 語句主要面向與具體數(shù)據(jù)操作相關(guān)的環(huán)境，所以在實(shí)驗(yàn)論證中只對(duì)關(guān)系型數(shù)據(jù)庫的部分DDL 語句和DML 語句，以及NoSQL 的標(biāo)準(zhǔn)CURD 語句進(jìn)行實(shí)驗(yàn)驗(yàn)證。實(shí)驗(yàn)分別在Oracle、MySQL 及MongoDB 數(shù)據(jù)庫創(chuàng)建相應(yīng)的數(shù)據(jù)集，并對(duì)多源異構(gòu)數(shù)據(jù)執(zhí)行增刪改查操作。實(shí)驗(yàn)結(jié)果如表5所示。

Table 5 Support for SQL statement表5 對(duì)SQL語句類型支持情況

其中，NoSQL 的CURD 操作對(duì)應(yīng)關(guān)系型數(shù)據(jù)庫的DML語句。MongoDB 的數(shù)據(jù)存儲(chǔ)類型是BSON 文檔，可以通過insert（）、update（）、delete（）方法動(dòng)態(tài)指定集合（Collection）、文檔（Document）內(nèi)部field 的數(shù)據(jù)類型。因此，MongoDB 對(duì)數(shù)據(jù)存儲(chǔ)對(duì)象的DDL 操作不納入測(cè)試。由表5 可知，解析轉(zhuǎn)換器支持所有常見關(guān)系型數(shù)據(jù)庫之間的DDL 與DML 互操作，以及關(guān)系型與NoSQL 的CURD 互操作。

4.3 性能測(cè)試

性能測(cè)試通過將系統(tǒng)與官方的mongo-jdbc 插入、刪除、更新和選擇操作的時(shí)間開銷進(jìn)行對(duì)比，以評(píng)估多源異構(gòu)解析轉(zhuǎn)換器的SQL 覆蓋率和各項(xiàng)訪問操作的性能。為有效評(píng)估解析轉(zhuǎn)換器的跨平臺(tái)訪問性能，本節(jié)引入MongoDB 官方推出的mongo-jdbc 驅(qū)動(dòng)插件，使用SQL 對(duì)MongoDB 進(jìn)行異構(gòu)訪問，分別讓MongoDB 數(shù)據(jù)庫、mongo-jdbc和測(cè)試系統(tǒng)執(zhí)行1 000 次INSERT、UPDATE、DELETE 與SELECT 操作，測(cè)試結(jié)果如表6 所示。其中，每個(gè)操作對(duì)應(yīng)的執(zhí)行時(shí)間為執(zhí)行的平均時(shí)間，單位為毫秒（ms）。

Table 6 Comparison of CURD performance testing表6 CURD性能測(cè)試結(jié)果對(duì)比

實(shí)驗(yàn)數(shù)據(jù)表明，查詢系統(tǒng)在CURD 操作方面的總體性能優(yōu)于mongo-jdbc。在同等條件下，測(cè)試系統(tǒng)執(zhí)行CURD操作的響應(yīng)時(shí)間較官方工具分別快了13.1 ms、8.8 ms、22.5 ms 與2.3 ms。其中，由于INSERT 操作的平均單次響應(yīng)時(shí)間較短，因此延遲率高，但平均響應(yīng)時(shí)間僅為mongojdbc 的49%。在SELECT 查詢操作上，系統(tǒng)較官方驅(qū)動(dòng)程序平均僅快2.3 ms，沒有明顯優(yōu)勢(shì)，主要由于相較于增刪改操作，查詢樣例涉及嵌套查詢、連接表、過濾條件式等復(fù)雜的query 業(yè)務(wù)，在解析優(yōu)化和底層執(zhí)行方面開銷更多，因此平均執(zhí)行和響應(yīng)時(shí)間更長(zhǎng)。

以上結(jié)果表明，面向多源異構(gòu)數(shù)據(jù)庫的SQL 解析轉(zhuǎn)換器相較于mongo-jdbc 有著更優(yōu)異的性能，且其運(yùn)算成本始終保持在一個(gè)固定范圍內(nèi)，與操作類型無關(guān)。實(shí)驗(yàn)結(jié)果證明，面向多源異構(gòu)數(shù)據(jù)庫的SQL 解析轉(zhuǎn)換器在功能和性能方面可滿足預(yù)期需求，有效實(shí)現(xiàn)了對(duì)多個(gè)異構(gòu)數(shù)據(jù)庫的集成操作，且能保證一定的正確性。

5 結(jié)語

本文提出一種滿足跨平臺(tái)統(tǒng)一查詢需求的SQL 解析和轉(zhuǎn)換方法，詳細(xì)設(shè)計(jì)了一系列查詢語言的適配存儲(chǔ)結(jié)構(gòu)和語義一致性轉(zhuǎn)換及性能優(yōu)化策略，允許用戶在異構(gòu)關(guān)系數(shù)據(jù)庫和NoSQL 數(shù)據(jù)庫上進(jìn)行準(zhǔn)確、可靠的SQL 操作，屏蔽了不同執(zhí)行平臺(tái)間在語法邏輯、底層機(jī)制方面的差異，將多個(gè)異構(gòu)數(shù)據(jù)庫轉(zhuǎn)換為一個(gè)統(tǒng)一的模式，并通過設(shè)計(jì)測(cè)試系統(tǒng)進(jìn)行功能和性能驗(yàn)證，證明了解析轉(zhuǎn)換器的可行性。實(shí)驗(yàn)結(jié)果表明，面向多源異構(gòu)數(shù)據(jù)庫的SQL 解析和轉(zhuǎn)換方法在滿足多源異構(gòu)數(shù)據(jù)庫跨平臺(tái)訪問功能需求的同時(shí)，還具有較好性能，且在集成系統(tǒng)的多對(duì)多數(shù)據(jù)訪問環(huán)境下具有良好的可擴(kuò)展性和準(zhǔn)確性。

由于條件和時(shí)間限制，本文仍有諸多不足，有待進(jìn)一步研究和改進(jìn)，主要改進(jìn)方向有：①增加對(duì)更多異構(gòu)數(shù)據(jù)庫的適配訪問和操作業(yè)務(wù)支持。目前跨平臺(tái)解析轉(zhuǎn)換方案僅實(shí)現(xiàn)了對(duì)Oracle、MySQL 和MongoDB 等若干數(shù)據(jù)庫的支持，對(duì)數(shù)據(jù)和事務(wù)的一致性支持尚不夠全面，難以支持復(fù)雜的業(yè)務(wù)操作；②提升跨平臺(tái)解析轉(zhuǎn)換方案面對(duì)真實(shí)海量數(shù)據(jù)處理業(yè)務(wù)的性能。實(shí)驗(yàn)的測(cè)試數(shù)據(jù)在數(shù)據(jù)規(guī)模和復(fù)雜度上與真實(shí)業(yè)務(wù)差距較大，需要將方案置于接近真實(shí)海量數(shù)據(jù)環(huán)境中進(jìn)行測(cè)試與改進(jìn)；③進(jìn)一步完善跨平臺(tái)執(zhí)行優(yōu)化模塊。目前優(yōu)化器主要基于傳統(tǒng)經(jīng)驗(yàn)編寫一系列靜態(tài)策略以實(shí)現(xiàn)查詢優(yōu)化，在開發(fā)和使用效率上具有局限性，可以引入基于代價(jià)的優(yōu)化（CBO）算法，獲得所有等價(jià)的重構(gòu)變換方案，進(jìn)一步提升查詢性能。