查詢感知的關系-圖數據庫自適應存儲技術研究

張 孝 ，孫一銘 ，吳旭峰

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

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

1 引言

近年來，社會上的數據量以指數級的增長速度在增長。根據IDC于2018年時的報告[1]上預測，中國的總數據量預計將達到8 060 EB，占到全球數據總量的18%。大數據時代，數據規模的不斷發展給人們帶來了諸多機遇，同時在技術上帶來了更多的挑戰。圖數據是具有節點或者邊標簽等圖結構特點的數據，并且可能附加信息與圖形相關聯。其特點主要在于數據集規模巨大，數據本身結構類型多變，應用場景豐富，使得用戶會在不同場景下有著不同的查詢操作需求。如何高效、智能地管理圖數據如今正在被廣泛研究。目前主流的單數據模型引擎對于圖數據的管理都只能提供部分應用場景上的高效查詢性能。多數據引擎協同存儲圖數據，可以在整個數據管理平臺中實現犧牲部分存儲成本，大大提高數據管理系統的查詢性能。同時提出的查詢感知的存儲優化算法，為這種存儲模式節省出更多的存儲成本。

在眾多的不同的數據模型中，關系數據模型一直自20 世紀80 年代就處于一個強勢統治地位，出現了以MySQL、Oracle 等為代表的關系數據庫管理系統[2]。但涉及到圖數據管理存儲時，由于當時的數據建模中的一些缺陷與問題，使得關系數據庫一度產生了對于高效存儲管理圖數據上的不適應。當時人們為了解決圖數據存儲管理問題，基于NoSQL[3]技術開發了新的數據模型，圖數據庫從此誕生。當前，多種并行的圖數據處理系統正在被不斷研究與提出用以提高圖數據的查詢與處理效率[4]。圖數據庫因其獨特的圖算法優化，使得它在很多圖數據處理場景下擁有較好的表現。然而，很多圖數據引擎都因為其不夠成熟，在實際應用中有著大大小小不同的問題。

圖數據庫雖然有亮眼之處，但是缺陷無法掩蓋。因此，許多學者重新將思路放回了擁有幾十年的工程積累的關系型數據庫。基于關系型數據庫，利用其良好的可拓展性構建圖數據庫。相對于圖數據庫，關系數據庫系統在并發、鎖、安全性和查詢優化等方面，有著工業級強度的支持。以PostgreSQL為例，目前已經有通過基于關系代數的運用來拓展PostgreSQL 數據庫系統在圖數據集上的表達能力[5]。盡管利用關系數據庫系統圖處理能力擴展研究正在發展，但圖數據的本質難題在關系數據庫中還是沒有得到太好的解決，即數據的高度關聯所帶來的嚴重的隨機訪問問題。傳統的關系型數據庫由于是靠連接實現關系，隨機訪問的情況會顯得更加嚴重。

針對如何在數據云服務平臺DataCloud中向用戶提供穩定高效的圖數據查詢性能的問題，基于單個數據模型在管理圖數據時的局限，本文提出了使用關系數據模型與圖數據模型協同存儲數據的方式來管理數據，目標在犧牲一小部分存儲成本之后，大大提高整個系統的查詢性能，從而達到更佳的管理效果。同時針對多數據模型管理方式下需要面對的數據冗余問題，使用查詢感知的自適應存儲算法。通過定期分析用戶提交的查詢，解析出不同用戶的個人需求與數據集特點，按照不同數據引擎的查詢優勢，完成數據的存儲刪減移動等優化。

本文主要貢獻包括：（1）對關系數據模型與圖數據模型研究與實驗測評，提出了利用兩個數據模型協同管理數據的模式；（2）通過實驗測試對比了關系數據庫PostgreSQL 與圖數據庫Neo4J 各自在實際應用中的查詢優勢；（3）設計了基于用戶查詢感知的自適應存儲優化技術，結合用戶需求與引擎特點，對數據存儲位置進行存儲調優。

2 相關工作

本章主要介紹了相關背景與現有的圖數據管理方式，主要有圖數據庫存儲與關系數據庫存儲兩種。

2.1 DataCloud數據服務平臺

