http://www.lupaworld.com/article-213231-1.html
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,已經接近了千兆 網卡 的極限
更新數據
▲
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
