文檔-關系數據查詢執行技術研究與實現*

馬志程，袁海峰，谷 洋，劉亞茹，張 孝+

1.國網甘肅省電力公司電力科學研究院，蘭州 730070

2.數據工程與知識工程教育部重點實驗室（中國人民大學），北京 100872

3.中國人民大學 信息學院，北京 100872

1 引言

近年來，數據已經滲透到當今每一個行業和業務職能領域，成為重要的生產因素。人們對于海量數據的挖掘和運用，預示著新一波生產率增長和消費者盈余浪潮的到來[1]。關系數據庫是數據管理中不可或缺的技術，尤其在涉及到用戶、財物等需要精細管理的應用領域時，更是具有不可替代的地位[2]。但是傳統的關系型數據庫在大數據背景下存在一些技術缺陷，尤其是在速度、存儲量以及多樣化結構數據的處理問題上存在一些短板。目前的大數據應用中包含的數據類型是多種多樣的，既可以是結構化的關系數據與圖數據等，還可以是JSON（Javascript object notation）、XML（extensible markup language）等半結構化數據，甚至是網頁、視頻等非結構化的數據[3]。數據模型是一個數據管理系統的核心，純關系模型已經無法靈活地管理多種類型的數據。其次，在包含大量節點的集群中，高速處理海量數據也是一個難點。再次，在關系數據庫上無法完成對數據的復雜分析[4]。

進入大數據時代之后，已經無法使用某種單一的數據庫管理系統來完成所有應用的數據管理。和關系數據庫不同的是，文檔數據庫往往是把某個對象的所有信息全部存儲在一個集合中，并且集合中的每個對象的內部結構無需完全相同，這種設計思想極大地簡化了從外部對象到數據庫對象的映射處理[5]。NoSQL（not only structured query language）數據庫目前處于百花齊放的狀態，由于存儲模式的不同，也沒有提供統一的查詢語言，也因此導致了NoSQL 數據庫沒有統一的數據訪問接口[6]。需要一種更加開放的數據庫管理系統。將具有豐富多樣的數據類型的數據在同一個數據管理系統中進行存儲、組織與管理。這也就意味著單一的數據庫引擎必定無法完成數據的統一訪問，需要能夠容納與支持多種數據模型的處理引擎并存于系統中。在異構數據的自適應存儲前提下（即不同結構的數據可能被獨立存儲在不同的數據庫中，或者為了更好地服務于查詢，同樣語義的數據被冗余地存儲于不同結構的數據庫中），如何基于關系數據庫的架構融入NoSQL數據庫引擎，怎樣面對用戶定義的操作，如何針對不同引擎的查詢特點來實現跨引擎的查詢以及如何處理大數據管理系統中的查詢表達與查詢優化并提高查詢性能，是構建能容納和支持多種不同結構數據處理引擎并存的大數據管理系統需要考慮的重點問題。

基于以上的研究背景，啟動了將關系型數據庫和NoSQL數據庫進行集成的通用性大數據管理平臺DataCloud 項目的研究設計。本文的研究是Data-Cloud 大數據管理平臺的一個子課題。本文研究了關系型數據庫和NoSQL文檔數據庫融合的查詢處理技術，實現了一個執行引擎ENTIA，將支持結構化數據和半結構化數據的兩種不同的數據庫引擎集成在同一大數據管理系統中，提供統一的訪問接口，來完成混合引擎的查詢處理，并基于啟發式規則完成部分查詢優化功能，為構建支持多種數據模型的通用性大數據管理系統奠定基礎。

