吳 剛，阿卜杜熱西提·熱合曼，李 梁，喬百友，韓東紅

1.東北大學(xué) 計(jì)算機(jī)科學(xué)與工程學(xué)院，沈陽(yáng) 110819

2.南京大學(xué) 計(jì)算機(jī)軟件新技術(shù)國(guó)家重點(diǎn)實(shí)驗(yàn)室，南京 210093

1 引言

近年來(lái)，隨著互聯(lián)網(wǎng)技術(shù)的快速發(fā)展，越來(lái)越多的網(wǎng)絡(luò)應(yīng)用需要能夠支持大量用戶的并發(fā)訪問(wèn)以及高吞吐量和低延時(shí)等特性。傳統(tǒng)的磁盤數(shù)據(jù)庫(kù)由于將所有數(shù)據(jù)放在磁盤上進(jìn)行管理，慢速的磁盤I/O限制了數(shù)據(jù)庫(kù)的性能。而內(nèi)存數(shù)據(jù)庫(kù)的數(shù)據(jù)存儲(chǔ)與管理都在內(nèi)存中進(jìn)行，因此綜合性能有了很大的提升，特別適合此類對(duì)性能要求極高的場(chǎng)合[1-4]。

為了保證數(shù)據(jù)庫(kù)的完整性，內(nèi)存數(shù)據(jù)庫(kù)通常使用日志結(jié)合檢查點(diǎn)的故障恢復(fù)機(jī)制[5-6]。日志記錄方面，ARIES類日志[7]和命令日志[8]為兩大日志記錄方式。其中，命令日志是專門為內(nèi)存數(shù)據(jù)庫(kù)而設(shè)計(jì)的粗粒度、輕量級(jí)的日志記錄方式。它的優(yōu)點(diǎn)是產(chǎn)生的日志小，I/O開銷低。因此這種日志記錄方式非常適合內(nèi)存數(shù)據(jù)庫(kù)。

但是，由于命令日志記錄的事務(wù)之間存在復(fù)雜的依賴關(guān)系，故障發(fā)生后無(wú)法直接進(jìn)行并行恢復(fù)[9]，很難發(fā)揮好多核處理器的并行處理性能，恢復(fù)速度較慢。針對(duì)該情況，現(xiàn)有的解決辦法是，在開始恢復(fù)之前，先分析日志記錄中事務(wù)之間的依賴關(guān)系，并求出最優(yōu)的并行執(zhí)行計(jì)劃，再開始并行恢復(fù)[10]。顯然這樣可以加快命令日志的恢復(fù)速度。但是，這需要在恢復(fù)之前遍歷一遍日志內(nèi)容。由于內(nèi)存數(shù)據(jù)庫(kù)的吞吐量很高，短時(shí)間內(nèi)都能產(chǎn)生很大的日志數(shù)據(jù)。因此，遍歷一遍日志的時(shí)間是不可忽視的。

相對(duì)于傳統(tǒng)對(duì)稱多處理器架構(gòu)的多個(gè)CPU通過(guò)單一內(nèi)存控制器訪問(wèn)內(nèi)存的體系架構(gòu)，在非統(tǒng)一內(nèi)存訪問(wèn)（non-uniform memory access，NUMA）體系架構(gòu)中，內(nèi)存和多核CPU分布在多個(gè)節(jié)點(diǎn)上，CPU通過(guò)節(jié)點(diǎn)間的高速鏈路可以訪問(wèn)系統(tǒng)內(nèi)所有節(jié)點(diǎn)的內(nèi)存[11]。因此這種架構(gòu)具有很好的可擴(kuò)展性。在這種架構(gòu)中，相比訪問(wèn)遠(yuǎn)端內(nèi)存，CPU訪問(wèn)本地內(nèi)存的延遲低，帶寬高[12]。在本文的實(shí)驗(yàn)部分所用NUMA體系架構(gòu)的服務(wù)器中，經(jīng)實(shí)驗(yàn)測(cè)得，CPU訪問(wèn)遠(yuǎn)端內(nèi)存的延時(shí)為251.1 ns，是訪問(wèn)本地內(nèi)存延時(shí)138.2 ns的1.82倍。

