面向OLAP應(yīng)用的OceanBase模式設(shè)計(jì)

顧 伶， 翁海星， 胡華梁，2， 趙 瓊

（1.華東師范大學(xué) 軟件學(xué)院，上海 200062；2.浙江理工大學(xué) 經(jīng)濟(jì)管理學(xué)院，浙江 310018；3.交通銀行 軟件研發(fā)中心，上海 201201）

0 引 言

在當(dāng)前的大數(shù)據(jù)時(shí)代，數(shù)據(jù)量已經(jīng)達(dá)到了PB級(jí)，但是人們對(duì)于查詢的要求越來越高，希望能在毫秒級(jí)時(shí)間內(nèi)得到想要的結(jié)果.傳統(tǒng)的數(shù)據(jù)庫存儲(chǔ)方式過于簡單，當(dāng)數(shù)據(jù)量很大時(shí)，大量數(shù)據(jù)的堆積會(huì)導(dǎo)致服務(wù)器回應(yīng)速率下降甚至崩潰，對(duì)企業(yè)造成很大的經(jīng)濟(jì)損失.分布式數(shù)據(jù)庫能夠解決這樣的問題，現(xiàn)在企業(yè)里常用的數(shù)據(jù)倉庫有Oracle、DB2、MySQL、Sybase、MS SQL Server等，但是這些數(shù)據(jù)庫都需要使用高性能的機(jī)器，并且擴(kuò)展性有限，最多只能達(dá)到幾百臺(tái)機(jī)器，當(dāng)前數(shù)據(jù)源多樣，并且增長迅速，這樣的數(shù)據(jù)庫無法很好的提供大數(shù)據(jù)的存儲(chǔ)以及查詢服務(wù).隨著經(jīng)濟(jì)迅速發(fā)展，方便大眾的業(yè)務(wù)也在不斷涌現(xiàn).例如，為了支持淘寶電子商務(wù)的業(yè)務(wù)，淘寶網(wǎng)和各家銀行及物流公司都有合作.這就需要淘寶的數(shù)據(jù)庫中存儲(chǔ)大量客戶信息和交易信息，銀行數(shù)據(jù)庫中存儲(chǔ)卡的交易信息，物流公司的數(shù)據(jù)庫中存儲(chǔ)客戶的信息和郵件信息.由于人口眾多以及時(shí)代發(fā)展，無論是電子商務(wù)在線交易，還是其他業(yè)務(wù)的辦理，都對(duì)數(shù)據(jù)庫產(chǎn)生了極大壓力.

OceanBase是一個(gè)支持海量數(shù)據(jù)的高性能分布式數(shù)據(jù)庫系統(tǒng)，能夠?qū)崿F(xiàn)數(shù)千億條記錄、數(shù)百TB數(shù)據(jù)上的跨行跨表事務(wù).這是由淘寶研發(fā)出來的適用于淘寶業(yè)務(wù)的數(shù)據(jù)庫，具備高可用性和可靠性.OceanBase能夠承受住“雙十一”在線交易的巨大壓力，在2013年的“雙十一”期間，事務(wù)量最大能達(dá)到68000TPS，一天內(nèi)的交易值達(dá)17億筆之多.使用OceanBase數(shù)據(jù)庫，只要增加更多的機(jī)器，數(shù)據(jù)會(huì)自動(dòng)遷移到新的機(jī)器上.通過這樣簡單的擴(kuò)展，淘寶成功渡過了交易量巨大的“雙十一”.盡管OceanBase當(dāng)前適用于淘寶，它處理大數(shù)據(jù)的能力卻是金融行業(yè)所急需的.

OceanBase也存在一些缺陷：未能支持DATE、DECIMAL等數(shù)據(jù)類型；也沒有足夠的查詢優(yōu)化：能夠支持主鍵索引，未能支持2級(jí)索引.金融企業(yè)的業(yè)務(wù)遠(yuǎn)比淘寶復(fù)雜，因此針對(duì)功能缺陷以及支持的索引來加快查詢速率，OceanBase的模式設(shè)計(jì)是非常必要的.

本文安排如下：第1節(jié)介紹OceanBase的整體框架、OLAP查詢的并行執(zhí)行框架、單表和多表查詢的執(zhí)行計(jì)劃以及OceanBase的功能缺陷.第2節(jié)首先介紹了TPC－H的業(yè)務(wù)場(chǎng)景，并對(duì)其中的查詢進(jìn)行了分類，最后分析OceanBase對(duì)于單表和多表查詢的模式設(shè)計(jì).第3節(jié)會(huì)通過實(shí)驗(yàn)來驗(yàn)證設(shè)計(jì)模式的有效性.第4節(jié)總結(jié)全文.

