陽(yáng)振坤

（阿里巴巴集團(tuán)，北京100020）

0 引 言

在過(guò)去半個(gè)世紀(jì)左右的時(shí)間里，數(shù)據(jù)庫(kù)系統(tǒng)從無(wú)到有，經(jīng)歷了層次數(shù)據(jù)庫(kù)、網(wǎng)狀數(shù)據(jù)庫(kù)和關(guān)系數(shù)據(jù)庫(kù)等幾個(gè)發(fā)展階段．時(shí)至今日，主要數(shù)據(jù)庫(kù)系統(tǒng)基本都是關(guān)系數(shù)據(jù)庫(kù)，并廣泛應(yīng)用于銀行、信用卡交易、商品銷售、航空與鐵路運(yùn)輸、電信、電力系統(tǒng)、教育、醫(yī)療與健康、電子商務(wù)等領(lǐng)域，成為了信息社會(huì)最關(guān)鍵的基礎(chǔ)設(shè)施之一．關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)也成為了最穩(wěn)定可靠、最核心的系統(tǒng)之一．

然而，在互聯(lián)網(wǎng)高速發(fā)展的今天，眾多知名的互聯(lián)網(wǎng)公司，例如Google、Facebook、Amazon、騰訊、阿里巴巴、百度、雅虎等，并沒(méi)有在他們的業(yè)務(wù)系統(tǒng)中采用商業(yè)關(guān)系數(shù)據(jù)庫(kù)（eBay旗下的PayPal除外）．難道互聯(lián)網(wǎng)公司不需要關(guān)系數(shù)據(jù)庫(kù)嗎？恰好相反，互聯(lián)網(wǎng)公司不僅需要關(guān)系數(shù)據(jù)庫(kù)，而且對(duì)關(guān)系數(shù)據(jù)庫(kù)的伸縮性、高性能、高可用和低成本有更高的要求，傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)難以滿足這些需求．

阿里巴巴的淘寶和天貓是網(wǎng)上購(gòu)物平臺(tái)，在2013年11月11日（雙11）創(chuàng)造了單日350．19億元人民幣的交易額［1］，同一天支付寶則完成了1．88億筆支付，高峰時(shí)達(dá)到79萬(wàn)筆／min［2］，都對(duì)傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)提出了很強(qiáng)的挑戰(zhàn)．過(guò)去4年時(shí)間里，阿里巴巴OceanBase團(tuán)隊(duì)研制了OceanBase［3］開(kāi)源 分布式無(wú)共享關(guān)系數(shù)據(jù)庫(kù)，以“OceanBase數(shù)據(jù)庫(kù)＋主流PC服務(wù)器”取代“商業(yè)數(shù)據(jù)庫(kù)＋高端服務(wù)器＋高端存儲(chǔ)”，廣泛應(yīng)用于淘寶、天貓和支付寶線上業(yè)務(wù)，極大地降低了軟件和設(shè)備成本，良好的伸縮性和自動(dòng)的故障恢復(fù)不僅很好地支撐了業(yè)務(wù)，而且大大地降低了運(yùn)行維護(hù)的人力成本．

本文的結(jié)構(gòu)如下：第1節(jié)介紹了互聯(lián)網(wǎng)應(yīng)用的特點(diǎn)，分析了互聯(lián)網(wǎng)新型應(yīng)用對(duì)傳統(tǒng)數(shù)據(jù)庫(kù)提出的挑戰(zhàn)；第2節(jié)給出了Oceanbase數(shù)據(jù)庫(kù)的系統(tǒng)架構(gòu)、數(shù)據(jù)庫(kù)事務(wù)等核心技術(shù)；第3節(jié)介紹了相關(guān)工作，對(duì)比分析了Oceanbase數(shù)據(jù)庫(kù)的特點(diǎn)；第4節(jié)對(duì)全文進(jìn)行了總結(jié)．

1 互聯(lián)網(wǎng)時(shí)代的關(guān)系數(shù)據(jù)庫(kù)