最近研究顯示，在NUMA體系架構(gòu)上優(yōu)化的內(nèi)存數(shù)據(jù)庫(kù)系統(tǒng)和內(nèi)存存儲(chǔ)引擎中，面向數(shù)據(jù)而非面向事務(wù)的設(shè)計(jì)架構(gòu)是一種主流思想[13]。面向事務(wù)的設(shè)計(jì)架構(gòu)中，事務(wù)處理所需要的數(shù)據(jù)往往會(huì)分布在不同的節(jié)點(diǎn)[14]。在NUMA架構(gòu)中使用面向數(shù)據(jù)的設(shè)計(jì)架構(gòu)可以避免這種跨節(jié)點(diǎn)訪問(wèn)數(shù)據(jù)帶來(lái)的延時(shí)。在面向數(shù)據(jù)的設(shè)計(jì)架構(gòu)中，通常的做法是將內(nèi)存數(shù)據(jù)庫(kù)中的每一條數(shù)據(jù)按鍵的范圍平均劃分到不同節(jié)點(diǎn)的內(nèi)存區(qū)域中，每個(gè)節(jié)點(diǎn)的CPU上創(chuàng)建一個(gè)線程負(fù)責(zé)執(zhí)行本區(qū)域內(nèi)數(shù)據(jù)的添加、刪除、修改、查找等操作[15]。這種策略有效地保證了各個(gè)節(jié)點(diǎn)所處理數(shù)據(jù)的均衡性，但忽略了數(shù)據(jù)訪問(wèn)的不均衡性，即忽略了數(shù)據(jù)的熱度。

Fig.1 Framework of command log recovery algorithm based on data popularity圖1 基于數(shù)據(jù)熱度的命令日志恢復(fù)算法框架

通常情況下，數(shù)據(jù)庫(kù)中的數(shù)據(jù)的訪問(wèn)符合正態(tài)分布規(guī)律。因此，一定會(huì)出現(xiàn)某些數(shù)據(jù)被頻繁訪問(wèn)的情形。在故障恢復(fù)時(shí)這種數(shù)據(jù)劃分策略顯露出其弊端。即如果某些數(shù)據(jù)的訪問(wèn)次數(shù)遠(yuǎn)高于其他數(shù)據(jù)，在故障恢復(fù)階段負(fù)責(zé)這些數(shù)據(jù)的線程的工作負(fù)載將會(huì)加重。劃分到那些被頻繁訪問(wèn)的數(shù)據(jù)的命令子隊(duì)列中的命令明顯多于其他命令子隊(duì)列。如圖1所示，命令子隊(duì)列中命令數(shù)目（藍(lán)色示意）呈現(xiàn)不均衡狀態(tài)。由于總的恢復(fù)時(shí)間由最后執(zhí)行完成的線程來(lái)決定，因此這種負(fù)載不均衡性顯然增加了恢復(fù)時(shí)間。

因此，從這個(gè)角度出發(fā)，為了更好地利用硬件性能，認(rèn)為在NUMA體系架構(gòu)上針對(duì)命令日志恢復(fù)進(jìn)行優(yōu)化是很有必要的。

在本文中，針對(duì)NUMA體系架構(gòu)的特性設(shè)計(jì)了NUMA體系架構(gòu)下的基于熱度記錄的命令日志快速恢復(fù)算法。該算法的框架如圖1所示。

在本文算法中，加載線程首先從磁盤加載檢查點(diǎn)和日志數(shù)據(jù)，并將它們送入命令隊(duì)列。然后，分發(fā)命令的線程使用一定策略將命令隊(duì)列中的數(shù)據(jù)分發(fā)到各個(gè)命令子隊(duì)列中。命令子隊(duì)列的數(shù)量取決于本服務(wù)器上NUMA節(jié)點(diǎn)的數(shù)量。最后，執(zhí)行線程不斷地從所屬的命令子隊(duì)列中取出命令并執(zhí)行，將數(shù)據(jù)添加到所在節(jié)點(diǎn)的內(nèi)存中。本文提出的NUMA架構(gòu)上基于數(shù)據(jù)熱度的故障恢復(fù)策略在故障恢復(fù)時(shí)通過(guò)使各個(gè)執(zhí)行線程的負(fù)載比較均衡，以此來(lái)加快恢復(fù)速度。本文的主要貢獻(xiàn)如下：

