張佳辰，劉曉光，王 剛

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

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

0 引言

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

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

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

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

3)針對數(shù)據(jù)庫壓縮系統(tǒng)的不同部署環(huán)境，提出了優(yōu)化數(shù)據(jù)庫緩存來提升數(shù)據(jù)庫I/O讀性能的方法，并進行了實驗驗證。

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

1 相關(guān)工作

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

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

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

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

2 數(shù)據(jù)庫壓縮性能評價標(biāo)準(zhǔn)

2．1 存儲效率

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

數(shù)據(jù)庫壓縮比r的值越大，說明當(dāng)前數(shù)據(jù)庫系統(tǒng)壓縮模塊的空間節(jié)省效果越好。

2．2 I/O 性能

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

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

圖1 數(shù)據(jù)庫壓縮系統(tǒng)讀寫基本流程Fig．1 Read and write process in database compression system

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

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

3 性能影響因素分析

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

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

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

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

3．2 I/O傳輸時間Ttrans

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

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

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

3．3 緩存命中率H

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

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

4 緩存優(yōu)化

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

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

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

4．1 優(yōu)化模型

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

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

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

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

4．2 模型分析

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

關(guān)于參數(shù)R，根據(jù)式(10)可以得出:

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

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

4．3 優(yōu)化方案

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

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

因此，本文的緩存優(yōu)化方案具體總結(jié)為如下兩條:

1)在數(shù)據(jù)庫系統(tǒng)中應(yīng)用壓縮時，避免雙緩存問題。關(guān)閉操作系統(tǒng)中虛擬文件系統(tǒng)的頁高速緩存，以提高數(shù)據(jù)庫對內(nèi)存的利用率。

2)對應(yīng)不同的運行環(huán)境和壓縮算法，選取合適的壓縮數(shù)據(jù)占緩存的比例R，以獲得最高的吞吐量。

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

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

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

5 實驗

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

5．1 HDD和SSD性能差異

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

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

5．2 虛擬化環(huán)境中的測試

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

圖3 虛擬化與非虛擬化環(huán)境中數(shù)據(jù)庫壓縮性能對比Fig．3 Database compression performance in virtualized and non-virtualized environments

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

5．3 優(yōu)化方法的性能評估

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

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

圖4 改變參數(shù)R后的數(shù)據(jù)庫壓縮系統(tǒng)OLTP性能Fig．4 Database compression performance after changing parameter R

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

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

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

圖5 優(yōu)化前后的OLTP性能對比Fig．5 OLTP performance before and after optimization

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

6 結(jié)語

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

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