天天看點

深度 | 每秒1.4億次!再度重新整理TPS記錄的PolarDB如何應對雙11“尖峰時刻”?

2020年是雲原生資料庫PolarDB全面支撐天貓雙十一的第二年,天貓交易、買家、賣家以及物流等系統在雙十一期間基于PolarDB為億萬客戶提供了順滑的體驗。同時,PolarDB還重新整理了去年由自己創造的資料庫處理峰值(TPS)紀錄,今年TPS峰值高達1.4億次/秒,較去年提升了60%。

PolarDB是阿裡自研的雲原生資料庫品牌, 通過獨有的存儲計算分離、分布式共享存儲技術,解決了傳統RDBMS容量有限、擴縮容時間長等問題, 在性能、容量、彈性、以及可用性上都有很大的突破:

 存儲容量可達100TB,單庫可擴充到16個節點,滿足企業級大資料存儲需求。

 高性能、高彈性、低成本,一寫多讀,分鐘級擴縮容

 多AZ高可用,資料高可靠性。跨AZ六副本,故障快速容災轉移

PolarDB今年下半年釋出了MySQL 5.7的相容版。至此PolarDB成為全球唯一一家相容 MySQL 所有在役版本的雲資料庫,可以覆寫更多的業務場景

性能優化

性能對于雙十一大促來說是永恒的主題。在天貓的核心交易鍊路的資料庫,在零點峰值場景中,會有大量的資料讀寫。而每一年随着峰值的增長,資料庫會遇到更嚴峻的挑戰。在過去的幾年中,随着資料庫硬體的不斷進化,我們為PolarDB重點優化了索引結構、I/O子系統、鎖系統以及事務系統來完成并發性能的提升。

首先是索引結構。衆所周知傳統的InnoDB 索引在這樣的場景下會遇到頻繁的頁面分裂導緻的并發瓶頸。所有的對索引結構的修改都要排隊串行執行。為了解決這個問題, PolarDB引入了新的索引結構來替代傳統索引,細化索引結構變更時的并發粒度,提升了接近20%的讀寫性能。新的索引結構使得原本需要将所有涉及索引分裂的頁面加鎖直到整個分裂動作完成後才釋放的邏輯變成逐層加鎖。這樣原本被索引頁面分裂阻塞的讀操作會有機會在整個分裂動作中間進來:通過對每個節點增加一個後繼連結的方式,使得在分裂的中間狀态也可以完成對資料頁面的安全的通路,進而提高讀取性能。

深度 | 每秒1.4億次!再度重新整理TPS記錄的PolarDB如何應對雙11“尖峰時刻”?

其次是IO子系統。由于PolarDB是采用的使用者态檔案系統, 是以需要有一套對應的IO系統來確定對底層分布式存儲的高效通路, InnoDB原有的AIO政策,是将所有異步IO請求按照目标位址進行組織存放在同一個IO數組中,友善将目标位址連續的小IO合并成大IO以提升IO的吞吐,但是在分布式存儲的場景下連續的大IO操作,會使得同一時刻,隻有一個或少量存儲節點處在服務狀态,其他的存儲節點處于空閑狀态,此外,分布式存儲在高IO負載的場景中會出現網絡中的Inflight IO較多的情況,IO任務數組中添加I和移除請求的開銷都很大。為此PolarDB專門對IO系統進行了重新的設計,主要包括:合理的選擇IO合并和拆解,充分利分布式存儲的多節點優勢;建立狀态有序的IO服務隊列,減少高負載下的IO服務開銷。新的子系統讓PolarDB在寫入和讀寫混合的場景下性能和穩定性都得到了顯著的性能提升。

深度 | 每秒1.4億次!再度重新整理TPS記錄的PolarDB如何應對雙11“尖峰時刻”?

再接下來是鎖系統的優化。 PolarDB和MySQL一樣都是采用MVCC的方式看來做事務之間的并發控制, 但是在處理寫請求和寫請求之間的并發時是通過兩階段的鎖來做保護的。大量且頻繁的插入更新删除帶來了鎖系統的負擔和并發的瓶頸。 是以PolarDB采取了Partition Lock System的方式,将鎖系統改造成由多個分片組成,每個分片中都有自己局部的并發控制,進而将這個瓶頸打散。尤其是在這種大壓力的寫入場景下明顯的提升寫入性能。