（1）提出了基于數(shù)據(jù)操作熱度的日志和檢查點(diǎn)記錄方案；

（2）設(shè)計(jì)并實(shí)現(xiàn)了NUMA架構(gòu)上基于熱度記錄的故障恢復(fù)算法。實(shí)驗(yàn)表明，本文算法的恢復(fù)速度比常規(guī)劃分策略快，恢復(fù)速度最高提升了19%。

本文工作安排如下：第2章介紹具有熱度記錄的日志和檢查點(diǎn)記錄方案；第3章介紹故障恢復(fù)算法；第4章為實(shí)驗(yàn)部分；第5章為結(jié)束語(yǔ)。

2 具有熱度記錄的日志和檢查點(diǎn)

首先提出數(shù)據(jù)熱度的定義。

定義1設(shè)D={d1,d2,…,dn}為數(shù)據(jù)記錄的集合，C={c1,c2,…,cn}為與D中一一對(duì)應(yīng)的數(shù)據(jù)記錄的被訪問(wèn)次數(shù)的集合，τ為閾值。如果存在cn＞τ,cn∈C，則與之對(duì)應(yīng)的數(shù)據(jù)記錄dn∈D為熱數(shù)據(jù)；反之，則為冷數(shù)據(jù)。cn越大，數(shù)據(jù)dn的熱度越高。

在實(shí)驗(yàn)中模擬了Key-Value型數(shù)據(jù)庫(kù)的操作過(guò)程。在本文的策略中，數(shù)據(jù)庫(kù)執(zhí)行過(guò)程中會(huì)記錄每一條數(shù)據(jù)記錄的訪問(wèn)次數(shù)，并保存在一個(gè)Map結(jié)構(gòu)中。在本文的算法中，日志記錄的格式如圖2（a）中所示。在日志內(nèi)容中除了記錄該數(shù)據(jù)的鍵和值外，還記錄該數(shù)據(jù)的熱度。數(shù)據(jù)記錄的熱度為該數(shù)據(jù)記錄在最近一次檢查點(diǎn)中所記錄的操作次數(shù)。如圖3所示為數(shù)據(jù)庫(kù)執(zhí)行過(guò)程的簡(jiǎn)易示意圖。t0為完成一次一致性檢查點(diǎn)的時(shí)刻。在t0至t1時(shí)間內(nèi)數(shù)據(jù)庫(kù)執(zhí)行過(guò)程中，數(shù)據(jù)記錄每被訪問(wèn)一次，就將該數(shù)據(jù)的操作次數(shù)自增1。在t1至t2時(shí)間內(nèi)檢查點(diǎn)制作過(guò)程中，將該數(shù)據(jù)的被訪問(wèn)次數(shù)作為該數(shù)據(jù)的熱度跟數(shù)據(jù)記錄一并傳輸?shù)酱疟P中。從t2開始到下一次檢查點(diǎn)之前，日志中數(shù)據(jù)熱度即為前一次檢查點(diǎn)時(shí)該數(shù)據(jù)的操作次數(shù)。如果某一數(shù)據(jù)是在此時(shí)間段內(nèi)新增數(shù)據(jù)，則其熱度置為零，并記錄其操作次數(shù)。在t3時(shí)刻發(fā)生故障后，數(shù)據(jù)庫(kù)進(jìn)入恢復(fù)階段。恢復(fù)階段根據(jù)熱度來(lái)劃分檢查點(diǎn)數(shù)據(jù)和日志數(shù)據(jù)。

在傳統(tǒng)的一致性檢查點(diǎn)中，只會(huì)記錄包括版本號(hào)在內(nèi)的頭部信息以及該時(shí)刻數(shù)據(jù)庫(kù)中數(shù)據(jù)的內(nèi)容。由于其沒(méi)有對(duì)熱數(shù)據(jù)進(jìn)行特殊劃分，因此無(wú)法保證故障恢復(fù)時(shí)的工作負(fù)載均衡。在本文方案中，在檢查點(diǎn)中還設(shè)置兩個(gè)全局參數(shù)D和C。其中，D記錄該時(shí)刻數(shù)據(jù)庫(kù)中的數(shù)據(jù)記錄的總數(shù)，C記錄從前一次檢查點(diǎn)到該時(shí)刻數(shù)據(jù)庫(kù)的總的操作次數(shù)。在制作檢查點(diǎn)時(shí)，這些信息將被放在檢查點(diǎn)頭部傳輸?shù)酱疟P中。檢查點(diǎn)格式如圖2（b）所示。

