如何客觀評測內(nèi)存數(shù)據(jù)庫的性能

康強(qiáng)強(qiáng)， 金澈清， 張 召， 胡華梁，2， 周傲英

（1.華東師范大學(xué) 軟件學(xué)院 數(shù)據(jù)科學(xué)與工程研究院，上海 200062；2.浙江理工大學(xué) 經(jīng)濟(jì)管理學(xué)院，杭州 310033）

0 引 言

在過去的10年間，隨著硬件迅速發(fā)展，內(nèi)存價格顯著降低，一個典型的計(jì)算機(jī)系統(tǒng)往往會布置大容量內(nèi)存.數(shù)據(jù)庫產(chǎn)品提供商于是投入大量資源來開發(fā)內(nèi)存數(shù)據(jù)庫，以提高數(shù)據(jù)處理吞吐量，其中包括SAP公司的 HANA［1］，Oracle公司的 TimesTen［2］，還有開源的 MonetDB［3］等等.內(nèi)存數(shù)據(jù)庫需要預(yù)先將數(shù)據(jù)裝載到內(nèi)存中，從而避免了后續(xù)的數(shù)據(jù)管理階段的I／O開銷.隨著諸多內(nèi)存數(shù)據(jù)庫產(chǎn)品的問世，如何公平、客觀地評測這些內(nèi)存數(shù)據(jù)庫的性能也變得愈發(fā)重要.

數(shù)據(jù)庫基準(zhǔn)旨在客觀、公正地評測數(shù)據(jù)庫產(chǎn)品的性能，以激勵數(shù)據(jù)庫廠商優(yōu)化其產(chǎn)品.自從威斯康星評測基準(zhǔn)被提出以來，數(shù)據(jù)庫評測基準(zhǔn)已在過去30年里取得了巨大的成功［18］.事務(wù)處理性能委員會（Transaction Processing Performance Council，TPC）提出了一系列基準(zhǔn)來評測關(guān)系型數(shù)據(jù)庫，包括TPC－C、TPC－H、TPC－E、TPC－DS等，得到學(xué)術(shù)界和工業(yè)界的廣泛認(rèn)可.其他典型基準(zhǔn)包括混合了TPC－C和TPC－H工作負(fù)載的CH－Benchmark［4］和針對決策支持系統(tǒng)的星型模式評測基準(zhǔn)（Star Schema Benchmark，SSB）［5］.此外，針對非關(guān)系型數(shù)據(jù)庫的評測基準(zhǔn)包括針對NoSQL數(shù)據(jù)庫的YCSB測試基準(zhǔn)［6］和針對面向?qū)ο髷?shù)據(jù)庫的Bucky測試基準(zhǔn)［7］等.傳統(tǒng)數(shù)據(jù)庫系統(tǒng)將數(shù)據(jù)存儲于磁盤之中，再通過大量I／O操作執(zhí)行數(shù)據(jù)管理任務(wù)，現(xiàn)有基準(zhǔn)均力求反映這一重要特性.然而，與傳統(tǒng)數(shù)據(jù)庫相比，內(nèi)存數(shù)據(jù)庫具有以下重要性質(zhì)：（1）啟動時加載：內(nèi)存數(shù)據(jù)庫需要將數(shù)據(jù)預(yù)先加載到內(nèi)存中.（2）數(shù)據(jù)組織：內(nèi)存數(shù)據(jù)庫并不局限于采用行存儲方式，也可采用列存儲方式，或者同時支持兩種數(shù)據(jù)存儲方式.（3）數(shù)據(jù)壓縮：內(nèi)存數(shù)據(jù)庫系統(tǒng)廣泛采用數(shù)據(jù)壓縮技術(shù)，以在內(nèi)存之中存儲更多數(shù)據(jù).總之，現(xiàn)有數(shù)據(jù)庫基準(zhǔn)并不適合評測內(nèi)存數(shù)據(jù)庫，亟需設(shè)計(jì)新基準(zhǔn)進(jìn)行評測，以充分反映以上若干特性.

