陽振坤

（阿里巴巴集團，北京100020）

0 引 言

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

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

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

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

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

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

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

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

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

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

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

2 OceanBase架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖1 數(shù)據(jù)庫單日修改數(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ù)庫一天的增刪改數(shù)據(jù)量相對于數(shù)據(jù)庫的記錄數(shù)比例較小，因此OceanBase以增量方式把當(dāng)天增刪改的數(shù)據(jù)保存在服務(wù)器內(nèi)存中（Redo log保存在磁盤），稱為MemTable；對應(yīng)的基線數(shù)據(jù)（即數(shù)據(jù)庫在MemTable開始時刻的快照）則分割后保存在磁盤（通常是固態(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通常保存在多臺服務(wù)器（稱為ChunkServer）的磁盤，以數(shù)據(jù)頁（page，例如8KB）方式存儲和訪問．圖3所示是單機群OceanBase的架構(gòu)圖．

圖3 OceanBase架構(gòu)（單機群）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的總控中心，負責(zé)ChunkServer／MergeServer的上線、下線管理以及Sstable的負載均衡．

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

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

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

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

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

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

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

2．4 讀事務(wù)

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

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

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

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

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

2．5 寫事務(wù)

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

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

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

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

3 OceanBase的特點分析

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

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

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

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

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

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

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

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

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

4 結(jié) 論

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

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

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

［3］OceanBase開源［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．