Fig.2 Log and checkpoint with popularity record圖2 帶有熱度記錄的日志和檢查點(diǎn)

在本文的方案中，總的數(shù)據(jù)量D，總的操作次數(shù)C以及每一個(gè)數(shù)據(jù)條目的操作次數(shù)均使用64位無(wú)符號(hào)整數(shù)來(lái)代替。

Fig.3 Database execution process圖3 數(shù)據(jù)庫(kù)執(zhí)行過(guò)程

3 故障恢復(fù)算法

3.1 整體介紹

首先介紹命令日志恢復(fù)實(shí)驗(yàn)的算法框架，如圖1所示。首先加載線程會(huì)從磁盤中加載檢查點(diǎn)數(shù)據(jù)到命令隊(duì)列。檢查點(diǎn)數(shù)據(jù)加載完畢后，向命令隊(duì)列發(fā)送一條結(jié)束指令，以表示檢查點(diǎn)數(shù)據(jù)加載完畢。隨后，加載線程加載命令日志數(shù)據(jù)，并將其數(shù)據(jù)追加到命令隊(duì)列。日志數(shù)據(jù)加載完畢后，加載線程同樣會(huì)發(fā)送一條結(jié)束指令到命令隊(duì)列，表示加載日志數(shù)據(jù)結(jié)束。就此，加載過(guò)程結(jié)束。

然后，分發(fā)命令的線程用熱度記錄分發(fā)策略將數(shù)據(jù)從命令隊(duì)列中取出并送入相應(yīng)的命令子隊(duì)列。命令分發(fā)算法為本程序的核心算法，而且檢查點(diǎn)數(shù)據(jù)的分發(fā)算法與日志數(shù)據(jù)的分發(fā)算法有些不同，兩種命令分發(fā)算法以加載時(shí)的結(jié)束指令為分界。命令分發(fā)過(guò)程的流程圖如圖4所示。命令分發(fā)算法單獨(dú)做介紹。

在分發(fā)命令結(jié)束后，各個(gè)NUMA節(jié)點(diǎn)上的執(zhí)行命令的線程不斷地從相應(yīng)命令子隊(duì)列中取出指令并執(zhí)行，將數(shù)據(jù)恢復(fù)到本地內(nèi)存中，每一個(gè)執(zhí)行命令的線程為Redis進(jìn)程。如此一來(lái)，數(shù)據(jù)庫(kù)恢復(fù)過(guò)程結(jié)束，數(shù)據(jù)庫(kù)恢復(fù)到了故障發(fā)生前的一致性狀態(tài)。

下面介紹檢查點(diǎn)數(shù)據(jù)和日志數(shù)據(jù)的命令分發(fā)算法。

3.2 檢查點(diǎn)數(shù)據(jù)的分發(fā)算法

由于檢查點(diǎn)數(shù)據(jù)具有熱度記錄，因此可以根據(jù)數(shù)據(jù)的熱度記錄采用與NUMA常規(guī)方案不同的方式分發(fā)數(shù)據(jù)。

首先，計(jì)算數(shù)據(jù)熱度的閾值τ。此處可以根據(jù)檢查點(diǎn)數(shù)據(jù)的頭部記錄中檢查點(diǎn)數(shù)據(jù)記錄的總量D和操作總次數(shù)C，以及設(shè)定的影響因子α，得到τ=(C/D)×α。則根據(jù)數(shù)據(jù)熱度的定義，操作次數(shù)大于τ的數(shù)據(jù)記錄屬于熱數(shù)據(jù)。

Fig.4 Command distribution thread flow chart圖4 命令分發(fā)線程流程圖

