龐天澤， 張晨東， 高 明， 宮學(xué)慶

（華東師范大學(xué) 軟件學(xué)院，上海 200062）

0 引 言

數(shù)據(jù)庫按照表結(jié)構(gòu)來組織、存儲和管理數(shù)據(jù)，被廣泛應(yīng)用于各行各業(yè)，以提供數(shù)據(jù)支撐［1］.數(shù)據(jù)庫模型主要分為網(wǎng)狀模型、層次模型、關(guān)系模型和面向?qū)ο竽Ｐ偷龋?］.其中，關(guān)系模型使用二維表來描述數(shù)據(jù)間的關(guān)系，具有很好的數(shù)據(jù)獨立性和簡潔的數(shù)據(jù)組織結(jié)構(gòu).目前主流數(shù)據(jù)庫管理系統(tǒng)均采用關(guān)系模型，如 Oracle［3］、DB2［4］、MySql［5］等，這類傳統(tǒng)的關(guān)系型數(shù)據(jù)庫采用集中式的管理模式，即數(shù)據(jù)的存儲和處理一般都集中于一個節(jié)點上.而數(shù)據(jù)庫廠商則通過不斷地提高節(jié)點的存儲和處理能力，來應(yīng)對業(yè)務(wù)和數(shù)據(jù)量的增長.但是，由于近幾年互聯(lián)網(wǎng)的快速發(fā)展，全球數(shù)據(jù)量正呈爆炸式增長，傳統(tǒng)的集中式數(shù)據(jù)庫難以承載海量數(shù)據(jù)的存儲和訪問.

為解決這一問題，分布式數(shù)據(jù)庫是一個不錯的選擇.在分布式數(shù)據(jù)庫中，系統(tǒng)通常會根據(jù)數(shù)據(jù)分片和數(shù)據(jù)分配的策略，將數(shù)據(jù)分布存儲在多個節(jié)點上.節(jié)點之間通過網(wǎng)絡(luò)相互連接，當(dāng)數(shù)據(jù)庫收到數(shù)據(jù)請求時，能夠?qū)⒄埱蟀l(fā)往相應(yīng)的節(jié)點進行處理，降低了單個節(jié)點的負載.另外，在分布式數(shù)據(jù)庫中，為了防止數(shù)據(jù)由于節(jié)點故障而造成丟失或無法訪問，一般會為數(shù)據(jù)創(chuàng)建多個副本，分別存儲在不同的節(jié)點上.這樣，即使有某個節(jié)點出現(xiàn)故障，也不會影響數(shù)據(jù)庫的正常使用，很大程度上提高了數(shù)據(jù)庫的可靠性.分布式數(shù)據(jù)庫很好地解決了集中數(shù)據(jù)庫的數(shù)據(jù)存儲瓶頸，并提升了數(shù)據(jù)庫的可靠性.但是在實際應(yīng)用中，它仍存在一些問題.在分布式數(shù)據(jù)庫中，節(jié)點之間通過網(wǎng)絡(luò)互連，數(shù)據(jù)會跨節(jié)點甚至跨地域分布.如果應(yīng)用中存在連接操作，并且涉及的各張表數(shù)據(jù)分別存儲在不同節(jié)點上，那么執(zhí)行該應(yīng)用時將會造成數(shù)據(jù)的跨節(jié)點交互.特別是對于OLAP業(yè)務(wù)，數(shù)據(jù)量一般十分龐大，連接操作導(dǎo)致的大量數(shù)據(jù)交互會產(chǎn)生巨大的網(wǎng)絡(luò)傳輸開銷，嚴(yán)重影響數(shù)據(jù)庫的性能.此外，由于數(shù)據(jù)分布存儲并具有多個副本，副本間的數(shù)據(jù)一致性需要數(shù)據(jù)庫來維護，這也會給數(shù)據(jù)庫的性能帶來負面影響.