1 OceanBase功能簡介

OceanBase是一個(gè)既可以支持OLAP應(yīng)用也可以支持OLTP應(yīng)用的分布式關(guān)系型數(shù)據(jù)庫，可以劃分為4個(gè)模塊［1］：主控服務(wù)器RootServer、更新服務(wù)器UpdateServer、基準(zhǔn)數(shù)據(jù)服務(wù)器ChunkServer以及合并服務(wù)器MergeServer.RootServer實(shí)現(xiàn)對(duì)數(shù)據(jù)分布和數(shù)據(jù)副本的管理.UpdateServer存儲(chǔ)著增量更新數(shù)據(jù)，并且只有這個(gè)服務(wù)器允許寫服務(wù).ChunkS－erver存儲(chǔ)著OceanBase的基準(zhǔn)數(shù)據(jù).OceanBase內(nèi)部按照時(shí)間線將數(shù)據(jù)劃分為基準(zhǔn)數(shù)據(jù)和增量數(shù)據(jù)，基準(zhǔn)數(shù)據(jù)是只讀的，而所有的修改都會(huì)更新到增量數(shù)據(jù)中，系統(tǒng)內(nèi)部會(huì)通過合并操作定期將增量數(shù)據(jù)融合到基準(zhǔn)數(shù)據(jù)中.當(dāng)查詢的時(shí)候，會(huì)先從ChunkServer取出數(shù)據(jù)，然后與UpdateServer上的增量數(shù)據(jù)進(jìn)行合并，最后由MergeServer返回合并后的結(jié)果.因此，為了減少查詢時(shí)的合并操作，就需要在查詢前進(jìn)行增量數(shù)據(jù)和基準(zhǔn)數(shù)據(jù)的合并.MergeServer主要負(fù)責(zé)接受并解析用戶的SQL請(qǐng)求，并且負(fù)責(zé)返回ChunkServer合并的結(jié)果集.OceanBase通過自己的容錯(cuò)機(jī)制來防止機(jī)器故障，以便在任何時(shí)候都能給用戶提供服務(wù).

OceanBase對(duì)于OLAP應(yīng)用能夠?qū)崿F(xiàn)并發(fā)查詢功能，很大地提高了查詢速率.當(dāng)用戶進(jìn)行查詢時(shí)，MergeServer首先進(jìn)行SQL的解析，然后將大請(qǐng)求拆分為多個(gè)小請(qǐng)求，將小請(qǐng)求發(fā)送到有相應(yīng)數(shù)據(jù)的ChunkServer，然后由各個(gè)ChunkServer并發(fā)執(zhí)行查詢.OceanBase會(huì)盡量實(shí)現(xiàn)SQL執(zhí)行本地化，包括Filter、Project、子請(qǐng)求部分的GroupBy、OrderBy等.每個(gè)ChunkServer執(zhí)行完查詢，將結(jié)果返回給MergeServer.如果有ChunkServer上的查詢執(zhí)行失敗，MergeServer會(huì)將讓存有副本的其他ChunkServer執(zhí)行，當(dāng)所有的查詢都執(zhí)行完，MergeServer會(huì)對(duì)全部數(shù)據(jù)進(jìn)行排序、分組等操作.

