朱海銘，黃向東+，喬嘉林，王建民

1.清華大學(xué) 軟件學(xué)院，北京 100084

2.大數(shù)據(jù)系統(tǒng)軟件國家工程研究中心，北京 100084

預(yù)寫日志（write-ahead logging，WAL）[1]是一種能在設(shè)備故障中保障數(shù)據(jù)庫管理系統(tǒng)持久性和原子性的技術(shù)，所有對(duì)數(shù)據(jù)的修改都會(huì)在實(shí)際修改數(shù)據(jù)庫文件之前被記錄到預(yù)寫日志文件中。為減少磁盤的讀寫（input/output，I/O）開銷，數(shù)據(jù)庫通常會(huì)在內(nèi)存（memory）中緩存對(duì)數(shù)據(jù)的修改操作，在積累到一定量形成內(nèi)存表（memory table，MemTable）后再落入磁盤，如果數(shù)據(jù)庫在內(nèi)存表落盤前發(fā)生故障，內(nèi)存表中包含的數(shù)據(jù)就可能被丟失或損壞，預(yù)寫日志的用途就是保障這部分?jǐn)?shù)據(jù)的持久性和原子性。

預(yù)寫日志是寫入請(qǐng)求與磁盤交互的第一關(guān)，因此預(yù)寫日志的寫入吞吐能力基本決定了數(shù)據(jù)庫整體的寫入性能上限。因此，如何讓預(yù)寫日志在變化的應(yīng)用負(fù)載和計(jì)算環(huán)境下充分利用磁盤的I/O 性能成為了一個(gè)至關(guān)重要的問題。一般來講，優(yōu)化I/O性能可以從以下幾個(gè)方向入手[2]：（1）批量寫入，增大每次系統(tǒng)調(diào)用寫入的數(shù)據(jù)量；（2）將磁盤的隨機(jī)I/O 轉(zhuǎn)換為順序I/O；（3）提高寫入內(nèi)存的并發(fā)度。然而在很多NoSQL 數(shù)據(jù)庫的實(shí)現(xiàn)中，預(yù)寫日志和數(shù)據(jù)庫或數(shù)據(jù)分區(qū)間的對(duì)應(yīng)關(guān)系是強(qiáng)耦合的，如LevelDB[3]中預(yù)寫日志和數(shù)據(jù)庫實(shí)例形成一對(duì)一關(guān)系，InfluxDB[4]中預(yù)寫日志和數(shù)據(jù)分片（shard）形成一對(duì)一關(guān)系，Apache-IoTDB[5-6]中預(yù)寫日志和時(shí)間分區(qū)（time partition）形成一對(duì)一關(guān)系等。這種內(nèi)存表和預(yù)寫日志間強(qiáng)耦合的對(duì)應(yīng)關(guān)系恰恰無法利用上述的優(yōu)化手段，限制了數(shù)據(jù)庫在預(yù)寫日志上針對(duì)I/O 性能進(jìn)行調(diào)優(yōu)的可能性。當(dāng)內(nèi)存表數(shù)量因應(yīng)用業(yè)務(wù)或計(jì)算環(huán)境發(fā)生變更而變化時(shí)，與之耦合的預(yù)寫日志的資源占用會(huì)一同發(fā)生變更，寫入請(qǐng)求被分散到不同的預(yù)寫日志上，不僅無法進(jìn)行批量寫入，還降低了同一預(yù)寫日志中內(nèi)存寫入的并發(fā)度。在極端情況下（如預(yù)寫日志數(shù)量達(dá)數(shù)千量級(jí)），零落分散的預(yù)寫日志還會(huì)產(chǎn)生大量磁盤隨機(jī)I/O，造成性能下降[7]。雖然當(dāng)前有部分?jǐn)?shù)據(jù)庫系統(tǒng)考慮到了將預(yù)寫日志與內(nèi)存表解耦（如HBase[8]），但它們的解耦方式不僅無法在運(yùn)行時(shí)動(dòng)態(tài)調(diào)整預(yù)寫日志數(shù)量，還存在著因主動(dòng)觸發(fā)低頻數(shù)據(jù)內(nèi)存表落盤而導(dǎo)致查詢效率下降的缺陷。