本文設(shè)計(jì)了一個新的數(shù)據(jù)庫基準(zhǔn)（InMemBench）來評測內(nèi)存數(shù)據(jù)庫系統(tǒng).該評測標(biāo)準(zhǔn)的數(shù)據(jù)庫模式包含8張表：2張大表和6張小表.大表的字段較多，分別超過100列和200列；小表的列數(shù)較少，不超過30個.該基準(zhǔn)還包括一個并行數(shù)據(jù)生成工具COLGen，以產(chǎn)生模擬數(shù)據(jù).該基準(zhǔn)擁有4個新穎的度量：啟動消耗（Startup Cost）、壓縮率（Compression Ratio）、每小時執(zhí)行查詢個數(shù)（Query per hour），和列擴(kuò)展性（Column Scalability）.在工作負(fù)載方面，該基準(zhǔn)包括2種類型，分別聚焦讀操作和寫操作.

本文第1節(jié)描述相關(guān)工作，第2節(jié)介紹數(shù)據(jù)庫模式，第3節(jié)介紹度量指標(biāo)，第4節(jié)介紹工作負(fù)載和執(zhí)行計(jì)劃，第5節(jié)報(bào)告實(shí)驗(yàn)結(jié)果，并在最后一節(jié)總結(jié)全文.

1 相關(guān)工作

隨著數(shù)據(jù)庫技術(shù)不斷發(fā)展，數(shù)據(jù)庫評測基準(zhǔn)也獲得較大提高.從20世紀(jì)80年代開始，學(xué)術(shù)界和工業(yè)界已經(jīng)研發(fā)出多款數(shù)據(jù)庫評測基準(zhǔn)，包括針對關(guān)系型數(shù)據(jù)庫的威斯康星測試基準(zhǔn)（Wisconsin）和TPC系列，針對面向?qū)ο髷?shù)據(jù)庫的 OO7［8］和bucky［7］評測基準(zhǔn)，針對XML數(shù)據(jù)的 XMark［9］和 EXRT［10］評測基準(zhǔn)，還有針對于大數(shù)據(jù)應(yīng)用的 YCSB［6］和 Big－Bench［11］評測基準(zhǔn)等.

近期，內(nèi)存數(shù)據(jù)庫技術(shù)得到了較大發(fā)展，典型代表包括SAP的HANA、Oracle的TimesTen，微軟的Hekaton，還有開源的HyperSql、SQLite、MemSql和 MonetDB等，這些數(shù)據(jù)庫均采用關(guān)系數(shù)據(jù)模型.威斯康星基準(zhǔn)是一款較早的評測基準(zhǔn)，其數(shù)據(jù)庫模式較為簡單，較好地評測了當(dāng)時的數(shù)據(jù)庫產(chǎn)品.TPC開發(fā)了一系列數(shù)據(jù)庫基準(zhǔn)來評測數(shù)據(jù)庫，包括針對于在線事務(wù)處理（Online Transaction Processing，OLTP）的TPC－C和 TPC－E，針對在線分析處理（Online Analytical Processing，OLAP）的 TPC－H 和 TPC－DS.CH－Benchmark則混合TPC－C和TPC－H的特點(diǎn)，可同時評測數(shù)據(jù)庫OLTP和OLAP功能.Set query基準(zhǔn)［12］使用一組基本的查詢語句，從文檔查詢、市場決策支持的角度來評估數(shù)據(jù)庫的性能.星型測試基準(zhǔn)SSB使用星型數(shù)據(jù)模型來測試數(shù)據(jù)庫的性能，這樣做主要是為了支持傳統(tǒng)的數(shù)據(jù)倉庫的應(yīng)用.

然而，以上評測基準(zhǔn)并未充分考慮內(nèi)存數(shù)據(jù)庫的特性，因此并不適合內(nèi)存數(shù)據(jù)庫.研究人員嘗試采用現(xiàn)評測基準(zhǔn)來評估內(nèi)存數(shù)據(jù)庫的性能，但是在度量選取等方面并未全面地契合內(nèi)存數(shù)據(jù)庫的特性［13－17］.本文所提出的新基準(zhǔn)則嘗試更加全面地解決了以上問題.

2 數(shù)據(jù)模型

本節(jié)先描述數(shù)據(jù)庫模式及其特點(diǎn)，再介紹數(shù)據(jù)生成器COLGen.