大數據云服務平臺DataCloud表示將不同類型的數據儲存在一個平臺中進行統一管理，允許多用戶訪問，或者單用戶進行不同需求的分析操作。它的主要特點如下：能夠處理、存儲不同類型的數據，包括關系數據、圖數據等；能夠適用于多種數據使用場景，比如不同需求目標的數據分析，針對數據的智能推薦服務等；提供持續穩定的高性能價比的數據和計算服務。如何能夠管理好復雜的圖數據也是DataCloud服務目標之一。因此，本文針對在該平臺背景下探求更智能、更科學的存儲模式提出了對應的存儲優化方案。

2.2 圖數據庫技術

圖數據的處理目前也正在被廣泛研究，面向大規模在線社交網絡、RDF、知識圖譜、生物網絡提出了大量圖算法。類似于廣度優先搜索[6]、連通分量計算、最短距離計算、拓撲排序[7]、PageRank[8]計算等算法在圖數據的處理中被大量使用。針對于此，學者們開發了大量不同類型的圖數據庫。

圖數據庫目前可以稱得上是種類繁多。其中主流的一類是以Neo4J[9]為代表的Native 圖數據庫。其主要特點是當用戶查找一個節點的邊或者是查找邊上的端節點時，不需要再走一次B+樹索引，而是直接通過指針直接指向下一個的物理地址，由此保持這種查詢下的高性能。通常其關系查詢時的時間復雜度可以達到O(n)。另一類熱門的圖數據庫是以Titan/JanusGraph[10]為代表的分布式圖數據庫。JanusGraph 利用Hadoop[11]進行圖的分析與圖的批處理，同時系統所支持外部的存儲系統包括 Apache Cassandra[12]、Apache HBase[13]、Google Cloud BigTable[14]、Apache Solr[15]與 Lucene 索引[16]、ElasticSearch[17]索引系統等。

為了解決圖數據高度關聯所帶來的嚴重隨機訪問問題，所開發的圖數據庫在很多場景下雖有很好的表現，但也暴露了不少問題。例如上面所提的Neo4J數據庫的數據屬性查詢慢、IO 性能低下等問題；JanusGaph存在查詢與存儲嚴重分離的問題等。因此，單單依靠目前的圖數據庫系統不能很好地達到高性能的管理圖數據的目標。

2.3 關系數據庫的圖數據管理技術

目前在關系數據庫上圖數據管理的研究愈發熱烈。Srihari教授在研究中發現了一種能夠在關系數據庫系統中有效挖掘圖數據中密集子圖的算法[18]；文獻[19]利用SQL中的窗口函數，在關系數據庫系統中實現了最短路徑算法；文獻[20]在研究中提出了基于SQL的聲明性查詢語言SciQL，作用是為了給關系數據庫系統提供圖的計算能力；文獻[21]研究開發了圖形存儲系統SQLGraph，它將鄰接信息的關系存儲與頂點和邊的屬性存儲用JSON 形式相結合，并通過實驗證明了該系統比大多的NoSQL圖形存儲性能要強。

除了在關系數據庫上實現圖操作的研究以外，部分研究者嘗試為關系數據庫添加新邏輯，由此成為新的圖數據庫。這種方式雖然形成了新的數據庫，但基本依然是憑借著關系數據庫的基礎。其中，這類典型之一，目前火熱的圖數據庫AgensGraph，就是在PostgreSQL 上重新添加新的一層邏輯，成為新的圖數據庫。AgensGraph作為新一代多模型數據庫，它能夠支持經典的關系型數據模型，允許開發人員仍然能夠集成經典的關系數據庫模型，同時也能夠支持提供圖數據分析環境。

基于關系數據庫的圖存儲管理技術開發，解決了很多之前純圖數據庫存儲圖數據時遇到的諸多問題，但由于關系數據模型本身的影響，導致面對復雜的圖運算時，數據庫的能力還是表現不足。

2.4 多模型數據管理系統

目前市場上雖說有數量不少的多模型數據庫產品，但是實際上大多只是將產品炒作成了多模型數據庫，只有少部分的系統才是真正的多數據模型數據庫。針對圖數據管理的多模型系統更是少。

