OceanBase是阿里集團研發(fā)的可擴展的關(guān)系數(shù)據(jù)庫，實現(xiàn)了數(shù)千億條記錄、數(shù)百TB數(shù)據(jù)上的跨行跨表事務(wù)，截止到2012年8月，支持了收藏夾、直通車報表、天貓評價等OLTP和OLAP在線業(yè)務(wù)，線上數(shù)據(jù)量已經(jīng)超過一千億條。
從模塊劃分的角度看，OceanBase可以劃分為四個模塊：主控服務(wù)器RootServer、更新服務(wù)器UpdateServer、基線數(shù)據(jù)服務(wù)器ChunkServer以及合并服務(wù)器MergeServer。OceanBase系統(tǒng)內(nèi)部按照時間線將數(shù)據(jù)劃分為基線數(shù)據(jù)和增量數(shù)據(jù)，基線數(shù)據(jù)是只讀的，所有的修改更新到增量數(shù)據(jù)中，系統(tǒng)內(nèi)部通過合并操作定期將增量數(shù)據(jù)融合到基線數(shù)據(jù)中。
淘寶收藏夾是淘寶線上應(yīng)用之一，淘寶用戶在其中保存自己感興趣的寶貝（即商品，此外用戶也可以收藏感興趣的店鋪）以便下次快速訪問、對比和購買等，用戶可以展示和編輯（添加/刪除）自己的收藏。淘寶收藏夾數(shù)據(jù)庫包含了收藏info表（一條一條的收藏信息）和收藏item表（被收藏的寶貝和店鋪）等：
●收藏info表保存收藏信息條目，數(shù)百億條。
●收藏item表保存收藏的寶貝和店鋪的詳細信息，數(shù)十億條。
●熱門寶貝可能被多達數(shù)十萬買家收藏。
●每個用戶可以收藏千個寶貝。
●寶貝的價格、收藏人氣等信息隨時變化。
如果用戶選擇按寶貝價格排序后展示，那么數(shù)據(jù)庫需要從收藏item表中讀取收藏的寶貝的價格等最新信息，然后進行排序處理。如果用戶的收藏條目比較多（例如4000條），那么查詢對應(yīng)的item的時間會較長：假設(shè)如果平均每條item查詢時間是5ms，則4000條的查詢時間可能達到20s，如果真如此，則用戶體驗會很差。
如果把收藏的寶貝的詳細信息實時冗余到收藏info表，則上述查詢收藏item表的操作就不再需要了。但是，由于許多熱門商品可能有幾千到幾十萬人收藏，這些熱門商品的價格等信息的變動可能導(dǎo)致收藏info表的大量修改，并壓垮數(shù)據(jù)庫。
OceanBase的目標(biāo)是支持數(shù)百TB的數(shù)據(jù)量以及數(shù)十萬TPS、數(shù)百萬QPS的訪問量，無論是數(shù)據(jù)量還是訪問量，即使采用非常昂貴的小型機甚至是大型機，單臺關(guān)系數(shù)據(jù)庫系統(tǒng)都無法承受。
一種常見的做法是根據(jù)業(yè)務(wù)特點對數(shù)據(jù)庫進行水平拆分，通常的做法是根據(jù)某個業(yè)務(wù)字段（通常取用戶編號，user_id）哈希后取模，根據(jù)取模的結(jié)果將數(shù)據(jù)分布到不同的數(shù)據(jù)庫服務(wù)器上，客戶端請求通過數(shù)據(jù)庫中間層路由到不同的分區(qū)。這種方式目前還存在一定的弊端，如下所示：
●數(shù)據(jù)和負載增加后添加機器的操作比較復(fù)雜，往往需要人工介入；
●有些范圍查詢需要訪問幾乎所有的分區(qū)，例如，按照user_id分區(qū)，查詢收藏了一個商品的所有用戶需要訪問所有的分區(qū)；
●目前廣泛使用的關(guān)系數(shù)據(jù)庫存儲引擎都是針對機械硬盤的特點設(shè)計的，不能夠完全發(fā)揮新硬件（SSD）的能力。
另外一種做法是參考分布式表格系統(tǒng)的做法，例如Google Bigtable系統(tǒng)，將大表劃分為幾萬、幾十萬甚至幾百萬個子表，子表之間按照主鍵有序，如果某臺服務(wù)器發(fā)生故障，它上面服務(wù)的數(shù)據(jù)能夠在很短的時間內(nèi)自動遷移到集群中所有的其他服務(wù)器。這種方式解決了可擴展性的問題，少量突發(fā)的服務(wù)器故障或者增加服務(wù)器對使用者基本是透明的，能夠輕松應(yīng)對促銷或者熱點事件等突發(fā)流量增長。另外，由于子表是按照主鍵有序分布的，很好地解決了范圍查詢的問題。
萬事有其利必有一弊，分布式表格系統(tǒng)雖然解決了可擴展性問題，但往往無法支持事務(wù)，例如Bigtable只支持單行事務(wù)，針對同一個user_id下的多條記錄的操作都無法保證原子性。而OceanBase希望能夠支持跨行跨表事務(wù)，這樣使用起來會比較方便。
最直接的做法是在Bigtable開源實現(xiàn)（如HBase或者Hypertable）的基礎(chǔ)上引入兩階段提交（Two-phase Commit）協(xié)議支持分布式事務(wù)，這種思路在Google的Percolator系統(tǒng)中得到了體現(xiàn)。然而，Percolator系統(tǒng)中事務(wù)的平均響應(yīng)時間達到2～5秒，只能應(yīng)用在類似網(wǎng)頁建庫這樣的半線上業(yè)務(wù)中。另外，Bigtable的開源實現(xiàn)也不夠成熟，單臺服務(wù)器能夠支持的數(shù)據(jù)量有限，單個請求的最大響應(yīng)時間很難得到保證，機器故障等異常處理機制也有很多比較嚴(yán)重的問題。總體上看，這種做法的工作量和難度超出了項目組的承受能力，因此，我們需要根據(jù)業(yè)務(wù)特點做一些定制。
通過分析，我們發(fā)現(xiàn)，雖然在線業(yè)務(wù)的數(shù)據(jù)量十分龐大，例如幾十億條、上百億條甚至更多記錄，但最近一段時間（例如一天）的修改量往往并不多，通常不超過幾千萬條到幾億條，因此，OceanBase決定采用單臺更新服務(wù)器來記錄最近一段時間的修改增量，而以前的數(shù)據(jù)保持不變，以前的數(shù)據(jù)稱為基線數(shù)據(jù)?；€數(shù)據(jù)以類似分布式文件系統(tǒng)的方式存儲于多臺基線數(shù)據(jù)服務(wù)器中，每次查詢都需要把基線數(shù)據(jù)和增量數(shù)據(jù)融合后返回給客戶端。這樣，寫事務(wù)都集中在單臺更新服務(wù)器上，避免了復(fù)雜的分布式事務(wù)，高效地實現(xiàn)了跨行跨表事務(wù)；另外，更新服務(wù)器上的修改增量能夠定期分發(fā)到多臺基線數(shù)據(jù)服務(wù)器中，避免成為瓶頸，實現(xiàn)了良好的擴展性。
當(dāng)然，單臺更新服務(wù)器的處理能力總是有一定的限制。因此，更新服務(wù)器的硬件配置相對較好，如內(nèi)存較大、網(wǎng)卡及CPU較好；另外，最近一段時間的更新操作往往總是能夠存放在內(nèi)存中，在軟件層面也針對這種場景做了大量的優(yōu)化。
整體架構(gòu)圖如下：
OceanBase由如下幾個部分組成：
●客戶端：用戶使用OceanBase的方式和MySQL數(shù)據(jù)庫完全相同，支持JDBC、 C客戶端訪問，等等?；贛ySQL數(shù)據(jù)庫開發(fā)的應(yīng)用程序、工具能夠直接遷移到OceanBase。
●RootServer：管理集群中的所有服務(wù)器，子表（tablet）數(shù)據(jù)分布以及副本管理。 RootServer一般為一主一備，主備之間數(shù)據(jù)強同步。
●UpdateServer：存儲OceanBase系統(tǒng)的增量更新數(shù)據(jù)。UpdateServer一般為一主一備，主備之間可以配置不同的同步模式。部署時，UpdateServer進程和RootServer進程往往共用物理服務(wù)器。
●ChunkServer：存儲OceanBase系統(tǒng)的基線數(shù)據(jù)?；€數(shù)據(jù)一般存儲兩份或者三份，可配置。
●MergeServer：接收并解析用戶的SQL請求，經(jīng)過詞法分析、語法分析、查詢優(yōu)化等一系列操作后轉(zhuǎn)發(fā)給相應(yīng)的ChunkServer或者UpdateServer。如果請求的數(shù)據(jù)分布在多臺ChunkServer上，MergeServer還需要對多臺ChunkServer返回的結(jié)果進行合并?？蛻舳撕蚆ergeServer之間采用原生的MySQL通信協(xié)議，MySQL客戶端可以直接訪問MergeServer。
OceanBase支持部署多個機房，每個機房部署一個包含RootServer、MergeServer、ChunkServer以及UpdateServer的完整OceanBase集群，每個集群由各自的RootServer負責(zé)數(shù)據(jù)劃分、負載均衡、集群服務(wù)器管理等操作，集群之間數(shù)據(jù)同步通過主集群的主UpdateServer往備集群同步增量更新操作日志實現(xiàn)?？蛻舳伺渲昧硕鄠€集群的RootServer地址列表，使用者可以設(shè)置每個集群的流量分配比例，客戶端根據(jù)這個比例將讀寫操作發(fā)往不同的集群，如下圖：
1）請求RootServer獲取集群中MergeServer的地址列表。
2）按照一定的策略選擇某臺MergeServer發(fā)送讀寫請求?？蛻舳伺cMergeServer之間的通信協(xié)議兼容原生的MySQL協(xié)議，因此，只需要調(diào)用MySQL JDBC Driver或者MySQL C客戶端這樣的標(biāo)準(zhǔn)庫即可?？蛻舳酥С值牟呗灾饕袃煞N：隨機以及一致性哈希。一致性哈希的主要目的是將相同的SQL請求發(fā)送到同一臺MergeServer，方便MergeServer對查詢結(jié)果進行緩存。
3）如果請求MergeServer失敗，則從MergeServer列表中重新選擇一臺MergeServer重試；如果請求某臺MergeServer失敗超過一定的次數(shù)，將這臺MergeServer加入黑名單并從MergeServer列表中刪除。另外，客戶端會定期請求RootServer更新MergeServer地址列表。
如果OceanBase部署多個集群，客戶端還需要處理多個集群的流量分配問題。使用者可以設(shè)置多個集群之間的流量分配比例，客戶端獲取到流量分配比例后，按照這個比例將請求發(fā)送到不同的集群。
RootServer的功能主要包括：集群管理、數(shù)據(jù)分布以及副本管理。
RootServer管理集群中的所有MergeServer、ChunkServer以及UpdateServer。每個集群內(nèi)部同一時刻只允許一個UpdateServer提供寫服務(wù)，這個UpdateServer成為主UpdateServer。這種方式通過犧牲一定的可用性獲取了強一致性。RootServer通過租約（Lease）機制選擇唯一的主UpdateServer，當(dāng)原先的主UpdateServer發(fā)生故障后，RootServer能夠在原先的租約失效后選擇一臺新的UpdateServer作為主UpdateServer。另外，RootServer與MergeServer＆ChunkServer之間保持心跳（heartbeat），從而能夠感知到在線和已經(jīng)下線的MergeServer＆ChunkServer機器列表。
OceanBase內(nèi)部使用主鍵對表格中的數(shù)據(jù)進行排序和存儲，主鍵由若干列組成并且具有唯一性。在OceanBase內(nèi)部，基線數(shù)據(jù)按照主鍵排序并且劃分為數(shù)據(jù)量大致相等的數(shù)據(jù)范圍，稱為子表（tablet）。每個子表的默認大小是256MB（可配置）。OceanBase的數(shù)據(jù)分布方式與Bigtable一樣采用順序分布，不同的是，OceanBase沒有采用根表（RootTable） 元數(shù)據(jù)表（MetaTable）兩級索引結(jié)構(gòu)，而是采用根表一級索引結(jié)構(gòu)。
如圖所示，主鍵值在[1，100]之間的表格被劃分為四個子表：1～25，26～50，51～80以及81～100。RootServer中的根表記錄了每個子表所在的ChunkServer位置信息，每個子表包含多個副本（一般為三個副本，可配置），分布在多臺ChunkServer中。當(dāng)其中某臺ChunkServer發(fā)生故障時，RootServer能夠檢測到，并且觸發(fā)對這臺ChunkServer上的子表增加副本的操作；另外，RootServer也會定期執(zhí)行負載均衡，選擇某些子表從負載較高的機器遷移到負載較低的機器上。
RootServer采用一主一備的結(jié)構(gòu)，主備之間數(shù)據(jù)強同步，并通過Linux HA（http://www.linux-ha.org）軟件實現(xiàn)高可用性。主備RootServer之間共享VIP，當(dāng)主RootServer發(fā)生故障后，VIP能夠自動漂移到備RootServer所在的機器，備RootServer檢測到以后切換為主RootServer提供服務(wù)。
MergeServer的功能主要包括：協(xié)議解析、SQL解析、請求轉(zhuǎn)發(fā)、結(jié)果合并、多表操作等。
OceanBase客戶端與MergeServer之間的協(xié)議為MySQL協(xié)議。MergeServer首先解析MySQL協(xié)議，從中提取出用戶發(fā)送的SQL語句，接著進行詞法分析和語法分析，生成SQL語句的邏輯查詢計劃和物理查詢計劃，最后根據(jù)物理查詢計劃調(diào)用OceanBase內(nèi)部的各種操作符。
MergeServer緩存了子表分布信息，根據(jù)請求涉及的子表將請求轉(zhuǎn)發(fā)給該子表所在的ChunkServer。如果是寫操作，還會轉(zhuǎn)發(fā)給UpdateServer。某些請求需要跨多個子表，此時MergeServer會將請求拆分后發(fā)送給多臺ChunkServer，并合并這些ChunkServer返回的結(jié)果。如果請求涉及多個表格，MergeServer需要首先從ChunkServer獲取每個表格的數(shù)據(jù)，接著再執(zhí)行多表關(guān)聯(lián)或者嵌套查詢等操作。
MergeServer支持并發(fā)請求多臺ChunkServer，即將多個請求發(fā)給多臺ChunkServer，再一次性等待所有請求的應(yīng)答。另外，在SQL執(zhí)行過程中，如果某個子表所在的ChunkServer出現(xiàn)故障，MergeServer會將請求轉(zhuǎn)發(fā)給該子表的其他副本所在的ChunkServer。這樣，ChunkServer故障是不會影響用戶查詢的。
MergeServer本身是沒有狀態(tài)的，因此，MergeServer宕機不會對使用者產(chǎn)生影響，客戶端會自動將發(fā)生故障的MergeServer屏蔽掉。
ChunkServer的功能包括：存儲多個子表，提供讀取服務(wù)，執(zhí)行定期合并以及數(shù)據(jù)分發(fā)。
OceanBase將大表劃分為大小約為256MB的子表，每個子表由一個或者多個SSTable組成（一般為一個），每個SSTable由多個塊（Block，大小為4KB～64KB之間，可配置）組成，數(shù)據(jù)在SSTable中按照主鍵有序存儲。查找某一行數(shù)據(jù)時，需要首先定位這一行所屬的子表，接著在相應(yīng)的SSTable中執(zhí)行二分查找。SSTable支持兩種緩存模式，塊緩存（Block Cache）以及行緩存（Row Cache）。塊緩存以塊為單位緩存最近讀取的數(shù)據(jù)，行緩存以行為單位緩存最近讀取的數(shù)據(jù)。
MergeServer將每個子表的讀取請求發(fā)送到子表所在的ChunkServer,ChunkServer首先讀取SSTable中包含的基線數(shù)據(jù)，接著請求UpdateServer獲取相應(yīng)的增量更新數(shù)據(jù)，并將基線數(shù)據(jù)與增量更新融合后得到最終結(jié)果。
由于每次讀取都需要從UpdateServer中獲取最新的增量更新，為了保證讀取性能，需要限制UpdateServer中增量更新的數(shù)據(jù)量，最好能夠全部存放在內(nèi)存中。OceanBase內(nèi)部會定期觸發(fā)合并或者數(shù)據(jù)分發(fā)操作，在這個過程中，ChunkServer將從UpdateServer獲取一段時間之前的更新操作。通常情況下，OceanBase集群會在每天的服務(wù)低峰期（凌晨1:00開始，可配置）執(zhí)行一次合并操作。這個合并操作往往也稱為每日合并。
UpdateServer是集群中唯一能夠接受寫入的模塊，每個集群中只有一個主Update-Server。UpdateServer中的更新操作首先寫入到內(nèi)存表，當(dāng)內(nèi)存表的數(shù)據(jù)量超過一定值時，可以生成快照文件并轉(zhuǎn)儲到SSD中?？煺瘴募慕M織方式與ChunkServer中的SSTable類似，因此，這些快照文件也稱為SSTable。另外，由于數(shù)據(jù)行的某些列被更新，某些列沒被更新，SSTable中存儲的數(shù)據(jù)行是稀疏的，稱為稀疏型SSTable。
為了保證可靠性，主UpdateServer更新內(nèi)存表之前需要首先寫操作日志，并同步到備UpdateServer。當(dāng)主UpdateServer發(fā)生故障時，RootServer上維護的租約將失效，此時，RootServer將從備UpdateServer列表中選擇一臺最新的備UpdateServer切換為主UpdateServer繼續(xù)提供寫服務(wù)。UpdateServer宕機重啟后需要首先加載轉(zhuǎn)儲的快照文件（SSTable文件），接著回放快照點之后的操作日志。
由于集群中只有一臺主UpdateServer提供寫服務(wù)，因此，OceanBase很容易地實現(xiàn)了跨行跨表事務(wù)，而不需要采用傳統(tǒng)的兩階段提交協(xié)議。當(dāng)然，這樣也帶來了一系列的問題。由于整個集群所有的讀寫操作都必須經(jīng)過UpdateServer,UpdateServer的性能至關(guān)重要。OceanBase集群通過定期合并和數(shù)據(jù)分發(fā)這兩種機制將UpdateServer一段時間之前的增量更新源源不斷地分散到ChunkServer，而UpdateServer只需要服務(wù)最新一小段時間新增的數(shù)據(jù)，這些數(shù)據(jù)往往可以全部存放在內(nèi)存中。另外，系統(tǒng)實現(xiàn)時也需要對UpdateServer的內(nèi)存操作、網(wǎng)絡(luò)框架、磁盤操作做大量的優(yōu)化。
定期合并和數(shù)據(jù)分發(fā)都是將UpdateServer中的增量更新分發(fā)到ChunkServer中的手段，二者的整體流程比較類似：
1）UpdateServer凍結(jié)當(dāng)前的活躍內(nèi)存表（Active MemTable），生成凍結(jié)內(nèi)存表，并開啟新的活躍內(nèi)存表，后續(xù)的更新操作都寫入新的活躍內(nèi)存表。
2）UpdateServer通知RootServer數(shù)據(jù)版本發(fā)生了變化，之后RootServer通過心跳消息通知ChunkServer。
3）每臺ChunkServer啟動定期合并或者數(shù)據(jù)分發(fā)操作，從UpdateServer獲取每個子表對應(yīng)的增量更新數(shù)據(jù)。
定期合并與數(shù)據(jù)分發(fā)兩者之間的不同點在于，數(shù)據(jù)分發(fā)過程中ChunkServer只是將UpdateServer中凍結(jié)內(nèi)存表中的增量更新數(shù)據(jù)緩存到本地，而定期合并過程中ChunkServer需要將本地SSTable中的基線數(shù)據(jù)與凍結(jié)內(nèi)存表的增量更新數(shù)據(jù)執(zhí)行一次多路歸并，融合后生成新的基線數(shù)據(jù)并存放到新的SSTable中。定期合并對系統(tǒng)服務(wù)能力影響很大，往往安排在每天服務(wù)低峰期執(zhí)行（例如凌晨1點開始），而數(shù)據(jù)分發(fā)可以不受限制。
