多種存儲環境下壓縮數據庫的緩存優化

張佳辰，劉曉光，王 剛

(南開大學計算機與控制工程學院，天津300350)

(* 通信作者電子郵箱 liuxg@nbjl．nankai．edu．cn)

0 引言

各行業所產出的數據量增速提升，對數據存儲和查詢的需求急劇增加，對承擔海量數據存取任務的數據庫管理系統進行優化的需求也從未減小。在這種背景下，一般的關系型數據庫系統中，磁盤I/O最為繁忙，當I/O成為性能瓶頸時，CPU占用率相對較低;同時，數據壓縮技術中的壓縮和解壓縮操作則需要占用大量的CPU計算資源。因此，許多數據庫存儲系統中開始引入數據壓縮技術，利用相對空閑的CPU計算資源，來減少存儲空間和 I/O傳輸帶寬，具有很大意義。MySQL［1］、Oracle［2］、SQL Server［3］、DB2［4］等數據庫都實現了各自的數據壓縮功能來降低存儲開銷和提升I/O吞吐量。

近年來，更高性能的新型存儲設備和虛擬化技術的快速普及，傳統的數據庫管理系統也開始面臨新的局面。固態硬盤(Solid State Drive，SSD)等存取速度更快的存儲設備作為加速緩存甚至整體代替傳統磁盤(Hard Disk Drive，HDD)被用到數據庫存儲系統中，來進一步解決二級存儲設備和主存儲器之間的巨大速度差異。同時，隨著云計算服務［5］的普及，越來越多的數據庫開始從物理服務器遷移到云上的虛擬機中，甚至衍生出了數據庫即服務(DataBase-as-a-Service，DBaaS)等以數據庫為核心的云計算業務［6］。因此，本文以提升數據庫壓縮技術性能為目的，針對SSD和虛擬機等當前流行的數據庫運行環境進行研究，主要貢獻如下:

1)分析了(帶壓縮)數據庫讀寫延遲的組成部分，逐一分析了影響系統性能的主要因素。

2)在應用數據庫壓縮技術的基礎上，以MySQL數據庫為例，對影響I/O性能的各種因素進行分析。

3)針對數據庫壓縮系統的不同部署環境，提出了優化數據庫緩存來提升數據庫I/O讀性能的方法，并進行了實驗驗證。

為具體分析、優化和驗證各種因素對數據庫壓縮系統I/O性能的影響，本文主要以MySQL這一被廣泛使用的開源數據庫為例進行分析和實驗。在討論虛擬化環境中的數據庫壓縮時，本文主要使用以系統模擬器QEMU(Quick Emulator)［7］作為虛擬機管理器(Virtual Machine Monitor，VMM)的內核虛擬機(Kernel-based Virtual Machine，KVM)［8］作為平臺進行實驗驗證。

1 相關工作

雖然有損壓縮算法的壓縮率較高，可以節省更多存儲空間［9］，但在數據庫系統中，由于要保證數據的完整性，所以應采用無損壓縮技術。Aghav［10］分析了不同類型的數據庫系統中可能應用的多種無損壓縮算法，指出在主流的關系型數據庫中，用戶記錄是按行存儲的，一般應采用基于字典的無損壓縮算法。在一些主流的數據庫系統中，MySQL InnoDB存儲引擎使用了基于DEFLATE字典無損壓縮壓縮算法的zlib庫實現了表格式壓縮功能［11］，Oracle［2］、SQL Server［3］、DB2［4］等數據庫也都采用了改進的基于字典的無損壓縮算法實現了各自的壓縮存儲功能。