針對(duì)上述問題，本文基于預(yù)寫日志中的重寫日志（Redo log）[9]，提出了一種面向內(nèi)存表的可動(dòng)態(tài)配置日志框架：將預(yù)寫日志和內(nèi)存表解耦，內(nèi)存表可以動(dòng)態(tài)地被分配給不同的預(yù)寫日志隊(duì)列，支持可變的對(duì)應(yīng)關(guān)系。預(yù)寫日志模塊的資源占用更易控制，當(dāng)計(jì)算環(huán)境和應(yīng)用負(fù)載發(fā)生變化時(shí)，能夠在不重啟的情況下通過簡單地調(diào)整預(yù)寫日志的配置來快速實(shí)現(xiàn)動(dòng)態(tài)性能調(diào)優(yōu)?？蚣苁褂脙?nèi)存表快照來避免現(xiàn)有方案中主動(dòng)觸發(fā)低頻數(shù)據(jù)內(nèi)存表落盤帶來的查詢性能損失，既能控制日志文件的總大小，又能保障較高的查詢效率。同時(shí)，本文在使用日志結(jié)構(gòu)合并樹（logstructured merge-tree，LSM-tree）[10-11]的Apache IoTDB上實(shí)現(xiàn)了預(yù)寫日志框架，并在合成的數(shù)據(jù)集和工作負(fù)載上進(jìn)行了相關(guān)實(shí)驗(yàn)。實(shí)驗(yàn)結(jié)果表明：（1）與強(qiáng)耦合的預(yù)寫日志方案相比，該框架能夠更好地適配不同的計(jì)算環(huán)境和應(yīng)用負(fù)載，通過調(diào)整預(yù)寫日志數(shù)量獲取最佳的寫入性能；（2）與已有的解耦方案相比，該框架不僅能夠在不重啟的情況下進(jìn)行動(dòng)態(tài)配置，還能在幾乎不影響寫入效率的同時(shí)更好地保障低頻數(shù)據(jù)的查詢效率。

1 相關(guān)工作

本文調(diào)研了多個(gè)使用LSM-tree 的存儲(chǔ)系統(tǒng)，包括LevelDB、InfluxDB、Apache IoTDB、HBase等。

LevelDB中預(yù)寫日志和數(shù)據(jù)庫實(shí)例個(gè)數(shù)相耦合，每個(gè)數(shù)據(jù)庫實(shí)例對(duì)應(yīng)一個(gè)預(yù)寫日志。當(dāng)寫入請(qǐng)求增多時(shí)，預(yù)寫日志很容易成為性能瓶頸，必須通過增加數(shù)據(jù)庫實(shí)例個(gè)數(shù)來提高寫入速度，而過多的數(shù)據(jù)庫實(shí)例又會(huì)產(chǎn)生大量磁盤隨機(jī)I/O，造成寫入效率下降，可配置性差。

InfluxDB中預(yù)寫日志和數(shù)據(jù)分片個(gè)數(shù)耦合，每個(gè)正在寫入的數(shù)據(jù)分片都會(huì)有自己對(duì)應(yīng)的預(yù)寫日志文件。和LevelDB相比，InfluxDB的預(yù)寫日志管理粒度更細(xì)致，因此更容易因計(jì)算環(huán)境和應(yīng)用負(fù)載變更暴露性能問題，當(dāng)數(shù)據(jù)分片數(shù)量增加時(shí)，內(nèi)存占用和I/O任務(wù)數(shù)會(huì)同時(shí)線性增加。

Apache IoTDB 和InfluxDB 類似，其預(yù)寫日志和正在寫入的數(shù)據(jù)文件個(gè)數(shù)耦合。除了存在與Influx-DB相同的問題外，IoTDB在開啟時(shí)間分區(qū)功能后，由于其不恰當(dāng)?shù)念A(yù)寫日志內(nèi)存管理機(jī)制，系統(tǒng)甚至可能因?yàn)榘l(fā)生內(nèi)存溢出（out of memory，OOM）而進(jìn)入不可用狀態(tài)，開啟時(shí)間分區(qū)后的系統(tǒng)可用性較差。