ArangoDB 作為原生的多模型數據庫，它將多種不同的數據存儲組合在一起存儲在了一個數據庫當中。在這個多模型數據庫中，用戶可以將數據存儲為鍵/值對形式、圖形形式或者是文檔形式。用戶可以使用統一的查詢語言進行訪問，單次查詢也允許用戶涉及多個數據模型的數據。

不同類型、不同結構的數據采用不同數據模型進行存儲，可以獲得更高的查詢效率，尤其在大型的數據管理平臺當中，具有很強的應用價值。ArangoDB 通過自身的實踐應用，證明了多模型數據庫的價值，在應用上擁有很高的訪問效率，當然為了獲得這些收益，必須面對一定的維護代價與數據冗余問題。

3 數據引擎查詢性能差異

本章主要介紹了關系數據庫PostgreSQL 與圖數據庫在存儲數據時的具體查詢性能差異。

3.1 TPC-H查詢測試

TPC-H 是由TPC 事務處理性能委員會組織提供的一套工具包，用戶進行OLAP 測試，主要目的是評價特定的一系列查詢的決策支持能力，關注的是數據庫平臺的查詢能力。使用TPC-H 數據集進行引擎性能對比的實驗測試的最大原因是一方面它成熟的測試體系與接近真實應用的數據集環境，另一方面它測試的查詢包含多個查詢要素，包括多表連接、聚集、排序等典型查詢，進而可以比對不同查詢的性能差別。

通過每個查詢數據庫查詢的響應時間，進行兩個數據模型實際應用下的性能對比。TPC-H測試中共22個查詢，盡管每個查詢的內容不同，但是包含查詢類型存在重復情況，鑒于測試側重于對比不同類型查詢的性能差異，因此在對22個查詢結構進行解析后，選取11個代表性查詢，如表1 所示。在這里需要補充的是，關系數據引擎與圖數據引擎查詢差異一般體現在復雜關系查詢與其他類型查詢上，因此實驗查詢主要是在此基礎上進行的。而表1 中查詢類型既包含著關系數據模型的查詢也包含著圖數據模型的查詢。為了保證實驗的準確性和可靠性，針對不同的測試實驗，需要做關系和圖數據查詢語言的轉換（查詢語言的轉換在實驗前統一完成），使其查詢條件是一一對應，從而也確保了TPC-H在多數據模型下的查詢測試的通用性。具體的語言轉換以表1中的序號1為例子進行說明：

關系數據庫查詢：

select filed，count（filed） from tname group by filed having coun（tfiled）＞count order by id

圖數據庫查詢：

START n=node（num）

MATCH（n）--＞（x）

WHERE coun（tx.filed）＞count

return x.filed，coun（tx.filed）

order by x.id

說明：id、filed為字段名稱，tname為表名，num為節點編號，count為常量值。

表1 實驗選取查詢包含類型情況

以上語言轉換，目前是根據sql 語句手工模擬出對應的圖查詢語句（下一步將做成程序自動模擬），從而執行Neo4J查詢，完成整個實驗過程。

實驗服務器環境基本配置如下：Windows10 專業版，i7-3770CPU，主頻 3.4 GHz，8 GB 內存，200 GB 硬盤。關系數據庫系統為PostgreSQL，圖數據庫系統為Neo4J。實驗數據來源為網頁爬取，在PostgreSQL 中生成后，然后轉換成CSV 的形式，再導入到Neo4J 中。每個查詢分別在每個數據引擎中進行20 次查詢（相同的查詢采用緩存機制），在去除最大值與最小值以排除偶然性因素后，取每一個查詢的平均值。最后的測試結果對比如圖1所示。

圖1 查詢時間對比

總體而言，PostgreSQL 查詢時間幾乎都優于Neo4J的。這主要是因為TPC-H 依然是關系數據庫上的測試基準，查詢上做了相對的優化。但隨著查詢序號增加，表的連接數同時增加，查詢時間開始逐漸接近。達到五表連接時，查詢時間就非常貼近了，最后，甚至出現了Neo4J 查詢時間少于PostgreSQL 的情況。這說明了Neo4J 在關系復雜情況下的查詢優勢。而在其他查詢類型下，關系數據引擎相比圖數據引擎依然有著不小優勢。

3.2 Yelp數據集查詢測試