壓縮算法的壓縮比和壓縮性能之間是需要權衡的，壓縮比越大的壓縮算法，節省的空間越多，但同時壓縮、解壓縮操作的時間通常也會增大。馬井瑋等提出在MySQL壓縮功能中用解壓更快的 LZ4HC算法［12］代替 zlib的 DEFLATE算法［13］，在磁盤空間節省變差5%的條件下將SSD上啟用壓縮功能的MySQL的讀性能提升了36%。雖然各種高性能的數據壓縮算法被陸續地被應用到各種數據庫存儲系統中，但是對于不同的工作負載和系統運行環境，仍然沒有一個絕對最優的壓縮算法。

一般關系型數據庫的邏輯結構分為數據庫、表和記錄等層次，而從存儲結構角度則一般存在文件和塊的概念。由于數據庫系統中存在多個存儲層次，所以數據壓縮理論上也可以實現于數據表層次、數據塊層次或用戶記錄層次等［10］。以MySQL InnoDB存儲引擎為例，用戶記錄以文件形式進行存儲，并定義了一種固定大小的頁結構作為訪存文件和管理緩沖池(Buffer Pool)緩存的基本單元。邏輯結構和存儲結構之間通過用戶行記錄進行聯系。用戶行記錄作為最小的邏輯單位被存儲在頁結構中［14］。由于MySQL自身定義的頁結構默認為16 KB，大小適中［15］，所以MySQL實現的壓縮功能中，是以頁結構作為壓縮單元進行壓縮和存儲的［16］，本文也以此為基礎進行進一步分析優化。

雖然上述很多工作都對數據庫壓縮進行過分析和改進，但還沒有在考慮系統所運行環境的特點的情況下對緩存進行優化的。實際上，不論是存儲設備類型的差異，還是云虛擬化環境與本地物理環境的差異，都會對系統的緩存效率、存儲性能造成很大影響。特別是近年來，數據庫有HDD逐步被SSD替代、本地數據庫逐步向云端遷移的趨勢，使這種差異引發的數據庫性能的不穩定性越發明顯。因此，本文針對這些不同存儲環境的特點，對數據庫壓縮系統中的緩存部分進行分析，提出了針對I/O吞吐性能的緩存優化方法。

2 數據庫壓縮性能評價標準

2．1 存儲效率

數據庫壓縮技術節省了數據存儲空間，提高了存儲空間利用效率。參照數據壓縮比的概念，本文定義一個數據庫壓縮比r來描述數據庫壓縮后的存儲空間節省情況，r的值等于壓縮前的數據文件原始大小DS和壓縮后的數據文件大小DScom之比。

數據庫壓縮比r的值越大，說明當前數據庫系統壓縮模塊的空間節省效果越好。

2．2 I/O 性能

數據庫系統的I/O吞吐量主要取決于每次讀寫請求的延遲。如圖1，在本文所討論的數據庫系統中，一次讀或寫所需的平均延遲時間Tread/write可分為兩部分:Ttrans表示所請求數據從數據庫存儲系統緩存區經過各個存儲層次最終到達二級存儲設備所需的總時間;Tprocess表示在數據庫系統用戶空間緩存中進行查找、更改、加密和壓縮等操作所需的總時間。即:

在Tprocess中，數據庫在自身緩存中對記錄的查找和更改所需要的時間很短，只有加密解密或者壓縮解壓縮操作占用的時間和傳輸時間是可以比擬的。由于本文只涉及其中壓縮性能的分析，所以式(2)中的Tprocess可以替換為Tcom或Tdecom來分別表示一次寫操作所需的壓縮時間或一次讀操作所需的解壓縮時間。

圖1 數據庫壓縮系統讀寫基本流程Fig．1 Read and write process in database compression system

另外由于數據庫系統自身的緩存機制，部分數據在被請求時已經緩存在內存中了，數據庫可以直接在緩存中進行操作，省去了從磁盤傳輸到內存的時間。本文將一次請求在數據庫存儲緩存區的命中率表示為H，此時，所有的請求就只有(1－H)的概率需要耗費Ttrans時間。

因此，分別對應讀操作Tread和寫操作Twrite，可以將式(2)改寫為:

