康強強, 金澈清, 張 召, 胡華梁,2, 周傲英
(1.華東師范大學(xué) 軟件學(xué)院 數(shù)據(jù)科學(xué)與工程研究院,上海 200062;2.浙江理工大學(xué) 經(jīng)濟管理學(xué)院,杭州 310033)
在過去的10年間,隨著硬件迅速發(fā)展,內(nèi)存價格顯著降低,一個典型的計算機系統(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ù)庫基準旨在客觀、公正地評測數(shù)據(jù)庫產(chǎn)品的性能,以激勵數(shù)據(jù)庫廠商優(yōu)化其產(chǎn)品.自從威斯康星評測基準被提出以來,數(shù)據(jù)庫評測基準已在過去30年里取得了巨大的成功[18].事務(wù)處理性能委員會(Transaction Processing Performance Council,TPC)提出了一系列基準來評測關(guān)系型數(shù)據(jù)庫,包括TPC-C、TPC-H、TPC-E、TPC-DS等,得到學(xué)術(shù)界和工業(yè)界的廣泛認可.其他典型基準包括混合了TPC-C和TPC-H工作負載的CH-Benchmark[4]和針對決策支持系統(tǒng)的星型模式評測基準(Star Schema Benchmark,SSB)[5].此外,針對非關(guān)系型數(shù)據(jù)庫的評測基準包括針對NoSQL數(shù)據(jù)庫的YCSB測試基準[6]和針對面向?qū)ο髷?shù)據(jù)庫的Bucky測試基準[7]等.傳統(tǒng)數(shù)據(jù)庫系統(tǒng)將數(shù)據(jù)存儲于磁盤之中,再通過大量I/O操作執(zhí)行數(shù)據(jù)管理任務(wù),現(xià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ù)庫基準并不適合評測內(nèi)存數(shù)據(jù)庫,亟需設(shè)計新基準進行評測,以充分反映以上若干特性.
本文設(shè)計了一個新的數(shù)據(jù)庫基準(InMemBench)來評測內(nèi)存數(shù)據(jù)庫系統(tǒng).該評測標準的數(shù)據(jù)庫模式包含8張表:2張大表和6張小表.大表的字段較多,分別超過100列和200列;小表的列數(shù)較少,不超過30個.該基準還包括一個并行數(shù)據(jù)生成工具COLGen,以產(chǎn)生模擬數(shù)據(jù).該基準擁有4個新穎的度量:啟動消耗(Startup Cost)、壓縮率(Compression Ratio)、每小時執(zhí)行查詢個數(shù)(Query per hour),和列擴展性(Column Scalability).在工作負載方面,該基準包括2種類型,分別聚焦讀操作和寫操作.
本文第1節(jié)描述相關(guān)工作,第2節(jié)介紹數(shù)據(jù)庫模式,第3節(jié)介紹度量指標,第4節(jié)介紹工作負載和執(zhí)行計劃,第5節(jié)報告實驗結(jié)果,并在最后一節(jié)總結(jié)全文.
隨著數(shù)據(jù)庫技術(shù)不斷發(fā)展,數(shù)據(jù)庫評測基準也獲得較大提高.從20世紀80年代開始,學(xué)術(shù)界和工業(yè)界已經(jīng)研發(fā)出多款數(shù)據(jù)庫評測基準,包括針對關(guān)系型數(shù)據(jù)庫的威斯康星測試基準(Wisconsin)和TPC系列,針對面向?qū)ο髷?shù)據(jù)庫的 OO7[8]和bucky[7]評測基準,針對XML數(shù)據(jù)的 XMark[9]和 EXRT[10]評測基準,還有針對于大數(shù)據(jù)應(yīng)用的 YCSB[6]和 Big-Bench[11]評測基準等.
近期,內(nèi)存數(shù)據(jù)庫技術(shù)得到了較大發(fā)展,典型代表包括SAP的HANA、Oracle的TimesTen,微軟的Hekaton,還有開源的HyperSql、SQLite、MemSql和 MonetDB等,這些數(shù)據(jù)庫均采用關(guān)系數(shù)據(jù)模型.威斯康星基準是一款較早的評測基準,其數(shù)據(jù)庫模式較為簡單,較好地評測了當時的數(shù)據(jù)庫產(chǎn)品.TPC開發(fā)了一系列數(shù)據(jù)庫基準來評測數(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的特點,可同時評測數(shù)據(jù)庫OLTP和OLAP功能.Set query基準[12]使用一組基本的查詢語句,從文檔查詢、市場決策支持的角度來評估數(shù)據(jù)庫的性能.星型測試基準SSB使用星型數(shù)據(jù)模型來測試數(shù)據(jù)庫的性能,這樣做主要是為了支持傳統(tǒng)的數(shù)據(jù)倉庫的應(yīng)用.
然而,以上評測基準并未充分考慮內(nèi)存數(shù)據(jù)庫的特性,因此并不適合內(nèi)存數(shù)據(jù)庫.研究人員嘗試采用現(xiàn)評測基準來評估內(nèi)存數(shù)據(jù)庫的性能,但是在度量選取等方面并未全面地契合內(nèi)存數(shù)據(jù)庫的特性[13-17].本文所提出的新基準則嘗試更加全面地解決了以上問題.
本節(jié)先描述數(shù)據(jù)庫模式及其特點,再介紹數(shù)據(jù)生成器COLGen.
圖1描述了InMemBench的數(shù)據(jù)庫模式.該模式使用了8張表來描述一個零售產(chǎn)品供應(yīng)的應(yīng)用場景.PART表描述銷售的零件,SUPPLIER表和CUSTOMER表描述零件的提供商和所有客戶,NATION表和REGION表描述供應(yīng)商和客戶來自的國家和地區(qū).由于一個零件可能有不止一個提供商,因此使用PARTSUPP表來描述此依賴關(guān)系.最后,ORDERS表描述客戶的所有訂單,每個訂單的詳細信息存儲在LINEITEM表中.這個模式源于TPC-H數(shù)據(jù)庫模式,但為了適應(yīng)內(nèi)存數(shù)據(jù)庫而進行了若干調(diào)整.
圖1 數(shù)據(jù)庫模式Fig.1 Database schema
主要的擴展包括兩處.第一,向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è)計的想法最初來自于真實的銷售場景中,有些大型企業(yè),例如淘寶和亞馬遜,它們的銷售表往往是超過16個字段的(TPC-H最大的表字段個數(shù)是16).因此,這需要對維護銷售明細的字段進行一個擴展.其實,這兩張表中所有新加的字段在實際的銷售場景中也有明確的含義,例如,LINEITEM這張表就有表示物品毛重和凈重的新增字段.考慮到空間的限制,這里沒有列出其他198個字段的介紹.這樣設(shè)計的另外一個想法是,足夠多的字段給我們評測行存儲數(shù)據(jù)庫和列存儲數(shù)據(jù)庫提供了一個可能途徑.
本數(shù)據(jù)庫模式的一個主要特點是“動態(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è)計是為了評測行存儲和列存儲2種不同存儲方式的列可擴展性.
通過擴展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的隨機選取填充到對應(yīng)字段中;數(shù)據(jù)產(chǎn)生規(guī)則定義了各字段之間的依賴關(guān)系、單個字段值的填充形式和取值范圍等.
圖2 COLGen的架構(gòu)Fig.2 The architecture of COLGen
此外,還定義了擴展因子(Scale Factor,SF)來控制模擬數(shù)據(jù)庫的規(guī)模.不同SF值對應(yīng)不同的數(shù)據(jù)庫規(guī)模.例如,當SF=1時,COLGen會生成10 GB數(shù)據(jù);若SF=2,則生成20 GB數(shù)據(jù);依次類推.
本文定義了4個度量指標來評測內(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)存所耗費的時間.各內(nèi)存數(shù)據(jù)庫都需要預(yù)先將數(shù)據(jù)裝載入內(nèi)存中以進行管理.
· 壓縮率CR@SF.數(shù)據(jù)的壓縮率描述內(nèi)存數(shù)據(jù)庫壓縮數(shù)據(jù)的能力.如前所述,內(nèi)存數(shù)據(jù)庫會對數(shù)據(jù)進行壓縮之后再存儲到內(nèi)存之中,以提升空間利用率.令Sdisk表示數(shù)據(jù)在磁盤上的空間容量,Smem表示數(shù)據(jù)在內(nèi)存中的占用量,以下公式計算壓縮率:
· 每小時查詢個數(shù)Qph@SF.每小時查詢個數(shù)描述評測任務(wù)的執(zhí)行性能,執(zhí)行時間包括:數(shù)據(jù)從磁盤文件裝載到數(shù)據(jù)庫的時間(TL)、數(shù)據(jù)從磁盤加載到內(nèi)存中的時間(TS)、執(zhí)行兩次查詢負載的時間(TQR1和TQR2)和執(zhí)行更新任務(wù)的時間(TR),具體流程如圖3所示:
圖3 度量指標Qph@SF的執(zhí)行過程Fig.3 The execution of Metric Qph@SF
從圖3中可以看出,整個流程包括2次查詢負載,首次執(zhí)行查詢負載的目的是評測數(shù)據(jù)庫在裝載數(shù)據(jù)之后該系統(tǒng)執(zhí)行查詢的能力,再次執(zhí)行查詢負載的目的是評測數(shù)據(jù)庫在執(zhí)行完更新操作之后該系統(tǒng)執(zhí)行查詢的能力.為了提高可讀性,TL、TS、TQR1、TQR2和TR的具體執(zhí)行過程會放在第4節(jié)執(zhí)行計劃中介紹.
公式(2)定義了Qph@SF的計算方法,其中S是執(zhí)行測試計劃的并發(fā)用戶個數(shù),共有16個查詢?nèi)蝿?wù)(執(zhí)行2次查詢負載,每個查詢負載種包括8個查詢),0.01是裝載時間可并入總的消耗時間的比例,指的是進行一次該執(zhí)行過程可算入在內(nèi)的有效裝載時間.該權(quán)重值較小的原因是數(shù)據(jù)裝載僅在數(shù)據(jù)庫啟動時運行一次,而查詢則會經(jīng)常執(zhí)行.因為上述過程都是以秒(s)為單位進行記時,因此需要在公式中乘以3600進行單位換算.文獻[19-20]使用一個相似公式計算每小時的查詢個數(shù).
· 列擴展性CS@SF.這個指標描述內(nèi)存數(shù)據(jù)庫系統(tǒng)的列擴張能力.如前所述,內(nèi)存數(shù)據(jù)庫中存在2種數(shù)據(jù)組織方式:列存儲和行存儲.一般說來,當需要執(zhí)行某個分析任務(wù)時,只有一張表中的少部分字段是需要處理的[17].CS@SF的設(shè)計目標就是測量某個內(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í)行計劃中介紹.
表1總結(jié)了InMemBench和其它現(xiàn)有評測基準的差異.和現(xiàn)有基準類似,InMemBench也可評測數(shù)據(jù)庫系統(tǒng)的常用特性,例如吞吐量和多用戶模式.此外,新基準還能評測內(nèi)存數(shù)據(jù)庫的若干特性,而現(xiàn)有基準并未考慮到這些因素.
表1 InMemBench和其他評測基準的比較Tab.1 The comparison of InMemBench and other benchmarks
本節(jié)首先描述了查詢和更新負載,然后提出兩個執(zhí)行計劃.
查詢負載共包括3組查詢,每組分別包括3、3和2個查詢.以下詳細描述各查詢組.
· 查詢組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個查詢.因為是對2張表進行連接操作,所以這個查詢組消耗的內(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張表進行連接操作,其內(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)沒有起到加速的作用.當執(zhí)行查詢組2和查詢組3時,緩存會重復(fù)利用前面的查詢結(jié)果,于是會加速執(zhí)行過程.同時需要注意的是,查詢組2中的每個查詢獲取的數(shù)據(jù)和查詢組1是沒有交集的,而查詢組3和查詢組1是有交集的,于是當查詢組3放在查詢組1后面執(zhí)行的時候,緩存會加速執(zhí)行過程.實際上,3個查詢組按照數(shù)值生序順序依次執(zhí)行,緩存會在數(shù)據(jù)有重復(fù)的兩個查詢中加速執(zhí)行過程.
該負載主要用于圖3中的更新負載執(zhí)行過程,它主要在查詢負載1和查詢負載2之間執(zhí)行.它主要包括兩個部分:插入操作和刪除操作.首先,測試系統(tǒng)會向表LINEITEM和ORDERS插入占原始記錄為0.1%的新記錄.隨后,所有新增加的記錄會被刪除.需要注意的是,所有的更新數(shù)據(jù)都是由數(shù)據(jù)生成器COLGen預(yù)先生成,數(shù)據(jù)記錄大小和SF的比例是1500∶1.
本文前面提出了4個度量標準從不同的角度測試內(nèi)存數(shù)據(jù)庫系統(tǒng)的性能.然而,這4個指標并不能在一次執(zhí)行過程中全部完成測試.因此設(shè)計了2個執(zhí)行計劃來完成這一目標.第1個計劃(計劃1)旨在測試啟動消耗(SC@SF),壓縮率(CR@SF)和每小時的查詢個數(shù)(Qph@SF),通過執(zhí)行圖3的過程,可以計算出上述的3個度量指標.第2個測試計劃(計劃2)來評估某個數(shù)據(jù)庫的列擴展性(CS@SF),這個測試需要不斷改變數(shù)據(jù)庫模式中的字段個數(shù).
計劃1:測量啟動消耗、壓縮率和每小時查詢個數(shù)
執(zhí)行這個測試計劃之前,需要預(yù)先設(shè)置SF的值來確定數(shù)據(jù)庫的大小.為了支持多用戶的模式,S的值也需要預(yù)先指定.這個值表示查詢流的數(shù)目,每個查詢流表示一個用戶.整個執(zhí)行過程如圖3所示,首先,啟動數(shù)據(jù)庫將測試數(shù)據(jù)從磁盤文件裝載到數(shù)據(jù)庫中,然后,數(shù)據(jù)庫將所需的數(shù)據(jù)從磁盤裝載到內(nèi)存中,依次執(zhí)行查詢負載1,更新負載和查詢負載2.查詢負載1和查詢負載2是相同的,包括8條查詢語句.
在上面的執(zhí)行過程結(jié)束之后,可以記錄TL、TS、TQR1、TQR2和TR.接著,啟動消耗SC@SF和每小時查詢數(shù)Qph@SF可以直接計算得到.為了測量壓縮率,可以分別記錄數(shù)據(jù)在磁盤和內(nèi)存中的大小,然后用公式(1)計算求出.
計劃2:測量列擴展性
這個測試是一個迭代的過程,因為需要不斷改變數(shù)據(jù)庫模式中字段的個數(shù).通過改變LINEITEM和ORDERS這兩張表新增字段的數(shù)目.例如,在LINEITEM(ORDERS)這張表中,用所有新增200(100)個字段中的20%、40%、60%、80%和100%來構(gòu)建每次迭代過程中的不同數(shù)據(jù)庫模式.對該測試計劃來說,需要預(yù)先指定SF的值來確定數(shù)據(jù)的大小.在每次迭代開始前,要重啟數(shù)據(jù)庫,執(zhí)行圖3中的每個過程,記錄相應(yīng)的時間T1,…,T5,最后用公式(3)計算得出CS@SF.
這一節(jié)通過一系列的實驗去評測內(nèi)存數(shù)據(jù)庫系統(tǒng).我們以數(shù)據(jù)庫X,Y,Z和MonetDB作為實際例子.內(nèi)存數(shù)據(jù)庫X和MonetDB支持列存儲組織方式,內(nèi)存數(shù)據(jù)庫Y和Z支持行存儲組織方式.被測試平臺有1 TB的內(nèi)存容量和8個CPU.在默認情況下,每個內(nèi)存數(shù)據(jù)庫可以使用的最大內(nèi)存容量為0.8 TB.
(1)壓縮率實驗
圖4(a)描述了隨著SF的變化,4個系統(tǒng)壓縮能力的改變.可以看到,系統(tǒng)X和Monet-DB有更好的壓縮能力,基本可壓縮原始文件的80%,對于系統(tǒng)Y和Z,數(shù)據(jù)在壓縮之前和壓縮之后基本沒有發(fā)生太大的變化.這是因為X和MonetDB都是以列存儲方式為主,這種存儲方式可以把同一個字段的數(shù)據(jù)在物理上組織到一起.
(2)啟動消耗實驗
圖4(b)描述啟動消耗隨SF增大而變化的趨勢,從圖中可以看到系統(tǒng)X和系統(tǒng)Y的啟動消耗都是隨著SF不斷增大的.然而,在同等數(shù)據(jù)量的情況下,系統(tǒng)X需要更少的啟動消耗,這是因為系統(tǒng)X有著更好的壓縮能力.
圖4 壓縮率和啟動消耗的評估Fig.4 Testing and evaluation for the compression ratio and startup cost
(3)每小時查詢數(shù)實驗
圖5(a)描述了當SF為5時,每個查詢和更新操作的執(zhí)行時間.在執(zhí)行前6條查詢的時候,列存儲系統(tǒng)表現(xiàn)的性能更好,這是因為它只需要獲取部分字段為將來的操作.而且前6條查詢主要是涉及到兩張表,進行連接操作中間產(chǎn)生的數(shù)據(jù)量也比較少.在執(zhí)行后面2個查詢時,行存儲系統(tǒng)Y表現(xiàn)出了更好的性能,這是因為后面2個查詢涉及到8張表的連接操作,中間會產(chǎn)生很多的數(shù)據(jù),而且列存儲系統(tǒng)需要執(zhí)行更多額外的解壓縮的操作.對于更新操作來說,行存儲比列存儲的性能要好,這是因為記錄本身是按照行存儲的物理組織方式進行插入的.圖5(b)顯示了隨著SF的增長,所有查詢的時間也隨之增長,使用公式(2)計算每小時的查詢個數(shù)(Qph@SF).
圖5 每小時查詢數(shù)的評估Fig.5 Testing and evaluation for query per hour
(4)列擴展性實驗
在這一部分,圖6(a)描述了當SF設(shè)置為5時每個模型執(zhí)行圖3的過程所需要的時間(單位為s),可以看到系統(tǒng)X隨著模型的不斷改變基本不發(fā)生太大的變化,然而系統(tǒng)Y卻隨著模型中字段個數(shù)的增加執(zhí)行時間也不斷變大.這是因為列組織方式的數(shù)據(jù)庫只需要查詢將需要處理的字段,而行存儲的組織方式則需要讀取全部的字段.隨著列數(shù)的降低,系統(tǒng)Y的性能超過系統(tǒng)X,這是因為在數(shù)據(jù)量相差不大的情況下,使用索引可以很好地加快行存儲組織的數(shù)據(jù)庫,對于列存儲組織的數(shù)據(jù)庫,索引一般沒有任何作用.隨后,圖6(b)表明,系統(tǒng)X和系統(tǒng)Y隨著SF的增加,整體執(zhí)行時間也不斷增大.
圖6 列擴展性的評估Fig.6 Testing and evaluation for column scalability
本文提出了針對內(nèi)存數(shù)據(jù)庫的測試基準InMemBench.這個測試基準充分考慮了內(nèi)存數(shù)據(jù)庫的主要特性,與之相應(yīng)地,提出了4個度量去客觀公正地評估內(nèi)存數(shù)據(jù)庫的性能.除此之外,該測試基準還包括自適應(yīng)動態(tài)數(shù)據(jù)庫模式、測試計劃、查詢和更新的工作負載.最后,對4個內(nèi)存數(shù)據(jù)庫進行了大量的實驗來驗證所提測試基準的有效性和執(zhí)行效率.在未來的研究工作中,我們會設(shè)計更為復(fù)雜的查詢以及對更多的內(nèi)存數(shù)據(jù)庫進行實驗驗證.
[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.