通過上一節的測試，可以得到關系數據模型與圖數據模型下不同查詢的性能差異：圖數據模型在復雜關系查詢上有著優勢，但在其他方面表現不如關系數據庫。為了進一步地明確具體查詢在兩個引擎上的表現，本節使用知名數據集Yelp進行實驗測試，從而得到每一個具體查詢在不同數據引擎下的對比。

Yelp 數據集來源于美國最大點評網站Yelp。數據集涵蓋了Yelp 內部存儲的商戶、點評和用戶數據，具體包括了用戶評價、商戶信息等。數據集由于來源真實，具有很強的實際意義，同時內部既存在復雜關系，也存在多樣的屬性集合。因此選取Yelp 在兩個數據引擎進行不同基本查詢的性能對比。實驗環境跟上一測試相同。本次實驗相對更為具體，以SQL語句關鍵詞為標志進行測試，具體為：（1）Order by，排序查詢；（2）Aggregate，聚集查詢；（3）Join，四表五表連接查詢；（4）Having，聚集子句；測試的關鍵詞選用標準來自上一個實驗總結。測試語句為基礎查詢語句，返回1 000條記錄，每種查詢類型都會用3 個不同的查詢語句測試，最后取加權平均值，得到這類查詢最終的平均查詢時間。

實驗為得到直觀的數據引擎的性能比，對查詢時間進行了相對得分處理，每一類查詢在兩個數據引擎中的總分為100，各自根據查詢平均時間的比值得到對應的性能比，如圖2所示。由圖可知，Yelp數據集的測試下，Neo4J的優勢查詢在于超過四層關聯關系查詢時，速度遠遠優于關系數據庫，而在其他查詢需求上，性能比不上傳統的關系數據引擎。

圖2 不同引擎下不同查詢類型的性能對比

4 關系-圖協同存儲與優化

基于第3 章中介紹的關系數據模型與圖數據數據模型的實際查詢性能的不同，提出兩個數據引擎協同存儲來獲得查詢的高性能，并介紹了查詢感知的自適應存儲優化技術的研究與實現。

4.1 協同存儲的查詢優勢

本節通過實驗舉例說明的方式，簡單證明關系-圖協同存儲下的查詢優勢。用戶查詢可以分為簡單查詢與復合查詢。簡單查詢是查詢結構簡單，只包含多表連接、聚集查詢等查詢中的一個或者兩個。簡單查詢情況下，由于兩個引擎可以根據自己的優勢進行查詢選擇，查詢效率一定會比單個引擎進行所有查詢的效率要高。因此在證明關系-圖協同存儲下的查詢優勢，只需要證明用戶復合查詢下多數據模型管理的性能優勢。

復合查詢是指查詢包含圖數據引擎擅長的復雜多表查詢，同時包含關系數據庫擅長的排序聚集等查詢。對此，分別使用單個圖數據引擎、單個關系數據引擎與雙引擎進行查詢，通過對比三種情況的查詢時間得到性能對比。實驗環境與數據集同上一章Yelp實驗相同，實驗方式具體如下，設置四組復合查詢，具體包含類型為：（1）三表連接、排序、聚集；（2）四表連接、排序；（3）五表連接、聚集；（4）五表連接、聚集、排序。實驗通過查詢分割，將復合查詢中各自擅長的查詢分配至對應查詢引擎，再將總的時間與中間成本進行整合得到復合查詢總時長。

對實驗結果進行比例調整，將協同存儲下的查詢時間設為單位1，則其他查詢結果如圖3所示。可以看到，在使用單個圖數據引擎或者單個關系數據引擎存儲時的查詢平均時間都是關系-圖復合存儲下的查詢時間的2～5倍。使用多數據模型協同管理復雜關系數據集時，用戶的查詢性能得到了相應的提高，驗證了這種存儲模式在查詢上的優勢性。

圖3 單引擎與多引擎查詢性能對比

4.2 查詢感知的關系-圖的存儲優化

多數據模型對數據集進行協同存儲體現了其性能的優越性，但也同時需要付出一定的代價。這方面主要體現在復雜的運維與冗余存儲上。本節提出了查詢感知的存儲優化方式，來結合數據特點與用戶需求，來解決冗余存儲的問題。