此外，本文的研究內容也對解決實際工程中的問題，提高開發效率具有很重要的意義。由于NoSQL數據庫采用非規范統一的存儲方式，即一種數據庫只服務于一種數據庫類型，導致截至目前仍然沒有統一的查詢表達來訪問所有的NoSQL數據庫。在實際的項目開發中，當需要同時訪問關系數據庫和NoSQL 數據庫時，往往需要程序員針對不同的數據庫引擎分別創建連接，用相應的數據庫引擎定義的查詢語言給出查詢請求，在獲取各個處理引擎返回的查詢結果之后，再以代碼的方式手工合并各部分結果從而完成整體的功能需求。這種處理方式不僅要求程序員需要掌握多種數據庫的查詢語言，還增加了研發的工作量，降低了開發效率。此外，無法充分基于數據、查詢與數據庫引擎本身的特性來對整體查詢做進一步的優化。

本文的主要貢獻如下：

（1）系統地介紹了執行引擎ENTIA 的整體架構與設計實現。ENTIA包含四大模塊：查詢解析模塊、查詢優化模塊、查詢翻譯模塊和查詢執行模塊。并具體地闡述了各個模塊的功能與實現原理。

（2）提供了統一的數據訪問接口。設計了全局視圖來屏蔽底層數據的結構類型與物理存儲的位置，并基于此定義查詢語言，使得用戶仍然采用熟悉的SQL（structured query language）來完成包含一種或多種存儲引擎、多種數據模型的混合查詢，大大提高了開發效率。

（3）基于啟發式規則進行查詢優化。在數據冗余存儲的前提下，將原查詢分解成若干子查詢，進而把計算推向合適的存儲引擎，充分利用各數據庫引擎的查詢優勢，從而提高整體查詢的性能。

（4）進行充分的實驗，并對實驗結果進行分析。通過實驗證明：與傳統方案對比，多引擎、多數據模型下的混合查詢在保證查詢結果正確的前提下，不降低查詢性能，證明了方法的正確性；與任一單獨數據庫的查詢性能進行對比，表明了優化方法對數據庫性能提升的有效性。

2 相關工作

異構數據庫集成的研究初期是以外部數據的管理開始的。Melton 等提出了一種稱為SQL/MED 的架構設計[7]。MED 的含義是Management of External Data。SQL/MED 提供了對SQL 語法的擴展，以及一組用于開發和管理訪問SQL 數據和NoSQL（也稱為外部）數據的應用程序的例程。SQL/MED 可以分為兩大部分。第一部分稱為包裝接口（wrapper inter-face），提供了可以查看由一個或多個外部服務器上外部數據的功能。外部數據可以存儲在文件系統、HTML 格式的網頁、XML 文檔或其他一些專門的存儲庫中[8-9]。SQL/MED 的第二部分稱為數據鏈（data-links），它提供了一些工具，使一個SQL Server能夠控制對駐留在一個或多個文件系統中的數據的引用完整性、恢復和授權的管理。

Tatemura等給出了一個原型系統Partiqle[10]，它將SQL引擎集成在基于鍵值存儲NoSQL數據庫HBase之上，以達到支持關系數據庫中的OLTP（on-line transaction process）特性的目的。在這個原型系統中，重點研究了如何將關系數據庫中的事務引入到HBase 中。Partiqle系統定義了一種“事務類”的聲明規范，來約束工作負載中的事務。給定一個SPJ（select-project-join）查詢，系統的編譯模塊會基于鍵值存儲的查詢優化器之上產生一個新的執行計劃。執行引擎和事務管理器會以一種樂觀的并發控制方式來執行此查詢計劃。所謂樂觀的并發控制方式就是，系統會緩沖寫操作，來提交HBase中的check-and-put的原子操作[10]。

Vila?a 等針對NoSQL 數據庫中的查詢需要手工編寫的缺陷[11]，在HBase 基礎之上集成了SQL 的引擎。在保留了NoSQL數據庫的高可擴展性與模式靈活性的前提下，融入了SQL 查詢，為NoSQL 數據庫增加了原來所不能支持的一些操作符，比如join等[12]。文中采用的方法是重寫關系數據庫的內部架構，在保留一部分原來組件的基礎之上，增加了NoSQL 數據庫的部分組件。查詢處理器將以SQL表達的訪問請求進行翻譯、編譯和執行，同時包括底層存儲的數據類型、存儲模式、索引以及各類操作符的一系列轉換，最終完成數據查詢[13]。該研究中采用了開源、輕量級用Java 編寫的Apache Derby 數據庫和HBase 來作為NoSQL數據庫[11]。