HBase雖然考慮了預(yù)寫日志與內(nèi)存表的解耦，但其實(shí)現(xiàn)的解耦方案不夠徹底，且?guī)砹瞬樵冃式档?、文件合并（compaction）[12]開銷大的隱患。在當(dāng)前實(shí)現(xiàn)中，Hbase包含多個(gè)HRegionServer，每個(gè)HRegion-Server 包括HRegion 和HLog（對(duì)應(yīng)預(yù)寫日志）兩部分，每個(gè)HRegion 中包含多個(gè)MemStore（對(duì)應(yīng)內(nèi)存表），系統(tǒng)啟動(dòng)時(shí)可以指定HLog 實(shí)例的個(gè)數(shù)，每個(gè)HRegion 在創(chuàng)建時(shí)被固定地分配一個(gè)HLog 實(shí)例，在系統(tǒng)運(yùn)行時(shí)永不變更。這樣的解耦方案主要有兩個(gè)缺點(diǎn)：首先，由于HRegion和HLog之間的關(guān)系在運(yùn)行時(shí)是固定的，當(dāng)系統(tǒng)啟動(dòng)后，HLog 的個(gè)數(shù)無法變更，計(jì)算環(huán)境和應(yīng)用負(fù)載變化后只能通過重啟系統(tǒng)來調(diào)整預(yù)寫日志；其次，HBase將多個(gè)MemStore的數(shù)據(jù)集中管理，當(dāng)某個(gè)MemStore中的數(shù)據(jù)積累過慢時(shí)，預(yù)寫日志很容易占用大量的磁盤空間。為了避免歷史數(shù)據(jù)的大量累積，HBase 會(huì)通過觸發(fā)這些MemStore 的落盤來刪除歷史數(shù)據(jù)。由于這些MemStore通常保存著低頻數(shù)據(jù)，這樣粗放的管理方式會(huì)導(dǎo)致磁盤上產(chǎn)生很多小文件，不僅會(huì)大幅降低查詢效率，還加重文件合并的負(fù)擔(dān)。

因此，本文提出的預(yù)寫日志框架需要解決以下三點(diǎn)問題：（1）將預(yù)寫日志與數(shù)據(jù)庫邏輯模型、分區(qū)配置等解耦；（2）可在運(yùn)行時(shí)動(dòng)態(tài)配置預(yù)寫日志，無需停機(jī)重啟；（3）在保障讀寫性能的同時(shí)，使日志的磁盤占用總量可控可治。

2 預(yù)寫日志框架

2.1 架構(gòu)概述

如圖1所示，每個(gè)預(yù)寫日志隊(duì)列包含一個(gè)阻塞隊(duì)列、兩個(gè)緩沖區(qū)、多個(gè)日志數(shù)據(jù)文件（.wal 文件）和一個(gè)日志控制文件（.ctrl文件）。

圖1 預(yù)寫日志框架架構(gòu)Fig.1 Architecture of write-ahead logging framework

（1）阻塞隊(duì)列。為了增大每次系統(tǒng)調(diào)用寫入的數(shù)據(jù)量，使用阻塞隊(duì)列緩存內(nèi)存表的數(shù)據(jù)項(xiàng)。序列化任務(wù)從隊(duì)列中批量取出數(shù)據(jù)項(xiàng)，序列化至緩沖區(qū)后落盤至預(yù)寫日志文件中。

（2）緩沖區(qū)。為增加并發(fā)度，從物理上將緩沖區(qū)分為大小相等的兩塊，分別用于序列化和落盤。存在兩類后臺(tái)線程，序列化線程負(fù)責(zé)將數(shù)據(jù)項(xiàng)序列化到序列化緩沖區(qū)中，磁盤同步線程負(fù)責(zé)將落盤緩沖區(qū)同步到磁盤。當(dāng)序列化緩沖區(qū)需要落盤時(shí)，序列化線程會(huì)阻塞直至落盤緩沖區(qū)落盤成功，然后交換兩個(gè)緩沖區(qū)，清空已落盤的緩沖區(qū)用于保存新的序列化數(shù)據(jù)，最后通知磁盤同步線程將序列化好的緩沖區(qū)落盤。

（3）日志文件。預(yù)寫日志的數(shù)據(jù)項(xiàng)和控制項(xiàng)分開存儲(chǔ)，便于重啟時(shí)快速恢復(fù)控制信息。一個(gè)預(yù)寫日志隊(duì)列下會(huì)有多個(gè)日志數(shù)據(jù)文件和一個(gè)日志控制文件，日志數(shù)據(jù)文件存儲(chǔ)一個(gè)或多個(gè)內(nèi)存表中的數(shù)據(jù)項(xiàng)，日志控制文件存儲(chǔ)內(nèi)存表的創(chuàng)建和落盤信息。