互聯(lián)網(wǎng)公司的業(yè)務(wù)不僅涉及大量非結(jié)構(gòu)化的數(shù)據(jù)，例如網(wǎng)站訪問(wèn)日志等，也有很多涉及結(jié)構(gòu)化數(shù)據(jù)的業(yè)務(wù)，例如Google的搜索廣告、淘寶／天貓的商品搜索廣告的計(jì)費(fèi)，淘寶／天貓、Amazon和eBay等的網(wǎng)上和移動(dòng)購(gòu)物，支付寶的網(wǎng)上和移動(dòng)支付等等，都是商務(wù)交易和金融交易，因此數(shù)據(jù)庫(kù)的事務(wù)（Transaction）功能不可或缺．事務(wù)需要滿足ACID原則：原子性（Atomicy）、一致性（Consistency）、隔離性（Isolation）和持久性（Durability）．然而，絕大多數(shù)大型互聯(lián)網(wǎng)公司（PayPal除外）都沒(méi)有在業(yè)務(wù)上使用商業(yè)數(shù)據(jù)庫(kù)，因?yàn)榛ヂ?lián)網(wǎng)的應(yīng)用場(chǎng)景跟傳統(tǒng)業(yè)務(wù)的應(yīng)用場(chǎng)景有了很大的不同．這些不同主要體現(xiàn)在以下四個(gè)方面．

（1）互聯(lián)網(wǎng)應(yīng)用需要數(shù)據(jù)庫(kù)的并發(fā)處理能力是傳統(tǒng)應(yīng)用的幾十倍甚至幾百倍．傳統(tǒng)應(yīng)用領(lǐng)域的數(shù)據(jù)庫(kù)系統(tǒng)，通常只有少數(shù)人和設(shè)備并發(fā)操作數(shù)據(jù)庫(kù)，例如銀行的職員及ATM機(jī)、商場(chǎng)的收銀員、飛機(jī)票火車票的售票員等，后臺(tái)的數(shù)據(jù)庫(kù)系統(tǒng)常常只有幾百和幾千的并發(fā)訪問(wèn)，幾萬(wàn)的并發(fā)訪問(wèn)量很少見(jiàn)，幾十萬(wàn)以上的并發(fā)幾乎見(jiàn)不到．在草根文化大行其道的互聯(lián)網(wǎng)，比如網(wǎng)上購(gòu)物和網(wǎng)上購(gòu)票等，可能每個(gè)網(wǎng)民都是收銀員或售貨／售票員，對(duì)于后臺(tái)數(shù)據(jù)庫(kù)，幾萬(wàn)和幾十萬(wàn)的并發(fā)隨時(shí)可見(jiàn)，特殊情況下，比如促銷期間和春節(jié)期間，幾百萬(wàn)的并發(fā)都很常見(jiàn)，2013年阿里巴巴天貓雙11大促（11月11日），同時(shí)在線人數(shù)達(dá)到1700萬(wàn)，是整個(gè)香港人口的2．5倍［4］．

（2）互聯(lián)網(wǎng)應(yīng)用需要的數(shù)據(jù)庫(kù)伸縮性也大大超越了傳統(tǒng)應(yīng)用．傳統(tǒng)業(yè)務(wù)的增長(zhǎng)，通常都比較平穩(wěn)，商場(chǎng)、銀行網(wǎng)點(diǎn)、售票點(diǎn)的新建／擴(kuò)建等，通常需要幾個(gè)月甚至幾年的周期；而互聯(lián)網(wǎng)的促銷，可能在一天之內(nèi)增加／減少幾倍、幾十倍的訪問(wèn)量，例如2013年雙11大促一天成交金額350．19億元人民幣，大約是全年日平均交易額的8．5倍［5］．再比如，“憤怒的小鳥(niǎo)”游戲在2012年圣誕節(jié)一天下載量超過(guò)800萬(wàn)［6］．這都要求數(shù)據(jù)庫(kù)有幾倍、幾十倍的伸縮能力，并且這種伸縮常常要在若干天甚至若干小時(shí)之內(nèi)完成．

（3）互聯(lián)網(wǎng)應(yīng)用對(duì)數(shù)據(jù)庫(kù)的性能價(jià)格比的要求也十分“苛刻”．在傳統(tǒng)應(yīng)用領(lǐng)域，數(shù)據(jù)庫(kù)系統(tǒng)處在最核心的位置，必須有極高的穩(wěn)定性和可靠性，為達(dá)到這一目的可能“不計(jì)成本”（例如采用高度穩(wěn)定可靠的服務(wù)器和存儲(chǔ)設(shè)備，使用成熟的商業(yè)數(shù)據(jù)庫(kù)軟件等），成本高昂．互聯(lián)網(wǎng)應(yīng)用需要的數(shù)據(jù)庫(kù)并發(fā)能力常常是傳統(tǒng)應(yīng)用的幾十倍、幾百倍，如果性價(jià)比保持不變，則互聯(lián)網(wǎng)公司需要傳統(tǒng)應(yīng)用幾十倍、幾百倍的數(shù)據(jù)庫(kù)成本．

