分布式環(huán)境中數(shù)據(jù)庫模式設(shè)計(jì)實(shí)踐

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

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

0 引 言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2 TPC－H案例研究與分析

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

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

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

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

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

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

運(yùn)送優(yōu)先權(quán)查詢Q3給出在指定的日期之前尚未運(yùn)送的訂單中具有最大收入的訂單的優(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ò)開銷.另外，將幾個(gè)大數(shù)據(jù)量的結(jié)果集進(jìn)行連接的效率也是很低的.經(jīng)過分析，可以對(duì)orders、lineitem和customer合并后的表orders＿li＿cu直接做單表查詢.

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

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

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

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

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

由于在新模式中，表orders＿li＿cu已經(jīng)包含了原模式orders，lineitem和customer中所有的字段，因此Q3就再不需要進(jìn)行join連接，而只需從oreders＿li＿cu中獲取數(shù)據(jù).因?yàn)閘＿orderkey＝o＿orderkey且c＿custkey＝o＿custkey，所以在擴(kuò)展表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è)計(jì)后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）并進(jìn)行數(shù)據(jù)加載.由于只測(cè)試Q1和Q3兩個(gè)案例，因此只需加載orders、customer和lineitem三張表，其記錄數(shù)分別為150 000、150 000和6 001 215.

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

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

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

4 總 結(jié)

本文介紹了范式設(shè)計(jì)和反范式設(shè)計(jì)的區(qū)別和應(yīng)用場(chǎng)景，以及一些典型的反范式模式設(shè)計(jì)方法，然后通過重新設(shè)計(jì)TPC－H基準(zhǔn)測(cè)試案例中的Q1和Q3相關(guān)數(shù)據(jù)庫模式，在分布式數(shù)據(jù)庫OceanBase中對(duì)查詢效率的提升進(jìn)行了實(shí)驗(yàn)驗(yàn)證.結(jié)果表明，新的數(shù)據(jù)庫模式可以有效提升OLAP業(yè)務(wù)的查詢效率.雖然增加了數(shù)據(jù)冗余，但是考慮分布式環(huán)境下的存儲(chǔ)容量不再是瓶頸，數(shù)據(jù)冗余可以不作為考慮因素.在進(jì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］.楊冬青，馬秀莉，譯.北京：機(jī)械工業(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ī)模分布式存儲(chǔ)系統(tǒng)：原理解析與架構(gòu)實(shí)戰(zhàn)［M］.北京：機(jī)械工業(yè)出版社，2013.

［8］ STEPHENS R K，PLEW R R.數(shù)據(jù)庫系統(tǒng)概論［M］.何玉潔，譯.北京：機(jī)械工業(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.