OceanBase目前不支持的數(shù)據(jù)類型有DECIMAL、DATE、CLOB、BLOB和NUMERIC，當(dāng)要使用這幾個(gè)類型的時(shí)候，可以根據(jù)具體場(chǎng)景用其他的類型替換.OceanBase也不支持EXISTS的子句.單表和多表查詢的物理查詢計(jì)劃和其他數(shù)據(jù)庫類似，但是OceanBase只是支持主鍵索引.根據(jù)圖1的單表查詢的物理查詢計(jì)劃，由于OceanBase只支持主鍵索引，以對(duì)于t1表，可以將c3作為第一主鍵，加快了掃描的速度.圖2顯示的是兩表連接的一個(gè)查詢.對(duì)于連接的查詢，on后面的過濾項(xiàng)是沒有索引作用的，所以需要將左邊的SQL轉(zhuǎn)換為中間的SQL形式.對(duì)于左外連接的數(shù)據(jù)查詢，OceanBase中過濾條件位于on和where后面的過濾效果與傳統(tǒng)數(shù)據(jù)庫不一致，因而在實(shí)際業(yè)務(wù)中將其他數(shù)據(jù)庫的左外連接的查詢遷移到OceanBase中時(shí)，過濾條件的位置會(huì)影響結(jié)果的正確性.例如下面2個(gè)SQL，右表的條件寫在on后面和where后面，當(dāng)寫在on后面的時(shí)候，數(shù)據(jù)庫應(yīng)該進(jìn)行的操作是，先按照B.c2＝1的條件進(jìn)行了過濾，然后和A表進(jìn)行連接，連接的結(jié)果是B表可以帶著NULL的情況.當(dāng)條件寫在where后面，就是A和B表做完left join，然后將最后的結(jié)果根據(jù)B.c2＝1進(jìn)行過濾，這時(shí)候的效果與INNER JOIN相同.另外，OceanBase不支持非等值連接，也就是連接的SQL中一定要帶有等值的連接.

（1）SELECT A.c1，B.c1 FROM A LEFT JOIN B ON A.c2＝B.c2 and B.c2＝1；

（2）SELECT A.c1，B.c1 FROM A LEFT JOIN B ON A.c2＝B.c2 WHERE B.c2＝1.

圖1 單表查詢的物理查詢計(jì)劃Fig.1 Physical query plan of single table＇s query

圖2 多表查詢的物理查詢計(jì)劃Fig.2 Physical query plan of multiple tables＇query

OceanBase對(duì)in的使用有特別要求，以加快查詢速率.如果一張表有多個(gè)主鍵，那么當(dāng)in語句中包含全部的主鍵的時(shí)候，這張表的查詢會(huì)用上主鍵索引.例如A表有主鍵k1、k2，需要 WHERE（k1，k2）in（v1，v2）.最后，OceanBase對(duì) where后面的子查詢是不支持的，當(dāng)出現(xiàn)這種情況，需要將子查詢拆分出來，用中間查詢結(jié)果集替換子查詢.

2 OceanBase下TPC－H案例研究

2.1 TPC－H

TPC Benchmark H是一個(gè)決策支持的基準(zhǔn)［5］，它由一系列面向商務(wù)應(yīng)用的查詢和并行數(shù)據(jù)修改組成.基準(zhǔn)里選擇的查詢和組成數(shù)據(jù)庫的數(shù)據(jù)在商業(yè)上都具有廣泛的代表性并且易于實(shí)現(xiàn).目前TPC－H是OLAP領(lǐng)域常用的評(píng)測(cè)標(biāo)準(zhǔn).

TPCH一共有8張表：訂單表（ORDERS），記錄著每個(gè)客戶的訂單狀態(tài)和總額；訂單詳情表（LINEITEM），記錄著每個(gè)訂單下的每個(gè)貨品的狀態(tài)；客戶表（CUSTOMER），記錄著客戶信息；國家表（NATION），記錄著國家的信息；地域表（REGION），記錄著地域的信息；供應(yīng)商表（SUPPLIER），記錄著供應(yīng)商的信息；供應(yīng)貨品表（PARTSUPP），記錄著供應(yīng)商提供的商品；貨品表（PART），記錄著貨品信息.表之間的關(guān)系如圖3所示：

TPC－H有22個(gè)復(fù)雜的查詢，所選擇的查詢?yōu)楦黝惿虡I(yè)分析提供定價(jià)和促銷、供貨和需求管理、利潤和收入管理、顧客滿意度研究、市場(chǎng)份額研究和運(yùn)輸管理.根據(jù)OceanBase功能特點(diǎn)將TPC－H的查詢進(jìn)行了分類：

· 單表有復(fù)雜運(yùn)算的查詢：Q1，Q6

· 多表并且?guī)в衑xists和not exists的查詢：Q4，Q21，Q22

· 多表并且?guī)в衝ot like或者not in的查詢：Q13，Q16

· where或者in中有子句的查詢：Q11，Q15，Q17，Q18，Q20

· 多表的有or條件：Q19

圖3 TPC－H的模式Fig.3 The schema of TPC－H

· 簡單的多表連接：Q2，Q3，Q5，Q7，Q8，Q9，Q10，Q12，Q14.