在實踐中，數(shù)據(jù)設(shè)計通常都會遵循范式.然而，嚴(yán)格的范式設(shè)計無法保證數(shù)據(jù)庫在任何情況下都能有最優(yōu)的性能［6］.為減少數(shù)據(jù)冗余，范式設(shè)計的數(shù)據(jù)庫通常會包含大量的表格，因此，查詢時可能需要連接多張表后才能獲得需要的全部數(shù)據(jù).而過多的連接操作是數(shù)據(jù)庫性能下降的主要因素，特別是在大數(shù)據(jù)量情況下，影響更大.因此，通過減少表的數(shù)量，同時增加數(shù)據(jù)冗余，盡量減少查詢中的連接操作，從而提高數(shù)據(jù)庫性能，這正是所謂的反范式數(shù)據(jù)庫模式設(shè)計.尤其是在數(shù)據(jù)倉庫業(yè)務(wù)中，由于數(shù)據(jù)量相對龐大，查詢請求也較為復(fù)雜，反范式設(shè)計可以很好地改善數(shù)據(jù)庫性能，以滿足業(yè)務(wù)需求.

由于在分布式數(shù)據(jù)庫中增加了網(wǎng)絡(luò)傳輸開銷，傳統(tǒng)的數(shù)據(jù)庫范式設(shè)計方法帶來的問題被放大.因此，反范式模式設(shè)計可能是分布式數(shù)據(jù)庫的一個選擇，這是因為：（1）分布式數(shù)據(jù)庫通過多節(jié)點數(shù)據(jù)冗余提高系統(tǒng)可用性，數(shù)據(jù)的完整性不再是通過減少冗余來實現(xiàn)；（2）反范式模式設(shè)計降低了網(wǎng)絡(luò)數(shù)據(jù)傳輸開銷，可以提高分布式數(shù)據(jù)庫的性能.但是反范式模式設(shè)計也有缺點，比如在OLTP中，數(shù)據(jù)庫的增、刪、改的操作十分常見，較多的數(shù)據(jù)冗余會增加操作異常、降低數(shù)據(jù)獨立性；但OLAP的絕大部分是海量數(shù)據(jù)庫上的select操作，不會導(dǎo)致操作異常，也不會影響數(shù)據(jù)獨立性.因此，反范式模式設(shè)計是分布式數(shù)據(jù)庫中OLAP業(yè)務(wù)的首選.本文主要針對OLAP介紹分布式數(shù)據(jù)庫的模式設(shè)計方法，為DBA提供一些思路和方法.基于分布式數(shù)據(jù)庫OceanBase［7］，通過常用的基準(zhǔn)測試TPC－H，驗證了反范式模式設(shè)計在分布式OLAP業(yè)務(wù)上的有效性.

本文第1節(jié)介紹了傳統(tǒng)數(shù)據(jù)庫模式設(shè)計，包括范式設(shè)計和反范式設(shè)計，并列舉了常用的反范式方法.第2節(jié)結(jié)合OceanBase數(shù)據(jù)庫，分析如何使用反范式模式設(shè)計方法改善OLAP的性能.第3節(jié)通過實驗驗證了反范式模式設(shè)計在OLAP業(yè)務(wù)中的有效性.最后，第4節(jié)總結(jié)全文.

1 數(shù)據(jù)庫模式設(shè)計

數(shù)據(jù)庫設(shè)計一般要經(jīng)過三個步驟：概念設(shè)計、邏輯設(shè)計和物理設(shè)計［8］.概念設(shè)計，就是對真實世界中的各種實體進行提煉和抽象，并明確它們之間的關(guān)系，是現(xiàn)實世界到數(shù)據(jù)實體的第一層抽象，一般通過E－R圖來描述.邏輯設(shè)計是針對特定數(shù)據(jù)庫，根據(jù)概念設(shè)計階段的數(shù)據(jù)實體和關(guān)系，建立一組數(shù)據(jù)庫表結(jié)構(gòu)的描述，包括確定表的屬性、主鍵以及表之間的關(guān)聯(lián)，它是數(shù)據(jù)庫設(shè)計的關(guān)鍵步驟，決定了設(shè)計的優(yōu)劣.物理設(shè)計將依據(jù)具體數(shù)據(jù)庫的功能，確定表格各屬性的存儲類型和約束，最終得到所需要的數(shù)據(jù)庫.

1.1 數(shù)據(jù)庫范式設(shè)計