無論是同構數據庫的集成還是異構數據庫的集成，數據模式都是非常核心與具有挑戰性的研究工作。Mason等在研究如何集成同構數據庫時提出了一種基于“注解”的方法來動態地生成全局語義視圖[14]。“注解”方法將復雜的語義識別任務轉移到局部注釋器而不是全局集成器，從而消除了全局視圖構建的瓶頸。這使得集成更加自動化、可擴展和可快速部署。數據源管理員使用有意義的名稱（可能使用本體）對架構進行注釋，并在XML文檔中導出具有注釋的架構設計。系統會加載每個單獨的注釋，匹配注釋中的名稱以生成集成視圖，然后標識用于跨數據庫連接全局鍵，最終得到一份數據模式的全局視圖[15]。

3 查詢引擎的實現

本章將系統闡述基于關系型數據庫PostgreSQL和NoSQL 數據庫MongoDB 所實現的執行引擎ENTIA 的架構設計，分析各個關鍵模塊的功能與實現細節。并以具體實例介紹如何通過該引擎來完成異構數據庫的混合查詢。

3.1 ENTIA的系統架構

ENTIA 主要用于解決在集成關系數據庫與NoSQL數據庫的系統中的查詢處理問題。該引擎包含查詢解析、查詢優化、查詢重寫和查詢執行四個模塊，其系統架構如圖1所示。

Fig.1 Architecture diagram of ENTIA system圖1 ENTIA系統架構圖

從圖1 中可以看到，不同的客戶端應用通過ENTIA提供的統一訪問接口來向服務器發出查詢請求。查詢解析模塊與元數據模塊協作完成查詢請求的解析工作，其中元數據模塊存儲著多源異構數據庫的數據模式的全局視圖，查詢解析后的結果以Java對象的形式來表示。查詢優化模塊基于解析后的結果與元數據信息給出執行效率最高的查詢計劃。根據優化器給出的查詢計劃，查詢翻譯模塊會將原本的查詢進行翻譯，即以SQL 表達的查詢請求轉換為該查詢計劃中所參與的各個數據庫引擎所能識別接受的查詢語言，最終給出與用戶原查詢等價的查詢任務列表。查詢執行模塊負責接收所有查詢任務，并給出最終的查詢結果。查詢執行器集成了不同數據庫引擎的訪問驅動，它既可訪問關系數據庫，又可訪問NoSQL數據庫。查詢執行器將查詢任務進行分發，不同數據庫引擎執行各自查詢任務，各數據庫引擎完成查詢后，將查詢結果全部返回給查詢執行器，查詢執行器完成全局的連接工作，得到最終的查詢結果，返回給客戶端。

從ENTIA 的架構中能夠看出，該引擎主要從三方面來實現跨引擎的混合查詢：首先，查詢執行模塊向上提供了統一的數據訪問接口，從而屏蔽了存儲層數據存儲的不一致。一份完整的數據既可部分存儲在關系數據庫，部分存儲在NoSQL數據庫，也可以不同的結構冗余存儲在多種數據庫中。無論采用怎樣的存儲策略，向上的訪問接口是一致的。其次，混合查詢使用全局數據模式和統一的查詢優化器來保證查詢的正確性和性能。再次，向客戶端提供統一的查詢語言，在查詢表達層做到了統一和規范。

3.2 全局視圖設計

全局視圖的設計主要是為了解決底層各個數據庫引擎存儲模式之間的差異問題。