下面的章節(jié)會(huì)考慮OceanBase當(dāng)前的架構(gòu)，將此TPC－H的案例應(yīng)用到OceanBase，并且讓每個(gè)查詢的效率在OceanBase中達(dá)到最高，還會(huì)將TPC－H的查詢分為單表查詢和多表查詢來進(jìn)行研究.

2.2 單表查詢的用例研究

OceanBase只支持主鍵索引，若想加快單表查詢的查詢速率，就需要設(shè)置輸入的屬性為第1主鍵.本節(jié)主要描述在單表查詢下，TPC－H模式的重新設(shè)計(jì)，使得單表查詢的效率提高.

在實(shí)際生產(chǎn)中，OLTP的數(shù)據(jù)在業(yè)務(wù)量少的時(shí)候會(huì)遷移到數(shù)據(jù)倉庫中，為了保證OLAP的高效率查詢，需要重新設(shè)計(jì)模式，并在數(shù)據(jù)傳送時(shí)進(jìn)行模式的變化.OceanBase由UpdateServer、ChunkServer和RootServer組成，UpdateServer存儲(chǔ)的是增量數(shù)據(jù)，ChunkS－erver存儲(chǔ)的基準(zhǔn)數(shù)據(jù)，RootServer相當(dāng)于1個(gè)master或者1個(gè)索引.當(dāng)進(jìn)行查詢時(shí)，OceanBase會(huì)查詢ChunkServer上的基準(zhǔn)數(shù)據(jù)，然后與UpdateServer上的增量數(shù)據(jù)合并，最后返回給用戶.由于需要合并，查詢速度受到了影響，所以在查詢前需要對(duì)每天的數(shù)據(jù)進(jìn)行合并，將UpdateServer上的數(shù)據(jù)合并到ChunkServer上.

由分類可以知道，單表查詢只有Q1和Q6.Q1查詢的是運(yùn)送日期在60～120天內(nèi)已經(jīng)付款、已運(yùn)送的和已返回的總金額.Q6查詢一年中在指定的百分比內(nèi)的訂單金額.這兩個(gè)查詢都是使用了表LINEITEM，但是表LINEITEM的主鍵是L＿ORDERKEY、LINENUMBER.OceanBase支持主鍵索引，所以若使用原來的主鍵，則無法運(yùn)用OceanBase的主鍵索引，查詢速率低.設(shè)置LINEITEM以L＿SHIPDATE為第1主鍵，并且將原主鍵也作為主鍵以便確定唯一性，就能使用上主鍵索引，從而加快了查詢速率.

2.3 多表查詢的用例研究

該小節(jié)主要討論多表連接的案例，統(tǒng)計(jì)了TPC－H中多表連接的案例并且列于下方.OceanBase會(huì)將操作下推到各個(gè)服務(wù)器端，先對(duì)各個(gè)表進(jìn)行過濾，然后將數(shù)據(jù)取到查詢的mergeserver上，最后進(jìn)行排序合并連接［2］，因此需要盡量減少連接.事實(shí)上，OceanBase對(duì)連接沒有優(yōu)化，而且只是支持主鍵索引，所以需要在外部程序的幫助下，求出做連接的表的主鍵值，對(duì)每個(gè)表增加了主鍵索引，加快了查詢速率.首先列出TPC－H中連接的各種情況，然后分析對(duì)TPC－H的雪花狀模型［3，4，6］的改變，以減少連接.最后將以連接最多的Q8為案例，講解在新的模型下的查詢變化.

表1 多表連接的分類情況Tab.1 Classification of joins

TPC－H模式是一個(gè)雪花狀模型，適合于維度分析，但是從表1中可以總結(jié)出來，查詢基本上是指標(biāo)分析，都會(huì)進(jìn)行連接.為了減少連接，需要根據(jù)這幾種連接來合并表結(jié)構(gòu).由于當(dāng)前的雪花狀模型，當(dāng)進(jìn)行連接的時(shí)候會(huì)涉及好幾張表.分析經(jīng)常出現(xiàn)的表連接有：（1）LINEITEM和ORDERS連接，例如LINEITEM存有供應(yīng)商的序號(hào)，ORDERS表存有顧客的序號(hào)，如果一個(gè)查詢中需要供應(yīng)商和顧客的信息，那么就需要將LINEITEM，ORDERS，SUPPLIER，CUSTOMER進(jìn)行連接，涉及到的查詢有 Q3，Q5，Q7，Q8，Q9，Q10，Q12，Q18，Q21；（2）SUPPLIER，NATION和REGION，例如查詢某個(gè)區(qū)域的售貨商情況，涉及的查詢有Q2，Q5，Q7，Q8，Q11，Q21；3、CUSTOMER，NATION和 REGION，例如查詢某個(gè)區(qū)域的客戶情況，涉及的查詢有Q5，Q7，Q10，Q21.