3 性能影響因素分析

3．1 解壓縮時間Tdecom和壓縮時間Tcom

逐一分析式(3)和式(4)中的項，Tdecom和Tcom主要取決于所使用的壓縮算法的運行效率和CPU的運行速度。

要提高壓縮算法的運行效率，可以針對數據庫系統的數據特點對壓縮算法進行專門的優化，如第1章所述，很多工作將重點集中于此。本文不重點討論壓縮算法的優化，而是在進行其他優化時采用了兩種具有代表性的壓縮算法進行分析:DEFLATE算法具有較高的壓縮比，但解壓速度較慢;LZ4算法解壓速度很快，但壓縮比相對較差。

要減小Tdecom和Tcom，可以使用更高性能的CPU。在虛擬化環境中，可以通過開啟虛擬化專用指令加速來使虛擬機中vCPU的執行效率接近物理CPU性能，本文涉及虛擬化環境的所有測試，就是在使用了開啟虛擬化指令加速的KVM虛擬機中進行測試的。

3．2 I/O傳輸時間Ttrans

Ttrans主要由二級存儲設備到物理內存的時間組成，也就是數據庫一次讀寫磁盤的總延遲時間。HDD和SSD之間的性能差別巨大，HDD順序讀寫的性能遠高于隨機讀寫的性能，而SSD的隨機讀寫和順序讀寫性能的差距則不明顯，并且SSD讀寫速度要遠高于HDD。選擇不同的二級存儲設備，會對式(3)和式(4)中的Ttrans參數造成數量級的差異，因此，數據庫存儲系統的整體性能，在很大程度上取決于系統當前存儲結構中二級存儲設備的I/O性能。

當數據庫存在多個連接同時處理SQL請求時，MySQL會以多線程讀寫文件;數據庫的請求操作取決于連接到數據庫的用戶，由于用戶數量和請求的不確定性，一般數據庫的隨機讀寫遠多于順序讀寫，因此，不論是讀還是寫，SSD的Ttrans都要遠小于HDD。

在虛擬化環境中，由于多個虛擬機Guest的I/O是共享物理主機Host的，這就產生資源競爭問題［17］，所以當Host存在多個運行有數據庫系統的Guest時，每個數據庫I/O吞吐量都會顯著下降，并且由于各個Guest中數據庫數據文件被用戶訪問的時間和空間的隨機性，磁盤隨機讀寫操作所占的比例將進一步增加，這將導致多Guest的Host的總I/O性能也會下降。另外，虛擬機的磁盤通常是以Host的文件模擬的，因此數據I/O的路徑被加長，使得Ttrans進一步增大;不同的虛擬機鏡像文件格式也會為Guest的I/O性能帶來不同程度的影響［18］。

3．3 緩存命中率H

雖然緩存命中率H的精確計算涉及到數據庫存儲系統的具體實現，但其一定是與數據庫緩存區大小CS(Cache Size)和當前數據庫數據總量大小DS(Data Size)之比正相關的［16］，可以表示為:

對于一定的數據量，較大的緩存區可以提高式(3)和式(4)中的命中率H。足夠的物理內存容量是數據庫開辟足夠大緩存區的必要條件，理想情況下，服務器的內存大于總數據量，此時可以期待所有數據最終都被緩存，命中率H將達到最大值1，數據庫性能達到最佳。但是在物理內存價格昂貴并且數據量巨大的情況下，讓內存大小超過數據大小并不現實，緩存區只能緩存部分數據的情況在數據庫系統的應用中廣泛存在。因此，要提升數據庫I/O性能，還需要根據具體工作負載，通過分析和測試來調整各種參數。

4 緩存優化

本章在式(3)的基礎上，進一步分析和優化虛擬化環境中MySQL頁級壓縮的讀性能。