2.1 數(shù)據(jù)庫模式

圖1描述了InMemBench的數(shù)據(jù)庫模式.該模式使用了8張表來描述一個零售產(chǎn)品供應(yīng)的應(yīng)用場景.PART表描述銷售的零件，SUPPLIER表和CUSTOMER表描述零件的提供商和所有客戶，NATION表和REGION表描述供應(yīng)商和客戶來自的國家和地區(qū).由于一個零件可能有不止一個提供商，因此使用PARTSUPP表來描述此依賴關(guān)系.最后，ORDERS表描述客戶的所有訂單，每個訂單的詳細(xì)信息存儲在LINEITEM表中.這個模式源于TPC－H數(shù)據(jù)庫模式，但為了適應(yīng)內(nèi)存數(shù)據(jù)庫而進(jìn)行了若干調(diào)整.

圖1 數(shù)據(jù)庫模式Fig.1 Database schema

主要的擴(kuò)展包括兩處.第一，向LINEITEM表中添加200個字段，名為：COLUMN1，…，COLUMN200，分屬3種數(shù)據(jù)類型：字符型char、數(shù)值型decimal（13，2）和日期類型date.在這新添的200個字段中，規(guī)定20%的字段使用數(shù)值型，剩下的20%和60%分別使用日期類型和字符類型.第二，向ORDERS這張表中添加100個字段，這100個字段也是有數(shù)值型、字符型和日期型3種類型組成，分別命名為抽象字段COLUMN1，…，COLUMN100.在這新添的100個字段中，他們的類型分布和LINEITEM這張表是一樣的.這樣設(shè)計(jì)的想法最初來自于真實(shí)的銷售場景中，有些大型企業(yè)，例如淘寶和亞馬遜，它們的銷售表往往是超過16個字段的（TPC－H最大的表字段個數(shù)是16）.因此，這需要對維護(hù)銷售明細(xì)的字段進(jìn)行一個擴(kuò)展.其實(shí)，這兩張表中所有新加的字段在實(shí)際的銷售場景中也有明確的含義，例如，LINEITEM這張表就有表示物品毛重和凈重的新增字段.考慮到空間的限制，這里沒有列出其他198個字段的介紹.這樣設(shè)計(jì)的另外一個想法是，足夠多的字段給我們評測行存儲數(shù)據(jù)庫和列存儲數(shù)據(jù)庫提供了一個可能途徑.

本數(shù)據(jù)庫模式的一個主要特點(diǎn)是“動態(tài)可適應(yīng)性”：即LINEITEM和ORDERS表中的字段個數(shù)會改變.該動態(tài)模型主要包含6張小表（SUPPLIER，PARTSUPP，PART，REGION，NATION和CUSTOMER）和2張大表（LINEITEM和ORDERS）.模型的動態(tài)變化主要是2張大表中新增字段個數(shù)的變化.例如，在模型的5次動態(tài)變化過程中，每一個狀態(tài)下2張大表新增的字段數(shù)目分別占新增總字段的20%、40%、60%、80%和100%.這樣設(shè)計(jì)是為了評測行存儲和列存儲2種不同存儲方式的列可擴(kuò)展性.

2.2 數(shù)據(jù)生成器

通過擴(kuò)展DataGen（TPC－H的數(shù)據(jù)生成工具），我們研發(fā)了一個并行數(shù)據(jù)生成工具（COLGen）來產(chǎn)生模擬數(shù)據(jù).該數(shù)據(jù)生成器需要使用數(shù)據(jù)字典和產(chǎn)生規(guī)則（如圖2所示）.數(shù)據(jù)字典包括了3類單詞，這些單詞均可通過RNG的隨機(jī)選取填充到對應(yīng)字段中；數(shù)據(jù)產(chǎn)生規(guī)則定義了各字段之間的依賴關(guān)系、單個字段值的填充形式和取值范圍等.

圖2 COLGen的架構(gòu)Fig.2 The architecture of COLGen