預(yù)寫日志的個(gè)數(shù)可靈活配置，內(nèi)存表被動(dòng)態(tài)地分配給不同的預(yù)寫日志隊(duì)列，形成可變的對(duì)應(yīng)關(guān)系，即一個(gè)預(yù)寫日志隊(duì)列可以處理任意數(shù)量內(nèi)存表的預(yù)寫日志。

2.2 日志數(shù)據(jù)文件和日志控制文件

日志數(shù)據(jù)文件保存數(shù)據(jù)項(xiàng)二元組，記錄數(shù)據(jù)項(xiàng)D信息及其對(duì)應(yīng)內(nèi)存表B的編號(hào)，通過該二元組即可確定數(shù)據(jù)項(xiàng)和內(nèi)存表間的索引關(guān)系。每個(gè)日志數(shù)據(jù)文件都有自己的文件號(hào)，文件號(hào)是一個(gè)遞增的正整數(shù)編號(hào)，用于維護(hù)日志數(shù)據(jù)文件間的相對(duì)順序。每個(gè)預(yù)寫日志隊(duì)列下只有一個(gè)正在寫入的日志數(shù)據(jù)文件，當(dāng)該文件的大小超過指定閾值后，將文件號(hào)自增，并滾動(dòng)至下一個(gè)日志數(shù)據(jù)文件。滾動(dòng)文件的大小閾值決定了日志數(shù)據(jù)文件刪除的粒度，閾值越大，刪除操作的粒度更粗，更容易造成數(shù)據(jù)文件的積累。

日志控制文件保存內(nèi)存表的相關(guān)信息，包括內(nèi)存表的編號(hào)、落盤的目標(biāo)文件和其初始數(shù)據(jù)項(xiàng)所在日志數(shù)據(jù)文件的編號(hào)。其中主要包含以下兩種日志信息類型：（1）表示內(nèi)存中新建了內(nèi)存表B；（2）表示內(nèi)存表B已成功落盤，其對(duì)應(yīng)的預(yù)寫日志可以被安全地刪除。

數(shù)據(jù)項(xiàng)和信息項(xiàng)的落盤順序必須滿足以下條件：（1）只有在信息項(xiàng)落盤后，內(nèi)存表B才可以進(jìn)行數(shù)據(jù)寫入，即所有數(shù)據(jù)項(xiàng)D會(huì)在該信息項(xiàng)后落盤；（2）在內(nèi)存表B落盤后，再記錄信息項(xiàng)。條件（1）保障內(nèi)存表的所有數(shù)據(jù)都會(huì)在其創(chuàng)建后被保存到預(yù)寫日志中，條件（2）保障內(nèi)存表在預(yù)寫日志中的數(shù)據(jù)備份會(huì)一直保留直至其成功落盤，兩個(gè)條件共同保證了數(shù)據(jù)的持久性。

重啟恢復(fù)時(shí)先讀取日志控制文件，確定需要恢復(fù)的內(nèi)存表（有創(chuàng)建信息但無落盤信息），然后讀取日志數(shù)據(jù)文件，過濾出待恢復(fù)的數(shù)據(jù)項(xiàng)，將數(shù)據(jù)項(xiàng)重新組成內(nèi)存表后落盤即可。

2.3 日志數(shù)據(jù)文件的刪除

（1）理想情況。如圖2（a）所示，在理想的刪除流程下，只需要比較所有未落盤內(nèi)存表初始數(shù)據(jù)項(xiàng)所在文件的編號(hào)，獲取其中最小的文件編號(hào)，然后刪除該編號(hào)前的所有無效日志數(shù)據(jù)文件即可。

圖2 日志數(shù)據(jù)文件刪除Fig.2 Logging data file deletion

