O
ceanBase是什麼
OceanBase是一個支持海量數據的高性能分佈式數據庫系統，實現了數千億條記錄、數百TB數據上的跨行跨表事務，由淘寶核心系統研發部、運維、DBA、廣告、應用研發等部門共同完成。
OceanBase解決什麼問題
許多公司的核心資產是各種各樣的商業數據，例如淘寶的商品、交易、訂單、購物愛好等等，這些數據通常是結構化的，並且數據之間存在各種各樣的關聯，傳統的關係數據庫曾經是這些數據的最佳載體。然而，隨着業務的快速發展，這些數據急劇膨脹，記錄數從幾千萬條增加到數十億條，數據量從百GB增加到數TB，未來還可能增加到數千億條和數百TB，傳統的關係型數據庫已經無法承擔如此海量的數據。OceanBase解決不斷增加的結構化數據存儲與查詢的問題。
從Eric Brewer教授的CAP(一致性C: Consistency， 可用性A: Availability，分區容錯性P: Tolerance of network Partition)理論角度分析，作爲電子商務企業，淘寶和其他公司的業務對一致性和可用性的要求高於分區容錯性，數據特徵是數據總量龐大且逐步增加，單位時間內的數據更新量並不大，但實時性要求很高。這就要求我們提供一套更加偏重於支持CA特性的系統，同時兼顧可分區性，並且在實時性、成本、性能等方面表現良好。
OceanBase的架構
OceanBase的邏輯架構簡圖
OceanBase架構的一些基本概念
主鍵
row key，也稱爲primary key，類似於DBMS的主鍵，與DBMS不同的是，OceanBase的主鍵總是二進制字符串(binary string)，但可以有某種結構。OceanBase以主鍵爲順序存放表格數據
sstable
一種數據存儲格式，OceanBase用來存儲一個或幾個表的一段按主鍵連續的數據
tablet
一個表按主鍵劃分的一個(前開後閉的)範圍，通常包含一個或幾個sstable，一個tablet的數據量通常在256MB左右
基準數據和動態數據
OceanBase以增量方式記錄一段時間內的表格數據的增刪改，從而保持着表格主體數據在一段時間內相對穩定，其中增刪改的數據稱爲動態數據(通常在內存，也稱爲內存表)，而一段時間內相對穩定的主體數據稱爲基準數據，基準數據和轉儲後(保存到SSD固態盤或磁盤)的動態數據以sstable格式存儲
ChunkServer
保存基準數據的服務器，通常是多臺，爲了避免軟件硬件故障導致的服務中斷，同一份基準數據通常保存了3份並存儲在不同ChunkServer上
UpdateServer
保存動態數據的服務器，一般是單臺服務器。爲了避免軟件硬件故障導致的服務中斷，UpdateServer記錄commit log並通常使用雙機熱備
MergeServer
進行靜態動態數據合併的服務器，常常與ChunkServer共用一臺物理服務器。MergeServer使得用戶能夠訪問到完整的最新的數據
RootServer
配置服務器，一般是單臺服務器。爲了避免軟件硬件故障導致的服務中斷，RootServer記錄commit log並通常採用雙機熱備。由於RootServer負載一般都很輕，所以它常常與UpdateServer共用物理機器
凍結
指動態數據(也稱爲內存表)的更新到一定時間或者數據量達到一定規模後，OceanBase停止該塊動態數據的修改，後續的更新寫入新的動態數據塊(即新的內存表)，舊的動態數據塊不再修改，這個過程稱爲凍結
轉儲
出於節省內存或者持久化等原因將一個凍結的動態數據塊(內存表)持久化(轉化爲sstable並保存到SSD固態盤或磁盤上)的過程
數據合併(merge)
查詢時，查詢項的基準數據與其動態數據(即增刪改操作)合併以得到該數據項的最新結果的過程。此外，把舊的基準數據與凍結的動態數據進行合併生成新的基準數據的過程也稱爲數據合併
聯表(join)
一張表與另一張或幾張表基於主鍵的左連接關係，類似於DBMS的自然連接
COW
Copy on Write的縮寫，在OceanBase中特指BTree在更新時複製數據備份寫入，避免系統鎖的技術手段
OceanBase的特點
OceanBase功能
OceanBase設計和實現的時候暫時摒棄了不緊急的DBMS的功能，例如臨時表，視圖(view)，研發團隊把有限的資源集中到關鍵點上，當前OceanBase主要解決數據更新一致性、高性能的跨表讀事務、範圍查詢、join、數據全量及增量dump、批量數據導入。
OceanBase數據訪問特點
雖然數據總量比較大，但跟許多行業一樣，淘寶業務一段時間(例如小時或天)內數據的增刪改是有限的(通常一天不超過幾千萬次到幾億次)，根據這個特點，OceanBase把一段時間內的增刪改等修改操作以增量形式記錄下來(稱之爲動態數據，通常保存在內存中)，這樣也使得了主體數據在一段時間內保持了相對穩定(稱之爲基準數據)。
由於動態數據相對較小，通常情況下，OceanBase把它保存在獨立的服務器UpdateServer的內存中。以內存保存增刪改記錄極大地提高了系統寫事務的性能。此外，假如每條修改平均消耗100 Bytes，那麼10GB內存可以記錄100M(即1億)條修改，且擴充UpdateServer內存即增加了內存中容納的修改量。不僅如此，由於凍結後的內存表不再修改，它也可以轉換成sstable格式並保存到SSD固態盤或磁盤上。轉儲到SSD固態盤後所佔內存即可釋放，並仍然可以提供較高性能的讀服務，這也緩解了極端情況下UpdateServer的內存需求。爲了應對機器故障，動態數據服務器UpdateServer寫commit log並採取雙機(乃至多機)熱備。由於UpdateServer的主備機是同步的，因此備機也可同時提供讀服務。
因爲基準數據相對穩定，OceanBase把它按照主鍵(primary key，也稱爲row key)分段(即tablet)後保存多個副本(一般是3個)到多臺機器(ChunkServer)上，避免了單臺機器故障導致的服務中斷，多個副本也提升了系統服務能力。單個tablet的尺寸可以根據應用數據特點進行配置，相對配置過小的tablet會合並，過大的tablet則會分裂。
由於tablet按主鍵分塊連續存放，因此OceanBase按主鍵的範圍查詢對應着連續的磁盤讀，十分高效。
對於已經凍結/轉儲的動態數據，OceanBase的ChunkServer會在自己不是太繁忙的時候啓動基準數據與凍結/轉儲內存表的合併，並生成新的基準數據。這種合併過程其實是一種範圍查詢，是一串連續的磁盤讀和連續的磁盤寫，也是很高效的。
傳統DBMS提供了強大的事務性、良好的一致性和很短的查詢修改響應時間，但數據規模受到嚴重製約，缺乏擴展性；現代雲計算提供了極大的數據規模、良好的擴展性，但缺乏跨行跨表事務、數據一致性也較弱、查詢修改響應時間通常也較長，OceanBase的設計和實現融合了二者的優勢：
UpdateServer：類似於DBMS中的DB角色，提供跨行跨表事務和很短的查詢修改的響應時間以及良好的一致性。
ChunkServer：類似於雲計算中的工作機(如GFS的chunk server)，具有數據多副本(通常是3)、中等規模數據粒度(tablet大小約256MB)、自動負載平衡、宕機恢復、機器plug and play等特點，系統容量及性能可隨時擴展。
MergeServer：結合ChunkServer和UpdateServer，獲得最新數據，實現數據一致性。
RootServer：類似於雲計算中的主控機(如GFS master)，進行機器故障檢測、負載平衡計算、負載遷移調度等。
上述的DBMS和雲計算技術的優勢互補使得OceanBase既具有傳統DBMS的跨行跨表事務、數據的強一致性以及很短的查詢修改響應時間，還有云計算的海量數據管理能力、自動故障恢復、自動負載平衡以及良好的擴展性。
OceanBase當前在淘寶的應用
OceanBase現在已經應用於淘寶收藏夾，用於存儲淘寶用戶收藏條目和具體的商品、店鋪信息，每天支持4～5千萬的更新操作。等待上線的應用還包括CTU、SNS等，每天更新超過20億，更新數據量超過2.5TB，並會逐步在淘寶內部推廣，也期待外部合作者。
主要的性能數據
測試軟硬件環境
Red Hat Enterprise Linux Server release 5.4 (Tikanga)
gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
Intel(R) Xeon(R) CPU E5520 @ 2.27GH
ChunkServer & MergeServer：Memory 16GB Disk 300GB SAS*10 NO Raid
UpdateServer & RootServer：Memory 48GB Disk 300GB SAS*6 Raid1
測試環境部署簡圖
測試數據規模
21億條數據，基準數據3備份。
測試Schema
兩張表，其中表1中有21列，表2中11列。
其中表1中的11列和表2中的11列存在join關係。
單條記錄大小爲500字節。
測試性能曲線圖
Range數據查詢
單條數據查詢
當壓力最大時，ChunkServer單臺輸出數據90MB/S，已經接近了千兆網卡的極限
更新數據
