云數據庫實現計算存儲分離，支持計算與存儲的獨立擴展，其用戶還可以享受按量付費等特性。這使得基于云數據庫的系統更加高效、靈活。因此，構建并使用云原生數據庫的勢頭愈演愈烈。另一方面，云化存儲服務已經是云的標準能力，存儲側提供兼容通用的文件接口，并且不對外暴露持久化、容錯處理等復雜細節，其易用性和規模化帶來的高性價比使得云存儲成為了云上系統的第一選擇。在通用云存儲服務上構建云數據庫，無疑是一種既能夠享受規模化云存儲紅利，又能夠通過可靠云存儲服務實現降低維護成本、加速數據庫開發周期的方案。 然而，考慮到云存儲和本地存儲之間的特性差異，在將本地數據庫遷移到云上構建云數據庫時，如何有效使用云存儲面臨了許多挑戰。對此，我們在論文里分析了基于B-tree和LSM-tree的存儲引擎在云存儲上部署時面臨的挑戰，并提出了一個優化框架CloudJump，以希望能夠幫助數據庫開發人員在基于云存儲構建數據庫時使系統更為高效。我們以云原生數據庫PolarDB為案例，展示了一系列針對性優化，并將部分工作擴展應用到基于云存儲的RocksDB上，以此來演示CloudJump的可用性。

背景 我們討論的云存儲主要基于彈性分布式塊存儲，云中其他類型的存儲服務，例如基于對象的存儲，不在本文的討論范圍內。共享云存儲（如分布式塊存儲服務加分布式文件系統）可以作為多個計算節點的共享存儲層，提供QoS（服務質量）保證、大容量、彈性和按量付費定價模型。對于大多數云廠商和云用戶來說，擁有云存儲服務比構建和維護裸機SSD集群更有吸引力。因此，與其為云本機數據庫構建和優化專用存儲服務，不如利用現有云存儲服務構建云本機數據庫，這是一種非常可行的選擇。此外，隨著云存儲服務幾乎實現了標準化，相應的開發、遷移變得更加快速。

圖1展示了本地數據庫（不含備份）與shared-storage云原生數據庫的系統結構，AWS Aurora首先引導了這種從本地數據庫向shared-storage云原生數據庫的遷移。它將數據庫分為存儲層和計算層，并可以獨立擴展每一層。為了消除了傳輸數據頁中產生的沉重的網絡開銷，它進一步定制了存儲層，在數據頁上應用重做日志，從而不再需要在兩層之間傳輸數據頁。無疑這種設計在云中提供了一種非標準存儲服務，只能由Aurora的計算層使用。 另一種方案是依賴標準化接口的云存儲服務遷移或構建獲得云數據庫，這也是本文的研究目標。前面已經提到過，這樣做的優勢主要在于的可以實現系統的快速開發、平滑遷移、收納標準化規模化存儲服務的原有優勢等。此外，特別是在我們項目（PolarDB）的硬件環境、已有背景下，兼顧服務可靠性和開發迭代需求，針對進行云存儲服務特性進行性能優化是最迫切的第一步。

挑戰與分析 云存儲和本地SSD存儲在帶寬、延遲、彈性、容量等方面存在巨大差異，例如圖2展示了在穩態條件下本地SSD與云存儲I/O延時、帶寬與工作線程關系，它們對數據庫等設計有著巨大影響。此外，共享存儲的架構特性也會對云存儲帶來影響，如多個節點之間的數據一致性增加了維護cache一致性開銷。

通過系統實驗、總結分析等，我們發現CloudJump面臨以下技術挑戰：

遠程分布式存儲集群的訪問導致云存儲服務的I/O延遲高；

通常聚合I/O帶寬未被充分利用；

在具有本地存儲的單機上運行良好但需要適應云存儲而導致特性改變的傳統設計，例如文件cache緩存；

長鏈路導致各種數據庫I/O操作之間的隔離度較低（例如，日志刷寫與大量數據I/O的競爭）；

云用戶允許且可能使用非常大的單表文件（例如數十TB）而不進行數據切分，這加劇了I/O問題的影響。

針對不同的數據存儲引擎，如基于B-tree和LSM-tree的存儲引擎，這些特性差異會帶來不同的性能差異，表1歸納總結了這些挑戰及其對數據庫設計的影響。其中有共性問題，如WAL路徑寫入變慢、共享存儲（分布式文件系統）cache一致性代價等；也有個性問題，如B-tree結構在獨占資源情況下做遠程I/O、遠程加劇I/OLSM-tree讀放大影響等。

優化原則 CloudJump針對上述挑戰，提出7條優化準則：

Thread-level Parallelism：例如依據I/O特性實驗，采用（更）多線程的日志、數據I/O線程及異步I/O模型，將數據充分打散到多個存儲節點上。