（2）非理想情況。單個(gè)數(shù)據(jù)文件中包含一個(gè)或多個(gè)內(nèi)存表的數(shù)據(jù)，因此在非理想情況下（如圖2（b）所示），只要有一個(gè)內(nèi)存表未落盤，那么這個(gè)數(shù)據(jù)文件就無法被刪除。因此，如果存在內(nèi)存表數(shù)據(jù)積累過慢的情況，那么預(yù)寫日志就會(huì)占用大量磁盤空間。HBase 采用主動(dòng)觸發(fā)內(nèi)存表的落盤來釋放預(yù)寫日志的磁盤占用，但是這種額外觸發(fā)落盤的行為會(huì)大幅降低查詢效率[13]，因此本文考慮通過在預(yù)寫日志中引入內(nèi)存表的快照來避免小內(nèi)存表的落盤。對(duì)內(nèi)存表做快照后，其全量信息被保存在最新的日志數(shù)據(jù)文件中，通過更新初始數(shù)據(jù)項(xiàng)所在的文件編號(hào)就可以安全地刪除大量積累的舊日志數(shù)據(jù)文件。由于做快照和正常寫入流程一樣使用預(yù)寫日志隊(duì)列的緩沖區(qū)進(jìn)行序列化，不會(huì)產(chǎn)生額外的內(nèi)存開銷。

此外，預(yù)寫日志文件的磁盤占用和內(nèi)存大小正相關(guān)，當(dāng)內(nèi)存表占用的內(nèi)存總量上升時(shí)，其對(duì)應(yīng)的預(yù)寫日志磁盤占用也會(huì)上升，因此單純使用磁盤占用大小來觸發(fā)數(shù)據(jù)表的快照是不合適的。本文通過計(jì)算日志數(shù)據(jù)文件中有效信息的占比來控制預(yù)寫日志的磁盤占用，每次滾動(dòng)數(shù)據(jù)文件時(shí)計(jì)算有效信息占比，當(dāng)占比低于給定閾值時(shí)，主動(dòng)觸發(fā)內(nèi)存表的快照釋放文件占用，進(jìn)而清理無效文件減少磁盤占用。其中，有效信息占比的計(jì)算方式為sizememory/(sizememory+sizedisk)，這里可以直接使用內(nèi)存大小指代磁盤大小，因?yàn)閮?nèi)存表大小sizememory與其磁盤占用大小sizedisk間存在固定的放縮比γ，即sizedisk=γ×sizememory。計(jì)算sizememory值可以通過對(duì)當(dāng)前所有內(nèi)存表的大小直接求和獲得。計(jì)算sizedisk需要額外給每個(gè)日志數(shù)據(jù)文件維護(hù)一個(gè)內(nèi)存統(tǒng)計(jì)值，該統(tǒng)計(jì)值記錄了日志數(shù)據(jù)文件從開始寫入到封口期間所有落盤內(nèi)存表的大小之和，這樣就可以將對(duì)sizedisk的計(jì)算轉(zhuǎn)換為對(duì)當(dāng)前所有日志數(shù)據(jù)文件的內(nèi)存統(tǒng)計(jì)值的求和。

2.4 在Apache IoTDB中的實(shí)現(xiàn)

SSTable 是LSM-tree 中的關(guān)鍵數(shù)據(jù)結(jié)構(gòu)，用于保存一塊連續(xù)的數(shù)據(jù)，所有寫請(qǐng)求在寫入預(yù)寫日志后再寫入內(nèi)存中的SSTable，這就構(gòu)成了本文中預(yù)寫日志和內(nèi)存表之間的對(duì)應(yīng)關(guān)系。因此，只需要在任意一個(gè)基于LSM-tree實(shí)現(xiàn)的數(shù)據(jù)庫管理系統(tǒng)中實(shí)現(xiàn)本文提出的框架，就能驗(yàn)證該框架的有效性。

本文選取Apache IoTDB 實(shí)現(xiàn)了預(yù)寫日志框架。Apache IoTDB是基于LSM-tree實(shí)現(xiàn)的，一體化收集、存儲(chǔ)、管理與分析物聯(lián)網(wǎng)時(shí)序數(shù)據(jù)的開源時(shí)序數(shù)據(jù)庫管理系統(tǒng)[14]。在Apache IoTDB 中，每個(gè)時(shí)間分區(qū)擁有一個(gè)內(nèi)存表，預(yù)寫日志和內(nèi)存表一一綁定，當(dāng)內(nèi)存表數(shù)量因計(jì)算環(huán)境和應(yīng)用負(fù)載發(fā)生變更而變化時(shí)，預(yù)寫日志的資源占用隨之產(chǎn)生波動(dòng)，很容易發(fā)生內(nèi)存溢出和性能下降。在實(shí)現(xiàn)該框架后，預(yù)寫日志和內(nèi)存表解耦，可針對(duì)不同計(jì)算環(huán)境和應(yīng)用負(fù)載靈活調(diào)整出最佳實(shí)踐方案，下面將用實(shí)驗(yàn)證明該結(jié)論。