如果需要查詢供應(yīng)商國家與顧客國家之間的貨物情況，就需要LINEITEM，ORDERS，SUPPLIER，CUSTOMER，PART，NATION，REGION的連接，下面就以連接最多的查詢Q8為例來看一下兩表合并后的SQL的變化：

圖4 連接的案例Fig.4 The example of join

Q8能夠顯示過去兩年中一個(gè)給定的零件類型在某國某地區(qū)的市場(chǎng)份額的改變.市場(chǎng)份額定義為某國某地區(qū)供應(yīng)商供應(yīng)特定種類的產(chǎn)品收入的百分比，是l＿extendedprice＊（1－ldiscount）的和.因?yàn)樾枰薅ü?yīng)商和顧客的國家，時(shí)間需要用ORDERS的訂單時(shí)間，這就需要將這么多的表進(jìn)行連接.由查詢看，只有PART表有p＿type有限定條件，ORDERS表有o＿orderdate有限定.TPC－H中最大的兩個(gè)表為ORDERS和LINEITEM，所以兩表的連接用時(shí)最長，通過將ORDERS和LINEITEM兩表合并為ORDER＿LINEITEM的操作將兩表查詢改為單表查詢.其次，只有CUSTOMER和SUPPLIER兩表有nation和region，所以可以讓CUSTOMER和 NATION、REGION通過C＿NATIONKEY＝N＿NATIONKEY，N＿REGIONKEY＝R＿REGIONKEY做連接，插入到新的表CUSTOMER＿N中.表SUPPLIER和NATION、REGION也通過相同的方法插入到SUPPLIER＿N中，這樣就減少了三表連接.

例1顯示了在新表下的查詢，整個(gè)變化后的模式在圖5中顯示.

圖5 改變后的TPC－H的模式Fig.5 The altered schema of TPC－H

OceanBase中對(duì)于TPC－H的模式與原來的模式不同之處有：將CUSTOMER和NATION，REGION合為CUSTOMER＿N；將SUPPLIER和 NATION，REGION合為SUPPLIER＿N；將LINEITEM和ORDERS合為ORDER＿LINEITEM；新的模式中仍然保留ORDERS，不保留SUPPLIER和CUSTOMER，因?yàn)橛行㏒QL會(huì)使用表ORDERS，如果以O(shè)RDER＿LINEITEM代替，那么掃描的數(shù)據(jù)量會(huì)增大；PART＿N的第1主鍵為P＿TYPE，SUPPLIER＿N的第1主鍵為R＿NAME，PARTSUPP＿N的第1主鍵為PS＿SUPPLYCOST，ORDER＿LINEITEM的第1主鍵為O＿ORDERDATE，CUSTOMER＿N的第1主鍵為N＿NAME.通過表結(jié)構(gòu)的合并減少了表的連接，并且重新設(shè)置第1主鍵，從而提高了查詢速率.

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

本節(jié)以TPC－H的前20個(gè)SQL為案例，根據(jù)上節(jié)所描述的對(duì)單表和多表的改寫方式進(jìn)行改寫.通過對(duì)比OceanBase上TPC－H的模式改變前后的查詢效率，驗(yàn)證OceanBase上模式設(shè)計(jì)的有效性.

3.1 硬件配置及數(shù)據(jù)集

實(shí)驗(yàn)的硬件配置：

· CPU：Intel Xeon cpu e7－4870＠2.4 GHZ8核

· 內(nèi)存：50 G

· 硬盤：100 G

· 操作系統(tǒng)：Redhat 6.2

· 數(shù)據(jù)庫：加上了DECIMAL運(yùn)算的OceanBase 0.4.2.8

實(shí)驗(yàn)所用的數(shù)據(jù)集：TPC－H的數(shù)據(jù)生成器DBgen，生成了1 G的數(shù)據(jù)，其中各個(gè)表的行數(shù)為：

· LINEITEM：6 001 215

· ORDERS：1 500 000

· CUSTOMER：150 000

· SUPPLIER：10 000

· PART：200 000

· PARTSUPP：800 000