開啟壓縮功能的數據庫的緩存一般被分成兩大部分:一部分存儲未被壓縮的數據，以提高對“熱數據”的讀寫效率，避免過多的壓縮解壓縮操作;另一部分用于緩存已完成壓縮的數據，來使得有限的緩存空間可以存儲更多的數據，來提高緩存的命中率。

以MySQL InnoDB存儲引擎為例，如第1章所述，壓縮是以頁結構為單位進行，原本16 KB大小的頁被壓縮為1 KB、2 KB、4 KB、8 KB等大小的壓縮頁，同時在InnoDB的Buffer Pool緩存中，壓縮頁和未壓縮頁都采用鏈表進行存儲，并采用LRU算法進行管理。MySQL傾向于將請求較多的頁保存在未壓縮頁鏈表中，在Buffer Pool接近飽和的情況下，未壓縮頁占整個Buffer Pool大小的10%，并且每個未壓縮頁一定對應一個壓縮頁;而占Buffer Pool大小90%的壓縮頁，則不一定能在Buffer Pool中找到與之對應的未壓縮頁，并且，存儲在二級存儲設備中的頁都是壓縮頁，以節省存儲空間。對于一般的修改，MySQL也可以將修改信息直接寫入壓縮頁中預留的mlog區域，減少壓縮次數，進而減小頁面壓縮重構的代價。

4．1 優化模型

正是由于InnoDB Buffer Pool中同時存在壓縮頁和未壓縮頁，所以在進行讀操作時，緩存命中率H可以表示為壓縮頁的緩存命中率Hc和未壓縮頁的緩存命中率Hu之和;并且以前所有頁都會涉及的解壓縮延遲Tdecom在未壓縮頁命中時不再需要。另外，由于網絡傳輸延遲不在本文討論范圍，本文將Ttrans表示為Tdisk_read，所以式(3)可以改寫為:

為尋求進一步優化MySQL數據庫壓縮的可能，本文將一些默認的或者原本固定的參數寫為參數變量，來方便分析各參數值對性能影響:本文將壓縮頁占Buffer Pool的大小的固定比例90%設為變量R，則未壓縮頁占Buffer Pool的大小為(1－R);還將默認8 KB和16 KB的壓縮和未壓縮頁的大小分別用PScom和PS表示。為了方便表示，沿用了式(1)的r，將其定義為原始數據大小DS和壓縮后的大小DScom之比;同時，將式(5)中出現的CS具體化為變量BS(Buffer Pool Size)。假設命中率和Buffer Pool中頁數與數據總頁數的比成正比，Hc和Hu可以分別表示為:

為方便化簡，設α=PScom/PS，β=BS/DS;并將式(1)、式(7)和式(8)代入式(6)中，得:

在β或數據庫壓縮比r較大時，由式(9)所計算出的Tread可能小于0，這在實際中是不可能出現的;且根據前文所述，Buffer Pool中每個未壓縮頁必然有一個壓縮頁與之對應，所以，未壓縮頁一定比壓縮頁少，即式(9)存在一些限制條件:

4．2 模型分析

式(9)中的參數中，與β參數有關的BS和DS取決于數據庫系統具體配置和數據庫存儲數據的大小。有關r參數的DS和DScom取決于所用的壓縮算法和存儲數據是否適合當前的壓縮算法。存儲設備和操作系統的實現決定了PScom是2的冪時效率較高，即1 KB、2 KB、4 KB等。而PS值默認為16 KB，所以α參數可以取1/16、1/8、1/4、1/2和1等值。觀察式(9)，要減小總的讀延遲時間，在其他條件不變的情況下，α應該盡量大。但本文并不對α參數進行詳細分析和實驗，因為α參數值的選擇主要應該考慮數據庫所存儲數據的類型，若數據記錄較大或者所存儲的數據壓縮效果不好，采用的壓縮頁大小PScom過小，在有數據寫入時，將會出現頻繁的壓縮失敗情況，導致大量的高代價頁分裂操作;當數據記錄較小或者數據適宜壓縮的情況下使用較小的壓縮頁，能夠適當地降低讀寫量，增加緩存中頁的總數，帶來一定的性能提升。對于不同的工作負載和讀寫請求比例，α應該根據實際情況選擇合適的值。另外，由于多數需要優化數據庫性能的情況中β=BS/DS通常遠小于1，所以調整［1－αβr(1－R)］項中的α對讀性能的影響并不明顯，所以本章后半部分的分析及實驗采用默認的PScom大小，即8 KB，此時α大小為1/2。