（4）互聯(lián)網(wǎng)應(yīng)用在數(shù)據(jù)庫(kù)可用性上面臨的挑戰(zhàn)也跟傳統(tǒng)應(yīng)用有很大的不同．不僅因?yàn)榛ヂ?lián)網(wǎng)應(yīng)用的訪問(wèn)量大、數(shù)據(jù)庫(kù)故障影響的人群數(shù)量更大，而且由于控制成本的原因，互聯(lián)網(wǎng)公司的數(shù)據(jù)庫(kù)使用廉價(jià)的主流PC服務(wù)器，其故障率也明顯高于高端服務(wù)器和高可靠存儲(chǔ)，因此面臨的可用性挑戰(zhàn)更大．

為了解決上述問(wèn)題，針對(duì)互聯(lián)網(wǎng)應(yīng)用的高并發(fā)、強(qiáng)伸縮性、低成本、高可用等方面的挑戰(zhàn)，設(shè)計(jì)實(shí)現(xiàn)了針對(duì)新型互聯(lián)網(wǎng)應(yīng)用的Oceanbase關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)．

2 OceanBase架構(gòu)

2．1 系統(tǒng)需求及目標(biāo)

在設(shè)計(jì)和開(kāi)發(fā)的過(guò)程中，OceanBase定位于通用的數(shù)據(jù)庫(kù)，并且需要滿足互聯(lián)網(wǎng)應(yīng)用對(duì)數(shù)據(jù)庫(kù)的伸縮性、高性能、高可用和低成本的要求．

基于這一總體需求，OceanBase的設(shè)計(jì)目標(biāo)如下．

（1）事務(wù)的ACID原則．事務(wù)是關(guān)系數(shù)據(jù)庫(kù)的核心技術(shù)．事務(wù)的ACID原則是保障淘寶和天貓等商業(yè)交易業(yè)務(wù)和支付寶等金融交易業(yè)務(wù)的關(guān)鍵，因此OceanBase把事務(wù)作為首要的、不可妥協(xié)的目標(biāo)．此外，為了降低業(yè)務(wù)的學(xué)習(xí)以及遷移成本，OceanBase并沒(méi)有定義自己的客戶端，而是使用了MySQL客戶端．

（2）低成本．低成本是OceanBase的重要目標(biāo)．OceanBase使用廉價(jià)PC服務(wù)器及其磁盤（主要是固態(tài)盤）代替了傳統(tǒng)數(shù)據(jù)庫(kù)使用的高端服務(wù)器和高端存儲(chǔ)．

（3）高性能．讀寫事務(wù)性能都是數(shù)據(jù)庫(kù)的主要指標(biāo)．OceanBase需要為業(yè)務(wù)提供很高的讀寫事務(wù)性能．與讀事務(wù)可通過(guò)緩存（cache）提升性能相比，寫事務(wù)性能的提升更加挑戰(zhàn)，因此OceanBase在設(shè)計(jì)實(shí)現(xiàn)上偏重于寫事務(wù)的性能，并消除了磁盤的隨機(jī)寫，以充分利用固態(tài)盤良好的隨機(jī)讀性能．

（4）在線伸縮．在線的、按“天”甚至按“小時(shí)”級(jí)別的伸縮是互聯(lián)網(wǎng)業(yè)務(wù)的關(guān)鍵需求．OceanBase采用了分布式架構(gòu)，可隨時(shí)增加／減少服務(wù)器，并自動(dòng)進(jìn)行數(shù)據(jù)遷移和負(fù)載均衡．

（5）在線故障恢復(fù)．傳統(tǒng)數(shù)據(jù)庫(kù)使用了高端服務(wù)器和高端存儲(chǔ)，這些設(shè)備有相當(dāng)高的可靠性，設(shè)備故障被認(rèn)為是罕見(jiàn)的．OceanBase使用了廉價(jià)PC服務(wù)器及其磁盤，硬件（特別是磁盤，包括固態(tài)盤）故障經(jīng)常發(fā)生，因此OceanBase需要能夠隨時(shí)進(jìn)行自動(dòng)、快速的故障恢復(fù)，以免設(shè)備故障影響業(yè)務(wù)．

2．2 系統(tǒng)假設(shè)

與數(shù)據(jù)庫(kù)的高性能、高并發(fā)相伴的常常是龐大數(shù)據(jù)量．調(diào)研和分析發(fā)現(xiàn)，許多數(shù)據(jù)庫(kù)中的數(shù)據(jù)量雖然很大，但一段時(shí)間（例如一天）內(nèi)增刪改的數(shù)據(jù)總量通常不大，每條記錄的修改往往在幾十到幾百字節(jié)（通常明顯低于單條記錄的尺寸）．例如在以下三個(gè)示例數(shù)據(jù)庫(kù)中，一段時(shí)間內(nèi)的數(shù)據(jù)增刪改影響的記錄數(shù)占整個(gè)數(shù)據(jù)庫(kù)記錄數(shù)的比例都很?。?/p>

