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%的讀寫性能。新的索引結構使得原本需要將所有涉及索引分裂的頁面加鎖直到整個分裂動作完成後才釋放的邏輯變成逐層加鎖。這樣原本被索引頁面分裂阻塞的讀操作會有機會在整個分裂動作中間進來：通過對每個節點增加一個後繼鏈接的方式，使得在分裂的中間狀態也可以完成對數據頁面的安全的訪問，從而提高讀取性能。
其次是IO子系統。由於PolarDB是採用的用戶態文件系統， 因此需要有一套對應的IO系統來確保對底層分佈式存儲的高效訪問， InnoDB原有的AIO策略，是將所有異步IO請求按照目標地址進行組織存放在同一個IO數組中，方便將目標地址連續的小IO合併成大IO以提升IO的吞吐，但是在分佈式存儲的場景下連續的大IO操作，會使得同一時刻，只有一個或少量存儲節點處在服務狀態，其他的存儲節點處於空閒狀態，此外，分佈式存儲在高IO負載的場景中會出現網絡中的Inflight IO較多的情況，IO任務數組中添加I和移除請求的開銷都很大。為此PolarDB專門對IO系統進行了重新的設計，主要包括：合理的選擇IO合併和拆解，充分利分佈式存儲的多節點優勢；建立狀態有序的IO服務隊列，減少高負載下的IO服務開銷。新的子系統讓PolarDB在寫入和讀寫混合的場景下性能和穩定性都得到了顯著的性能提升。
再接下來是鎖系統的優化。 PolarDB和MySQL一樣都是採用MVCC的方式看來做事務之間的併發控制， 但是在處理寫請求和寫請求之間的併發時是通過兩階段的鎖來做保護的。大量且頻繁的插入更新刪除帶來了鎖系統的負擔和併發的瓶頸。 因此PolarDB採取了Partition Lock System的方式，將鎖系統改造成由多個分片組成，每個分片中都有自己局部的併發控制，從而將這個瓶頸打散。尤其是在這種大壓力的寫入場景下明顯的提升寫入性能。
最後是事務系統。 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秒內。 全局讀寫分離技術結合多級別的一致性能力， 讓業務不用做任何的改造的前提下降低整體的訪問延遲。
熱緩存技術
雙十一對數據庫的可用性要求非常高，核心應用在大促期間處於高負載的狀態，長時間高負荷的運行不可避免會存在單一節點的故障，如何能快速恢復成為了一個重要的課題。過去的節點故障恢復需要經歷相當長的時間的恢復時間，而重啟拉起後的系統還需要緩存預熱後才能達到最佳訪問性能。
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的並行查詢框架取得了非常好的表現。
並行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倍的速度提升。
總結
今年的雙十一對PolarDB在性能和功能上提出了更高的要求。 PolarDB在併發性能、跨域、彈性以及可用性上都更進了一步，POLARDB不僅承載著整個阿里集團的實時OLTP數據業務，而且在雲上為更為廣大的客戶提供服務。 我們的目標是將雲原生的數據庫技術普惠所有的企業客戶，幫助客戶更好的實現業務價值。