由于數據存儲的優化方案受到數據集本身特點與用戶個人查詢需求的影響，系統很難一開始就對用戶傳入的數據集進行結構判斷與需求分析，因此采用用戶查詢感知的方式進行協同存儲調優，其機制是：定期解析用戶輸入的查詢內容，分析用戶的查詢需求并解析數據庫中的數據結構，進而完成自適應存儲優化，達到為用戶優化存儲空間的目的。

根據上述基于查詢感知的存儲優化思路，用戶上傳至平臺的數據流如圖4 所示。用戶上傳數據并選擇數據庫默認選項為全冗余形式，即將數據全部傳輸至兩個數據引擎當中。同時平臺也提供了用戶選項，用戶可以在上傳數據時或者在自適應優化存儲過程中，申請主動分配數據至指定空間或申請主動從某一引擎刪除部分數據。用戶選項的設置一方面可以提高基于查詢感知自適應調優程序的容錯率，減少因調優程序引起部分查詢效率降低的情況，另一方面也可以更好地獲取用戶個人需求信息，進行更準確的存儲調優。

圖4 數據庫引擎間的數據流

在用戶上傳數據進入平臺之后，數據將以全冗余的形式存入到兩個數據引擎當中。接下來，平臺的自適應調優程序將會對用戶提交的每一個查詢進行相應的分析，并存儲至用戶對應的查詢歷史記錄當中。存儲調優過程如圖5 所示。調優程序將會定期調用存儲的查詢記錄，根據解析用戶提交的查詢對數據集結構特點與用戶需求進行判斷，從而得到如何對數據進行存儲判斷。需要提及的是，程序中用戶的查詢輸入暫時默認為SQL語句形式。

圖5 自適應存儲調優處理過程

基于以上的分析，協同存儲優化實現算法主要分為兩個部分：用戶查詢解析算法與存儲優化算法。

4.2.1 用戶查詢解析算法

用戶查詢解析算法將用戶的每一個查詢進行結構上與內容上的解析，進而判斷用戶所存儲的數據集中哪一部分數據參與了復雜的表連接查詢，哪一部分數據經常參與了聚集查詢等。將查詢語句所隱含的信息解析出來之后，用作接下來自適應存儲調優算法的判斷依據，進而完成存儲優化的目標。

算法整體可分為預處理階段與信息解析階段。預處理階段將用戶輸入的查詢語句格式統一后分塊。分塊后有利于之后的信息挖掘與獲取。信息解析階段將分塊后的信息進行解析整合。解析后，每個數據表的信息會以哈希表的形式存儲下來：該表總查詢訪問數，該表參與屬性查詢數，該表參與查詢的本身表連接數以及該表參與查詢的總連接數。通過這些哈希表存儲的信息，來傳達用戶查詢中潛藏的表信息與用戶需求。算法具體描述如下：

算法1查詢解析算法

4.2.2 存儲優化算法

用戶查詢解析后，算法將每個表的信息存到對應表中，接下來存儲調優算法進行冗余存儲優化。算法將使用解析信息，對用戶需求與數據結構進行判斷，由此完成對部分數據在某一引擎中的存儲或者刪除操作。數據存儲調整單位為關系數據庫中的數據表，當在關系數據庫中的表發生存儲變化時，只需按照表的形式進行調整；當圖數據庫中的數據發生調整時，則只需按照節點情況進行增減。值得一提的是，由于Neo4J的存儲模式問題，在Neo4J引擎中進行任何的數據變更成本都比較高，所以算法在判斷數據在Neo4J 中的存儲或者刪除時，要求會相對較高。

解析算法核心為啟發式規則：（1）當數據表本身參與連接數不超過該表總查詢數時，認定該表每次查詢最多本身只參與一次表連接，可判斷這類表基本主要職能為存儲某一節點的屬性集，因此這類表存儲位置判斷為關系數據庫。（2）當該表每次查詢都有x次（x為可調整系數，目前設定為2）聚集、排序等查詢時，則該表至少存儲在關系數據庫中。若該表參與的每個查詢都小于y表連接數（y為可調整系數，目前設定為3），刪除該表在Neo4J 引擎中的存儲，否則，兩個引擎冗余存儲這段數據。（3）當該表參與的每個查詢都超過了z表連接數（z為可調整系數，目前設定為5），判斷數據應存入Neo4J 數據引擎。若該表每次查詢自身參與連接數超過n（n為可調整系數，目前設定為2），刪除該表在關系數據引擎中的存儲。算法具體描述如下：