3 實(shí)驗(yàn)分析

本章首先驗(yàn)證了不同應(yīng)用負(fù)載和計(jì)算環(huán)境下，預(yù)寫日志隊(duì)列數(shù)量對(duì)寫入性能的影響，證明框架能夠在不同場景下找到最佳的配置方案。其次，設(shè)計(jì)實(shí)驗(yàn)對(duì)比為低頻內(nèi)存表做快照和直接刷盤相比讀寫性能的差異，證明與現(xiàn)有方案使用的刷盤策略相比，本文提出的快照策略能夠在幾乎不影響寫入效率的同時(shí)更好地保障查詢速度。

3.1 實(shí)驗(yàn)環(huán)境與數(shù)據(jù)

本節(jié)的所有實(shí)驗(yàn)都使用一臺(tái)配置如表1 的服務(wù)器，并使用時(shí)序數(shù)據(jù)庫性能測試工具IoTDBBenchmark[15]統(tǒng)計(jì)寫入和查詢的效率。在同一臺(tái)服務(wù)器上部署IoTDB-Benchmark 和Apache IoTDB，使用IoTDB-Benchmark 生成數(shù)據(jù)集，為每個(gè)內(nèi)存表創(chuàng)建40 000 條時(shí)間序列（40 個(gè)設(shè)備，每個(gè)設(shè)備下1 000 個(gè)測點(diǎn)），并在每條時(shí)間序列內(nèi)寫入10 000個(gè)數(shù)據(jù)點(diǎn)。

表1 實(shí)驗(yàn)環(huán)境Table 1 Experimental environment

3.2 不同應(yīng)用負(fù)載和計(jì)算環(huán)境寫入性能對(duì)比

本實(shí)驗(yàn)通過變化內(nèi)存表數(shù)量模擬不同的應(yīng)用負(fù)載，通過固態(tài)硬盤（solid state disk，SSD）和機(jī)械硬盤兩種設(shè)備模擬不同的計(jì)算環(huán)境。分別在25 個(gè)內(nèi)存表（占用4 GB內(nèi)存，對(duì)應(yīng)圖3（a））、50個(gè)內(nèi)存表（占用8 GB 內(nèi)存，對(duì)應(yīng)圖3（b））、100 個(gè)內(nèi)存表（占用16 GB內(nèi)存，對(duì)應(yīng)圖3（c））下對(duì)寫入性能進(jìn)行測試，統(tǒng)計(jì)每秒寫入的數(shù)據(jù)點(diǎn)數(shù)，以耦合方案（25、50、100 個(gè)預(yù)寫日志隊(duì)列）下的寫入性能為基線對(duì)比不同隊(duì)列數(shù)量下寫入性能的差異。

圖3 不同應(yīng)用負(fù)載和計(jì)算環(huán)境下寫入性能對(duì)比Fig.3 Write performance comparison under different application loads and computing environments

實(shí)驗(yàn)結(jié)果如圖3 所示，最大性能提升如表2 所示。在使用SSD 的場景下，多隊(duì)列的寫入性能近似相同，只有使用1 個(gè)隊(duì)列時(shí)的寫入性能最佳，性能較耦合方案分別提升了約19%、11%、12%。在使用HDD 的場景下，大多數(shù)場景的寫入性能均好于耦合方案的寫入性能，其中分別是使用10、25、30 個(gè)預(yù)寫日志隊(duì)列的寫入性能最佳，性能較耦合方案分別提升了約8%、16%、8%，甚至能夠逼近相同配置下使用SSD 的寫入速度。綜合來看，在不同場景下，使用預(yù)寫日志框架可以找到比耦合方案更優(yōu)的預(yù)寫日志配置方案。此外，結(jié)合三種場景來看，當(dāng)應(yīng)用負(fù)載（內(nèi)存表數(shù)量）發(fā)生變化時(shí)，動(dòng)態(tài)調(diào)整預(yù)寫日志隊(duì)列個(gè)數(shù)的方式能夠適應(yīng)不同應(yīng)用負(fù)載，實(shí)現(xiàn)性能調(diào)優(yōu)。這一點(diǎn)可以從使用HDD 的計(jì)算環(huán)境下看出，當(dāng)內(nèi)存表個(gè)數(shù)在25、50、100 之間變化時(shí)，只需在10、25、30 之間調(diào)整預(yù)寫日志隊(duì)列的數(shù)量，就可保障最佳的寫入性能，可見該框架對(duì)動(dòng)態(tài)性能調(diào)優(yōu)的幫助。

