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

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

0 引 言

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

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

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

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

1 OceanBase功能簡介

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

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

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

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

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

2 OceanBase下TPC－H案例研究

2.1 TPC－H

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

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

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

· 單表有復雜運算的查詢：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é)會考慮OceanBase當前的架構(gòu)，將此TPC－H的案例應用到OceanBase，并且讓每個查詢的效率在OceanBase中達到最高，還會將TPC－H的查詢分為單表查詢和多表查詢來進行研究.

2.2 單表查詢的用例研究

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

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

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

2.3 多表查詢的用例研究

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

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

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

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

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

Q8能夠顯示過去兩年中一個給定的零件類型在某國某地區(qū)的市場份額的改變.市場份額定義為某國某地區(qū)供應商供應特定種類的產(chǎn)品收入的百分比，是l＿extendedprice＊（1－ldiscount）的和.因為需要限定供應商和顧客的國家，時間需要用ORDERS的訂單時間，這就需要將這么多的表進行連接.由查詢看，只有PART表有p＿type有限定條件，ORDERS表有o＿orderdate有限定.TPC－H中最大的兩個表為ORDERS和LINEITEM，所以兩表的連接用時最長，通過將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顯示了在新表下的查詢，整個變化后的模式在圖5中顯示.

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

OceanBase中對于TPC－H的模式與原來的模式不同之處有：將CUSTOMER和NATION，REGION合為CUSTOMER＿N；將SUPPLIER和 NATION，REGION合為SUPPLIER＿N；將LINEITEM和ORDERS合為ORDER＿LINEITEM；新的模式中仍然保留ORDERS，不保留SUPPLIER和CUSTOMER，因為有些SQL會使用表ORDERS，如果以O(shè)RDER＿LINEITEM代替，那么掃描的數(shù)據(jù)量會增大；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 實 驗

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

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

實驗的硬件配置：

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

· 內(nèi)存：50 G

· 硬盤：100 G

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

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

實驗所用的數(shù)據(jù)集：TPC－H的數(shù)據(jù)生成器DBgen，生成了1 G的數(shù)據(jù)，其中各個表的行數(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 模式改變前后效率對比

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

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

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

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

表2 TPC－H的查詢時間對比表Tab.2 The running time comparison of TPC－H queries s

4 總 結(jié)

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

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

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

［3］ 袁霖，康慕寧，李建良，等.一個面向OLAP應用的多維數(shù)據(jù)查詢語言及其在對象關(guān)系數(shù)據(jù)庫中的實現(xiàn)［J／OL］.計算機工程與應用，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.