簡單來說，范式設(shè)計是將數(shù)據(jù)屬性進行組織、精煉的過程.E.F.Codd最先開始了范式研究，并提出了三大范式［9，10］.使用范式設(shè)計的數(shù)據(jù)庫，可以合理地組織數(shù)據(jù)，使得數(shù)據(jù)庫的各表之間具有很高的獨立性，很大程度上減少了數(shù)據(jù)冗余.在進行更新、刪除等操作時，由于數(shù)據(jù)獨立性高，用戶通常只需要對一張表的數(shù)據(jù)做相應(yīng)操作，減少了由于數(shù)據(jù)冗余帶來的各種操作異常.對于OLTP應(yīng)用，例如在線交易、銀行轉(zhuǎn)賬等，通常會存在大量的增、刪、改等操作.在OLTP應(yīng)用中使用范式能夠有效組織數(shù)據(jù)，并減少數(shù)據(jù)冗余和更新異常.依照范式設(shè)計數(shù)據(jù)庫，實現(xiàn)數(shù)據(jù)庫規(guī)范化，對于數(shù)據(jù)庫性能一般會有積極影響.范式設(shè)計雖然提高了數(shù)據(jù)獨立性，但也意味著增加了表的數(shù)量，導(dǎo)致表間關(guān)聯(lián)操作的增加，而這正是影響關(guān)系型數(shù)據(jù)庫查詢效率的關(guān)鍵所在.在OLAP業(yè)務(wù)中，絕大部分需求都是查詢統(tǒng)計.這些查詢需求一般都比較復(fù)雜，涉及到很多的統(tǒng)計分析和表的連接操作.而且由于OLAP業(yè)務(wù)需要處理的數(shù)據(jù)量十分龐大，數(shù)據(jù)庫的性能必將因為大量的連接操作而大幅下降，以至無法滿足業(yè)務(wù)需求.

1.2 數(shù)據(jù)庫反范式設(shè)計

為降低查詢復(fù)雜度，提高查詢效率，針對OLAP業(yè)務(wù)，在數(shù)據(jù)庫的模式設(shè)計階段反范式（Denormalization）設(shè)計是一種重要的方法.

所謂反范式設(shè)計，是指通過降低傳統(tǒng)的數(shù)據(jù)規(guī)范化程度，以提高查詢性能的過程.通過反范式可以顯著減少表的數(shù)量，并減少查詢請求中的連接操作的數(shù)量.目前，已經(jīng)有許多關(guān)于反范式設(shè)計的應(yīng)用和方法的研究.Tupper［11］提出兩種方法，分別在數(shù)據(jù)庫設(shè)計的不同階段考慮反范式，一種方式是在設(shè)計ERD（實體聯(lián)系圖）階段，就盡可能減少邏輯實體的數(shù)量，不用過于考慮數(shù)據(jù)的冗余度；另一種方式則是在物理設(shè)計階段，針對具體的應(yīng)用，使用反范式的方法增加表或表的屬性，引入數(shù)據(jù)冗余并通過觸發(fā)器來保證冗余數(shù)據(jù)的更新一致性.Date［12］認為，應(yīng)當(dāng)在物理設(shè)計時使用反范式，而不建議在邏輯設(shè)計階段考慮反范式，否則可能會影響原本清晰合理的數(shù)據(jù)結(jié)構(gòu)和邏輯關(guān)系；Hahnke［13］證明了在商業(yè)分析型的應(yīng)用中，反范式設(shè)計的數(shù)據(jù)庫模式可以提供更佳的查詢和分析性能.Rodgers［8］討論了反范式的應(yīng)用場景，介紹了何時應(yīng)考慮進行反范式設(shè)計，并認為通常在一對一的實體關(guān)系中，反范式是有效的.反范式設(shè)計也有其不足之處，例如數(shù)據(jù)冗余、數(shù)據(jù)更新異常以及更復(fù)雜的數(shù)據(jù)完整性約束.Coleman［14］認為，反范式設(shè)計在適應(yīng)數(shù)據(jù)變化上有所不足，需要設(shè)計者深刻理解業(yè)務(wù)場景，充分考慮數(shù)據(jù)更新的頻繁性，如果數(shù)據(jù)經(jīng)常進行更新，那么對于這些數(shù)據(jù)就需要慎用反范式方法，以免造成更新效率降低，甚至產(chǎn)生數(shù)據(jù)不一致.盡管反范式設(shè)計有缺點，但合理的設(shè)計可以降低這些缺點帶來的不利影響，充分發(fā)揮反范式的優(yōu)點可以提高OLAP業(yè)務(wù)的性能.

1.3 數(shù)據(jù)庫反范式設(shè)計