（1）人口數(shù)據(jù)庫(kù)．人口數(shù)據(jù)庫(kù)保存了每個(gè)人的姓名、身份證號(hào)、戶口、婚姻、住址等信息，假如每人一條記錄，全國(guó)就有14億條記錄．但每天修改的記錄并不多，例如人口出生（每天幾萬(wàn)人）、死亡（每天幾萬(wàn)人）、修改姓名、戶口遷入遷出等，這些增刪改記錄數(shù)跟總記錄數(shù)相比，只占一個(gè)很小的比例．

（2）交易數(shù)據(jù)庫(kù)．每個(gè)交易對(duì)應(yīng)一條（或幾條）記錄，線上數(shù)據(jù)庫(kù)通常保存一年或更長(zhǎng)時(shí)間的交易記錄，但每天新增的記錄并不多（相當(dāng)于1年的1／365），每天修改的記錄（例如支付寶的一筆交易由“買家已付款”修改為“賣家已發(fā)貨”等），也只占幾類總數(shù)的一個(gè)很小的比例．

（3）賬務(wù)數(shù)據(jù)庫(kù)．賬務(wù)記錄了每個(gè)用戶的一個(gè)或多個(gè)賬戶信息．當(dāng)新建賬戶、注銷賬戶、發(fā)生付款或收款時(shí)，需要修改對(duì)應(yīng)的信息，盡管賬務(wù)數(shù)據(jù)庫(kù)可能有幾千萬(wàn)條甚至幾億條記錄，但每天修改的記錄數(shù)，同樣只占一個(gè)很小的比例．

設(shè)想一個(gè)系統(tǒng)一天有10億筆寫事務(wù)，每筆信息為100－Byte，那么一天的信息量即為10億×100＝100 GB，這已經(jīng)是當(dāng)前單個(gè)PC服務(wù)器內(nèi)存可以達(dá)到的容量．因此盡管數(shù)據(jù)庫(kù)記錄總數(shù)可能很大，但一天內(nèi)的增刪改記錄數(shù)，只占很小的比例，如圖1所示．

圖1 數(shù)據(jù)庫(kù)單日修改數(shù)據(jù)比例示意圖Fig．1 Schematic diagram of daily mutated data portion in a database

2．3 系統(tǒng)架構(gòu)

基于第2．2節(jié)的分析，由于大多數(shù)數(shù)據(jù)庫(kù)一天的增刪改數(shù)據(jù)量相對(duì)于數(shù)據(jù)庫(kù)的記錄數(shù)比例較小，因此OceanBase以增量方式把當(dāng)天增刪改的數(shù)據(jù)保存在服務(wù)器內(nèi)存中（Redo log保存在磁盤），稱為MemTable；對(duì)應(yīng)的基線數(shù)據(jù)（即數(shù)據(jù)庫(kù)在MemTable開(kāi)始時(shí)刻的快照）則分割后保存在磁盤（通常是固態(tài)盤）上，稱為Sstable，如圖2所示．

圖2 OceanBase數(shù)據(jù)模型Fig．2 Data model of OceanBase

由于增刪改數(shù)據(jù)MemTable通常較少，所以MemTable通常保存在服務(wù)器（稱為UpdateServer）的內(nèi)存，以增量方式保存，多次修改之間以指針連接；基線數(shù)據(jù)Sstable通常保存在多臺(tái)服務(wù)器（稱為ChunkServer）的磁盤，以數(shù)據(jù)頁(yè)（page，例如8KB）方式存儲(chǔ)和訪問(wèn)．圖3所示是單機(jī)群OceanBase的架構(gòu)圖．

圖3 OceanBase架構(gòu)（單機(jī)群）Fig．3 OceanBase architecture（single cluster）

OceanBase系統(tǒng)架構(gòu)中，包括四類服務(wù)器：主控服務(wù)器RootServer、基線數(shù)據(jù)服務(wù)器ChunkServer、合并服務(wù)器MergeServer，以及更新服務(wù)器UpdateServer．

（1）主控服務(wù)器RootServer．該服務(wù)器是OceanBase的總控中心，負(fù)責(zé)ChunkServer／MergeServer的上線、下線管理以及Sstable的負(fù)載均衡．

