數據庫

大兴阳光波尔多:TPC-C解析系列04_TPC-C基準測試之數據庫事務引擎的挑戰

廣告
廣告

微信掃一掃,分享到朋友圈

TPC-C解析系列04_TPC-C基準測試之數據庫事務引擎的挑戰
0 0

OceanBase這次TPC-C測試與榜單上Oracle和DB2等其他數據庫在硬件使用上有非常大的不同,OceanBase的數據庫服務器使用的是204+3臺型號是ecs.i2.16xlarge阿里云ECS服務器,其中204臺作為data node,還有3臺作為root node,每位讀者都可以在阿里云網站上輕松按需購買。如果讀者翻看Oracle和DB2的TPC-C測試報告會發現,這些數據庫都會使用專用的存儲設備,例如前最高記錄保持者Oracle在2010年的測試,使用了97臺COMSTAR專用的存儲設備,其中28臺用來存儲數據庫的重做日志(Redo Log)。

硬件的差異給軟件架構提出了完全不同的挑戰,專用的存儲設備其內部通過硬件冗余實現了設備自身的可靠保證,數據庫軟件在使用這樣的存儲設備時就天然的預設了數據不會丟失。但是,這種方式帶來了成本的極大消耗,專用的存儲設備的價格都是特別昂貴的。

OceanBase使用通用的ECS服務器提供數據庫服務,并且只使用ECS機器自帶的本地硬盤做數據存儲,這是最通用的硬件條件。但是這種方式對軟件架構提出了很大的挑戰,因為單個ECS服務器的不如專用的存儲設備可靠性高。這也對OceanBase的事務引擎提出了很大的挑戰,OceanBase是在普通的ECS服務器上就可以實現ACID特性。

TPC-C測試是對事務ACID特性有完整并且嚴格的要求。下面分別介紹OceanBase針對事務ACID的特性的解決方案。

Paxos日志同步保證持久性(Durability)

OceanBase 數據庫的事務持久性(Durability)保證是依賴事務重做日志(Redo Log)的持久性來達成的。所有的 Redo Log 會實時強同步到另外兩臺數據庫服務機器上,包含產生 Redo Log 的機器在內,總共會有三臺機器在硬盤中持久化 Redo Log。OceanBase 采用了 Paxos 一致性同步協議來協調這三臺機器上 Redo Log 的持久化,Paxos協議采用超過半數(也叫“多數派”)成功即算成功的算法(三個副本時,兩個成功即超過半數),當其中兩臺機器完成持久化后,事務即可完成提交,剩下的一臺機器的 Redo Log 在通常情況下,也是立即就持久化完成了。但如果這臺機器碰巧出現異常,也不會影響事務的提交,系統會在其恢復后自動補齊所缺失的 Redo Log。如果機器永久故障,系統會將故障機器所應負責同步的數據分散給集群內的其他機器,這些機器會自動補齊所缺失內容,并跟上最新的 Redo Log 寫入。

使用Paxos一致性協議的最大優勢是數據持久化和數據庫服務可用性(Availability)的完美平衡。當使用三個副本時,任何時候壞掉一個副本時至少還有另一個副本有數據,并且寫入還可以持續,因為還剩下兩個副本,后續的寫入也不受影響。所以,OceanBase 在保證了事務持久性的同時,也大大提升了數據庫的連續服務能力。TPC組織的審計員在現場審計OceanBase持久性能力時,在客戶端持續產生壓力的情況下,從OceanBase集群中隨意挑選了一臺機器做了強制斷電操作,發現數據庫的數據不僅沒丟,數據庫不需要任何人工干預還能持續的提供服務,審計員們都很吃驚,并且對OceanBase大為贊賞。

依靠自動兩階段提交解決原子性(Atomicity)

TPC-C測試模型的五種事務中的“訂單創建”和“訂單支付”兩個事務分別會對很多數據做修改,是其中相對復雜的兩個事務。TPC-C標準對事務的原子性(Atomicity)是強制性的要求,要求一個事務內部對倉庫、訂單、用戶等表格的修改一定要原子的生效,不允許出現只有一半成功的情況。

OceanBase的數據是按照倉庫ID(Warehouse_ID)拆分到多臺機器上的,如果所有的事務都是發生在同一個倉庫內部,那么無論數據量有多大,事務的修改都只會涉及一臺機器的數據,也就是在一臺機器上完成事務提交,這是一種完美的線形擴展的場景。但是這不符合實際的業務場景,大多數的實際業務都會有很多不同維度之間的數據交互。TPC-C測試標準也是對此認真考慮,所以對于事務操作數據的隨機性規則提出了要求,最終要保證產生10%的“訂單創建”事務和15%的“訂單支付”事務要操作兩個及以上的倉庫。在OceanBase數據庫內,這樣就產生了跨機器的事務操作,而這必須使用兩階段提交協議來保證原子性。