全局視圖中，每一個數據元素都有兩個名稱：一個是該數據元素的“原始名稱”；另一個是該數據元素在全局視圖下的“語義名稱”。“語義名稱”并不具有唯一性，不同的數據元素可能具有相同的“語義名稱”。針對“表”或者“集合”，全局視圖會給出“語義名稱”“數據源”“數據庫”“數據域”“主鍵”“外鍵”共六個屬性。“數據源”為該表或集合的存儲引擎。“數據庫”為該表或集合所屬的數據庫名稱。“數據域”為該表所包含的字段或屬性。主、外鍵屬性用來完成多表之間的連接操作。針對數據庫元素中的“字段”或者“屬性”，全局視圖會給出“字段名稱”“語義名稱”和“數據類型”三個屬性。全局視圖由數據庫管理員生成，以JSON文件的形式保存在系統中。當系統中任意一個數據庫引擎的數據模式發生變化時，需要更新JSON 文件來保持全局視圖與各個數據庫引擎之間的同步。ENTIA系統中的全局視圖設計示例如下所示：

3.3 查詢語言設計

本文中的研究內容暫時只支持數據查詢語言（data query language，DQL）[16-17]。由于MongoDB 中沒有數據模式的概念，ENTIA 所支持的SQL 是基于全局視圖中的語義名稱來構成。其基本語法如下：

SELECT[ALL|DISTINCT]<全局視圖-目標列表達式>[,<全局視圖-目標列表達式>]……

FROM<全局視圖-表名>[,<全局視圖-表名>]……

[WHERE <條件表達式>]

[GROUP BY<全局視圖-列名1>[HAVING<條件表達式>]]

[ORDER BY<全局視圖-列名2>[ASC|DESC]]

3.4 查詢實例

本節按照查詢處理的順序來介紹ENTIA對用戶的訪問請求的處理流程。以查詢Q3.1為例：

其中，字段name、stars 存儲在PostgreSQL 中，屬性attribute存儲在MongoDB中。

ENTIA 收到查詢之后，首先會基于JSqlParser 對查詢進行解析，生成一個代表該SQL 查詢的Java 對象ParseNode。

針對Q3.1，ENTIA 的查詢優化模塊給出的邏輯查詢計劃如圖2所示。

Fig.2 Logical plan query diagram of Q3.1圖2 Q3.1邏輯計劃查詢圖

4 查詢優化

4.1 查詢優化概述

在跨引擎的混合查詢中，如何將計算任務合理地分配到每一個數據源直接決定了結果的正確性與查詢效率。本節中的查詢優化的目標就是基于優化規則，把數據推向合適的計算引擎，將查詢任務盡量下推到各個數據庫引擎，而針對分離后的查詢子任務的更為具體的查詢計劃則是由各個數據庫引擎給出。查詢優化的策略是由用戶查詢的特點與數據的存儲情況所共同決定的。

在混合存儲引擎系統中，數據的存儲情況在字段的粒度上可分為冗余存儲與非冗余存儲兩種情況。非冗余存儲是指，字段被唯一地存儲于眾多數據庫引擎當中的某一個數據庫引擎中，該字段的數據僅此一份。冗余存儲是指，字段在至少兩個甚至多個數據庫引擎中都有所存儲，該字段擁有多份不同結構類型的數據，雖然存儲形式不同，但所表達的語義相同。

用戶的查詢特點是查詢優化中優化策略的另一決定因素。經前期實驗測試：與PostgreSQL 相比，MongoDB在聚合操作與選擇全表掃描策略時的字段投影操作具有明顯的查詢優勢，而在表連接的操作上，性能遠不如PostgreSQL。此外，數據查詢語言DQL中，不相關子查詢是較為具有代表性、更容易解析與判斷的復雜查詢。因此基于前期的實驗結論，當用戶的查詢中具備上述特點時，ENTIA 可對此類查詢進行優化。