同時(shí)，每一個(gè)命令子隊(duì)列也會(huì)記錄該子隊(duì)列中的數(shù)據(jù)的操作總次數(shù)。如果從命令隊(duì)列中取出的數(shù)據(jù)記錄是熱數(shù)據(jù)，則動(dòng)態(tài)地將其分發(fā)到當(dāng)前操作總次數(shù)最少的命令子隊(duì)列，并將該熱數(shù)據(jù)的key和分發(fā)到的命令子隊(duì)列的序號(hào)i保存在為熱數(shù)據(jù)創(chuàng)建的哈希表Map中。否則，根據(jù)其key值計(jì)算出哈希值，并分發(fā)到該哈希值相應(yīng)的命令子隊(duì)列中。當(dāng)從命令隊(duì)列中取到結(jié)束指令時(shí)，檢查點(diǎn)數(shù)據(jù)分發(fā)結(jié)束。該算法如算法1所示。

算法1檢查點(diǎn)數(shù)據(jù)的命令分發(fā)算法

輸入：Ci，第i個(gè)線程所持有的數(shù)據(jù)在檢查點(diǎn)中記錄的操作次數(shù)之和；C，檢查點(diǎn)中存放的所有操作次數(shù)之和；D，檢查點(diǎn)中所存放的數(shù)據(jù)條目數(shù)量；α，影響因子；Q，命令隊(duì)列；Qi，命令子隊(duì)列；Hi，命令子隊(duì)列Qi在堆H中的位；Map，哈希表，鍵為熱數(shù)據(jù)的鍵，值為其分配的命令子隊(duì)列的序號(hào)。

輸出：命令子隊(duì)列Qi。

1.Distribute_data_in_checkpoint():

2.τ=(C/D)×α

3.whileDATA=Q.top_and_pop：

4.ifDATA.N＞τ:

5.i=min(H)

6.Map[DATA.key]=i

7.else:

8.i=hash(DATA.key)%H.size()

9.H[Hi]+=N

10.Qi.push(DATA)

3.3 日志數(shù)據(jù)的命令分發(fā)算法

加載完檢查點(diǎn)數(shù)據(jù)后，數(shù)據(jù)庫(kù)恢復(fù)到了故障發(fā)生前最近一次一致性檢查點(diǎn)完成時(shí)的狀態(tài)。檢查點(diǎn)數(shù)據(jù)也就是數(shù)據(jù)庫(kù)在該檢查點(diǎn)完成時(shí)刻的數(shù)據(jù)庫(kù)中的數(shù)據(jù)。隨后的日志為對(duì)這些數(shù)據(jù)的各種操作。日志恢復(fù)期間將所獲取到的命令日志按序執(zhí)行。此過(guò)程中，有可能會(huì)重復(fù)更新某條數(shù)據(jù)，且有可能增加新數(shù)據(jù)或刪除已有數(shù)據(jù)。

日志恢復(fù)期間的命令分發(fā)算法如算法2所示。

首先從命令隊(duì)列Q中獲取命令。命令有可能是范圍操作，如果是范圍操作，則向每一個(gè)命令子隊(duì)列發(fā)送此命令；如果不是，再判斷其是否為熱數(shù)據(jù)的訪問(wèn)操作。如果是，則從哈希表Map中取其分配的命令子隊(duì)列序號(hào)i；如果不是熱數(shù)據(jù)的操作，則計(jì)算其哈希值，得到其分發(fā)的子隊(duì)列的序號(hào)i。最后將其分發(fā)到命令子隊(duì)列i中。

算法2命令日志數(shù)據(jù)的命令分發(fā)算法

輸入：Q，命令隊(duì)列；Qi，命令子隊(duì)列；Map，哈希表，鍵為熱數(shù)據(jù)的鍵，值為被分配的命令子隊(duì)列的序號(hào)。

輸出：命令子隊(duì)列Qi。

1.Distribute_data_in_log():

2.whileCMD=Q.top_and_pop():

3.ifCMDis a range command:

4.Q[every].push(CMD)

5.ifCMD.N>τ:

6.QMap[CMD.KEY].push(CMD)

7.else:

8.Qhash(CMD.KEY).push(CMD)

4 實(shí)驗(yàn)及結(jié)果分析

