作者：柯煜昌 顧問軟件工程師
目前從事 RadonDB 容器化研發(fā)，華中科技大學研究生畢業(yè)，有多年的數(shù)據(jù)庫內核開發(fā)經(jīng)驗。
你將 Pick 這些內容：
- 云原生的概念
- 云原生數(shù)據(jù)庫的概念
- 兩種主流技術路線分析
- 六種云原生數(shù)據(jù)庫方案和功能介紹
- 云原生數(shù)據(jù)庫的核心功能和價值
背景
隨著云計算的蓬勃發(fā)展，IT 應用轉向云端，云服務出現(xiàn)如下若干特點：
- 提供按需服務；
- 用戶只愿支付運營費用而不愿支付資產(chǎn)費用；
- 云服務提供商集群規(guī)模越來越大，甚至遍布全球，集群達到云級規(guī)模（Cloud-Scale）。
根據(jù)以上特點，要求云產(chǎn)品需要提供一定 “彈性”（Elastic），而且達到云級規(guī)模；節(jié)點故障如同噪聲” 一樣不可避免，這又要求云服務有一定的 “自愈”（Resilience）能力。
起初，通過借助 IaaS，直接將傳統(tǒng)的數(shù)據(jù)庫 “搬遷” 到云上，于是出現(xiàn)了關系型數(shù)據(jù)庫服務（RDS）。這樣雖然能部分實現(xiàn) “彈性” 與 “自愈”，但是這種方案存在資源利用率低，維護成本高，可用性低等問題。于是，設計適應云特點的云原生數(shù)據(jù)庫就至關重要。
RDS 的挑戰(zhàn)
以 MySQL 為例，如果要實現(xiàn)高可用或者讀寫分離集群，則需要搭建 binlog 復制集群。
如上圖所示，除了頁寫入與 double write，redo log 寫入操作外，還有 binlog 與 relay log 的寫入。
| 缺陷 | 說明 |
|---|---|
| 寫放大嚴重 | 如果以上架構中，F(xiàn)ileSystem 部署在分布式文件系統(tǒng)中，頁的寫操作，會因為副本復制的機制將 IO 放大，最后 IO 延遲也會放大。 |
| 資源浪費嚴重 | 1. binlog 復制是為了適配 MySQL 所有存儲引擎，屬于邏輯復制。本質是將 SQL 在從實例執(zhí)行（除了沒有主實例的鎖爭用外，其他代價幾乎一樣），效率不高，也浪費了 CPU 與內存的資源。 2. 擴展集群的計算能力時，不得不同時擴展存儲空間，導致磁盤資源的浪費。 |
| 備份恢復慢 | 無論是物理備份/恢復，還是邏輯備份/恢復，備份操作均會上鎖，影響正常業(yè)務進行，并且，備份恢復的時間也隨著存儲容量的增大而線性增長。 |
| 擴展代價大 | 1. 新增從實例，首先要從備份中恢復數(shù)據(jù)，然后應用binlog以達到與主實例一致的狀態(tài)。這個過程耗時取決于恢復的時間以及binlog日志應用的時間，數(shù)據(jù)量大、數(shù)據(jù)狀態(tài)過時的情況下，耗時費力而且不保證正確。彈性能力有限。 2. 存儲容量受限于單機存儲容量，無法自由擴展。 |
| 可用性低 | Aurora[1]指出，在高規(guī)模的集群環(huán)境中，軟件或者硬件故障如同“背景噪聲”那樣不可避免，并且縮短平均故障間隔時間（MTTF）是非常困難的，可行的方法是減少平均恢復的時間（MTTR）從而達到高可用性。 如上所示，RDS 仍然是傳統(tǒng)的備份恢復的方法修復故障，如果數(shù)據(jù)量大的話，可能是數(shù)小時，超過平均故障時間間隔（Aurora 是 10s），出現(xiàn)更多節(jié)點故障，可能使得共識算法無效（超過半數(shù)），可用性就大大打折扣。 |
| 運維成本高 | 備份/恢復與擴展，均需要專業(yè) DBA 團隊運維，每個步驟出現(xiàn)錯誤需要人工檢查。 |
云原生數(shù)據(jù)庫簡介
為了解決以上問題，需要針對云上服務的特點，改造或者開發(fā)新一代云數(shù)據(jù)庫，這便是云原生數(shù)據(jù)庫。
| 特點 | 說明 |
|---|---|
| 計算存儲分離 | 對存儲與計算進行解耦合，實現(xiàn)存儲與計算分離。 |
| 無狀態(tài) | 計算節(jié)點無狀態(tài)或較少狀態(tài)。 |
| 存儲集群靈巧化 | 采用小存儲塊方式組織副本，用以減少平均恢復時間，多副本共識算法，實現(xiàn)存儲的高可用與故障“自愈”能力。 |
通過解耦合與少狀態(tài)，計算節(jié)點擴展就會很輕量，擴展速度近乎進程啟動的速度。避免擴展計算資源的時候，不得不浪費存儲資源的窘境。
解耦合也使得存儲節(jié)點也少了一定的約束，可以使用成熟的分布式存儲技術實現(xiàn)靈巧化，降低運維成本提高可用性。
接下來將介紹目前兩種主流的技術路線和幾種知名的方案。
1 Spanner 類
以 Google 的 Spanner[2] 為代表，基于云原生開發(fā)全新的數(shù)據(jù)庫。受其影響，產(chǎn)生了CockrochDB、TiDB、YugabyteDB 等產(chǎn)品。
1.1 架構
以 TiDB[3] 架構圖為例：
總體來說，此類產(chǎn)品其特點都是在 key-value 存儲基礎上包裝一層分布式 SQL 執(zhí)行引擎，使用 2PC 提交或者其變種方案實現(xiàn)事務處理能力。計算節(jié)點是 SQL 執(zhí)行引擎，可以徹底實現(xiàn)無狀態(tài)，本質是一個分布式數(shù)據(jù)庫。
1.2 存儲高可用性
Spanner 將表拆分為 tablet，以 tablet 為單位使用多副本 + Paxos 算法 實現(xiàn)。
TiDB 為 Region 為單位使用多副本 + Multi-Raft 算法，而 CockroachDB 則采用 Range 為單位進行多副本，共識算法也是使用 Raft。
Spanner 中 key-value 持久化方案，邏輯上仍然是基于日志復制的狀態(tài)機模型（log-replicated state machines）上再加共識算法實現(xiàn)。
1.3 優(yōu)缺點
| 說明 | |
|---|---|
| 優(yōu)點 | 1. 徹底的 Share-Nothing 2. 號稱全球部署 3. 使用 key-value 結構與 LSM 樹，以及日志復制自動機機制，天然無寫放大效應 4. 不需要人為分庫分表，有很好的橫向擴展能力 |
| 缺點 | 1. 全新開發(fā)工作量大，技術不算成熟 2. 性能不佳 3. 事務處理能力有限 ?3.1 在內存中處理事務沖突，有沖突的需要讀寫等待或者提交等待。 ?3.2 如：Spanner 對有沖突的事務 TPS 能力最大只有 125 4. SQL 支持能力有限 ?4.1 如：YugabyteDB 不支持 Join 語句 |
2 Aurora 類
Aurora 是亞馬遜推出的云原生數(shù)據(jù)庫。與 Google 的技術路線不同，Aurora 是傳統(tǒng)的 MySQL（PostgreSQL）等數(shù)據(jù)庫進行計算與存儲分離改造，進而實現(xiàn)云原生的需求，但其本質仍然是單體數(shù)據(jù)庫的讀寫分離集群。
Aurora 論文對 Spanner 的事務處理能力并不滿意，認為它是為 Google 重讀（read-heavy）負載定制的數(shù)據(jù)庫系統(tǒng)[1] 。這種方案得到一些數(shù)據(jù)庫廠商的認同，出現(xiàn)了微軟 Socrates、阿里PolarDB、騰訊 CynosDB、極數(shù)云舟 ArkDB 以及華為 TarusDB 云原生數(shù)據(jù)庫等。
2.1 架構
Aurora 架構如下：
下圖綠色部分為日志流向。
由于傳統(tǒng)數(shù)據(jù)庫持久化最小單位是一個物理頁，哪怕修改一行，持久化仍然是一個頁，加上需要寫 redo 日志與 undo 記錄，本身就存在一定的寫放大問題。如果機械的將文件系統(tǒng)替換成使用分布式文件系統(tǒng)，并且為了實現(xiàn)高可用采用多副本，則寫放大效應進一步放大，導致存儲網(wǎng)絡成為瓶頸而性能無法接受。
Aurora 繼承了 Spanner 的日志持久化的思想，甚至激進提出“日志即數(shù)據(jù)庫”的口號，其核心思想是存儲網(wǎng)絡盡量傳輸日志流，對于讀操作，存儲網(wǎng)絡傳輸數(shù)據(jù)頁在所難免，但是計算節(jié)點可以通過 buffer pool 來優(yōu)化。
它對傳統(tǒng)數(shù)據(jù)庫進行了如下改造：
- 數(shù)據(jù)庫主實例變成計算節(jié)點，數(shù)據(jù)庫主實例不再進行刷臟頁動作，僅僅向存儲寫日志，存儲應用日志實現(xiàn)持久化，即日志應用下沉到存儲。數(shù)據(jù)庫主實例沒有后臺寫動作，沒有 cache 強制刷臟替換，沒有檢查點；
- 數(shù)據(jù)庫復制實例獲取日志內容，通過日志應用更新自身的 buffer/cache 等內存對象；
- 主實例與復制實例共享存儲；
- 將崩潰恢復，備份、恢復、快照功能下放到存儲層。
并且，以原有 S3 存儲系統(tǒng)為基礎，對存儲進行如下改造：
- 將存儲分段（Segment），以 10G 作為分段單位大小, 每個分段共六個副本，部署于三個可用區(qū)（Available Zone），每個可用區(qū)兩個副本，Aurora 將這六個分段稱為一個保護組（Protection Group，PG），實現(xiàn)高可用。
- 存儲節(jié)點能接收日志記錄應用來實現(xiàn)數(shù)據(jù)庫物理頁的持久化，并且使用 Gossip 協(xié)議同步各個副本間的日志。
存儲能提供多版本物理頁，用以適配多個復制實例的延遲。并且后臺有歷史版本頁面回收線程。
持久化頁存儲流程圖如下：
2.2 高可用
Aurora 采用仲裁協(xié)議（Quorum）多數(shù)派投票方式來檢測故障節(jié)點。這種高可用的前提是，10G 分段恢復時間為 10 秒，而 10 秒內出現(xiàn)第二個節(jié)點故障的可能性幾乎為 0。
它采用 3 個可用區(qū)，可以形成 4/6 仲裁協(xié)議（6 個節(jié)點，寫需 4 個投票，讀需 3 個投票）。最壞情況是某個可用區(qū)出現(xiàn)災害（地震，水災，恐怖襲擊等）時，同時隨機出現(xiàn)一個節(jié)點故障，此時仍然有 3 個副本，可以使用 2/3 仲裁協(xié)議（3 個節(jié)點，寫需 2 個投票，讀需 2 個投票）繼續(xù)保持高可用性（AZ+1 高可用）。
| 說明 | |
|---|---|
| 優(yōu)點 | 1. 在成熟的數(shù)據(jù)庫系統(tǒng)進行改造，技術相對成熟穩(wěn)定、工作量小 2. 事務處理能力，性能能保持傳統(tǒng)數(shù)據(jù)庫的優(yōu)勢 |
| 缺點 | 1. 本質仍然是改良的讀寫分離集群 2. 有修改一行寫一個頁的寫放大問題，需要小心處理 3. 需要 proxy 等組件才能支持分布式事務 |
3 CynosDB 方案
CynosDB[9] 幾乎復刻了 Aurora 的實現(xiàn)方式。
但是有其自身的特點：
- 存儲多副本之間用 Raft 算法保證高可用，Raft 算法包含了 Quorum 仲裁算法，而且更加靈活；
- 與 Aurora 一樣，主從計算節(jié)點通過網(wǎng)絡傳輸 redo 日志，同步雙方的 buffer cache 以及其他內存對象。
4 PolarDB 方案
PolarDB[5] 也是存儲與計算分離架構，但與 Aurora 最大的不同，就是沒有將 redo 日志下放到存儲進行處理，計算節(jié)點仍然要向存儲寫物理頁，僅主實例與復制實例之間使用 redo 日志進行物理復制同步 buffer pool [4]、事務等其他內存對象，使用現(xiàn)有的分布式文件系統(tǒng)，不對其進行改造。
PolarDB 目前集中于分布式文件系統(tǒng)優(yōu)化（PolarFS），以及查詢加速優(yōu)化（FPGA 加速）。
5 Socrates 方案
Socrates[7] 是微軟新研發(fā)的 DaaS 架構。與 Aurora 類似，使用存儲與計算分離架構，強調日志的作用。但是 Socrates 采用的復用已有 SQL Server 組件：
- SQL Server 為了支持 Snapshot 隔離級，提供了多版本數(shù)據(jù)頁（Page Version Store）的功能；
- 使用 SSD 存儲作為 buffer pool 的擴展（Reslilient Cache），可以加速故障崩潰恢復過程；
- RBIO Protocol 是擴展的網(wǎng)絡協(xié)議，用以進行遠程數(shù)據(jù)頁讀?。?/li>
- Snapshot Backup/Restore 快速備份與恢復；
- 新增 XLogService 模塊。
其特點如下：
- 盡量復用了原有 SQL Server 的特性，使用 SQL Server 組件充當 Page Server，模擬 Aurora 的存儲節(jié)點；
- Socrates 有一個很大的創(chuàng)新，日志與頁面存儲分離。它認為持久性（durability）不需要使用快速存儲設備中的副本，而可用性（availability）不需要有固定數(shù)量的復制節(jié)點。因此 XLog 和 XStore 負責 durability，計算節(jié)點和 page server 僅用于可用性（它們失效的時候不會丟數(shù)據(jù)，僅僅是不可用）；
- redo 日志傳遞均借助 Xlog Service，而不是通過主從計算節(jié)點通過網(wǎng)絡傳輸。主實例節(jié)點不需要額外進行日志緩存來適應從實例節(jié)點。
6 TaurasDB 方案
TaurasDB[8] 架構如上圖，它繼承了 Aurora 的日志下沉存儲的思想，也繼承了 Socrates 的日志與頁面存儲分離的思想，并且在計算節(jié)點添加了存儲抽象層（SAL）。LogStore 與 PageStore 采用與 Aurora 類似的 Quorum 仲裁算法實現(xiàn)高可用。
總結
云原生數(shù)據(jù)庫的核心功能
- 計算與存儲分離，計算節(jié)點保持少狀態(tài)，甚至無狀態(tài)；
- 基于日志的進行持久化；
- 存儲分片/分塊，易于擴容；
- 存儲多副本與共識算法；
- 備份、恢復、快照功能下放到存儲層。
知名方案的非核心功能
【全球部署】
多機房升級版，需要考慮全球可用性，全球分布式事務能力，以及 GDPR 合規(guī)要求的地理分區(qū)（Geo-Partitioning）特性。
由于歐盟出臺通用數(shù)據(jù)保護條例（GDPR）[6]，使得數(shù)據(jù)不得隨意跨境轉移。違者最高罰款 2000 萬歐元，或者全球營收 4%。原有分布式庫處理技術，例如使用復制表進行 Jion 優(yōu)化，就存在違規(guī)風險。此外，國內以及其他國家均有類似的數(shù)據(jù)保護法規(guī)，合規(guī)性將來也會是重要的需求。
云原生數(shù)據(jù)庫的核心價值
【更高的性能】
基于日志進行持久化與復制更輕量，避免寫放大效應，各大廠商均號稱比原版 MySQL 有 5～7 倍性能。
【更好的彈性】
計算節(jié)點無狀態(tài)或少狀態(tài)，計算節(jié)點與存儲擴展靈活。
【更好的可用性】
將數(shù)據(jù)庫持久文件分片，以小粒度方式副本方式降低 MTTR，以及共識算法來實現(xiàn)高可用。
【更高的資源利用率】
計算能力與存儲容量按需伸縮，減少資源浪費。
【更小的成本】
更少的資源、更少的浪費、更少的維護，最終達到更小的成本。
云原生數(shù)據(jù)庫本質是用現(xiàn)有技術組合，實現(xiàn)云原生需求，而且也是數(shù)據(jù)庫實現(xiàn) serverless 的必由之路。
參考文獻
[1]: "Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases"
[2]: "Spanner: Google’s Globally-Distributed Database"
[3]: TiDB: A Raft-based HTAP Database
[4]: PolarDB redo replication https://www.percona.com/live/18/sites/default/files/slides/polardb_p18_slides.pdf
[5]: PolarDB Architecture https://www.intel.com/content/dam/www/public/us/en/documents/solution-briefs/alibaba-polardb-solution-brief.pdf5
[6]: GDPR https://gdpr-info.eu/
[7]: "Socrates: The New SQL Server in the Cloud"
[8]: Taurus Database: How to be Fast, Available, and Frugal in the Cloud
[9]: 騰訊云新一代自研數(shù)據(jù)庫CynosDB技術詳解——架構設計https://cloud.tencent.com/developer/article/1367387
- 文中圖片均來自以上參考鏈接