深度 | 每秒1.4億次!再度重新整理TPS記錄的PolarDB如何應對雙11“尖峰時刻”?

最後是事務系統。 PolarDB中支援Snapshot Isolation的隔離級别,通過保留使用的Undo版本資訊來支援對不同版本的記錄的通路,即MVCC。而實作MVCC需要事務系統有能力跟蹤目前活躍及已經送出的事務資訊。在之前的實作中每當有寫事務開始時,需要配置設定一個事務ID,并将這個ID添加到事務系統中的一個活躍事務清單中。當有讀請求需要通路資料時,會首先配置設定一個ReadView,其中包括目前已配置設定最大的事務ID,以及目前這個活躍事務清單的一個備份。每當讀請求通路資料時,會通過從索引開始的指針通路到這個記錄所有的曆史版本,通過對比某個曆史版本的事務ID和自己ReadView中的活躍事務清單,可以判斷是不是需要的版本。然而,這就導緻每當有讀事務開始時,都需要在整個拷貝過程對這個活躍事務清單加鎖,進而阻塞了新的寫事務将自己的ID加入。同樣寫事務和寫事務之間也有通路活躍事務清單的沖突。進而活躍事務清單在這裡變成一個明顯的性能瓶頸,在雙十一這種大壓力的讀寫場景下尤為明顯。對此,我們将事務系統中的這個活躍事務清單改造成無鎖Hash實作,寫事務添加ID以及讀事務拷貝到ReadView都可以并發進行。大大提升了性能。

全球資料庫技術

諸如AliExpress這一類針對海外消費者的購物大促,業務遍及各個大洲和國家等等。是以資料庫的異地可讀,資料同步有非常高的要求。在過去DTS承載了區域間資料同步任務,DTS訂閱了二進制日志然後分發到不同的區域并進行高速應用以實作區域間資料狀态一緻性。今年PolarDB內建了全新的全球資料庫技術來解決跨域通路以及容災的問題,PolarDB全球資料庫(PolarDB Global Database Network,PolarDB-GDN)采用了資料庫實體日志異步複制的方案。但是達成以上目标需要解決幾個關鍵難點:高網絡延遲下的資料同步問題和跨Region的資料讀寫問題。針對這兩點問題,PolarDB-GDN通過高并發流水線技術将同步速度提升7倍,将資料跨大洲同步延遲控制在2秒内。 全局讀寫分離技術結合多級别的一緻性能力, 讓業務不用做任何的改造的前提下降低整體的通路延遲。

深度 | 每秒1.4億次!再度重新整理TPS記錄的PolarDB如何應對雙11“尖峰時刻”?

熱緩存技術

雙十一對資料庫的可用性要求非常高,核心應用在大促期間處于高負載的狀态,長時間高負荷的運作不可避免會存在單一節點的故障,如何能快速恢複成為了一個重要的課題。過去的節點故障恢複需要經曆相當長的時間的恢複時間,而重新開機拉起後的系統還需要緩存預熱後才能達到最佳通路性能。

PolarDB今年在存儲計算分離架構上繼續往前邁進一大步,實作了計算和記憶體的分離。通過将記憶體緩沖池從計算節點剝離,讓計算節點狀态最小化 。計算節點重新開機後可以快速恢複到重新開機前的狀态,避免大量耗時的緩存預熱。傳統資料庫的錯誤恢複需要檢查點開始掃描所有的redo日志、回放日志、事務恢複等步驟,該過程涉及大量磁盤IO、CPU計算等工作量,其時間往往很長。使用了熱緩存技術的PolarDB在計算節點崩潰後,需要恢複的是緩存可能處于不一緻的狀态,如部分尚未修改完成的緩存頁面以及記憶體結構等。而在CPU緩存分離的架構下隻需要新的計算節點來根據各種控制資訊和redo日志将這些被污染的記憶體恢複到一緻的狀态。因為無需重新建構緩存池,修複工作量小。在正常讀寫負載下,重新開機後的資料庫最大吞吐下降到原來的5%以下,并在200秒後逐漸恢複正常水準,而利用了熱緩存技術的執行個體幾乎無任何性能下降。

跨AZ容災能力