此外，還定義了擴(kuò)展因子（Scale Factor，SF）來控制模擬數(shù)據(jù)庫的規(guī)模.不同SF值對應(yīng)不同的數(shù)據(jù)庫規(guī)模.例如，當(dāng)SF＝1時，COLGen會生成10 GB數(shù)據(jù)；若SF＝2，則生成20 GB數(shù)據(jù)；依次類推.

3 度量指標(biāo)

本文定義了4個度量指標(biāo)來評測內(nèi)存數(shù)據(jù)庫的性能，即：啟動消耗（Startup Cost，SC＠SF）、壓縮率（Compression Ratio，CR＠SF）、每小時查詢個數(shù)（Query per hour，Qph＠SF）和列處理能力（Column Scalability，CS＠SF）.

· 啟動消耗SC＠SF.啟動消耗描述將數(shù)據(jù)從磁盤裝載到內(nèi)存所耗費(fèi)的時間.各內(nèi)存數(shù)據(jù)庫都需要預(yù)先將數(shù)據(jù)裝載入內(nèi)存中以進(jìn)行管理.

· 壓縮率CR＠SF.數(shù)據(jù)的壓縮率描述內(nèi)存數(shù)據(jù)庫壓縮數(shù)據(jù)的能力.如前所述，內(nèi)存數(shù)據(jù)庫會對數(shù)據(jù)進(jìn)行壓縮之后再存儲到內(nèi)存之中，以提升空間利用率.令Sdisk表示數(shù)據(jù)在磁盤上的空間容量，Smem表示數(shù)據(jù)在內(nèi)存中的占用量，以下公式計(jì)算壓縮率：

· 每小時查詢個數(shù)Qph＠SF.每小時查詢個數(shù)描述評測任務(wù)的執(zhí)行性能，執(zhí)行時間包括：數(shù)據(jù)從磁盤文件裝載到數(shù)據(jù)庫的時間（TL）、數(shù)據(jù)從磁盤加載到內(nèi)存中的時間（TS）、執(zhí)行兩次查詢負(fù)載的時間（TQR1和TQR2）和執(zhí)行更新任務(wù)的時間（TR），具體流程如圖3所示：

圖3 度量指標(biāo)Qph＠SF的執(zhí)行過程Fig.3 The execution of Metric Qph＠SF

從圖3中可以看出，整個流程包括2次查詢負(fù)載，首次執(zhí)行查詢負(fù)載的目的是評測數(shù)據(jù)庫在裝載數(shù)據(jù)之后該系統(tǒng)執(zhí)行查詢的能力，再次執(zhí)行查詢負(fù)載的目的是評測數(shù)據(jù)庫在執(zhí)行完更新操作之后該系統(tǒng)執(zhí)行查詢的能力.為了提高可讀性，TL、TS、TQR1、TQR2和TR的具體執(zhí)行過程會放在第4節(jié)執(zhí)行計(jì)劃中介紹.

公式（2）定義了Qph＠SF的計(jì)算方法，其中S是執(zhí)行測試計(jì)劃的并發(fā)用戶個數(shù)，共有16個查詢?nèi)蝿?wù)（執(zhí)行2次查詢負(fù)載，每個查詢負(fù)載種包括8個查詢），0.01是裝載時間可并入總的消耗時間的比例，指的是進(jìn)行一次該執(zhí)行過程可算入在內(nèi)的有效裝載時間.該權(quán)重值較小的原因是數(shù)據(jù)裝載僅在數(shù)據(jù)庫啟動時運(yùn)行一次，而查詢則會經(jīng)常執(zhí)行.因?yàn)樯鲜鲞^程都是以秒（s）為單位進(jìn)行記時，因此需要在公式中乘以3600進(jìn)行單位換算.文獻(xiàn)［19－20］使用一個相似公式計(jì)算每小時的查詢個數(shù).