OceanBase會自動跟蹤一個事務內所有SQL語句操作的數據,根據實際數據修改的位置自動確定兩階段提交的參與者,事務開始提交時,OceanBase自動選擇第一個參與者作為協調者,協調者會給所有參與者發送Prepare消息,每個參與者都需要寫各自的Redo Log和Prepare Log(也意味著每個參與者各自做自己的Paxos同步),等協調者確認所有參與者的Redo Log和Prepare Log完成后,然后再給所有參與者發送Commit消息,再等所有參與者的Commit工作完成。整個協議是在事務提交過程中自動完成,對用戶完全透明。OceanBase為每一個兩階段提交事務自動選擇一個協調者,整個系統任何機器都可以分擔協調者工作,所以OceanBase可以將事務處理能力進行線形擴展。

多版本并發控制保證事務的隔離性(Isolation)

TPC-C標準里要求“訂單創建”、“訂單支付”、“訂單配送”、“訂單支付”事務之間都是串行化隔離級別(Serializable)。OceanBase采用的方法是基于多版本的并發控制機制。事務提交時會申請一個事務的提交時間戳,事務內的修改以新的版本寫入存儲引擎,并且保證之前版本的數據不受影響。事務開始時會獲取一個讀取時間戳,整個事務內數據的讀取操作只會看到基于讀取時間戳的已提交數據。所以,事務的讀取不會遇到臟數據、不可重復讀數據以及幻讀數據。同時,事務的修改會在修改的數據行上持有行鎖,保證兩個并發的修改相同行的事務會互斥。

OceanBase的全局時間戳生成器也是由多副本組成,可以獨立部署在三臺機器上,也可以像這次TPC-C評測中一樣部署在root node機器上,與root node共享資源。全局時間戳的三副本是一種極高可用的架構,任何一次時間戳的獲取操作都至少在三臺機器上的兩臺獲得了確認,所以任意一臺機器出現故障,獲取時間戳的操作不會有一點影響。

按照TPC-C標準,OceanBase準備了9種不同的場景測試有讀-讀、讀-寫沖突時事務的隔離性,最終都完美通過了審計員的審計。

一致性保證(Consistency)

在有了上述的事務能力后,OceanBase可以完美的保證各種數據的一致性的約束。TPC-C標準里提出了12種不同的一致性測試場景在各種測試運行前后對數據庫內的數據進行一致性校驗。因為OceanBase此次測試數據規模龐大,一致性校驗的SQL需要核對大量的數據,所以一致性校驗的挑戰在于校驗的SQL本身運行的效率?;贠ceanBase的并行查詢能力,發揮整個集群所有的計算資源,校驗SQL的運行時間均縮短了幾個數量級,很好的完成一致性功能的審計工作。

復制表

TPC-C測試模型中有一張商品(ITEM)表,這張表的內容是測試所模擬的銷售公司所有售賣的商品信息,包含了商品的名字、價格等信息?!岸┑ゴ唇ā筆攣裰蔥兄行枰肭笳庹瘧砟詰氖堇慈范ǘ┑サ募鄹裥畔?,如果商品表的數據只存放在一臺機器上,那么所有機器上發生的“訂單創建”事務都會請求包含商品表的機器,這臺機器就會成為瓶頸。OceanBase支持復制表功能,將商品表設置為復制表后,商品表的數據會自動復制到集群中的每一臺機器上。TPC-C標準不限制數據的副本數,但是不管數據的組織形式,標準里要求事務的ACID一定要保證。OceanBase使用特殊的廣播協議保證復制表的所有副本的ACID特性,當復制表發生修改時,所有的副本會同時修改。并且,當有機器出現故障時,復制表的邏輯會自動剔除無效的副本,保證數據修改過程中不會因為機器故障出現無謂的等待。復制表在很多業務場景中都有使用,例如很多業務中存儲關鍵信息的字典表,還有金融業務中存儲匯率信息的表。

總結

OceanBase堅持在普通的PC服務器上實現高可靠、高可用、高性能、可擴展的數據庫,實現了用廉價硬件和云計算的部署環境提供最關鍵的數據庫服務的能力。后續,我們會持續優化事務處理的性能,豐富事務的各種功能特性,為用戶提供更好用的數據庫服務。

作者介紹:

韓富晟:現任螞蟻金服OceanBase團隊資深技術專家,OceanBase初創成員之一,目前負責OceanBase事務引擎以及性能優化相關的研發工作。

我還沒有學會寫個人說明!

TPC-C解析系列03_TPC-C基準測試之SQL優化

上一篇

TPC-C解析系列05_TPC-C基準測試之存儲優化

下一篇

你也可能喜歡

TPC-C解析系列04_TPC-C基準測試之數據庫事務引擎的挑戰

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