關于參數R，根據式(10)可以得出:

由于在本文需要優化的情況中，緩存大小BS通常遠小于數據量DS，即兩者之比βㄍ1，同時數據庫壓縮比r取值一般在1～3，所以有1/βr＞1;又由于α ＞0，所以α/(α+1) ＞0，所以有:

值得注意的是，雖然可以調整參數R到R＜α/(α+1)的情況，但這樣一定會導致性能下降，這是因為MySQL開啟壓縮后，每個未壓縮頁在內存中必然有與之對應的壓縮頁，所以如果分配給壓縮頁的緩存比例過小，將會使未壓縮頁無法完全占滿剩余的緩存，導致緩存空間的浪費。所以若令R＜α/(α+1)，在其他條件相同的情況下，性能不可能達到最優。

4．3 優化方案

首先，在式(9)中，當傳輸時間Tdisk_read明顯大于解壓縮時間Tdecom時，應該增大R的值;當Tdisk_read明顯小于Tdecom時，應該減小R的值。

其次，如果將數據庫系統建立在文件系統之上，會導致數據庫系統和文件系統頁高速緩存［19－20］重疊的“雙緩存”問題;同樣，在虛擬化環境中部署數據庫系統時，也會帶來Guest文件系統和Host文件系統兩層頁高速緩存重疊的“雙緩存”問題。兩種情況的“雙緩存”問題都會導致不必要的內存浪費，所以應盡量繞過Guest和Host操作系統虛擬文件系統的頁高速緩存，盡量消除緩存的重疊情況，來保證大部分內存都用于數據庫緩存，進而保證整個系統性能的穩定。

因此，本文的緩存優化方案具體總結為如下兩條:

1)在數據庫系統中應用壓縮時，避免雙緩存問題。關閉操作系統中虛擬文件系統的頁高速緩存，以提高數據庫對內存的利用率。

2)對應不同的運行環境和壓縮算法，選取合適的壓縮數據占緩存的比例R，以獲得最高的吞吐量。

具體實現時，繞過數據庫系統所在操作系統頁高速緩存的方法并不復雜，只需要在配置文件my．cnf文件中將innodb_flush_method項設為O_DIRECT。在虛擬化環境下，要繞過Host操作系統的頁高速緩存，可以采用和MySQL繞過Host虛擬文件系統緩存類似的方式。比如，虛擬機管理器QEMU支持在開啟虛擬機時加入一個后端存儲文件控制參數cache=none來關閉對頁高速緩存的使用。在本文討論的虛擬化環境下運行的數據庫壓縮系統的情況中，避免“雙緩存”問題后的I/O及緩存結構如圖2。

圖2 虛擬化環境中解決“雙緩存”問題Fig．2 “Double caching”issue in virtualized environment

為了調整壓縮數據在數據庫緩存中所占比例R，只需要修改數據庫源碼中對應的限制條件。例如，在InnoDB Buffer Pool的具體實現中，當啟用頁級壓縮時，InnoDB將額外增加一個稱為unzip_LRU的LRU鏈表單獨管理Buffer Pool未壓縮頁［21－23］，本章所述R值是在需要進行頁面逐出時，通過選擇從LRU鏈表還是unzip_LRU鏈表進行逐出來控制的，本文改變了這部分代碼中的判斷邏輯和所涉及的參數，進而實現了對MySQL源碼中的R值的改變。

