OceanBase是一個支持海量數據的高性能分散式資料庫系統，實現了數千億條記錄、數百TB數據上的跨行跨表事務，由淘寶核心繫統研發、運維、DBA、廣告、套用研發等部門共同完成。在設計和實現OceanBase的時候暫時摒棄了不緊急的DBMS的功能，例如臨時表，視圖(view)，研發團隊把有限的資源集中到關鍵點上，當前 OceanBase主要解決數據更新一致性、高性能的跨表讀事務、範圍查詢、join、數據全量及增量dump、批量數據導入。
目前OceanBase已經套用於淘寶收藏夾，用於存儲淘寶用戶收藏條目和具體的商品、店鋪信息，每天支持4～5千萬的更新操作。等待上線的套用還包括CTU、SNS等，每天更新超過20億，更新數據量超過2.5TB，並會逐步在淘寶內部推廣。
OceanBase 0.3.1在Github開源，開源版本為Revision:12336。
基本介紹
- 外文名：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，獲得最新數據，實現數據一致性。
上述的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，已經接近了千兆網卡的極限
更新數據
套用
許多公司的核心資產是各種各樣的商業數據，例如淘寶的商品、交易、訂單、購物愛好等等，這些數據通常是結構化的，並且數據之間存在各種各樣的關聯，傳統的關係資料庫曾經是這些數據的最佳載體。然而，隨著業務的快速發展，這些數據急劇膨脹，記錄數從幾千萬條增加到數十億條，數據量從百GB增加到數TB，未來還可能增加到數千億條和數百TB，傳統的關係型資料庫已經無法承擔如此海量的數據。OceanBase解決不斷增加的結構化數據存儲與查詢的問題。
從Eric Brewer教授的CAP(一致性C: Consistency， 可用性A: Availability，分區容錯性P: Tolerance of network Partition)理論角度分析，作為電子商務企業，淘寶和其他公司的業務對一致性和可用性的要求高於分區容錯性，數據特徵是數據總量龐大且逐步增加，單位時間內的數據更新量並不大，但實時性要求很高。這就要求我們提供一套更加偏重於支持CA特性的系統，同時兼顧可分區性，並且在實時性、成本、性能等方面表現良好。
架構
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固態盤或磁碟上)的過程
