阿里云原生数据库：POLARDB
目錄
POLARDB?產品架構簡介
POLARDB?架構
POLARDB 的存儲引擎性能優化
POLARDB?的計算引擎性能優化
如何降低成本
POLARDB?產品架構簡介
POLARDB?是阿里云數據庫團隊研發的基于第三代云計算架構下的商用關系型云數據庫產品，實現?100%?向下兼容?MySQL 5.6?的同時，支持單庫容量擴展至上百?TB?以及計算引擎能力及存儲能力的秒級擴展能力，對比?MySQL?有?6?倍性能提升及相對于商業數據庫實現大幅度降低成本。（數據是2017年的，現在的性能肯定提升的更多）
首先，受益于第三代分布式共享存儲架構，使?POLARDB?實現了計算節點（主要做?SQL?解析以及存儲引擎計算的服務器）與存儲節點（主要做數據塊存儲，數據庫快照的服務器）的分離，提供了即時生效的可擴展能力和運維能力。
其次，與傳統云數據庫一個實例一份數據拷貝不同，POLARDB?同一個實例的所有節點（包括讀寫節點和只讀節點）都實現訪問存儲節點上的同一份數據，使得?POLARDB?的數據備份耗時實現秒級響應。（備份時間與底層數據量無關）
最后，借助優秀的?RDMA?網絡以及最新的塊存儲技術，實現服務器宕機后無需搬運數據重啟進程即可服務，滿足了互聯網環境下企業對數據庫服務器高可用的需求。
?
?
POLARDB?架構
引用?PolarDB?和?PolarStore?的設計師的話：
首先要向?AWS Aurora?的創新性致敬！Aurora?通過計算節點和存儲節點分離，計算節點Scale up，存儲節點?Scale out?的理念將公有云的關系數據庫產品推向了一個新的高度。
在設計方法上，阿里云的?PolarDB?和?Aurora?走了不一樣的路，歸根結底是我們的出發點不同。AWS?的?RDS?一開始就是架設在它的虛擬機產品?EC2?之上的，使用的存儲是云盤?EBS。?EC2?和?EBS?之間?通過網絡通訊?，因此?AWS?的團隊認為?"網絡成為數據庫的瓶頸"，在 Aurora?的論文中，他們開篇就提出?"Instead, the bottleneck moves to the network between the database tier requesting I/Os and the storage tier that performs these I/Os."??Aurora?設計于?12?到?13?年之際，當時網絡主流是萬兆網絡，確實容易成為瓶頸。
而?PolarDB?是從?2015?年開始研發的，我們見證了?IDC?從萬兆到?25Gb RDMA?網絡的飛躍。因此我們非常大膽的判斷，未來幾年主機通過高速網絡互聯，其傳輸速率會和本地?PCIe?總線存儲設備帶寬打平，網絡無論在延遲還是帶寬上都會接近總線，因此不再成為高性能服務器的瓶頸。而恰恰是軟件，過去基于內核提供的?syscall?開發的軟件代碼，才是拖慢系統的一環。Bottleneck resides in the software。
在架構上?Aurora?和?PolarDB?各有特色。我認為?PolarDB?的架構和技術更勝一籌。
(1) 現代云計算機型的演進和分化，計算機型向高主頻，多?CPU，大內存的方向演進；存儲機型向高密度，低功耗方向發展。機型的分化可以大大提高機器資源的使用率，降低?TCO。因此?PolarStore?中大量采用?OS-bypass?和?zero-copy?的技術來節約?CPU，降低處理單位?I/O?吞吐需要消耗的?CPU?資源，確保存儲節點處理?I/O?請求的效率。而?Aurora?的存儲節點需要大量?CPU?做?redolog?到?innodb page?的轉換，存儲節點的效率遠不如?PolarStore。
(2)?Aurora?架構的最大亮點是存儲節點具有將?redolog?轉換為?innodb page?的能力，這個改進看著很吸引眼球，事實上這個優化對關系數據庫的性能提升很有限，性能瓶頸真的不在這里，反而會拖慢關鍵路徑?redolog?落地的性能。在PolarDB?架構下，redolog?離線轉換為?innodb page?的能力不難實現，但我們目前不認為這是高優先級要做的。
(3)?Aurora?的存儲多副本是通過?quorum?機制來實現的，Aurora?是六副本，也就是說，需要計算節點向六個存儲節點分別寫六次，這里使計算節點的網絡開銷又上去了，而且是發生在寫?redolog?這種關鍵路徑上。而?PolarDB?是采用基于?RDMA?實現的?ParallelRaft?技術來復制數據，計算節點只要寫一次?I/O?請求到?PolarStore?的?Leader?節點，由?Leader?節點保證?quorum?寫入其他節點，相當于多副本?replication?被?offload?到存儲節點上。此外，在最終一致性上?Aurora?是用?Gossip?協議來兜底的，在完備程度上沒有?PolarDB?使用的?ParallelRaft?算法有保證。
(4)?Aurora?的改動手術切口太大，使得它很難后面持續跟進社區的新版本。這也是 AWS 幾個數據庫產品線的通病，例如?Redshift，如何吸收?PostgrelSQL 10?的變更是他們的開發團隊很頭疼的問題。對新版本做到與時俱進是云數據庫的一個樸素需求。怎么設計這個刀口，達到?effect?和?cost?之間的平衡，是對架構師的考驗。
?
補充：
亞馬遜彈性計算云（EC2，Elastic Compute Cloud）是一個讓使用者可以租用云端電腦運行所需應用的系統。EC2 借由提供 Web 服務的方式讓使用者可以彈性地運行自己的 Amazon 機器映像檔，使用者將可以在這個虛擬機器上運行任何自己想要的軟件或應用程序。提供可調整的云計算能力。它旨在使開發者的網絡規模計算變得更為容易。
Amazon Elastic Block Store (EBS) 是一種易于使用的高性能數據塊存儲服務，旨在與 Amazon Elastic Compute Cloud (EC2) 一起使用，適用于任何規模的吞吐量和事務密集型工作負載。Amazon EBS 上部署著各種各樣的工作負載，例如關系數據庫和非關系數據庫、企業應用程序、容器化應用程序、大數據分析引擎、文件系統和媒體工作流。
?
?
POLARDB 的存儲引擎性能優化
持續釋放硬件紅利
眾所周知，關系型數據庫是 IO 密集型?的應用，IO 性能的提高對數據庫的性能提升至關重要。過去十年我們看到在數據庫領域， SSD 替換 HDD 的過程給數據庫數據處理的吞吐能力帶來了數量級的提升。
POLARDB?采用了領先的硬件技術：包括使用?3DXpoint?存儲介質的?Optane?存儲卡、NVMe SSD?和?ROCE RDMA?網絡。同時面向新硬件架構實現軟硬一體優化：從數據庫、文件系統到網絡通訊協議、分布式存儲系統和設備驅動，POLARDB?實現縱貫軟件棧各層次的整個?IO?鏈條的深度優化。
為了將?3DXpoint?顆粒的高性能和?3D NAND?顆粒的低成本結合起來，POLARDB?創新的在軟件層實現對高速的?Optane?卡和大容量高吞吐的?NVMe SSD?進行組合，實現一個名為混合存儲層。既保證數據寫入的低延遲、高吞吐、高?QoS，又使整體方案兼具較高的性價比。
?
旁路內核，榨干硬件能力
在?POLARDB?里，為了追求更高的性能、更低的延遲，阿里云數據庫團隊大膽的拋棄了Linux內核提供的各種機制（比如塊設備、各種文件系統例如?ext4，以及?TCP/IP?協議棧和?socket?編程接口），而選擇了另起爐灶。最終，POLARDB?實現了一整套在用戶態運行的?IO?和網絡協議棧。
POLARDB?用戶態協議棧解決了內核?IO?協議棧慢的問題。用戶程序在用戶態直接通過 DMA?操作硬件設備，通過輪詢的方式監聽硬件設備完成 IO 事件，消除了上下文切換和中斷的開銷。用戶程序還可以將?IO?處理線程和?CPU 進行一一映射，每個?IO?處理線程獨占?CPU，相互之間處理不同的?IO?請求，綁定不同的?IO?設備硬件隊列，一個?IO?請求生命周期從頭到尾都在一個線程一顆?CPU?上處理，不需要鎖進行互斥。這種技術實現最大化的和高速設備進行性能交互，實現一顆?CPU?達每秒約?20?萬次?IO?處理的能力，并且保持線性的擴展能力，也就意味著?4?顆?CPU?可以達到每秒?80?萬次?IO?處理的能力，在性能和經濟型上遠高于內核。
網絡也是類似的情況。過去傳統的以太網，網卡發一個報文到另一臺機器，中間通過一跳交換機，大概需要一百到兩百微秒。POLARDB?支持?ROCE?以太網，應用程序通過?RDMA?網絡，直接將本機的內存寫入另一臺機器的內存地址，或者從另一臺機器的內存讀一塊數據到本機，中間的通訊協議編解碼、重傳機制都由?RDMA?網卡來完成，不需要?CPU?參與。使性能獲得極大提升，傳輸一個?4k?大小報文只需要?6、7?微秒的時間。如同內核的?IO?協議棧跟不上高速存儲設備能力，再一次的，內核的?TCP/IP?協議棧跟不上高速網絡設備能力，被?POLARDB?的用戶態網絡協議棧代替。
?
硬件 DMA 和物理復制實現的數據庫多副本
大家都知道關系型數據庫的重要特性歸納起來是?"ACID"，其中?A?是原子性，C?是一致性，I 是隔離性，D?是持久性。
POLARDB?將從兩個維度出發，從根本上改進多副本復制。一個是保證數據庫?ACID?中的 D（Durable），把網絡、存儲硬件提供的?DMA?能力串起，用硬件通道高性能的把主庫的日志數據持久化到三個存儲節點的磁盤中；另一個是實現了高效的只讀節點，在主庫和只讀節點之間通過物理復制同步數據，直接更新到只讀節點的內存里。
POLARDB?實現日志數據持久化到三個存儲節點的磁盤中。主庫通過?RDMA?將日志數據發送到存儲節點的內存中，存儲節點之間再通過?RDMA?互相復制，每個存儲節點用?SPDK?將數據寫入?NVMe?接口的存儲介質里，整個過程?CPU?不用訪問被同步的數據塊（Payload），實現數據零拷貝。
同時由?RDMA?網卡和?NVMe?控制器完成數據傳輸和持久化，CPU?僅做狀態機的維護，在一致性協議的協調下，把網卡和存儲卡兩塊硬件串起來，存儲節點之間數據同步采用?ParallelRaft 協議，和?Raft?協議一樣，決議在?leader?節點上是串行生成和提交的，但?ParallelRaft?協議可以允許主從之間亂序同步，簡單的說，允許?follower?節點在漏掉若干條日志的情況先?commit?并?apply?后面過來的日志，并異步的去補之前漏掉的日志，數據同步的性能和穩定性都顯著優于?Raft?協議。
POLARDB?在主庫和只讀實例之間的數據流上，放棄了基于?binlog?的邏輯復制，而是基于?innodb?的?redolog?實現了物理復制，從邏輯復制到物理復制對主庫和從庫性能帶來的提升都非常明顯。
在主庫上，原本引擎需要和?binlog?做?XA?事務，事務要等到?binlog?和?redolog?同時寫盤后才能返回，去掉?binlog?后，XA?事務可以去掉，事務的執行路徑更短，IO?開銷也更小。在從庫上，redolog?由于是物理復制，僅需比對頁面的?LSN?就可以決定是否回放，天然可以多線程執行，數據的正確性也更有保證，此外，POLARDB?的從庫收到?redolog?后只需要更新緩存里的頁面，并不需要寫盤和?IO?操作，開銷遠低于傳統多副本復制里的從庫。
?
針對數據庫加速的?Smart Storage
POLARDB?的存儲節點針對數據庫的?IO workload?進行了一些針對性的優化。
IO?優先級優化：POLARDB?在文件系統和存儲節點兩層都開了綠色通道，對?redolog?文件的更新進行優待處理，減少排隊，提高?IO?的優先級。redolog?也從?512?對齊調整為?4k?對齊，對?SSD?性能更加友好。
double write 優化：POLARDB?存儲節點原生支持?1MB?的原子寫，因此可以安全關閉 double write?，從而節省了近一倍的?IO?開銷。
group commit?優化：POLARDB?里一次?group commit?可以產生寫入幾百?KB?的單個大?IO。對于單個?SSD，延遲和?IO?的大小是呈線性的，而??POLARDB??從文件系統到存儲節點都進行一系列優化來保證這種類型的?IO?能盡快刷下去，針對?redolog?文件進行條帶化，將一個上百?KB?的大?IO?切割為一批?16KB?的較小?IO，分發到多個存儲節點和不同的磁盤上去執行，進一步的降低關鍵?IO?路徑的延遲。
?
?
POLARDB?的計算引擎性能優化
使用共享存儲物理復制
由于?POLARDB?使用共享存儲和物理復制，實例的備份恢復也做到完全依賴?redolog，因此去掉了?binlog。使得單個事務對?IO 的消耗減少，有效減少語句響應時間，提升吞吐量。同時避免了引擎需要與?binlog?做的?XA?事務邏輯，事務語句的執行路徑更短。
?
鎖優化
POLARDB?針對高并發場景，對引擎內部鎖做了大量優化，比如把?latch?分解成粒度更小的鎖，或者把?latch?改成引用計數的方式從而避免鎖競爭，例如?Undo segment mutex，?log system mutex?等等。PolarDB?還把部分熱點的數據結構改成了?Lock Free?的結構，例如?Server?層的?MDL?鎖。
?
日志提交優化
Redolog?的順序寫性能對數據庫性能的影響很大，為了減少?Redolog?切換時對性能的影響，我們后臺采用類似?fallocate?的方式預先分配日志文件，此外，現代的?SSD?硬盤很多都是?4K?對齊，而?MySQL?代碼還是按照早期磁盤?512?字節對齊的方式刷日志的，這樣會導致磁盤做很多不必要的讀操作，不能發揮出?SSD?盤的性能，我們在這方面也做了優化。我們對日志提交時?Group Commit?進行優化，同時采用?Double RedoLog Buffer?提升并行度。
?
復制性能
POLARDB?中物理復制的性能至關重要，我們不僅通過基于數據頁維度的并行提高了性能，還對復制中的必要流程進行了優化，例如在?MTR?日志中增加了一個長度字段，從而減少了日志?Parse?階段的?CPU?開銷，這個簡單的優化就能減少?60%?的日志解析時間。我們還通過復用?Dummy Index?的內存數據結構，減少了其在?malloc / free?上的開銷，進一步提高復制性能。
?
讀節點性能
POLARDB?的?Replica?節點，日志目前是一批一批應用的，因此當新的一批日志被應用之前，Replica?上的讀請求不需要重復創建新的?ReadView，可以使用上次緩存下來的。這個優化也能提高?Replica?上的讀性能。
?
?
如何降低成本
存儲資源池化
POLARDB?采用了一種計算和存儲分離的架構，DB?運行在計算節點，計算節點組成了一個計算資源池，數據都放在存儲節點上，存儲節點組成了一個存儲資源池。如果?CPU?和內存不夠了，就擴充計算資源池，如果容量或者?IOPS?不夠了，就擴充存儲資源池，兩個池子都是按需擴容。而且存儲節點和計算節點可以分別向兩個方向優化，存儲節點會選擇低配的?CPU?和內存，提高存儲密度，而計算節點可以選擇小容量、低配的?SSD?作為操作系統和日志盤，上多路服務器增加?CPU?的核數。
而傳統的數據庫部署模型則是一種煙囪模型，一臺主機既跑數據庫又存數據，這帶來兩個問題。一個是機型難以選擇，CPU?和磁盤的配比主要取決于實際業務的需求，很難提前找到最優比例。第二是磁盤碎片問題，一個生產集群里，總有部分機器磁盤使用率是很低的，有的還不到?10%，但出于業務穩定性要求，會要求獨占主機的?CPU，這些機器上的?SSD?其實是被浪費的。通過存儲資源池化，這兩個問題都能得到解決，SSD?的利用率得到提高，成本自然也降低下來。
?
透明壓縮
POLARDB?的存儲節點除了對?ibd?文件提供?1MB?的原子寫，消除?double write?的開銷，還支持對?ibd?文件的數據塊進行透明壓縮，壓縮率可以達到?2.4?倍，進一步降低了存儲成本。
而傳統數據庫在?DB?內進行壓縮的方案相比，存儲節點實現透明壓縮不消耗計算節點的?CPU，不影響?DB?的性能，利用?QAT?卡進行加速，以及在?IO?路徑上用?FPGA?進行加速。POLARDB?的存儲節點還支持快照去重（dedup）功能，數據庫的相鄰快照之間，如果頁面沒有發生修改，會鏈接到同一份只讀頁面上，物理上只會存儲一份。
?
0 存儲成本的只讀實例
傳統數據庫做只讀實例，實施一寫多讀方案，是通過搭建只讀副本的方案，先拷貝一個最近的全量備份恢復一個臨時實例，再讓這個臨時實例連接主庫或者其他?binlog?源同步增量數據，增量追上后，把這個臨時實例加到線上升級為一個只讀副本。這種方法一個是耗時，搭建一個只讀實例需要的時間與數據量成正比；另一方面也很昂貴，需要增加一份存儲成本，比如用戶購買一個主實例加上五個只讀實例，需要付 7~8 份存儲的錢（ 7 份還是 8 份取決于主實例是兩副本還是三副本）。
而在?PolarDB?架構中，這兩個問題都得到解決，一方面新增只讀實例不需要拷貝數據，不管數據量有多大都可以在?2?分鐘內創建出來；另一方面，主實例和只讀實例共享同一份存儲資源，通過這種架構去增加只讀副本，可以做到零新增存儲成本，用戶只需要支付只讀實例消耗的?CPU?和內存的費用。
?
?
參考：Cloud-Native Database Systems at Alibaba: Opportunities?and Challenges https://www.zhihu.com/question/63987114/answer/244520478
https://yq.aliyun.com/articles/214367
總結
以上是生活随笔為你收集整理的阿里云原生数据库：POLARDB的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 分布式事务——TCC 原理
- 下一篇： 在知乎引发众多分布式数据库大佬争相回答的