5 實驗

本文采用sysbench［24］作為測試工具，測試了磁盤I/O性能和數據庫OLTP性能，同時使用了KVM虛擬機作為虛擬化環境對優化方案進行實驗評估，具體實驗的軟硬件環境如表1。

5．1 HDD和SSD性能差異

本文首先模擬實驗驗證了數據庫壓縮系統部署于不同存儲設備時的性能差異:分別在SSD和HDD上生成4個總量為4 GB的文件，來模擬數據庫的多表文件;采用了1 KB、2 KB、4 KB、8 KB、16 KB讀寫塊大小，來模擬數據庫的實際讀寫單位;以4個線程進行隨機讀寫測試，來模擬數據庫的多鏈接請求情況;同時為了僅對比二級存儲設備造成的性能差異，用O_DIRECT標志位打開文件，即關閉操作系統的頁高速緩存，以消除系統緩存的影響。測試結果如表2。

由測試結果可以看出，SSD和HDD的讀寫速度差距懸殊，SSD無論讀還是寫都明顯優于HDD。因此，如果在數據庫存儲系統部分或整體用SSD代替當前主流的HDD磁盤，就可以顯著提升其 I/O性能。此外，應用磁盤陣列(Redundant Array of Independent Disks，RAID)等并行存儲技術，也可以提升存儲系統的性能。但是，更高性能的二級存儲設備往往帶來更高額的存儲成本［25］，比如，在2017年11月，SSD和HDD的單位GB存儲成本相差10倍左右。因此，在數據庫系統中引入數據壓縮技術來節省存儲成本很有意義。

5．2 虛擬化環境中的測試

按照4．3節中的第一條優化方法，本文繞過了Host操作系統和guest操作系統的頁高速緩存。為了對比虛擬機和非虛擬機環境中的數據庫壓縮系統的性能，本文采用聯機事務處理過程(OnLine Transaction Processing，OLTP)工作負載進行測試。圖3中，本文分別在SSD和HDD上測試了不應用壓縮(nocom)和應用壓縮(LZ4HC)兩種情況下的數據庫的OLTP性能。測試結果的單位是每秒事務處理量(Transactions Per Second，TPS)，數值越大，表明數據庫系統的事務處理性能越好。

圖3 虛擬化與非虛擬化環境中數據庫壓縮性能對比Fig．3 Database compression performance in virtualized and non-virtualized environments

可以發現，在讀性能方面，不論是SSD還是HDD平臺，也不論是否應用數據庫壓縮，Guest相對Host都有20%到30%的下降;對于寫性能，在SSD上Guest會有一半以上的性能損失，在HDD上由于寫速度慢，Guest和Host的差別不大。由于Guest中的數據庫讀性能更加接近Host，以讀操作為主要工作負載的數據庫系統，更適合部署于虛擬化環境。本文也因此繼續驗證了4．3節所提出的第二條優化方法在虛擬機中的讀性能優化效果。

5．3 優化方法的性能評估

按照4．3節中的第二條優化方法，調整MySQL壓縮表格式功能開啟時的R值，讓其在0～1變化。每次改變R值后，在SSD和HDD上分別進行MySQL的OLTP性能測試來對優化進行評估。

實驗時InnoDB Buffer Pool大小為128 MB，使用HDD進行實驗時，生成的測試數據大小為512 MB，使用SSD時，生成的測試數據量為4 GB。被測試的壓縮算法包括DEFLATE和LZ4HC，并以未啟用數據庫壓縮功能的情況作為基準進行比較，實驗結果如圖4所示。

圖4 改變參數R后的數據庫壓縮系統OLTP性能Fig．4 Database compression performance after changing parameter R