算法2存儲優化算法

4.2.3 存儲優化算法分析

基于啟發式的存儲空間優化算法通過一系列的規則判斷來完成以表為單位的刪除與存儲選擇，而對于這個規則它是后期經過不斷的學習和修改進行完善的。就目前來說，算法中的啟發式規則借鑒了大量實踐經驗，可以保證絕大多數情況下存儲優化算法判斷的正確性，代表了一定的普遍性，但考慮到用戶的查詢不可預測性、數據的多樣化性以及存儲結構的不斷調整可能會影響用戶某些查詢的執行性能以及協同存儲的分配準確率，因此系統在優化上還進行了以下設定：一是定期調用自適應存儲優化算法執行程序，待調優完畢后刪除之前的查詢解析信息，重新統計下一周期的用戶查詢信息，確保每一次存儲調優都是基于用戶最近時間的查詢記錄，同時根據變化完善算法規則；二是開放用戶選項，允許用戶申請調整數據的存儲位置，若是采用這一過程將會加大數據分類存儲的復雜性以及存儲優化算法的適用性，增加了存儲算法的挑戰性，如果成功，則無異于增強了算法的健壯性與普遍性，從而使系統的執行更加完善和具有代表性。因此基于以上分析，采用定期調用存儲優化程序與開放用戶選項兩者相結合的思路，從而實現協同存儲算法的不斷優化性、可用性與實用性和用戶查詢效率的最大化與最優化。

5 實驗與分析

實驗分為兩部分：（1）測試雙引擎全冗余存儲下和優化存儲后的查詢性能對比與存儲空間優化率；（2）測試單數據引擎存儲情況下和優化存儲后的查詢性能對比與存儲空間對比。通過兩部分實驗來評估查詢感知的自適應存儲調優性能。

5.1 實驗環境

實驗環境中的軟硬件配置如表2 所示。實驗使用數據集使用Yelp公開數據集，為了達到測試不同數據規模的算法效果，同時準備了2倍、4倍與8倍于原數據量的實驗數據集。

Yelp 數據集本身的組織形式為JSON 格式，解析將其存入關系數據庫PostgreSQL 中，一共18 張表。在將Yelp實際數據集導入關系數據庫PostgreSQL中后，再將其轉換成CSV 后導入Neo4J 當中。圖數據Neo4J 中存儲節點數量達到900萬，節點主要類型有商家、用戶、圖片、評論和建議等。Yelp原數據集信息統計如表3所示。

表2 實驗環境配置

表3 實驗數據集統計信息

5.2 查詢實驗設置

為提高用戶查詢的仿真度，從數據源網站中隨機選取了多個用戶常見查詢作為構造查詢的主要參考。為了檢測到存儲優化算法的每一個規則是否都有作用，因此查詢設置也盡可能地涉及了更多查詢類型，同時查詢的表也盡可能訪問到數據庫中18個數據表。具體查詢類型設計情況如表4所示，并給出了簡單的樣例查詢介紹。

表4 查詢實驗設置

實驗查詢組以包含查詢類型為分組，在每一個實驗查詢組都包含15 個符合條件的查詢，一共設有120個對應的查詢。

5.3 實驗結果與性能評估

本節主要說明兩組對比實驗的查詢結果對比與存儲情況對比，并根據兩組實驗對比的結果進行存儲優化算法執行的性能評估。

5.3.1 全冗余存儲與優化存儲對比

該對比實驗主要是為了檢驗查詢感知的自適應存儲優化算法的實際優化效果以及算法對整個系統查詢性能影響。

實驗具體操作如下：將設置好的查詢在全冗余存儲下進行測試，記錄時間，并啟動存儲優化程序。查詢實驗全部完成后，按照調優程序進行存儲位置優化后，重新使用查詢實驗進行測試，得到優化后的查詢時間。圖6 展示了不同規模大小數據集優化前后的存儲空間變化。

圖6 存儲空間優化效果