（2）基線數(shù)據(jù)服務(wù)器ChunkServer．ChunkServer保存基線數(shù)據(jù)Sstable并提供讀訪問(wèn)．為了防止由于ChunkServer故障導(dǎo)致服務(wù)不可用甚至數(shù)據(jù)丟失，每個(gè)Sstable保存了多個(gè)副本并分布在不同的ChunkServer上．

（3）合并服務(wù)器MergeServer．OceanBase的應(yīng)用接口，支持JDBC／ODBC協(xié)議，接收并解析用戶的SQL請(qǐng)求，經(jīng)過(guò)詞法分析、語(yǔ)法分析、生成執(zhí)行計(jì)劃等一系列操作后，發(fā)送到相應(yīng)的ChunkServer．

（4）更新服務(wù)器UpdateServer．執(zhí)行寫事務(wù)、保存修改增量（到內(nèi)存）、寫Redo log（到磁盤）并提供讀服務(wù)．UpdateServer通常也有多個(gè)副本．

由于UpdateServer內(nèi)存是有限的，修改后的增量無(wú)法一直保存在內(nèi)存中，因此Ocean－Base通常每天在某個(gè)時(shí)刻（例如后半夜業(yè)務(wù)低谷期）凍結(jié)當(dāng)前MemTable并開(kāi)啟新的MemTable；此后新的增刪改寫入新的MemTable，然后系統(tǒng)在后臺(tái)把凍結(jié)的MemTable與當(dāng)前基線數(shù)據(jù)融合，生成新的基線數(shù)據(jù)，這個(gè)過(guò)程稱為每日合并．每日合并完成后，凍結(jié)的MemTable以及舊的Sstable即可釋放，其占用的內(nèi)存和磁盤空間也被回收．

為了防止UpdateServer故障或者機(jī)房故障導(dǎo)致服務(wù)不可用甚至數(shù)據(jù)丟失，OceanBase通常部署多個(gè)機(jī)群（例如一主兩備），主機(jī)群執(zhí)行寫事務(wù)并且至少同步到一個(gè)或多個(gè)備用機(jī)群（超過(guò)半數(shù)［7］）．這樣任何一個(gè)機(jī)群異常都不會(huì)導(dǎo)致服務(wù)不可用，從而保證了數(shù)據(jù)庫(kù)的高可用性．其架構(gòu)如圖4所示．

傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)通常采用主備庫(kù)鏡像，主庫(kù)備庫(kù)之間的網(wǎng)絡(luò)異常以及備庫(kù)異常都可能導(dǎo)致主庫(kù)備庫(kù)不同步；OceanBase的多機(jī)群（≥3）方式使得不僅單個(gè)備機(jī)群異常不會(huì)影響業(yè)務(wù)，而且使得，即使主機(jī)群突然故障，數(shù)據(jù)庫(kù)系統(tǒng)也會(huì)在最多若干秒后自動(dòng)恢復(fù)服務(wù)，不會(huì)造成任何數(shù)據(jù)丟失．

圖4 OceanBase架構(gòu)（三機(jī)群）Fig．4 OceanBase architecture（triple clusters）

2．4 讀事務(wù)

對(duì)于用戶的讀取任務(wù)，MergeServer接受SQL請(qǐng)求并解析生成SQL執(zhí)行計(jì)劃．MergeServer確定事務(wù)中數(shù)據(jù)的基線數(shù)據(jù)在哪些ChunkServer上，然后通知這些ChunkServer執(zhí)行對(duì)應(yīng)的讀請(qǐng)求．由于基線數(shù)據(jù)與修改增量的分離，如圖2所示，讀事務(wù)需要融合基線數(shù)據(jù)和修改的更新數(shù)據(jù)，返回滿足查詢條件的數(shù)據(jù)．

一個(gè)特殊的情況是在每日合并期間，讓所有ChunkServer同步完成每日合并或者同步啟用新的Sstable可能非常復(fù)雜甚至無(wú)法完成（比如某個(gè)ChunkServer網(wǎng)絡(luò)異常），因此某些ChunkServer的部分Sstable完成了與凍結(jié)的MemTable的融合，生成了新的Sstable，其他Sstable尚未完成融合，有些查詢可能用到舊的Sstable，有些查詢可能用到新的Sstable，還有的查詢可能同時(shí)用到舊的Sstable和新的Sstable．相同內(nèi)容的SQL語(yǔ)句，到達(dá)的MergeServer不同或到達(dá)時(shí)間不同，使用新舊Sstable的情況可能有所不同，那么查詢的結(jié)果是否一致呢？答案是肯定的．因?yàn)椴樵兪褂门f基線數(shù)據(jù)時(shí)，會(huì)融合舊增量數(shù)據(jù)（即凍結(jié)的MemTable）和新增量數(shù)據(jù)（即新的MemTable），查詢使用新基線數(shù)據(jù)時(shí)，則只融合新增量數(shù)據(jù)（新的MemTable），因此得到的結(jié)果是一致的，如圖5所示．