反范式會通過增加冗余來提高查詢性能，即所謂的“以空間換時間”.需要注意的是，反范式不是一種設(shè)計規(guī)范，而僅僅是當(dāng)數(shù)據(jù)庫性能不能滿足要求時的一種解決方案.通常都是先按照范式進行數(shù)據(jù)設(shè)計，然后基于當(dāng)前數(shù)據(jù)組織結(jié)構(gòu)使用反范式策略，以提高查詢效率.反范式設(shè)計通常有下列幾種方法［15，16］.

（1）通過預(yù)連接減少連接開銷.如果用戶需要經(jīng)常使用包含多表連接操作的查詢，可以提前將這些表連接后的結(jié)果存入一張單表中.這樣使得查詢由對多表的操作轉(zhuǎn)為單表，避免了重復(fù)連接，能顯著提高效率.當(dāng)連接涉及的表的更新較少時，預(yù)連接結(jié)果可以長時間保持不變，因此這種方法是比較有效的.

（2）通過表鏡像提高訪問并發(fā)度.鏡像技術(shù)主要對數(shù)據(jù)庫中訪問量較高的表進行復(fù)制，源表和鏡像表的模式完全相同，均可以同時對外提供服務(wù).由于源表和鏡像表之間的數(shù)據(jù)是異步的，源表和鏡像表的數(shù)據(jù)可能會出現(xiàn)不一致，因此，源表可以提供對外的讀和寫服務(wù)，而鏡像表一般只對外提供讀服務(wù).

（3）生成統(tǒng)計報表提高OLAP查詢效率.很多業(yè)務(wù)是通過查詢獲得一系列報表數(shù)據(jù)，涉及大量的統(tǒng)計計算.為了提高效率，可以事先將報表所需的信息進行統(tǒng)計，并記錄到一張單表中.由于報表通常是對過去一段時間信息的統(tǒng)計，對實時數(shù)據(jù)不敏感，因此可以在每日訪問低峰期生成報表，用于第二天的查詢.

（4）拆分表結(jié)構(gòu)減少用戶查詢時涉及的數(shù)據(jù)量.根據(jù)業(yè)務(wù)查詢需要的字段的不同，將表格拆分成多個子表.每個業(yè)務(wù)只需要訪問各自的子表即可獲取所需數(shù)據(jù)，減少了需要搜索的數(shù)據(jù)量.拆分表結(jié)構(gòu)一般包括垂直拆分和水平拆分，垂直拆分是將源表的屬性根據(jù)不同的業(yè)務(wù)需求分割開，存入不同的新表中，每張新表都冗余原始表的主鍵屬性，以保證記錄唯一性；而水平拆分則是保留源表所有屬性，根據(jù)主鍵范圍進行拆分，拆分后每塊數(shù)據(jù)存入新的表中，新表的結(jié)構(gòu)與源表一致.

（5）增加派生屬性減少查詢時的運算開銷.如果有查詢需要經(jīng)常對表中某幾個屬性數(shù)據(jù)做相同運算，那么可以為表格增加一個派生屬性，用于存儲這幾個屬性數(shù)據(jù)預(yù)算的結(jié)果.如果數(shù)據(jù)有更新，派生屬性也需要做相應(yīng)的更新.之后該查詢就可以直接從派生屬性獲取數(shù)據(jù)，無需再做運算.

（6）通過冗余數(shù)據(jù)避免表連接，提高查詢效率.與預(yù)連接方法不同的是，冗余數(shù)據(jù)的方法是在邏輯設(shè)計時，就將原本需要連接多張表才能獲取到的屬性存儲在一張表中.查詢所需要的數(shù)據(jù)都可以在這張表中得到，也就不必再進行連接操作.

2 分布式數(shù)據(jù)庫中模式設(shè)計分析

2.1 OceanBase系統(tǒng)架構(gòu)