· 列擴(kuò)展性CS＠SF.這個指標(biāo)描述內(nèi)存數(shù)據(jù)庫系統(tǒng)的列擴(kuò)張能力.如前所述，內(nèi)存數(shù)據(jù)庫中存在2種數(shù)據(jù)組織方式：列存儲和行存儲.一般說來，當(dāng)需要執(zhí)行某個分析任務(wù)時，只有一張表中的少部分字段是需要處理的［17］.CS＠SF的設(shè)計(jì)目標(biāo)就是測量某個內(nèi)存數(shù)據(jù)庫在字段個數(shù)不斷變化情況下的性能.正如第3節(jié)數(shù)據(jù)模型介紹的那樣，2張大表LINEITEM和ORDERS的字段個數(shù)不是固定的，會隨著數(shù)據(jù)庫模式動態(tài)適應(yīng)而不斷改變.那么就記錄了不同數(shù)據(jù)模式下數(shù)據(jù)庫系統(tǒng)完成圖3中的執(zhí)行過程所需要的時間.公式（3）形式化地定義了CS＠SF.其中T1，…，T5分別表示不同模型下數(shù)據(jù)庫的執(zhí)行時間.具體的測試過程會在第5節(jié)執(zhí)行計(jì)劃中介紹.

表1總結(jié)了InMemBench和其它現(xiàn)有評測基準(zhǔn)的差異.和現(xiàn)有基準(zhǔn)類似，InMemBench也可評測數(shù)據(jù)庫系統(tǒng)的常用特性，例如吞吐量和多用戶模式.此外，新基準(zhǔn)還能評測內(nèi)存數(shù)據(jù)庫的若干特性，而現(xiàn)有基準(zhǔn)并未考慮到這些因素.

表1 InMemBench和其他評測基準(zhǔn)的比較Tab.1 The comparison of InMemBench and other benchmarks

4 工作負(fù)載和執(zhí)行計(jì)劃

本節(jié)首先描述了查詢和更新負(fù)載，然后提出兩個執(zhí)行計(jì)劃.

4.1 查詢負(fù)載

查詢負(fù)載共包括3組查詢，每組分別包括3、3和2個查詢.以下詳細(xì)描述各查詢組.

· 查詢組1：主要是針對表LINEITEM，有sum、avg和count等聚集函數(shù).根據(jù)過濾條件（where子句）劃分，共有3個查詢，如查詢組1所示，其中DELTA1和DELTA2是2個輸入?yún)?shù).

查詢組1的查詢

查詢1.1 DELTA1＝1992－01－01 and DELTA2＝1992－12－01

查詢1.2 DELTA1＝1992－12－01 and DELTA2＝1994－12－01

查詢1.3 DELTA1＝1994－12－01 and DELTA2＝1995－12－01

· 查詢組2：主要是針對LINEITEM和ORDERS 2張表，包括3個查詢.因?yàn)槭菍?張表進(jìn)行連接操作，所以這個查詢組消耗的內(nèi)存空間比第一個查詢組要大.如查詢組2所示，SHIPMODE1、SHIPMODE2和DELTA是輸入?yún)?shù).

查詢組2的查詢

查詢2.1 SHIPMODE1＝FOB，SHIPMODE2＝TRUCK and DELTA＝1996－12－01

查詢2.2 SHIPMODE1＝TRUCK，SHIPMODE2＝SHIP and DELTA＝1997－06－01

查詢2.3 SHIPMODE1＝SHIP，SHIPMODE2＝AIR and DELTA＝1997－12－01

· 查詢組3：對所有8張表進(jìn)行連接操作，其內(nèi)存消耗量最大.該查詢組包括兩個查詢，由參數(shù)DELTA1和DELTA2決定，如查詢組3所示.

查詢組3的查詢

查詢3.1 DELTA1＝1994－01－01 and DELTA2＝1996－01－01

查詢3.2 DELTA1＝1992－01－01 and DELTA2＝1998－12－01

在上面查詢組中，可以看到查詢組1的每個查詢獲取的數(shù)據(jù)是沒有交集的，然而查詢組2和查詢組3獲取的數(shù)據(jù)是有重復(fù)的.因此在執(zhí)行查詢組1時，緩存（caching）沒有起到加速的作用.當(dāng)執(zhí)行查詢組2和查詢組3時，緩存會重復(fù)利用前面的查詢結(jié)果，于是會加速執(zhí)行過程.同時需要注意的是，查詢組2中的每個查詢獲取的數(shù)據(jù)和查詢組1是沒有交集的，而查詢組3和查詢組1是有交集的，于是當(dāng)查詢組3放在查詢組1后面執(zhí)行的時候，緩存會加速執(zhí)行過程.實(shí)際上，3個查詢組按照數(shù)值生序順序依次執(zhí)行，緩存會在數(shù)據(jù)有重復(fù)的兩個查詢中加速執(zhí)行過程.