Task-level Parallelism：例如對集中Log buffer按Page Partition分片，實現并行寫入并基于分片進行并行Recovery。

Reduce remote read and Prefetching：例如通過收集并聚合原分散meta至統一的superblock，將多個I/O合一實現fast validating；通過預讀利用聚合讀帶寬、減少讀任務延時；通過壓縮、filter過濾減少讀取數據量。與本地SSD上相比，這些技術在云存儲上更能獲得收益。

Fine-grained Locking and Lock-free Data Structures：云存儲中較長的I/O延遲放大了同步開銷，主要針對Update-in-place系統，實現無鎖刷臟、無鎖SMO等。

Scattering among Distributed Nodes：在云存儲中，多個節點之間的分散訪問可以利用更多的硬件資源，例如將單個大I/O并發分散至不同存儲節點 ，充分利用聚合帶寬。

Bypassing Caches：通過Bypassing Caches來避免分布式文件系統的cache coherence，并在DB層面優化I/O格式匹配存儲最佳request格式。

Scheduling Prioritized I/O Tasks：由于訪問鏈路更長（如路徑中存在更多的排隊情況），不填I/O請求間的隔離性相對本地存儲更低，因此需要在DB層面對不同I/O進行打標、調度優先級，例：優先WAL、預讀分級。

實踐案例

實踐案例：PolarDB

PolarDB構建基于具有兼容Posix接口的分布式文件系統PolarFS，與Aurora一樣采用計算存儲分離架構，借助高速RDMA網絡以及最新的塊存儲技術實現超低延遲和高可用能力能力。在PolarDB上，我們做了許多適配于分布式存儲特性、符合CloudJump準則的性能優化，大幅提升了云原生數據庫PolarDB的性能。

1. WAL寫入優化 WAL（Write ahead log）寫入是用于一致性和持久性的關鍵路徑，事務的寫入性能對log I/O的延遲非常敏感。原生InnoDB以MTR（Mini-Transaction）的粒度組織日志，并保有一個全局redo日志緩沖區。當一個MTR被提交時，它緩存的所有日志記錄被追加到全局日志緩沖區，然后集中的順序刷盤以保證持久化特性。這一傳統集中日志模式在本地盤上工作良好，但使用云存儲時，集中式日志的寫入性能隨著遠程I/O時延變高而下降，進而影響事務寫入性能。基于云存儲的特性，我們提出了兩個優化來提升WAL的寫入性能：日志分片和（大）I/O任務并行打散。

Redo日志分片：InnoDB的redo采用的是Physiological Logging的方式，大部分MTR針對單個的數據頁（除部分特殊），頁之間基本相互獨立。如圖5（左），我們將redo日志、redo緩沖區等按其修改的page進行分片（partition），分別寫入不同的文件中，來支持并發寫log（以及并發Recovery，并發物理復制等），從而在并發寫友好的分布式文件系統上的獲得寫入性能優勢。 I/O任務并行打散：在云存儲中，一個文件由多個chunk組成，根據chunk的分配策略，不同chunk很可能位于不同的存儲節點中。我們將每個redo分片（partition）的文件進一步拆分為多個物理分片（split），如圖5（右）所示，對于單個大log I/O任務（如group commit、BLOB record等），log writer會將I/O按lsn切片并且并發的分發I/O請求至不同split。通過這種方式，可以將大延時的log I/O任務拆分，并利用分布式存儲高分布寫特性來減少整體I/O時間。 2. 快速恢復 為了實現快速恢復，我們提出了兩個優化：快速（啟動）驗證和全并行恢復。

在InnoDB的原有恢復過程中，InnoDB首先在啟動期間會打開所有文件讀取元信息（如文件名、表ID等）并驗證正確性，然后通過ARIES風格的恢復算法重做未checkpoint的數據。為了加速啟動，快速驗證方法不會掃描所有文件，而是在數據庫的生命周期中記錄和集中必要的元信息，并在創建、修改文件時將必要的元信息集中記錄在一個superblock中，在啟動時僅掃描元數據塊文件。因此，減少了啟動掃描過程中的遠程I/O訪問開銷。其次，依賴于Redo日志分片，我們將log file按page拆分成多個文件，在恢復階段（可以進一步劃分為parse、redo、undo三個階段），可以天然的支持并發parse和redo（undo階段在后臺進行），通過并發任務充分調動CPU和I/O資源加速恢復。

3. 預讀取

在云存儲環境下，讀I/O延時大大增加，當用戶任務訪問數據發生cache miss的情況下，而有效的預讀取能夠充分利用聚合讀帶寬來減少讀任務延時。InnoDB中有線性預讀和非線性預讀兩種原生的物理預讀方法，我們進一步引入了邏輯預讀策略（由于無序的插入和更新，索引在物理上不一定是順序的）。例如對于主索引掃描，當任務線程從起始鍵順序掃描索引超過一定閾值時，邏輯預讀會在主索引上按邏輯順序觸發異步預讀，提前讀取一定量的順序頁。又如對于具有二級索引和非索引列回表操作的掃描，在對二級索引進行掃描同時批量收集相關命中的主鍵，積累一定批數據后觸發異步任務預讀對應主索引數據（此時剩余的二級索引掃描可能仍在進行中）。