雙十一的核心業務必須要能夠跨AZ的容災, PolarDB提供了跨AZ容災RPO為0的方案。PolarDB 在存儲層(PolarStore)提供3副本的同時,還可以通過自研的 X-Paxos 庫提供跨節點、跨機房、跨 AZ 級别的資料同步能力,提供 RPO = 0 的容災解決方案。這個方案利用 PolarDB 經過多年驗證的實體複制技術和 X-Paxos 一緻性協定庫,提供高可靠、低延遲的資料複制技術。相比于 RDS/MySQL 的邏輯日志複制,PolarDB 在節點切換時,受大事務/DDL 的影響更小,RTO 小于1分鐘。同時,這個方案在保證資料備援的同時,盡量減少部署成本。PolarDB 跨AZ版可以部署Leader,Follower 和 Log 節點。其中 Log 節點隻記錄日志,不參與選主,不存儲資料,部署成本相比于現有架構隻增加了 active redo log ,顯著降低了部署成本。

并行查詢增強

雙十一不僅是消費者的盛筵, 也是衆多賣家的狂歡。 賣家經常需要實時的查詢自己的銷售資料以及做一些快速的分析。PolarDB擁有查詢引擎,在衆多場景下能滿足一些即時查詢的需求,它充分利用硬體多核優勢,并基于COST自動選擇并行查詢引擎,顯著提升了查詢性能。今年PolarDB在該方向并沒有停止腳步,利用并行查詢引擎了優化更多的應用場景。在大規格的執行個體中, 并行的提升效果尤為顯著。

在今年, PolarDB的并行查詢新增加了衆多場景的覆寫, 有聯合(Union)子查詢的并行優化,擴充并行查詢引擎對聯合(Union)子查詢的支援;派生表(Derived Table)的并行優化;使用者自定義臨時表的并行優化;Count的并行優化;Limit的并行優化;條件下推優化,減少資料彙總代價;HASH JOIN 的并行優化,同時優化算子和執行的并行度。

除此之外, POLARDB對GROUP BY / Distinct / SEMI-JOIN / 常量表以及包含Window函數的子查詢也做了并行優化,通過利用更多的CPU資源, 有效降低了這些場景下的查詢耗時。在标準的TPC-H場景下,POLARDB的并行查詢架構取得了非常好的表現。

深度 | 每秒1.4億次!再度重新整理TPS記錄的PolarDB如何應對雙11“尖峰時刻”?

并行schema變更

在阿裡的業務中大量的POLARDB承載了超大規模的資料,然而業務的需求是實時變化的。過去對這些大表做DDL會持續數小時甚至數天,如此之高的延遲是難以容忍的。以建立二級索引為例,過高延遲的DDL操作會阻塞後續依賴新索引查詢的DML操作。DDL操作會消耗CPU/Memory/IO資源,對業務DML帶來一定的影響,是以使用者往往在業務低峰期進行schema變更,但是如果不能確定變更在業務低峰期之内完成會對業務的穩定性産生嚴重的影響。

我們認為大表DDL運作緩慢的根本原因在于傳統的DDL操作是針對單核和傳統硬碟設計的。随着多核處理器的日益發展和高速存儲的普及,DDL的并行化是可以取得非常好的效果的。

Online DDL分為建立臨時表掃描拷貝全量資料加上增量應用期間的變更等幾個主要階段。以增加索引為例需要掃描主鍵所有記錄,生成新的二級索引記錄,寫入磁盤檔案中;對所有二級索引記錄進行排序,寫入磁盤檔案;将有序的二級索引記錄插入到新的二級索引中。

POLARDB可以對索引樹進行并行掃描、并行多路歸并的Merge Sort、并行的Bulk Load索引。 在8core32G規格的執行個體中針對CPU Bound 和 IO Bound的場景分别進行了測試,都可以達到6-13倍的速度提升。

深度 | 每秒1.4億次!再度重新整理TPS記錄的PolarDB如何應對雙11“尖峰時刻”?

總結

今年的雙十一對PolarDB在性能和功能上提出了更高的要求。 PolarDB在并發性能、跨域、彈性以及可用性上都更進了一步,POLARDB不僅承載着整個阿裡集團的實時OLTP資料業務,而且在雲上為更為廣大的客戶提供服務。 我們的目标是将雲原生的資料庫技術普惠所有的企業客戶,幫助客戶更好的實作業務價值。