4.2 更新負(fù)載

該負(fù)載主要用于圖3中的更新負(fù)載執(zhí)行過程，它主要在查詢負(fù)載1和查詢負(fù)載2之間執(zhí)行.它主要包括兩個部分：插入操作和刪除操作.首先，測試系統(tǒng)會向表LINEITEM和ORDERS插入占原始記錄為0.1%的新記錄.隨后，所有新增加的記錄會被刪除.需要注意的是，所有的更新數(shù)據(jù)都是由數(shù)據(jù)生成器COLGen預(yù)先生成，數(shù)據(jù)記錄大小和SF的比例是1500∶1.

4.3 執(zhí)行計(jì)劃

本文前面提出了4個度量標(biāo)準(zhǔn)從不同的角度測試內(nèi)存數(shù)據(jù)庫系統(tǒng)的性能.然而，這4個指標(biāo)并不能在一次執(zhí)行過程中全部完成測試.因此設(shè)計(jì)了2個執(zhí)行計(jì)劃來完成這一目標(biāo).第1個計(jì)劃（計(jì)劃1）旨在測試啟動消耗（SC＠SF），壓縮率（CR＠SF）和每小時的查詢個數(shù)（Qph＠SF），通過執(zhí)行圖3的過程，可以計(jì)算出上述的3個度量指標(biāo).第2個測試計(jì)劃（計(jì)劃2）來評估某個數(shù)據(jù)庫的列擴(kuò)展性（CS＠SF），這個測試需要不斷改變數(shù)據(jù)庫模式中的字段個數(shù).

計(jì)劃1：測量啟動消耗、壓縮率和每小時查詢個數(shù)

執(zhí)行這個測試計(jì)劃之前，需要預(yù)先設(shè)置SF的值來確定數(shù)據(jù)庫的大小.為了支持多用戶的模式，S的值也需要預(yù)先指定.這個值表示查詢流的數(shù)目，每個查詢流表示一個用戶.整個執(zhí)行過程如圖3所示，首先，啟動數(shù)據(jù)庫將測試數(shù)據(jù)從磁盤文件裝載到數(shù)據(jù)庫中，然后，數(shù)據(jù)庫將所需的數(shù)據(jù)從磁盤裝載到內(nèi)存中，依次執(zhí)行查詢負(fù)載1，更新負(fù)載和查詢負(fù)載2.查詢負(fù)載1和查詢負(fù)載2是相同的，包括8條查詢語句.

在上面的執(zhí)行過程結(jié)束之后，可以記錄TL、TS、TQR1、TQR2和TR.接著，啟動消耗SC＠SF和每小時查詢數(shù)Qph＠SF可以直接計(jì)算得到.為了測量壓縮率，可以分別記錄數(shù)據(jù)在磁盤和內(nèi)存中的大小，然后用公式（1）計(jì)算求出.

計(jì)劃2：測量列擴(kuò)展性

這個測試是一個迭代的過程，因?yàn)樾枰粩喔淖償?shù)據(jù)庫模式中字段的個數(shù).通過改變LINEITEM和ORDERS這兩張表新增字段的數(shù)目.例如，在LINEITEM（ORDERS）這張表中，用所有新增200（100）個字段中的20%、40%、60%、80%和100%來構(gòu)建每次迭代過程中的不同數(shù)據(jù)庫模式.對該測試計(jì)劃來說，需要預(yù)先指定SF的值來確定數(shù)據(jù)的大小.在每次迭代開始前，要重啟數(shù)據(jù)庫，執(zhí)行圖3中的每個過程，記錄相應(yīng)的時間T1，…，T5，最后用公式（3）計(jì)算得出CS＠SF.

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