近年來，分布式數(shù)據(jù)庫產(chǎn)品也在商業(yè)實踐中得到成功應(yīng)用，例如Oracle公司的Mysql Cluster［17］，Google的 Spanner［18］，Greenplum［19］以及淘寶的 OceanBase［7］等.其中，Ocean－Base是淘寶自主研發(fā)的關(guān)系型分布式數(shù)據(jù)庫，支持千億級記錄的跨行跨表事務(wù)，能夠為互聯(lián)網(wǎng)級應(yīng)用提供數(shù)據(jù)存儲平臺，并滿足其高性能并發(fā)訪問需求.OceanBase實現(xiàn)了數(shù)據(jù)的分布存儲并提供了數(shù)據(jù)的基本操作功能.OceanBase將數(shù)據(jù)劃分后分布式地存儲在不同的節(jié)點上，極大增加了數(shù)據(jù)庫的存儲能力.OceanBase根據(jù)服務(wù)器節(jié)點功能的不同，將其分為4類，包括 RootServer、UpdateServer、ChunkServer和 MergeServer，如圖 1 所示.其中ChunkServer負責(zé)數(shù)據(jù)存儲，集群中大部分節(jié)點都用于部署ChunkServer；MergeServer主要用來做SQL解析和執(zhí)行，并收集執(zhí)行結(jié)果返回給用戶，一般與ChunkServer共享物理節(jié)點；UpdateServer是OceanBase中唯一接收寫請求的節(jié)點，寫入的數(shù)據(jù)會定期合并到ChunkServer中；RootServer主要用于管理集群中各個節(jié)點，維護數(shù)據(jù)分布信息，以及其它一些全局參數(shù).

圖1 OceanBase物理架構(gòu)［7］Fig.1 The physical architecture of OceanBase

OceanBase的查詢處理流程與其他分布式數(shù)據(jù)庫有所區(qū)別.當(dāng)查詢開始時，MergeServer會接受并解析查詢請求.由于OceanBase自動對表進行水平切分，每各分塊可能存儲在不同的ChunkServer上，因此MergeServer可能會將數(shù)據(jù)請求發(fā)往不同ChunkServer.最終MergeServer再將從各個存儲節(jié)點上獲取的數(shù)據(jù)集進行合并，并返回給用戶.對于涉及表連接的查詢，數(shù)據(jù)庫會首先根據(jù)查詢條件對各個關(guān)聯(lián)表過濾，這個過程相當(dāng)于對每張表做單表查詢，之后MergeServer會將返回結(jié)果進行連接等操作，最后將結(jié)果返回給用戶.整個查詢處理流程中，會包含多次網(wǎng)絡(luò)傳輸；如果ChunkServer返回的結(jié)果集過大，會導(dǎo)致很大的網(wǎng)絡(luò)開銷.另外，數(shù)據(jù)處理和連接操作的壓力都集中在MergeServer，使得MergeServer負載較高.為優(yōu)化性能，OceanBase中引入了主鍵序和主鍵前綴的概念.在定義表的模式時，可以按序?qū)⒈碇械娜舾蓚€字段，如c1、c2，定義為聯(lián)合主鍵，c1和c2分別被稱為第一主鍵和第二主鍵.其中c1的主鍵序為1，而c2的主鍵序為2.第一主鍵c1被稱作c1、c2聯(lián)合主鍵的主鍵前綴.OceanBase針對主鍵前綴做了索引優(yōu)化，因此應(yīng)用中使用主鍵前綴進行查詢，可以顯著提高查詢效率.

OceanBase適用于海量數(shù)據(jù)的存儲并能夠應(yīng)對網(wǎng)絡(luò)級數(shù)據(jù)應(yīng)用，并具有良好的可擴展性，應(yīng)用前景廣泛.目前，OceanBase已經(jīng)在淘寶業(yè)務(wù)中得到廣泛使用，成功的實踐證明了OceanBase的可靠性.但是，由于OceanBase的開發(fā)初衷是支持淘寶業(yè)務(wù)，其功能還不如DB2等傳統(tǒng)數(shù)據(jù)庫齊全，例如不支持where條件的子查詢、二級索引等功能，也不支持DATE、CLOB、BLOB等數(shù)據(jù)類型.另外，OceanBase系統(tǒng)雖然解決了數(shù)據(jù)存儲的問題，但在處理OLAP業(yè)務(wù)時的性能仍有待提高.其實，由于網(wǎng)絡(luò)開銷較大，OceanBase都無法高效地處理OLAP業(yè)務(wù).下面幾節(jié)，本文將結(jié)合OceanBase的架構(gòu)，介紹如何在分布式數(shù)據(jù)庫中合理使用反范式來提高OLAP業(yè)務(wù)的查詢效率，并使用TPC－H作為測試基準(zhǔn)進行驗證.