圖3 是ENTIA 查詢優化模塊的工作流程圖。目前ENTIA能夠優化的查詢為包含聚合操作或者全表掃描操作的不相關子查詢。ENTIA根據查詢解析之后的ParseNode以及數據存儲的元信息進行判斷：用戶查詢的所有數據是否冗余存儲，若非冗余存儲，則進一步判斷當前查詢是否為跨引擎查詢。若數據全部存儲在某一引擎中，顯然該查詢會被完整地在該引擎中完成，若查詢是跨引擎的混合查詢，查詢模塊將分離原查詢中各個操作符，使得各引擎單獨完成分解之后的查詢，并保證各部分查詢之后返回的結果與用戶的原請求查詢等價。當查詢數據被冗余存儲在不同結構的數據庫引擎中時，需要進一步判斷是否為可優化的查詢。若不滿足可優化規則，則ENTIA統一將查詢交由PostgreSQL來完成。若滿足優化規則，再根據查詢中是否包含聚合操作，或者全表掃描操作來選擇對應的規則進行優化。

4.2 優化規則

4.2.1 聚合操作規則

規則1（聚合操作規則）由于MongoDB 中聚合操作采用管道流水線來處理管道中的一個個功能節點，大大提高了聚合操作的效率，其性能遠遠高于PostgreSQL。因此，聚合操作優化規則是指當查詢符合以下形式時：

即，如果整體查詢為不相關子查詢，并且子查詢中包含聚合操作，那么該查詢會被分解成兩個子任務：子查詢被重寫為MongoDB 查詢，外層查詢仍然由PostgreSQL 執行，兩個子任務并行執行，兩數據庫引擎返回各自查詢結果，最后連接兩部分查詢結果得到用戶原查詢的結果。其中，含有聚合操作的子查詢重寫為MongoDB查詢的方式為：

Fig.3 Query optimization workflow of ENTIA圖3 ENTIA查詢優化的工作流程圖

聚合操作優化規則的偽代碼如算法1所示。

算法1聚合操作優化規則

輸入：參數1，形式為包含聚合操作的不相關子查詢；參數2，保存全局視圖的JSON文件的路徑。

輸出：重寫后的PostgreSQL查詢和MongoDB查詢。

4.2.2 全表掃描規則

經過前期的實驗測試，當查詢請求的執行計劃為全表掃描時，MongoDB 的查詢速度要遠遠快于PostgreSQL 的查詢速度。因為在MongoDB 中，當數據庫啟動時，會將磁盤的數據加載到內存中，充分利用系統的內存資源，磁盤的I/O效率與內存的查詢導致兩者查詢速度的差異自然十分明顯。全表掃描優化規則是指，當查詢符合以下形式時：

即整體查詢為不相關子查詢，子查詢的查詢計劃是全表掃描操作時，該查詢可被進一步優化，原查詢被拆解成兩部分執行，子查詢被重寫為MongoDB 的查詢，外層查詢仍然交給PostgreSQL來執行，兩引擎并行執行各自的查詢任務，最后將返回的兩部分查詢結果連接起來完成原來的查詢任務。其中子查詢被重寫為MongoDB的查詢的形式為：

在MongoDB 中查詢條件是由多個鍵值對的形式來表達的，將多個查詢條件組合在一起，即完成了“條件1 AND 條件2 OR 條件3”的表達。鍵為列名、值為1的形式用來表示此列被投影出來，與SQL中的project語義相同。另外，在對當前查詢判斷是否符合全表掃描優化規則時，在程序中需要基于EXPLAIN SQL 來獲取該子查詢的查詢計劃，再進一步判斷是否由全表掃描操作完成。全表操作優化規則的偽代碼與算法1類似。

5 實驗分析

5.1 實驗說明

5.1.1 實驗環境

實驗在普通PC 機上進行，基本的硬件配置如表1所示。

Table 1 Hardware configuration表1 硬件配置

5.1.2 實驗數據集