如前文所討論可知，HDD性能明顯差于SSD，Tdisk_read更大;DEFLATE解壓速度明顯差于LZ4HC，Tdecom更大;并且對于所測試的系統，LZ4HC解壓縮速度可達上千MB/s，HDD隨機讀寫數據的速度只有幾MB/s，故LZ4HC解壓速度遠遠高于HDD隨機讀寫速度。觀察圖4(a)中的曲線，SSD上應用DEFLATE壓縮算法時，Tdisk_read明顯小于Tdecom，應盡量減小R值，且此時由式(6)和此時使用的α值0．5，R理論上最小取值為0．33，實驗中，R值在0．3左右達到最好的性能，符合預期結論;HDD上應用LZ4HC或DEFLATE壓縮算法時，Tdisk_read明顯大于Tdecom，此時較大的R值會得到較好的性能，觀察圖4(b)中的曲線，應用DEFLATE算法時，性能在取值大于0．85時最佳，而LZ4HC算法在最大取值0．99達到最佳，符合預期。

圖5中分別列出了優化前后虛擬機Guest和宿主機Host中MySQL頁級表壓縮的OLTP性能。進行對比的三種情況均開啟了數據庫壓縮功能，其中Guest代表優化前虛擬化環境下部署數據庫的OLTP性能，Host代表在非虛擬化環境且沒有進行過緩存優化的情況下的數據庫性能，Guest_Opt代表在虛擬化環境下且應用了最佳緩存優化參數后的數據庫的性能。

可以看出，在SSD上應用DEFLATE壓縮算法時，優化后相對優化前的性能提升了43．6%;SSD上應用LZ4HC壓縮算法時，性能提升了5．2%。在圖5(b)中，HDD上應用LZ4HC壓縮算法時，性能提升了41．3%。可見，MySQL固定的R值0．9僅在HDD上應用DEFLATE算法的情況下效果較好，在使用SSD等更快的二級存儲設備或使用LZ4HC等更快的解壓縮速度的壓縮算法，未優化版本均不能達到令人滿意的性能。

圖5 優化前后的OLTP性能對比Fig．5 OLTP performance before and after optimization

從實驗結果中，還可看出虛擬機中數據庫壓縮優化后的最佳性能(Guest_Opt)與非虛擬化環境中未優化數據庫壓縮的OLTP性能(Host)。通過對比可以發現，在使用SSD存儲的同時應用DEFLATE壓縮算法，或者在使用HDD存儲的同時應用LZ4HC壓縮算法兩種情況下，由于優化效果更為明顯，Guest數據庫壓縮性能從優化前的差于Host變為了優化后的超過Host。其中，SSD+DEFLATE情況的Guest_Opt相對Host性能提升了21．3%，HDD+LZ4HC情況的Guest_Opt相對Host性能提升了13．72%。雖然這兩種性能優化組合并非最佳，但在很多特定情況下仍具有很大意義，例如，SSD的成本昂貴，DEFLATE算法具有較高的壓縮比，SSD+DEFLATE的優化組合可以在控制存儲成本的同時達到更好的性能。因此，在虛擬化環境中，本文提出的優化方案有很大的應用價值。

6 結語

本文首先闡述了在數據庫系統中應用數據壓縮技術的優勢。然后給出了針對數據庫壓縮系統的分析模型，分析和實驗驗證了影響數據庫壓縮性能的因素。最后，在前人模型的基礎上進行改進和分析，提出了一種在虛擬化環境中，通過優化緩存系統結構和使用結構來優化以讀操作為主的數據庫壓縮性能的方法，使性能提升了40%以上。這種優化方法也使得在幾種特定情況下，虛擬化環境中的數據庫壓縮性能達到并超過非虛擬化環境下的性能，具有很大意義。

本文也存在一些相關問題有待進一步研究。比如對數據庫壓縮的壓縮算法的優化沒有討論;對虛擬化環境中數據庫壓縮系統的性能優化也僅限于虛擬機用戶空間的數據庫系統，以后的工作中還可以在虛擬機或宿主機操作系統層面開展進一步的分析優化工作。