圖5 OceanBase每日合并期間的查詢Fig．5 OceanBase query during daily merging

盡管使用了與傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)相似的方式存儲(chǔ)，Sstable的隨機(jī)讀并沒(méi)有成為Ocean－Base的瓶頸，這得益于OceanBase通常采用固態(tài)盤作為存儲(chǔ)并且沒(méi)有隨機(jī)磁盤寫，一個(gè)沒(méi)有隨機(jī)磁盤寫的固態(tài)盤可以提供每秒幾萬(wàn)次的隨機(jī)讀（一個(gè)機(jī)械盤每秒只能提供幾百次的隨機(jī)讀）．

傳統(tǒng)的基于磁盤的關(guān)系數(shù)據(jù)庫(kù)，其讀事務(wù)操作的基本步驟是先從磁盤中讀出數(shù)據(jù)頁(yè)（page），再?gòu)闹腥〕鲂枰膬?nèi)容，然后根據(jù)用戶的SQL進(jìn)行操作得到結(jié)果．OceanBase的讀事務(wù)操作與它們類似，不同的是OceanBase從讀出的數(shù)據(jù)頁(yè)中取出需要的內(nèi)容時(shí)，還得與對(duì)應(yīng)的修改增量融合．由于被修改數(shù)據(jù)所占的比例比較小、修改增量以及融合操作都在內(nèi)存中，這個(gè)操作對(duì)性能的損耗很?。c此同時(shí)，由于使用固態(tài)盤并且沒(méi)有隨機(jī)寫，OceanBase能夠充分利用固態(tài)盤優(yōu)異的隨機(jī)讀性能，因此能夠獲得很好的讀性能．

2．5 寫事務(wù)

MergeServer解析SQL請(qǐng)求生成SQL執(zhí)行計(jì)劃后，如果不是只讀事務(wù)，則向ChunkServer獲取對(duì)應(yīng)的基線數(shù)據(jù)，然后連同執(zhí)行計(jì)劃提交給主機(jī)群UpdateServer執(zhí)行．主機(jī)群UpdateServer執(zhí)行寫事務(wù)，生成Redo log，同步給備機(jī)群并持久化到各自磁盤，如果成功者（包括自己）超過(guò)了半數(shù)，則在MemTable中提交該事務(wù)并應(yīng)答客戶．

盡管有大量的隨機(jī)訪問(wèn)，由于增刪改的修改增量放置在內(nèi)存，Redo log是順序?qū)?，所以O(shè)ceanBase系統(tǒng)中沒(méi)有隨機(jī)寫磁盤．不僅如此，OceanBase的UpdateServer服務(wù)器通常配置帶電池或電容的RAID卡，這種RAID帶有內(nèi)存（例如1GB）并且在服務(wù)器斷電時(shí)能夠保持其中的數(shù)據(jù)不丟失，當(dāng)小塊的Redo log寫入磁盤時(shí)，其實(shí)只是寫到了RAID卡的內(nèi)存中，該RAID卡稍后批量把其內(nèi)存中數(shù)據(jù)寫到磁盤上，這樣不僅縮短了日志刷盤的時(shí)間（大約0．1 ms），而且降低了小塊Redo log的寫入對(duì)固態(tài)盤的性能和壽命的影響（因?yàn)楣虘B(tài)盤的寫入也是以頁(yè)（page）為單位的，例如4KB，并且寫入前需要先擦除，在已有頁(yè)上即使追加一個(gè)字節(jié)也需要把原有頁(yè)讀出來(lái)，與追加字節(jié)合并，然后寫入一個(gè)新的頁(yè)）．每日合并期間把修改增量與舊基線數(shù)據(jù)合并生成新基線數(shù)據(jù)時(shí)，對(duì)磁盤的訪問(wèn)是順序讀和順序?qū)?，?dāng)施加一定的流量控制后，這種順序讀和順序?qū)憣?duì)磁盤的隨機(jī)讀的影響也是可控的．