這一節(jié)通過一系列的實(shí)驗(yàn)去評測內(nèi)存數(shù)據(jù)庫系統(tǒng).我們以數(shù)據(jù)庫X，Y，Z和MonetDB作為實(shí)際例子.內(nèi)存數(shù)據(jù)庫X和MonetDB支持列存儲組織方式，內(nèi)存數(shù)據(jù)庫Y和Z支持行存儲組織方式.被測試平臺有1 TB的內(nèi)存容量和8個CPU.在默認(rèn)情況下，每個內(nèi)存數(shù)據(jù)庫可以使用的最大內(nèi)存容量為0.8 TB.

（1）壓縮率實(shí)驗(yàn)

圖4（a）描述了隨著SF的變化，4個系統(tǒng)壓縮能力的改變.可以看到，系統(tǒng)X和Monet－DB有更好的壓縮能力，基本可壓縮原始文件的80%，對于系統(tǒng)Y和Z，數(shù)據(jù)在壓縮之前和壓縮之后基本沒有發(fā)生太大的變化.這是因?yàn)閄和MonetDB都是以列存儲方式為主，這種存儲方式可以把同一個字段的數(shù)據(jù)在物理上組織到一起.

（2）啟動消耗實(shí)驗(yàn)

圖4（b）描述啟動消耗隨SF增大而變化的趨勢，從圖中可以看到系統(tǒng)X和系統(tǒng)Y的啟動消耗都是隨著SF不斷增大的.然而，在同等數(shù)據(jù)量的情況下，系統(tǒng)X需要更少的啟動消耗，這是因?yàn)橄到y(tǒng)X有著更好的壓縮能力.

圖4 壓縮率和啟動消耗的評估Fig.4 Testing and evaluation for the compression ratio and startup cost

（3）每小時查詢數(shù)實(shí)驗(yàn)

圖5（a）描述了當(dāng)SF為5時，每個查詢和更新操作的執(zhí)行時間.在執(zhí)行前6條查詢的時候，列存儲系統(tǒng)表現(xiàn)的性能更好，這是因?yàn)樗恍枰@取部分字段為將來的操作.而且前6條查詢主要是涉及到兩張表，進(jìn)行連接操作中間產(chǎn)生的數(shù)據(jù)量也比較少.在執(zhí)行后面2個查詢時，行存儲系統(tǒng)Y表現(xiàn)出了更好的性能，這是因?yàn)楹竺?個查詢涉及到8張表的連接操作，中間會產(chǎn)生很多的數(shù)據(jù)，而且列存儲系統(tǒng)需要執(zhí)行更多額外的解壓縮的操作.對于更新操作來說，行存儲比列存儲的性能要好，這是因?yàn)橛涗洷旧硎前凑招写鎯Φ奈锢斫M織方式進(jìn)行插入的.圖5（b）顯示了隨著SF的增長，所有查詢的時間也隨之增長，使用公式（2）計(jì)算每小時的查詢個數(shù)（Qph＠SF）.

圖5 每小時查詢數(shù)的評估Fig.5 Testing and evaluation for query per hour

（4）列擴(kuò)展性實(shí)驗(yàn)

在這一部分，圖6（a）描述了當(dāng)SF設(shè)置為5時每個模型執(zhí)行圖3的過程所需要的時間（單位為s），可以看到系統(tǒng)X隨著模型的不斷改變基本不發(fā)生太大的變化，然而系統(tǒng)Y卻隨著模型中字段個數(shù)的增加執(zhí)行時間也不斷變大.這是因?yàn)榱薪M織方式的數(shù)據(jù)庫只需要查詢將需要處理的字段，而行存儲的組織方式則需要讀取全部的字段.隨著列數(shù)的降低，系統(tǒng)Y的性能超過系統(tǒng)X，這是因?yàn)樵跀?shù)據(jù)量相差不大的情況下，使用索引可以很好地加快行存儲組織的數(shù)據(jù)庫，對于列存儲組織的數(shù)據(jù)庫，索引一般沒有任何作用.隨后，圖6（b）表明，系統(tǒng)X和系統(tǒng)Y隨著SF的增加，整體執(zhí)行時間也不斷增大.

圖6 列擴(kuò)展性的評估Fig.6 Testing and evaluation for column scalability

6 總 結(jié)