2.2 TPC－H案例研究與分析

TPC－H［20］是 TPC（Transaction Processing Performance Council，事務(wù)處理性能委員會）提出的基準(zhǔn)程序，是一個決策支持的標(biāo)準(zhǔn)，常用于對OLAP數(shù)據(jù)庫性能進行基準(zhǔn)測試.TPC－H包含一組面向商務(wù)應(yīng)用的查詢語句和數(shù)據(jù)修改語句，共22個，這些語句都具有代表性且易于實現(xiàn).TPC－H中共有8張基本表，表的模式（Schema）定義和各個表的關(guān)系如圖2所示.

圖2 TPC－H模式Fig.2 The Schema of TPC－H

TPC－H包含的22個查詢測試案例中大部分都比較復(fù)雜，具有隨機特性.表1列出了22個查詢案例，并指出了每個查詢案例中對性能影響最大的因素，并列出各個案例涉及到的表格.少數(shù)案例只涉及單表查詢，但包含了大量的統(tǒng)計計算，這樣會嚴(yán)重影響查詢效率；而多數(shù)案例中存在多表連接，不僅包括顯式的JOIN語句，還包含隱含在子查詢中的連接.經(jīng)過分析發(fā)現(xiàn)，國家表nation和地域表region在很多案例的SQL中都被關(guān)聯(lián)在一起，而且這兩張表的數(shù)據(jù)通常不會被更新和修改.因此，可以將nation表與region表合并為一張新的表nation＿re，這樣就避免了這兩張表的連接操作.orders表存儲了訂單信息，很多TPC－H的案例，例如Q2、Q3和Q4等，希望同時獲取交易明細信息（lineitem）、客戶信息（customer）和訂單信息（orders），或者三者之二.lineitem和orders的數(shù)據(jù)量都很大，又經(jīng)常相互連接.為進一步減少表連接，特別是大表連接操作，可以在orders表中冗余l(xiāng)ineitem和customer表的信息，得到表orders＿li＿cu.對于查詢Q1來說，復(fù)雜的統(tǒng)計計算嚴(yán)重影響了查詢效率.可以先通過SQL將需要獲取的統(tǒng)計信息計算出來，存入統(tǒng)計表中，查詢時只需要訪問統(tǒng)計表即可.

表1 TPC－H查詢案例情況Tab.1 Cases in TPC－H

由于OceanBase支持的功能有限，凡涉及視圖、exist語句、where條件的子句等功能都無法在TPC－H上進行測試.經(jīng)過篩選，在TPC－H的22查詢案例中OceanBase只支持價格摘要報告查詢（Q1）和運送優(yōu)先權(quán)查詢（Q3）.其中，Q1是單表查詢，但是涉及到了大量統(tǒng)計計算，而Q3涉及多表連接.這兩個案例在SQL語法上較為簡單，在邏輯上易于理解，而且不涉及OceanBase不支持的功能，能夠很容易地遷移到OceanBase上進行實驗.另外，Q1和Q3都是典型的OLAP查詢，它們包含的數(shù)據(jù)統(tǒng)計和多表連接也都是傳統(tǒng)數(shù)據(jù)庫中常見的.如果使用嚴(yán)格的范式數(shù)據(jù)庫設(shè)計，其查詢效率通常不高.

價格摘要報告查詢Q1提供了給定日期運送的所有行的價格摘要報告.每次查詢時，系統(tǒng)都會將符合條件的數(shù)據(jù)記錄全部從ChunkServer遷移到MergeServer上，然后由MergeServer完成統(tǒng)計計算，這使得MergeServer負載很高，查詢響應(yīng)時間長.如果有大量用戶同時提交該查詢，甚至?xí)绊懻麄€數(shù)據(jù)庫的訪問效率.因此，本文根據(jù)反范式模式設(shè)計策略，預(yù)先生成統(tǒng)計報表lineitem＿sta，其中，Q1中作為分組條件的兩個字段l＿retrunflag和l＿linestatus，以及運送日期l＿shipdate組成聯(lián)合主鍵，l＿shipdate設(shè)為第一主鍵.統(tǒng)計表還包含sum＿qty，sum＿base＿price，sum＿disc＿pirce等統(tǒng)計屬性.統(tǒng)計報表中的每條記錄表示某個運送日期之前（包含運送日期），某組l＿returnflag和l＿linestatus的統(tǒng)計信息.這樣，查詢Q1可以直接根據(jù)l＿shipdate查詢lineitem＿sta的若干條記錄獲取所需結(jié)果.