4.1 實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)在內(nèi)核版本為4.13.0的Ubuntu 16.04系統(tǒng)中實(shí)現(xiàn)NUMA架構(gòu)下基于熱度的內(nèi)存數(shù)據(jù)庫(kù)日志恢復(fù)算法。所用主機(jī)是配有4個(gè)NUMA節(jié)點(diǎn)的服務(wù)器（結(jié)構(gòu)見(jiàn)圖5）。該服務(wù)器的詳細(xì)配置如表1所示。

Fig.5 Server structure圖5 服務(wù)器結(jié)構(gòu)

Table1 Detailed server configuration information表1 服務(wù)器詳細(xì)配置信息

4.2 實(shí)驗(yàn)負(fù)載參數(shù)

實(shí)驗(yàn)中所用命令日志和檢查點(diǎn)數(shù)據(jù)另由一個(gè)程序產(chǎn)生，并保存在磁盤中。其中，數(shù)據(jù)記錄的鍵為64位無(wú)符號(hào)整型數(shù)組成的字符串，值為大小為512 Byte至1 024 Byte的隨機(jī)字符組成的字符串。命令日志中數(shù)據(jù)的鍵由檢查點(diǎn)數(shù)據(jù)中數(shù)據(jù)記錄的鍵按正態(tài)分布規(guī)律訪問(wèn)而得，符合數(shù)據(jù)庫(kù)的日常訪問(wèn)規(guī)律。如圖6所示，橫坐標(biāo)的整數(shù)值表示數(shù)據(jù)記錄的鍵的值，數(shù)據(jù)記錄的鍵互不重復(fù)，而且相鄰兩個(gè)鍵相差為1，縱坐標(biāo)表示該數(shù)據(jù)的訪問(wèn)次數(shù)，訪問(wèn)次數(shù)超過(guò)τ的數(shù)據(jù)為熱數(shù)據(jù)。這樣，檢查點(diǎn)中數(shù)據(jù)記錄的數(shù)量可理解為圖6中左右邊界A和B中整數(shù)點(diǎn)的數(shù)量，日志數(shù)量為這些離散點(diǎn)的縱坐標(biāo)值之和。實(shí)驗(yàn)中通過(guò)調(diào)整檢查點(diǎn)數(shù)據(jù)記錄的數(shù)量、命令日志數(shù)量、影響因子α以及正態(tài)分布函數(shù)的參數(shù)σ2來(lái)產(chǎn)生不同的實(shí)驗(yàn)數(shù)據(jù)。

Fig.6 Key access rules in checkpoint data圖6 檢查點(diǎn)數(shù)據(jù)中鍵的訪問(wèn)規(guī)律

4.3 命令日志恢復(fù)實(shí)驗(yàn)

4.3.1 控制檢查點(diǎn)數(shù)據(jù)記錄數(shù)量不變

實(shí)驗(yàn)1中恢復(fù)所用數(shù)據(jù)是通過(guò)控制檢查點(diǎn)數(shù)據(jù)記錄的數(shù)量不變，針對(duì)不同的σ2產(chǎn)生的。該實(shí)驗(yàn)中的實(shí)驗(yàn)負(fù)載參數(shù)如表2所示。σ2會(huì)影響正態(tài)分布曲線的陡峭程度。

Table2 Experiment 1 load parameters表2 實(shí)驗(yàn)1負(fù)載參數(shù)

由于控制檢查點(diǎn)數(shù)據(jù)記錄的數(shù)量不變，數(shù)據(jù)記錄的鍵的分布區(qū)域的邊界已固定，σ2越小時(shí)，正態(tài)分布曲線越陡，產(chǎn)生的日志數(shù)量也越多，因此恢復(fù)所需時(shí)間也就越多。圖7為檢查點(diǎn)數(shù)據(jù)記錄的數(shù)量為1.0×105，命令日志恢復(fù)實(shí)驗(yàn)。其中橫坐標(biāo)為與其訪問(wèn)規(guī)律相關(guān)的參數(shù)σ2，縱坐標(biāo)為恢復(fù)時(shí)間，副縱坐標(biāo)表示檢查點(diǎn)數(shù)據(jù)記錄中熱數(shù)據(jù)記錄所占比例。從圖中可以看出，在本次實(shí)驗(yàn)中，雖然所產(chǎn)生日志數(shù)量各不相同，但針對(duì)每一數(shù)據(jù)，基于熱度記錄的內(nèi)存數(shù)據(jù)庫(kù)恢復(fù)策略比NUMA架構(gòu)的常規(guī)恢復(fù)策略要快，而且隨著σ2的增大，熱數(shù)據(jù)所占比有增長(zhǎng)的趨勢(shì)。圖8和圖9分別為檢查點(diǎn)數(shù)據(jù)記錄數(shù)量為5.0×105和1.0×106時(shí)的內(nèi)存數(shù)據(jù)庫(kù)日志恢復(fù)實(shí)驗(yàn)。這兩個(gè)實(shí)驗(yàn)中能發(fā)現(xiàn)同樣的規(guī)律。