傳統(tǒng)的基于磁盤的關(guān)系數(shù)據(jù)庫(kù)，其寫事務(wù)操作的基本步驟是從磁盤中讀出數(shù)據(jù)頁(yè)（page），再?gòu)闹腥〕鲂枰膬?nèi)容，然后根據(jù)用戶的SQL進(jìn)行修改，再把修改后的結(jié)果與原數(shù)據(jù)頁(yè)融合生成新的數(shù)據(jù)頁(yè)，寫日志（Redo log、Undo log）并把新的數(shù)據(jù)頁(yè)刷到磁盤，由于每次修改通常在幾十到幾百字節(jié)，而數(shù)據(jù)頁(yè)的大小通常在幾KB（例如8KB），這就出現(xiàn)了明顯的寫放大（8KB／100≈80X）．OceanBase的寫事務(wù)操作也是先從磁盤中讀出數(shù)據(jù)頁(yè)，再?gòu)闹腥〕鲂枰膬?nèi)容，然后根據(jù)用戶的SQL進(jìn)行修改操作以生成增刪改的增量，寫日志（Redo log）并且把修改增量加入到MemTable．

由于內(nèi)存中修改增量沒(méi)有也不需要做成數(shù)據(jù)頁(yè)，因此OceanBase不僅省去了寫新的數(shù)據(jù)頁(yè)到磁盤的操作（隨機(jī)寫磁盤），也避免了傳統(tǒng)數(shù)據(jù)庫(kù)的寫入放大（每日合并通常在系統(tǒng)低谷期間進(jìn)行，對(duì)業(yè)務(wù)影響很小，更不會(huì)影響高峰期的業(yè)務(wù)）．這使得OceanBase在寫事務(wù)性能上有明顯的優(yōu)勢(shì)．

3 OceanBase的特點(diǎn)分析

目前，國(guó)內(nèi)外的學(xué)術(shù)界和工業(yè)界在支撐互聯(lián)網(wǎng)應(yīng)用的數(shù)據(jù)庫(kù)產(chǎn)品方面做了大量努力．Google的Bigtable［8］是一個(gè)基于Google File System［9］的分布式表格系統(tǒng)，只支持單行事務(wù)．Google的Spanner［10］實(shí)現(xiàn)了跨越全球的分布式事務(wù)，但復(fù)雜SQL性能較低，且對(duì)時(shí)鐘有很強(qiáng)的依賴．OceanBase系統(tǒng)是在保證“強(qiáng)一致性”的前提下，追求系統(tǒng)的“最大可用性”，實(shí)現(xiàn)面向互聯(lián)網(wǎng)業(yè)務(wù)需求的強(qiáng)伸縮性、高性能、高可用和低成本的通用數(shù)據(jù)庫(kù)．

根據(jù)數(shù)據(jù)存儲(chǔ)方式的不同，我們可以把目前的數(shù)據(jù)庫(kù)分為三類：外存型數(shù)據(jù)庫(kù)、全內(nèi)存數(shù)據(jù)庫(kù)以及內(nèi)外存混合型數(shù)據(jù)庫(kù)．

（1）外存型數(shù)據(jù)庫(kù)．這種類型的數(shù)據(jù)庫(kù)的讀寫事務(wù)都基于外存（磁盤），內(nèi)存作為緩存（Cache），數(shù)據(jù)的存儲(chǔ)基于數(shù)據(jù)頁(yè)（page），讀和寫都有一定的放大效應(yīng)，寫入放大和磁盤隨機(jī)寫性能限制了數(shù)據(jù)庫(kù)的性能．多數(shù)傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)都屬于這個(gè)類型．

（2）全內(nèi)存數(shù)據(jù)庫(kù)．這種類型的數(shù)據(jù)庫(kù)數(shù)據(jù)全部在內(nèi)存中（log除外），沒(méi)有數(shù)據(jù)頁(yè)的概念，數(shù)據(jù)讀寫都在內(nèi)存中進(jìn)行（寫日志除外），性能很高．VoltDB（http：／／voltdb．com／）和MemSQL（http：／／www．memsql．com／）屬于這個(gè)類型，并且都號(hào)稱是全世界最快的內(nèi)存數(shù)據(jù)庫(kù)．

（3）內(nèi)外存混合型的數(shù)據(jù)庫(kù)．這種類型的數(shù)據(jù)庫(kù)部分?jǐn)?shù)據(jù)在外存（磁盤），部分?jǐn)?shù)據(jù)在內(nèi)存，在磁盤上的數(shù)據(jù)以數(shù)據(jù)頁(yè)為單位存儲(chǔ)，內(nèi)存中的數(shù)據(jù)不使用數(shù)據(jù)頁(yè)，內(nèi)存也不僅僅作為緩存．OceanBase屬于這個(gè)類型，其基線數(shù)據(jù)以數(shù)據(jù)頁(yè)方式保存在磁盤上，而增刪改的增量則在內(nèi)存中，性能介于磁盤型的數(shù)據(jù)庫(kù)與全內(nèi)存數(shù)據(jù)庫(kù)之間．