表2 最大性能提升百分比Table 2 Maxperformance improvement percentage

3.3 低頻內(nèi)存表處理方案對(duì)比

本實(shí)驗(yàn)使用1 個(gè)預(yù)寫日志隊(duì)列，并格外增加了1個(gè)內(nèi)存表用于進(jìn)行低頻數(shù)據(jù)寫入，從而模擬低頻內(nèi)存表造成預(yù)寫日志文件堆積的情況。以現(xiàn)有方案采用的刷盤策略作為基線，通過統(tǒng)計(jì)讀寫操作的平均耗時(shí)，對(duì)比本框架提出的快照策略和現(xiàn)有方案使用的刷盤策略對(duì)讀寫性能的影響。查詢共包括以下10種類型：精確點(diǎn)查詢（Q1）、范圍查詢（Q2）、帶值過濾的范圍查詢（Q3）、帶時(shí)間過濾的聚合查詢（Q4）、帶值過濾的聚合查詢（Q5）、帶值過濾和時(shí)間過濾的聚合查詢（Q6）、分組聚合查詢（Q7）、最近點(diǎn)查詢（Q8）、倒序范圍查詢（Q9）、倒序帶值過濾的范圍查詢（Q10）。

實(shí)驗(yàn)結(jié)果如圖4所示。從圖4（a）可以看出，雖然本框架提出的快照策略耗時(shí)略大于現(xiàn)有方案使用的刷盤策略，約慢1.08%，差異較小，但是結(jié)合圖4（b）可以看出，得益于不主動(dòng)觸發(fā)內(nèi)存表落盤，本框架提出的快照策略對(duì)查詢的收益是較大的，各類查詢均快于現(xiàn)有方案使用的刷盤策略，可降低2%～20%的查詢耗時(shí)?？梢?，快照策略能夠在幾乎不影響寫入效率的同時(shí)更好地保障數(shù)據(jù)的查詢效率。

圖4 快照策略和刷盤策略的性能對(duì)比Fig.4 Performance comparison between snapshot strategy and flush strategy

4 結(jié)束語

本文提出了一種面向內(nèi)存表的可動(dòng)態(tài)配置日志框架，能夠?qū)㈩A(yù)寫日志和內(nèi)存表解耦，能針對(duì)不同計(jì)算環(huán)境和應(yīng)用負(fù)載動(dòng)態(tài)調(diào)整預(yù)寫日志隊(duì)列個(gè)數(shù)，實(shí)現(xiàn)動(dòng)態(tài)性能調(diào)優(yōu)。為了驗(yàn)證預(yù)寫日志框架的有效性，本文基于Apache IoTDB實(shí)現(xiàn)了該框架，并設(shè)計(jì)了相關(guān)實(shí)驗(yàn)。實(shí)驗(yàn)證明該框架能夠動(dòng)態(tài)適配不同計(jì)算環(huán)境和應(yīng)用負(fù)載，通過調(diào)整預(yù)寫日志數(shù)量保障最快的寫入性能。

計(jì)劃在未來從以下幾個(gè)方面進(jìn)行改進(jìn)：（1）使用增量快照替代全量快照。通過增量快照來避免因同一內(nèi)存表被多次快照而導(dǎo)致的寫放大（write amplification）問題[16]。（2）實(shí)現(xiàn)內(nèi)存表的智能分配?；跀?shù)據(jù)寫入頻率對(duì)內(nèi)存表進(jìn)行分類，讓寫入頻率相似的內(nèi)存表共享預(yù)寫日志隊(duì)列，更智能地管理預(yù)寫日志及其磁盤文件大小。