4. 同步（鎖）優化

相關背景可以先查閱《InnoDB btree latch 優化歷程》[1]這篇文章。
無鎖刷臟：原生InnoDB在刷臟時需要持有當前page的sx鎖，導致I/O期間當前page的寫入被完全阻塞。而在云存儲上I/O延遲更高，阻塞時間更久。我們采用shadow page的方式，首先對當前page構建內存副本，構建好內存副本后原有page的sx鎖被釋放，然后用這個shadow page內容去做刷臟及相關刷寫信息更新。

SMO加鎖優化：在InnoDB 里面, 依然有一個全局的index latch, 由于全局的index latch 存在會導致同一時刻在Btree 中只有一個SMO 能夠發生, index latch 依然會成為全局的瓶頸點。上述index latch不僅是計算瓶頸，而從另一方面考慮，鎖同步期間index上其他可能I/O操作無法并行，存儲帶寬利用率較低。相關實現可以參考文章《路在腳下, 從BTree 到Polar Index》[2]。

5. 多I/O任務隊列適配

針對云存儲具有I/O隔離性低的挑戰，同時為了避免云存儲無法識別DB層存儲內核的I/O語義，而造成優先級低的I/O請求（如page刷臟、低優先級預讀）影響關鍵I/O路徑的性能，在數據庫內核中提供合理的I/O調度模型是很重要的。在 PolarDB 中，我們在數據庫內核層為不同類型的I/O請求進行調度，實現根據當前I/O壓力實現數據庫最優的性能，每個I/O請求都具有 DB 層的語義標簽，如 WAL 讀/寫，Page 讀/寫。

我們為數據庫的異步I/O請求建立了多個支持并發寫入的生產者 / 消費者隊列，并且其存在三種不同特性的隊列，分別為 Private 隊列，Priority 隊列，以及 General 隊列，不同隊列的數量是根據當前云存儲的I/O能力決定的。

正常情況下，WAL 的寫入只通過其 Private 隊列，當寫入量增大時，其I/O請求也會轉發至 Priority 隊列，此時 Priority 隊列會優先執行 WAL 的寫入，并且后續Page寫入的I/O不會進入 Priority 隊列。基于這種I/O模型，我們保證了一定部分的I/O資源時預留給WAL寫入，保證事務提交的寫入性能，充分利用云存儲的高聚合帶寬。此外，I/O任務隊列的長度和數目也進行了拓展以一步匹配云存儲高吞吐、大帶寬但時延較高且波動大的特性。

6. 格式化I/O請求

云存儲和本地存儲在I/O格式上具有顯著的不同，例如 Block 大小，I/O請求的發起方式。在大多數分布式的云存儲中，在實現多個計算節點的共享時，為了避免維護計算節點 cache 一致性的問題，不存在 page cache，此時采用原先本地存儲的I/O格式在云上會造成例如 read-on-write 和邏輯與物理位置映射的問題，造成性能下降。在 PolarDB中，我們為WAL I/O和 Page I/O匹配了適應云存儲的請求I/O格式以盡可能降低單個I/O的延時。

WAL I/O對齊：文件是通過固定大小的 block 進行讀寫的。云存儲具有更大的 block size （4-128 KB），傳統的 log 對齊策略不適合云存儲上的 stripe boundary。我們在 log 數據進行提交的時候，將I/O請求的長度和偏移與云存儲的 block size進行對齊。

Data I/O對齊：例如當前存在兩種類型的數據頁：常規頁和壓縮頁，常規頁為16 KB，可以很容易與云存儲的 Block size 進行對齊，但是壓縮頁會造成后續大量的不對齊I/O。以PolarDB 中對于壓縮頁的對齊為例。首先，我們讀取時保證以最小單位（如PolarFS的4 KB）讀取。而在寫入時，對于所有小于最小訪問單元的壓縮頁數據，我們會拓展到最小單位再進行寫入，以保證存儲上的頁數據都是最小單位對齊的。

去除 Data I/O合并：在本地數據庫中，數據頁的I/O會被合并來形成大的I/O實現連續地順序寫入。在云存儲中，并發地向不同存儲節點寫入具有更高的性能，因此在云存儲的數據庫上，可以無需數據頁的I/O合并操作。

受篇幅所限，我們在本文中只簡單介紹所提優化方法的大致實現邏輯，具體實現細節請讀者查閱論文及相關文章。