本實驗所使用的數據集是美國最大的點評網站Yelp 所公開的內部數據集。該數據集的內容是Yelp所涵蓋的商家數據、用戶數據和點評數據的一個子集。目前Yelp 提供了這個數據集的JSON 文件。該數據集被廣泛用于自然語言處理和情感分析、數據庫、圖像挖掘等領域。本文將該數據集的JSON格式數據存儲于MongoDB 中，共有business、user 和rev-iew三個集合。利用該JSON文件生成結構化的關系數據，存儲于PostgreSQL 數據庫中。三個集合（表）的數據量分別為20 萬條、150 萬條、600 萬條記錄。為進一步測試，根據原有數據，為每一個集合（表）又進一步生成了兩倍數據和四倍數據。

5.2 前期實驗

本節介紹優化規則設定的前期實驗，證明優化規則設定的合理性。本節的實驗從單字段查詢、表連接查詢、聚合操作查詢三方面，對比關系數據庫PostgreSQL 和文檔數據庫MongoDB 在簡單查詢上的查詢性能。

（1）單字段查詢

單字段查詢從整型、字符型、日期型、JSON 字符串類型四種數據類型測試。測試所使用的查詢實例如下：

PostgreSQL 與MongoDB 在以上查詢上的時間消耗與對比分別如表2 和圖4 所示。在單字段上的簡單查詢以及聚合操作上，MongoDB 的性能遠高于PostgreSQL，但是當涉及到表連接操作時，哪怕是簡單的兩表連接，PostgreSQL的查詢性能遠高于Mongo-DB的查詢性能。

Table 2 Simple query time consumption of PostgreSQL and MongoDB表2 PostgreSQL 與MongoDB 簡單查詢時間消耗

Fig.4 Comparison of simple query time between PostgreSQL and MongoDB圖4 PostgreSQL 與MongoDB 簡單查詢時間對比

5.3 功能符合型測試

本實驗的目的是測試執行引擎ENTIA對既涉及MongoDB 又涉及PostgreSQL 的混合查詢的查詢處理的正確性，通過與傳統方法的查詢結果與查詢時間對比，證明ENTIA 對跨引擎查詢處理的可行性。本實驗中采取的查詢實例為查詢Q3.1。針對Q3.1，傳統的解決思路是，程序員手動分別寫出PostgreSQL與MongoDB 兩個查詢，分別向兩個數據庫引擎發送查詢請求，獲取兩部分查詢結果之后，再手動連接兩部分結果，得到最終的查詢結果。

將查詢Q3.1訪問的表business以及集合business的元組（文檔）數量N分別設為20萬、40萬、80萬組，對ENTIA 的執行情況與傳統思路各測試10 次，記錄時間（單位為ms），并取平均值。ENTIA 與傳統方法分別使用ENTIA-U 與TRAN-U 表示，其查詢時間對比如表3所示。

Table 3 Query time comparison between ENTIA and traditional method表3 ENTIA與傳統方法查詢時間對比

從表3中可以看出，兩種方法的查詢時間幾乎相同。ENTIA由于要將混合查詢進行解析、重寫，進而再分發給相應的數據庫引擎查詢，因此在查詢時間上要略大于傳統思路的查詢時間，兩種方法性能差在0.15%左右，在可接受范圍之內。但是ENTIA大大提高了程序開發效率，降低了程序員對數據庫能力的要求，通過訪問ENTIA的接口即可完成跨引擎查詢。

5.4 性能測試

本實驗的目的是測試可優化查詢在PostgreSQL、MongoDB以及本文提出的基于啟發式規則的優化方法的查詢時間，對比三種方法的性能，驗證兩種優化方法的正確性和效果。

將上述查詢實例訪問的表（集合）business、user和review 的元組（文檔）數量N分別設為（20 萬、150萬、600萬）、（40萬、300萬、1 200萬）、（80萬、600萬、2 400 萬）三組數據，對PostgreSQL、MongoDB、ENTIA 的執行情況各測試十次，記錄時間（單位為ms），并取平均值。基于聚合操作優化規則的性能對比結果如表4所示，基于全表掃描優化規則的性能對比結果如表5所示。