· NATION：25

· REGION：5

3.2 模式改變前后效率對(duì)比

以TPC－H的前20個(gè)查詢?yōu)榘咐?，由于最?個(gè)查詢有exists，所以未使用Q21和Q22查詢.首先，將TPC－H的SQL改為OceanBase能夠支持的，使用原來的模式，記錄在OceanBase中運(yùn)行的總時(shí)間.然后，將TPC－H的SQL改為新的模式下的SQL，在Ocean－Base中運(yùn)行后也記錄下時(shí)間.實(shí)驗(yàn)結(jié)果列于表2，時(shí)間以秒為單位.

單表查詢有Q1和Q6，Q6的效果很明顯，因?yàn)镼1是對(duì)LINEITEM的查詢，過濾項(xiàng)只是L＿SHIPDATE小于某個(gè)時(shí)間，主鍵索引沒有太大的作用，過濾出的數(shù)據(jù)集大于Q6的數(shù)據(jù)集，所以導(dǎo)致效果不是那么明顯.從Q6可以看出，在OceanBase中第1主鍵的改變能夠使得查詢速率提高4倍多.

多表連接的查詢中有14個(gè)SQL運(yùn)行時(shí)間是更少的.剩余的4個(gè)多表查詢運(yùn)行時(shí)間長的原因是查詢中沒有直接對(duì)于ORDER＿LINEITEM的過濾項(xiàng)，并且沒有構(gòu)建索引表.對(duì)于多表查詢，在沒有構(gòu)建索引表的情況下，大部分的SQL運(yùn)行時(shí)間更短，因此表的合并使得查詢效率提高.

從實(shí)驗(yàn)結(jié)果可以看出，在OceanBase中對(duì)于TPC－H模式的第1主鍵的改變以及表的合并使得查詢效率提高了許多.

表2 TPC－H的查詢時(shí)間對(duì)比表Tab.2 The running time comparison of TPC－H queries s

4 總 結(jié)

本文講述了面向OLAP應(yīng)用的OceanBase的模式設(shè)計(jì)，并將TPC－H作為案例研究，通過對(duì)比實(shí)驗(yàn)，說明了模式設(shè)計(jì)的有效性.OceanBase支持主鍵索引，但是對(duì)于連接操作還沒有并行處理機(jī)制，并且在左外連接上有缺陷，會(huì)影響結(jié)果的正確性.根據(jù)OceanBase的特點(diǎn)，在模式設(shè)計(jì)的過程中，需要根據(jù)查詢的過濾項(xiàng)來改變表的第1主鍵.如果表的數(shù)據(jù)量小于10 000行，可以不需要主鍵索引.其次，OceanBase支持排序合并連接，所以O(shè)ceanBase需要盡可能減少連接.在模式設(shè)計(jì)過程中，可以根據(jù)業(yè)務(wù)場(chǎng)景來減少連接，將多個(gè)表合為1張表，將多表查詢轉(zhuǎn)換為單表查詢，再通過第1主鍵的設(shè)置，可以加快查詢速率.

［1］ 楊傳輝.大規(guī)模分布式存儲(chǔ)系統(tǒng)：原理解析與架構(gòu)實(shí)戰(zhàn)［M］.北京：機(jī)械工業(yè)出版社，2013.

［2］ 莫利納H，厄爾曼J，懷德姆J.數(shù)據(jù)庫系統(tǒng)實(shí)現(xiàn)［M］.楊冬青，吳愈青，包小源，等譯.2版.北京：機(jī)械工業(yè)出版社，2010.

［3］ 袁霖，康慕寧，李建良，等.一個(gè)面向OLAP應(yīng)用的多維數(shù)據(jù)查詢語言及其在對(duì)象關(guān)系數(shù)據(jù)庫中的實(shí)現(xiàn)［J／OL］.計(jì)算機(jī)工程與應(yīng)用，2004，13：182－218.

［4］ IMHOFF C，NICHOLAS.Mastering data warehouse design：relational and dimensional techniques［M］.John Wiley ＆sons，2004.

［5］ Transaction Processing Performance Council（TPC）.TPC BENCHMARKTM H ［EB／OL］.（1993）［2013－01－02］.http：／／www.tpc.org／tpch／spec／tpch2.17.0.pdf.

［6］ 王珊，薩師煊.數(shù)據(jù)庫系統(tǒng)概論［M］.4版.北京：高等教育出版社，2006.