Fig.7 Recovery time when checkpoint data number is1.0×105圖7 檢查點(diǎn)數(shù)據(jù)記錄數(shù)量為1.0×105時(shí)恢復(fù)時(shí)間

Fig.8 Recovery time when checkpoint data number is5.0×105圖8 檢查點(diǎn)數(shù)據(jù)記錄數(shù)量為5.0×105時(shí)恢復(fù)時(shí)間

Fig.9 Recovery time when checkpoint data number is1.0×106圖9 檢查點(diǎn)數(shù)據(jù)記錄數(shù)量為1.0×106時(shí)恢復(fù)時(shí)間

為了展示檢查點(diǎn)數(shù)據(jù)記錄數(shù)量不變時(shí)，不同的σ2產(chǎn)生的日志大小，實(shí)驗(yàn)中獲取了檢查點(diǎn)數(shù)據(jù)記錄數(shù)量為1.0×106，日志大小隨σ2而變化的情況，如表3所示。從表中可以看出，σ2越小，所產(chǎn)生的日志數(shù)據(jù)越多，恢復(fù)所需時(shí)間也將隨之越多，符合圖中所示實(shí)驗(yàn)結(jié)果。

Table3 σ2and log size when the number of checkpoint data is1.0×106表3 檢查點(diǎn)數(shù)據(jù)數(shù)量為1.0×106時(shí)σ2與日志大小

4.3.2 控制日志大小不變

實(shí)驗(yàn)2中恢復(fù)所用數(shù)據(jù)是控制日志數(shù)量不變，調(diào)整σ2的大小而產(chǎn)生的。該實(shí)驗(yàn)中，實(shí)驗(yàn)負(fù)載參數(shù)如表4所示。由于日志數(shù)量不變，為了產(chǎn)生數(shù)量固定的日志數(shù)據(jù)，圖6中檢查點(diǎn)數(shù)據(jù)的鍵的左右邊界會(huì)隨著σ2的增大而增大。

Table4 Experiment 2 load parameters表4 實(shí)驗(yàn)2負(fù)載參數(shù)