從存儲(chǔ)方式來(lái)看，OceanBase屬于內(nèi)外存混合型數(shù)據(jù)庫(kù)；與內(nèi)存數(shù)據(jù)庫(kù)相比，OceanBase在讀寫事務(wù)性能上的劣勢(shì)不大，但在經(jīng)濟(jì)性上優(yōu)勢(shì)十分明顯，具體在以下幾方面．

（1）讀事務(wù)性能．內(nèi)存數(shù)據(jù)庫(kù)完全避免了磁盤I／O（寫日志除外）并且也沒(méi)有數(shù)據(jù)頁(yè)導(dǎo)致的讀放大．然而，由于固態(tài)盤的隨機(jī)讀響應(yīng)時(shí)間（0．1 ms）僅為機(jī)械盤（3～5 ms）的幾十分之一，并且由于80／20法則，OceanBase可以用相對(duì)較小的內(nèi)存代價(jià)（比如全量數(shù)據(jù)的20%）緩存少部分比較熱的數(shù)據(jù)，再加上query cache，因此讀事務(wù)并不會(huì)成為OceanBase的性能瓶頸．

（2）寫事務(wù)性能．OceanBase的寫事務(wù)也是內(nèi)存操作，與全內(nèi)存數(shù)據(jù)庫(kù)類似，其中的讀操作，由于SSD優(yōu)異的隨機(jī)讀性能以及緩存（80／20法則），因此OceanBase與全內(nèi)存數(shù)據(jù)庫(kù)的寫性能的差距不大．

（3）經(jīng)濟(jì)性．80／20法則表明，一段時(shí)間（例如小時(shí)或者天）內(nèi)數(shù)據(jù)庫(kù)中的數(shù)據(jù)只有小部分會(huì)被頻繁訪問(wèn)，大部分?jǐn)?shù)據(jù)被很少訪問(wèn)或者根本沒(méi)有被訪問(wèn)．把這些很少或沒(méi)有被訪問(wèn)的數(shù)據(jù)與頻繁訪問(wèn)的數(shù)據(jù)同等對(duì)待并一樣占用昂貴的內(nèi)存資源，顯然是不經(jīng)濟(jì)的．由于固態(tài)盤容量大大高于內(nèi)存容量，同等尺寸的數(shù)據(jù)量，內(nèi)存數(shù)據(jù)庫(kù)需要的服務(wù)器數(shù)量也比內(nèi)外存混合型的OceanBase數(shù)據(jù)庫(kù)需要的服務(wù)器數(shù)量多得多．

4 結(jié) 論

針對(duì)互聯(lián)網(wǎng)應(yīng)用對(duì)關(guān)系數(shù)據(jù)庫(kù)的高可擴(kuò)展、高性能、高可用和低成本的需求，本文闡述了傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的不足，給出了OceanBase關(guān)系數(shù)據(jù)庫(kù)的架構(gòu)，對(duì)OceanBase的讀寫事務(wù)事務(wù)及其性能進(jìn)行了分析，并對(duì)比分析了OceanBase與傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)以及全內(nèi)存數(shù)據(jù)庫(kù)的優(yōu)劣．

［1］天貓微博［EB／OL］．http：／／weibo．com／1768198384／AiigJrzYT？mod＝weibotime．

［2］支付寶微博［EB／OL］．http：／／weibo．com／1627897870／AiiuiseVH？mod＝weibotime．

［3］OceanBase開(kāi)源［EB／OL］．http：／／alibaba．github．io／oceanbase／．

［4］天貓微博．http：／／weibo．com／1768198384／Aie2CyONt？mod＝weibotime＃＿rnd1404271771131．

［5］阿 里 巴 巴 招 股 書［EB／OL］．2014－06－17．http：／／www．sec．gov／Archives／edgar／data／1577552／000119312514236860／d709111df1a．htm．

［6］Angry Birds Racks Up 8Million Downloads in One Day［EB／OL］．http：／／www．forbes．com／sites／davidthier／2013／01／04／angry－birds－racks－up－8－million－downloads－in－one－day／．

［7］LAMPORT，L．The part－time parliament［J］．ACM TOCS，1998，16（2）：133－169．

［8］CHANG F，DEAN J，GHEMAWAT S，et al．Bigtable：A distributed storage system for structured data［J］．OSDI，2006：205－218．

［9］GHEMAWAT S，GOBIOFF H，LEUNG，et al．The Google file system［R］．ACM SOSP，2003：29－43．

［10］CORBETT J C，DEAN J，EPSTEIN M，et al．Spanner：Google’s globally－distributed database［C］．OSDI，2012：251－264．