運送優(yōu)先權(quán)查詢Q3給出在指定的日期之前尚未運送的訂單中具有最大收入的訂單的優(yōu)先權(quán)和潛在的收入.Q3需要連接三張表，其中l(wèi)ineitem表和orders表的數(shù)據(jù)量都很大.并且查詢語句中給出的查詢條件都是范圍查詢，使得每張表過濾出的結(jié)果集較大，導(dǎo)致大量數(shù)據(jù)從ChunkServer通過網(wǎng)絡(luò)傳輸?shù)組ergeServer，造成很大的網(wǎng)絡(luò)開銷.另外，將幾個大數(shù)據(jù)量的結(jié)果集進行連接的效率也是很低的.經(jīng)過分析，可以對orders、lineitem和customer合并后的表orders＿li＿cu直接做單表查詢.

最后，經(jīng)過反范式設(shè)計的新TPC－H模式如圖3所示.新的模式中，orders＿li＿cu表冗余存儲了orders、lineitem表和customer表的所有數(shù)據(jù)，去除了原來的三張表.將nation表和region表合并為nation＿re.另外，還增加了lineitem的統(tǒng)計表lineitem＿sta.

圖3 新TPC－H模式Fig.3 New schema of TPC－H

3 實 驗

根據(jù)新的數(shù)據(jù)庫模式，將Q1和Q3對應(yīng)的SQL查詢需要做相應(yīng)調(diào)整.Q1可以使用圖4（右）所示的查詢SQL代替.其中，為了方便描述，將SQL語句中的條件date‘1998－12－01’－interval‘［DELTA］’day（3）直接改為‘［DATE］’，表示在［DATE］這個日期之前的數(shù)據(jù)需要進行統(tǒng)計.

圖4 使用反范式設(shè)計后Q1查詢SQL的修改Fig.4 Modification of SQL query for Q1 after denormalization

由于在新模式中，表orders＿li＿cu已經(jīng)包含了原模式orders，lineitem和customer中所有的字段，因此Q3就再不需要進行join連接，而只需從oreders＿li＿cu中獲取數(shù)據(jù).因為l＿orderkey＝o＿orderkey且c＿custkey＝o＿custkey，所以在擴展表orders＿li＿cu中只需要o＿custkey，不必冗余l(xiāng)＿orderkey和custkey字段.查詢案例中可以去除條件l＿orderkey＝o＿orderkey，并將l＿orderkey改為o＿orderkey.同理，也可以去除條件c＿custkey＝o＿custkey.查詢SQL調(diào)整后的結(jié)果見圖5（右）.

圖5 使用反范式設(shè)計后Q3查詢SQL的修改Fig.5 Modification of SQL query for Q3 after denormalization

在Linux服務(wù)器上搭建0.4.2.18＿22M版本的OceanBase數(shù)據(jù)庫，服務(wù)器的硬件配置說明見表2.

表2 服務(wù)器的硬件配置Tab.2 The configuration of servers

在OceanBase中新建數(shù)據(jù)表后，使用TPC－H數(shù)據(jù)生成器生成數(shù)據(jù)（SF參數(shù)設(shè)置為1）并進行數(shù)據(jù)加載.由于只測試Q1和Q3兩個案例，因此只需加載orders、customer和lineitem三張表，其記錄數(shù)分別為150 000、150 000和6 001 215.

當(dāng)測試Q1時，選取6個［DATE］參數(shù)進行查詢，與TPC－H原始案例進行比較.測試Q3時，［SEGMENT］設(shè)置為 BUILDING，［DATE］參數(shù)則在［1995－03－01，1995－03－31］中選取，共取6個日期作為參數(shù)，間隔5 d.實驗結(jié)果如表3與表4所示.表3中，隨DATE參數(shù)增長，根據(jù)Q1中的過濾條件，查詢時需要進行統(tǒng)計的數(shù)據(jù)集也隨之增大，使得使用舊模式設(shè)計的數(shù)據(jù)庫響應(yīng)時間成線性增長.但使用反范式重新設(shè)計模式后，表中只需存儲Q1的統(tǒng)計結(jié)果，無需進行復(fù)雜計算，降低了系統(tǒng)開銷.查詢時，通過DATE參數(shù)，可以直接獲得該日期之前的統(tǒng)計信息，因此新的數(shù)據(jù)庫模式下，查詢響應(yīng)時間得到顯著提高，且基本不會隨DATE參數(shù)的變化而改變.表4是Q3的實驗結(jié)果，可以看出查詢效率得到了很大提升，基本相差一個量級.這是由于重新設(shè)計的數(shù)據(jù)庫模式中，已經(jīng)將查詢Q3所涉及的字段值都冗余到了表orders＿li＿cu中，將原來的三表連接查詢改為單表查詢，避免了連接操作，減少了網(wǎng)絡(luò)傳輸?shù)拈_銷.