本文提出了針對內(nèi)存數(shù)據(jù)庫的測試基準(zhǔn)InMemBench.這個測試基準(zhǔn)充分考慮了內(nèi)存數(shù)據(jù)庫的主要特性，與之相應(yīng)地，提出了4個度量去客觀公正地評估內(nèi)存數(shù)據(jù)庫的性能.除此之外，該測試基準(zhǔn)還包括自適應(yīng)動態(tài)數(shù)據(jù)庫模式、測試計(jì)劃、查詢和更新的工作負(fù)載.最后，對4個內(nèi)存數(shù)據(jù)庫進(jìn)行了大量的實(shí)驗(yàn)來驗(yàn)證所提測試基準(zhǔn)的有效性和執(zhí)行效率.在未來的研究工作中，我們會設(shè)計(jì)更為復(fù)雜的查詢以及對更多的內(nèi)存數(shù)據(jù)庫進(jìn)行實(shí)驗(yàn)驗(yàn)證.

［1］ F?RBER F，CHA S K，PRIMSCH J，et al.SAP HANA database：data management for modern business applications［J］.SIGMOD Record，2011，8：45－51.

［2］ lAHIRI T，NEIMAT M A，F(xiàn)OLKMAN S.Oracle TimesTen：an in－memory database for enterprise applications［J］.IEEE Data Eng Bull，2013：6－13.

［3］ BONCZ P A，KERSTEN M L，MANEGOLD S.Breaking the memory wall in MonetDB［J］.Commun ACM，2008，51（12）：77－85.

［4］ COLE R，F(xiàn)UNKE F，GIAKOUMAKIS L，et al.The mixed workload CH－benCHmark［C］.DBTest，2011，8：1－8：6.

［5］ RABL T，POESS M，JACOBSEN H A，et al.Variations of the star schema benchmark to test the effects of data skew on query performance［C］.ICPE，2013：361－372.

［6］ COOPER B F，SILBERSTEIN A，TAM E，et al.Benchmarking cloud serving systems with YCSB［J］.SoCC，2010：143－154.

［7］ CAREY M J，DEWITT D J，NAUGHTON J F，et al.The BUCKY object－relational benchmark（Experience Paper）［C］／／SIGMOD Conference，1997：135－146.

［8］ CAREY M J，DEWITT D J，NAUGHTON J F.The 007 Benchmark［C］／／SIGMOD Conference，1993：12－21.

［9］ SCHMIDT A，WAAS F，KERSTEN M，et al.XMark：A benchmark for XML data management［C］／／Proceedings of the 28th international conference on Very Large Data Bases，2002：974－985.

［10］ CAREY M J，LING L，NICOLA M，et al.EXRT：towards a simple benchmark for XML readiness testing［C］／／TPCTC，2010：93－109.

［11］ GHAZAL A，RABL T，HU M，et al.BigBench：towards an industry standard benchmark for big data analytics［C］／／SIGMOD Conference，2013：1197－1208.

［12］ PATRICK E，NEIL O.A set query benchmark for large databases［C］／／Int CMG Conference，1989：710－721.

［13］ LIU D，LUAN H，WANG S，et al.Main memory database TPC－H workload characterization on modern process［J］.Journal of Software，2008，19（10）：2573－2584.

［15］ T?ZüN P，PANDIS I，KAYNAK C，et al.From A to E：analyzing TPC’s OLTP benchmarks：the obsolete，the ubiquitous，the unexplored［C］／／EDBT，2013：17－28.

［16］ PLATTNER H.A common database approach for OLTP and OLAP using an in－memory column database［C］／／SIGMOD Conference，2009：1－2.

［17］ ABADI D J，MADDEN S，HACHEM N.Column－stores vs.row－stores：how different are they really［C］／／SIGMOD Conference，2008：967－980.

［18］ GRAY J.Benchmark Handbook：For Database and Transaction Processing Systems［J］.San Francisco：Morgan Kaufmann Publishers Inc，1992.

［19］ NAMBIAR R O，POESS M.The making of TPC－DS［C］／／VLDB，2006：1049－1058.

［20］ POESS M，NAMBIAR R O，WALRATH D.Why you should run TPC－DS：a workload analysis［C］／／VLDB，2007：1138－1149.