圖10和圖11分別為日志數(shù)量為1.0×107和5.0×107時(shí)的內(nèi)存數(shù)據(jù)庫(kù)日志恢復(fù)時(shí)間圖。此實(shí)驗(yàn)中日志數(shù)量保持不變，檢查點(diǎn)數(shù)據(jù)記錄的數(shù)量隨σ2的變化而不同。兩張圖的恢復(fù)時(shí)間的變化趨勢(shì)基本類似，即σ2較小時(shí)，兩種恢復(fù)策略的恢復(fù)時(shí)間差值較大，熱數(shù)據(jù)策略相對(duì)常規(guī)策略的恢復(fù)速度的提升比例較大，最大提升為19%。隨著σ2的增大，兩種策略的恢復(fù)時(shí)間越來(lái)越接近。本實(shí)驗(yàn)中由于日志數(shù)量保持不變，在σ2較小時(shí)，數(shù)據(jù)訪問(wèn)規(guī)律的正態(tài)分布曲線比較陡，訪問(wèn)的數(shù)據(jù)比較集中。此時(shí)，各個(gè)執(zhí)行恢復(fù)操作的線程的負(fù)載不均衡度越高?；跓岫扔涗浀幕謴?fù)策略可以很好地做到負(fù)載均衡。此時(shí)，恢復(fù)性能的提升較高。隨著σ2的增大，數(shù)據(jù)庫(kù)對(duì)數(shù)據(jù)的訪問(wèn)越來(lái)越分散，正態(tài)分布曲線越來(lái)越平緩，導(dǎo)致NUMA架構(gòu)下常規(guī)策略的執(zhí)行恢復(fù)操作的線程的負(fù)載越來(lái)越趨向均衡。因此，常規(guī)策略的恢復(fù)時(shí)間會(huì)越來(lái)越少。熱數(shù)據(jù)策略為負(fù)載均衡所做的開銷逐漸成為劣勢(shì)。因此，隨著σ2的增大，熱數(shù)據(jù)策略的恢復(fù)性能提升比例越來(lái)越小，兩種策略的恢復(fù)時(shí)間越來(lái)越接近。圖中，σ2的值為1.0×106時(shí)的兩種恢復(fù)策略所用時(shí)間都明顯高于前面幾組的恢復(fù)時(shí)間。這是因?yàn)?，在?shí)驗(yàn)2中由于固定日志數(shù)量不變，當(dāng)σ2較小時(shí)，所產(chǎn)生的檢查點(diǎn)數(shù)據(jù)記錄的數(shù)量很小，加載檢查點(diǎn)數(shù)據(jù)的時(shí)間對(duì)整體恢復(fù)時(shí)間來(lái)說(shuō)可忽略。但從σ2的值為1.0×105開始，檢查點(diǎn)數(shù)據(jù)記錄的數(shù)量為日志數(shù)量的5.2%，σ2的值為1.0×106時(shí)為37.3%。此時(shí)的檢查點(diǎn)數(shù)據(jù)的加載時(shí)間會(huì)導(dǎo)致整體的數(shù)據(jù)庫(kù)恢復(fù)時(shí)間增大。

Fig.10 Recovery time when the number of logs is1.0×107圖10 日志數(shù)量為1.0×107時(shí)的恢復(fù)時(shí)間

Fig.11 Recovery time when the number of logs is5.0×107圖11 日志數(shù)量為5.0×107時(shí)的恢復(fù)時(shí)間

5 結(jié)束語(yǔ)

針對(duì)在面向數(shù)據(jù)設(shè)計(jì)的內(nèi)存數(shù)據(jù)庫(kù)系統(tǒng)中，NUMA體系架構(gòu)環(huán)境下進(jìn)行日志恢復(fù)時(shí)，因恢復(fù)線程負(fù)載不均衡而導(dǎo)致的恢復(fù)速度慢的問(wèn)題，本文提出了基于數(shù)據(jù)熱度的命令日志恢復(fù)算法。該算法利用數(shù)據(jù)的訪問(wèn)頻次將數(shù)據(jù)分為熱數(shù)據(jù)和非熱數(shù)據(jù)，將熱數(shù)據(jù)分配給相對(duì)空閑的恢復(fù)線程，有效解決了恢復(fù)線程負(fù)載不均衡的問(wèn)題。實(shí)驗(yàn)表明，在數(shù)據(jù)訪問(wèn)相對(duì)集中時(shí)，基于數(shù)據(jù)熱度的命令劃分方案比NUMA架構(gòu)的常規(guī)方案快，最高快19%?？梢缘贸觯贜UMA架構(gòu)下面向數(shù)據(jù)設(shè)計(jì)的內(nèi)存數(shù)據(jù)庫(kù)系統(tǒng)中，對(duì)數(shù)據(jù)的訪問(wèn)頻率相對(duì)集中的數(shù)據(jù)庫(kù)系統(tǒng)中，適合使用本文提出的基于熱度記錄的命令日志恢復(fù)策略，相反則適合使用NUMA架構(gòu)下的常規(guī)的平均劃分策略。在未來(lái)的研究中主要解決的問(wèn)題是在NUMA體系架構(gòu)環(huán)境下，面向數(shù)據(jù)設(shè)計(jì)的內(nèi)存數(shù)據(jù)庫(kù)中，提高數(shù)據(jù)的本地性，減少CPU跨節(jié)點(diǎn)訪問(wèn)遠(yuǎn)端內(nèi)存中的數(shù)據(jù)的問(wèn)題。