存儲算法優化空間效果達到了接近三分之一，已經十分接近理想情況下無冗余存儲的0.5。對比不同大小實驗集時，優化效果最好的為8 倍的數據集，最差的為原數據集。數據集本身的大小跟優化效果關聯并不是很大。僅從存儲空間優化來看，存儲優化算法的優化效率還是比較理想的，但仍需關注存儲優化對查詢性能的影響。圖7為不同規模數據集下，查詢性能變化。

優化前全冗余的存儲形式相對而言在查詢性能上擁有優勢。當數據規模大小增大時，部分設置的查詢組的查詢時間也隨之變大了。這主要是因為隨著數據集規模的增大，兩個引擎中進行的數據查找操作也變得復雜起來。設置查詢組后半部分變化較大，也是由于后半部分設置的查詢組涉及查詢類型較多，數據處理情況更為復雜。

從實驗結果來看，存儲優化算法產生的查詢時間影響波動在5%到20%之間變化。其中，高幅度變化的查詢數量實驗下并不多。綜合四個數據集下不同查詢的平均變化來看，優化后的整體查詢時間增加了12%左右。本文認為這個數值處于一個可接受的波動范圍，并且未來認為同通過查詢優化的方式進行進一步的時間優化。總體而言，存儲優化算法在實驗環境中為全冗余存儲的實驗數據完成了30%左右的實際存儲空間優化，同時查詢性能下降了12%左右，優化效果較為良好。

圖7 查詢性能優化效果

5.3.2 優化存儲與單引擎存儲對比

這一組實驗對比是為了驗證整個系統在經過多引擎協同存儲與自適應存儲優化后，與傳統的單引擎管理圖數據進行查詢性能上與存儲空間上的對比，從而得出查詢感知的關系-圖自適應存儲優化的多模型協同管理方案的整體效果。

實驗查詢空間對比如圖8所示。可以看到，在進行存儲優化后，多數據模型協同管理數據依然需要使用大量存儲空間。總的來看，相比單引擎，優化后的多數據引擎管理使用了多40%左右的實際存儲。在不考慮查詢的情況下，這種存儲空間對比使用還是不可忽視的。所以依然還是需要結合查詢時間對比得到更準確的性能對比結論。

圖8 單引擎與優化多引擎存儲對比

圖9 為單引擎和優化后協同存儲多引擎的查詢時間對比實驗結果。總的來看，在任何查詢組中，優化過后的協同存儲管理下的查詢效率始終不是最差的。根據查詢實驗平均查詢時間得出：單個引擎的查詢時間都是優化存儲查詢時間的三倍以上。從這兩個方面而言，優化組的查詢性能相對是比較高的。

圖9 單引擎與優化后存儲多引擎的查詢性能對比

從不同數據規模實驗結果對比來看，隨著數據規模的增加，實驗查詢組——后幾組的性能差距也隨之增大。本文認為這主要是因為數據規模的增加，使數據引擎需要做的查詢操作變得更加復雜，不同引擎之間的查詢性能差距將不斷擴大，尤其是多表連接查詢，使得后幾組查詢實驗中涉及多表連接查詢的實驗，在使用單個數據庫引擎管理數據時，性能會不斷變差，而在多數據模型協同管理情況下的查詢性能相對會好很多。這也證明了多數據模型管理在經過優化后，依然具有很大的整體查詢優勢。總體而言，優化后的多數據協同管理在多使用了不到五成的存儲成本下，可以獲得三倍以上的查詢性能。

6 結束語

本文針對在數據云服務平臺DataCloud中如何保證圖數據在不同需求場景下的高查詢性能問題，通過對多個數據模型的查詢效率進行預備實驗和結果分析，提出了多數據模型協同管理數據的模式，并提出了基于查詢感知的自適應存儲優化算法來解決多數據模型存儲數據時的存儲冗余問題。該方法利用查詢歷史，分析查詢結構與內容，并利用啟發式規則建立代價模型，來完成數據的遷移與刪除等存儲優化工作。實驗結果表明，多數據模型協同存儲數據相比單引擎存儲，有著更好的查詢效果；同時驗證了存儲優化算法為此種存儲模式提供了良好的存儲優化效果。未來將考慮文檔、KV 等更多引擎，以及基于存儲優化能力進一步優化系統查詢處理操作或過程。

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