張佳辰，劉曉光，王 剛

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

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

0 引言

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

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

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

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

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

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

1 相關(guān)工作

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

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

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

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

2 數(shù)據(jù)庫(kù)壓縮性能評(píng)價(jià)標(biāo)準(zhǔn)

2．1 存儲(chǔ)效率

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

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

2．2 I/O 性能

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

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

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

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

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

3 性能影響因素分析

3．1 解壓縮時(shí)間Tdecom和壓縮時(shí)間Tcom

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

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

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

3．2 I/O傳輸時(shí)間Ttrans

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

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

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

3．3 緩存命中率H

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

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

4 緩存優(yōu)化

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

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

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

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

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

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

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

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

4．2 模型分析

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

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

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

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

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

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

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

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

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

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

具體實(shí)現(xiàn)時(shí)，繞過數(shù)據(jù)庫(kù)系統(tǒng)所在操作系統(tǒng)頁(yè)高速緩存的方法并不復(fù)雜，只需要在配置文件my．cnf文件中將innodb_flush_method項(xiàng)設(shè)為O_DIRECT。在虛擬化環(huán)境下，要繞過Host操作系統(tǒng)的頁(yè)高速緩存，可以采用和MySQL繞過Host虛擬文件系統(tǒng)緩存類似的方式。比如，虛擬機(jī)管理器QEMU支持在開啟虛擬機(jī)時(shí)加入一個(gè)后端存儲(chǔ)文件控制參數(shù)cache=none來(lái)關(guān)閉對(duì)頁(yè)高速緩存的使用。在本文討論的虛擬化環(huán)境下運(yùn)行的數(shù)據(jù)庫(kù)壓縮系統(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ù)庫(kù)緩存中所占比例R，只需要修改數(shù)據(jù)庫(kù)源碼中對(duì)應(yīng)的限制條件。例如，在InnoDB Buffer Pool的具體實(shí)現(xiàn)中，當(dāng)啟用頁(yè)級(jí)壓縮時(shí)，InnoDB將額外增加一個(gè)稱為unzip_LRU的LRU鏈表單獨(dú)管理Buffer Pool未壓縮頁(yè)［21－23］，本章所述R值是在需要進(jìn)行頁(yè)面逐出時(shí)，通過選擇從LRU鏈表還是unzip_LRU鏈表進(jìn)行逐出來(lái)控制的，本文改變了這部分代碼中的判斷邏輯和所涉及的參數(shù)，進(jìn)而實(shí)現(xiàn)了對(duì)MySQL源碼中的R值的改變。

5 實(shí)驗(yàn)

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

5．1 HDD和SSD性能差異

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6 結(jié)語(yǔ)

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

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