表4 查詢Q3的響應(yīng)時間Tab.4 The response time of Q3

表3 查詢Q1的響應(yīng)時間Tab.3 The response time of Q1

4 總 結(jié)

本文介紹了范式設(shè)計和反范式設(shè)計的區(qū)別和應(yīng)用場景，以及一些典型的反范式模式設(shè)計方法，然后通過重新設(shè)計TPC－H基準(zhǔn)測試案例中的Q1和Q3相關(guān)數(shù)據(jù)庫模式，在分布式數(shù)據(jù)庫OceanBase中對查詢效率的提升進行了實驗驗證.結(jié)果表明，新的數(shù)據(jù)庫模式可以有效提升OLAP業(yè)務(wù)的查詢效率.雖然增加了數(shù)據(jù)冗余，但是考慮分布式環(huán)境下的存儲容量不再是瓶頸，數(shù)據(jù)冗余可以不作為考慮因素.在進行分布式數(shù)據(jù)庫模式設(shè)計時，需要充分考慮業(yè)務(wù)需求，適當(dāng)利用一些反范式方法，可以有效優(yōu)化查詢性能.

［1］ SILBERSCHATZ A，KORTH H F，SUDARSHAN S.數(shù)據(jù)庫系統(tǒng)概念［M］.楊冬青，馬秀莉，譯.北京：機械工業(yè)出版社，2012.

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

［3］ Oracle［DB／OL］.http：／／www.oracle.com／index.html.

［4］ BD2［DB／OL］.http：／／www－01.ibm.com／software／data／db2.

［5］ Mysql［DB／OL］.www.mysql.com.

［6］ RODGERS U.Denormalization：why，what，and how？［J］.Database Programming and Design，1989，2（12）：46－53.

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

［8］ STEPHENS R K，PLEW R R.數(shù)據(jù)庫系統(tǒng)概論［M］.何玉潔，譯.北京：機械工業(yè)出版社，2001.

［9］ CODD E F.A relational model of data for large shared data banks［J］.Comm ACM，1970，13（6）：377－387.

［10］ CODD E F.Normalized data base structure：A brief tutorial［C］／／Proceedings of ACM SIG－FIDET Workshop on Data Description，Access，and Control.San Diego，California，Nov.11－12，1971.

［11］ TUPPER C.The physics of logical modeling.Database［J］.Programming ＆ Design，1998.

［12］ DATE C J.The birth of the relational model［J］.Intelligent Enterprise Magazine.1998.

［13］ HAHNKE J.Data model design for business analysis［J］.Unix Review，1996，14（10）.

［14］ COLEMAN G.Normalizing not only way［J］.Computerworld，1989：63－64.

［15］ HOLLINGSWORTH M.Data normalization，denormalization，and the forces of darkness［EB／OL］.http：／／www.fastanimals.com／melissa.

［16］ SANDERS G L，SHIN S.Denormalization effects on performance of RDBMS［C］／／Proceeding of the 34th Hawaii International Conference on System Sciences－HICSS，2001.

［17］ MySQL Cluster.Overview［EB／OL］.http：／／dev.mysql.com／doc／refman／5.0／en／mysql－cluster－overview.html.

［18］ CORBETT J C，DEAN J，EPSTEIN M，et al.Spanner：Google’s Globally－Distributed Database［C］／／Proceedings of the first USENIX Symposium on Operating Systems Design and Implementation（OSDI），2012.

［19］ GREENPLUM 數(shù)據(jù)庫引擎探究［DB／OL］.http：／／www.cnblogs.com／daduxiong／archive／2010／10／13／1850411.html.

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