為了驗證我們的優化效果, 我們對比了為針對云存儲優化的MySQL 分別運行在PolarStore 和 Local Disk, 以及我們優化以后的PolarDB, 從下圖可以看到PolarDB 在CPU-bound, IO-bound sysbench, TPCC 等各個場景下都表現除了明顯的性能優勢。

同時, 為了證明我們的優化效果不僅僅對于我們自己的云存儲PolarStore 有收益, 對于所有的云存儲應該都有收益, 因此我們將針對云存儲優化的PolarDB 運行在 StorageX, ESSD 等其他云存儲上, 我們發現均能獲得非常好的性能提升, 從而說明我們的優化對于大部分云存儲都是有非常大的收益

實踐案例：RocksDB

我們還將CloudJump的分析框架和部分優化方法拓展到基于云存儲的RocksDB上，同樣獲得了預計的性能收益。

1. Log I/O任務并行打散

RocksDB同樣使用集中WAL來保證進程崩潰的一致性，集中日志收集多個column family的日志記錄并持久化至單個日志文件。考慮到LSM-Tree只需要恢復尾部append-only的數據塊，我們采用在上一個案例中提到的log I/O并行打散的方法在log writer中切分批日志并且并行分發到不同文件分片中。

2. 數據訪問加速

在RocksDB中有許多加速數據訪問的技術，主要有prefetching, filtering 和compression機制。考慮到云存儲的特性，這些技術（經過適當改造）在云存儲環境中更有價值。經過分析和實驗，我們提出了以下建議：1）預讀機制能加速部分查詢和compaction操作，建議compaction操作開啟預讀并設定合理的預讀I/O任務優先級，并將單個預讀操作的大小對齊存儲粒度，對于查詢操作預讀應由用戶場景確定；2）在云存儲上建議開啟bloom filters，并且將filter的meta和常規數據分離，將filter信息并集中管理；3）采用塊壓縮來減小數據訪問的整體用時，如下表展示了數據量和PolarFS訪問延時，表中存儲基于RDMA，在延遲更高的存儲環境中，壓縮收益更高，引入壓縮后數據訪問的整體延時（特別是讀延時）下降。

3. 多I/O任務隊列及適配

在多核硬件環境中，我們引入了一個多隊列I/O模型并在RocksDB中拆分I/O任務和工作任務（例如壓縮作業和刷新作業）。這是因為我們通過調整I/O線程的數量來控制較好吞吐和延遲關系。由于將I/O任務與后臺刷寫作業分離，因此無需進一步增加刷寫線程的數量，刷寫線程只會對齊I/O請求并進行調度分發。RocksDB本身提供了基于線程角色的優先級調度方案，而我們的調度方法這里是基于I/O標簽。

我們根據云存儲調整I/O請求和數據組織（例如block和SST）的大小，并進行更精確的控制，以使SST文件過濾器的塊大小也正確對齊。以PolarFS為例，存儲的最小請求大小為4 KB（表示最小的處理單元），理想的請求大小為16 KB的倍數（不造成read-on-write），元數據存儲粒度為4 MB。SST大小和塊大小分別嚴格對齊存儲粒度和理想請求大小的倍數。原生RocksDB也有對齊策略，我們在此需要進行存儲參數適配并且對壓縮數據塊也進行對齊。

我們不會向多隊列I/O模型傳遞小于最小請求大小的I/O請求，而是對齊最小I/O大小，并將未對齊的后綴緩存在內存中以供后續對齊使用。其次，我們不會下發單個大于存儲粒度的I/O請求，而是通過多隊列I/O模型執行并行任務（例如一個6 MB的I/O會分散成4 MB加1 MB的兩個任務）。這不僅可以將數據盡可能分散在不同的存儲節點上，還可以最大限度地提高并行性以充分利用帶寬。

4. I/O對齊

在所有日志和數據I/O請求排入隊列前，對其的大小和起始offset進行對齊。對于WAL寫入路徑，類似于PolarDB的log I/O對齊。對于數據寫入路徑，在采用數據壓縮時，LSM樹結構可能會有大量未對齊的數據塊。例如要刷寫從1 KB開始的2 KB日志數據時，它將從內存緩存的數據中填充前1 KB（對于append-only結構通過保存尾部數據緩存實現，這是與update-in-place結構直接拓展原生頁至最小單位的不同之處），并在3-4 KB中附加零，然后從0 KB起始發送一個4 KB的I/O。

總結

在這項論文工作中，我們分析了云存儲的性能特征，將它們與本地SSD存儲進行了比較，總結了它們對B-tree和LSM-tree類數據庫存儲引擎設計的影響，并推導出了一個框架CloudJump來指導本地存儲引擎遷移到云存儲的適配和優化。并通過PolarDB, RocksDB 兩個具體Case 展示優化帶來的收益。

審核編輯 ：李倩