Table 4 Performance comparison based on aggregation operation optimization rules表4 基于聚合操作優化規則的性能對比結果

Table 5 Performance comparison based on full table scan optimization rules表5 基于全表掃描優化規則的性能對比結果

圖5為基于聚合操作優化規則下，可優化查詢在三種引擎中的查詢性能對比圖。從圖5中可以看出，每個數量級下ENTIA的執行均具有明顯的優勢。其次，由于MongoDB 在聚合操作上的查詢性能較高，每個數量級下MongoDB 的查詢時間均少于Post-greSQL 中的查詢時間。重寫后的查詢，充分利用MongoDB 聚合操作的查詢優勢，各引擎并行執行查詢任務，大大提高了查詢效率。

Fig.5 Performance comparison graph based on aggregation operation optimization rules圖5 基于聚合操作優化規則的性能對比圖

圖6為基于聚合操作優化規則下，ENTIA相對于PostgreSQL和MongoDB性能提升的趨勢圖。從圖6中可以看出，隨著數據量的增大，性能提升的效果越來越明顯。ENTIA使PostgreSQL避免了執行聚合操作，使MongoDB避免了執行NoSQL數據庫所不擅長的連接操作。隨著數據量的增大，對于包含聚合操作的不相關子查詢而言，聚合操作所耗費的時間要遠遠大于連接查詢所耗費的時間，也因此，ENTIA相對于兩種數據庫引擎而言，性能提升越來越明顯，且相對PostgreSQL的性能提升要高于相對于MongoDB的性能提升。

Fig.6 Performance improvement trend graph based on aggregation operation optimization rules圖6 基于聚合操作優化規則的性能提升趨勢圖

Fig.7 Performance comparison graph based on full table scan optimization rules圖7 基于全表掃描優化規則的性能對比圖

圖7為基于全表掃描優化規則下，可優化查詢在三種引擎中的查詢性能對比圖。從圖7中可以看出，每個數量級下ENTIA的執行均具有明顯的優勢。分析可優化查詢的查詢計劃，時間耗費為子查詢中的全表掃描操作和兩表的Join 操作。當執行計劃為全表掃描時，其MongoDB 的查詢速度遠遠快于在PostgreSQL 中的查詢速度。因此，將子查詢重寫為MongoDB的查詢，大大提高了整個查詢的速度。

圖8為基于全表掃描優化規則下，ENTIA相對于PostgreSQL和MongoDB性能提升的趨勢圖。從圖8中可以看出，隨著數據量的增大，性能提升效果越來越明顯。ENTIA 避免了執行MongoDB 所不擅長的連接操作與PostgreSQL在大數據量下的全表掃描操作。由于表與表之間的連接操作所耗費的時間性能的因素比單字段查詢所耗費的時間性能因素更加明顯，導致ENTIA相對MongoDB的性能提升要高于相對于PostgreSQL的性能提升。

Fig.8 Performance improvement trend graph based on full table scan optimization rules圖8 基于全表掃描優化規則的性能提升趨勢圖

6 結束語

本文基于關系數據庫PostgreSQL和文檔數據庫MongoDB 對查詢處理進行探索研究，實現執行引擎ENTIA，給出了混合查詢的查詢處理，并基于啟發式規則對混合引擎進行查詢優化，提高了查詢效率。在未來的研究工作中，希望進行擴展，加入更多NoSQL數據庫，使系統支持更加豐富的數據類型。

致謝本文工作得到國家電網有限公司科技項目（合同號：SGGSKY00FJJS1900296）的部分支持，也得到了中國人民大學信息技術與管理國家級實驗教學示范中心的部分支持。感謝審稿專家們的寶貴修改意見和建議，同時感謝中國人民大學數據工程與知識工程教育部重點實驗室人大行云云平臺為本論文項目提供的實驗環境。