作者：柯煜昌 顧問軟件工程師
目前從事 RadonDB 容器化研發(fā)杏死，華中科技大學(xué)研究生畢業(yè)敬鬓，有多年的數(shù)據(jù)庫內(nèi)核開發(fā)經(jīng)驗(yàn)宣决。
你將 Pick 這些內(nèi)容：
- 云原生的概念
- 云原生數(shù)據(jù)庫的概念
- 兩種主流技術(shù)路線分析
- 六種云原生數(shù)據(jù)庫方案和功能介紹
- 云原生數(shù)據(jù)庫的核心功能和價值
背景
隨著云計算的蓬勃發(fā)展，IT 應(yīng)用轉(zhuǎn)向云端鸥滨，云服務(wù)出現(xiàn)如下若干特點(diǎn)：
- 提供按需服務(wù)戴甩；
- 用戶只愿支付運(yùn)營費(fèi)用而不愿支付資產(chǎn)費(fèi)用符喝；
- 云服務(wù)提供商集群規(guī)模越來越大，甚至遍布全球甜孤，集群達(dá)到云級規(guī)模（Cloud-Scale）协饲。
根據(jù)以上特點(diǎn)，要求云產(chǎn)品需要提供一定 “彈性”（Elastic）缴川，而且達(dá)到云級規(guī)模茉稠；節(jié)點(diǎn)故障如同噪聲” 一樣不可避免，這又要求云服務(wù)有一定的 “自愈”（Resilience）能力把夸。
起初而线，通過借助 IaaS，直接將傳統(tǒng)的數(shù)據(jù)庫 “搬遷” 到云上，于是出現(xiàn)了關(guān)系型數(shù)據(jù)庫服務(wù)（RDS）吞获。這樣雖然能部分實(shí)現(xiàn) “彈性” 與 “自愈”况凉，但是這種方案存在資源利用率低谚鄙，維護(hù)成本高各拷，可用性低等問題。于是闷营，設(shè)計適應(yīng)云特點(diǎn)的云原生數(shù)據(jù)庫就至關(guān)重要烤黍。
RDS 的挑戰(zhàn)
以 MySQL 為例，如果要實(shí)現(xiàn)高可用或者讀寫分離集群傻盟，則需要搭建 binlog 復(fù)制集群速蕊。
如上圖所示，除了頁寫入與 double write娘赴，redo log 寫入操作外规哲，還有 binlog 與 relay log 的寫入。
| 缺陷 | 說明 |
|---|---|
| 寫放大嚴(yán)重 | 如果以上架構(gòu)中诽表，F(xiàn)ileSystem 部署在分布式文件系統(tǒng)中唉锌，頁的寫操作，會因?yàn)楦北緩?fù)制的機(jī)制將 IO 放大竿奏，最后 IO 延遲也會放大袄简。 |
| 資源浪費(fèi)嚴(yán)重 | 1. binlog 復(fù)制是為了適配 MySQL 所有存儲引擎，屬于邏輯復(fù)制泛啸。本質(zhì)是將 SQL 在從實(shí)例執(zhí)行（除了沒有主實(shí)例的鎖爭用外绿语，其他代價幾乎一樣），效率不高候址，也浪費(fèi)了 CPU 與內(nèi)存的資源吕粹。 2. 擴(kuò)展集群的計算能力時，不得不同時擴(kuò)展存儲空間岗仑，導(dǎo)致磁盤資源的浪費(fèi)昂芜。 |
| 備份恢復(fù)慢 | 無論是物理備份/恢復(fù)，還是邏輯備份/恢復(fù)赔蒲，備份操作均會上鎖泌神，影響正常業(yè)務(wù)進(jìn)行，并且舞虱，備份恢復(fù)的時間也隨著存儲容量的增大而線性增長欢际。 |
| 擴(kuò)展代價大 | 1. 新增從實(shí)例，首先要從備份中恢復(fù)數(shù)據(jù)矾兜，然后應(yīng)用binlog以達(dá)到與主實(shí)例一致的狀態(tài)损趋。這個過程耗時取決于恢復(fù)的時間以及binlog日志應(yīng)用的時間，數(shù)據(jù)量大椅寺、數(shù)據(jù)狀態(tài)過時的情況下浑槽，耗時費(fèi)力而且不保證正確蒋失。彈性能力有限。 2. 存儲容量受限于單機(jī)存儲容量桐玻，無法自由擴(kuò)展篙挽。 |
| 可用性低 | Aurora[1]指出，在高規(guī)模的集群環(huán)境中镊靴，軟件或者硬件故障如同“背景噪聲”那樣不可避免铣卡，并且縮短平均故障間隔時間（MTTF）是非常困難的，可行的方法是減少平均恢復(fù)的時間（MTTR）從而達(dá)到高可用性偏竟。 如上所示煮落，RDS 仍然是傳統(tǒng)的備份恢復(fù)的方法修復(fù)故障，如果數(shù)據(jù)量大的話踊谋，可能是數(shù)小時蝉仇，超過平均故障時間間隔（Aurora 是 10s），出現(xiàn)更多節(jié)點(diǎn)故障殖蚕，可能使得共識算法無效（超過半數(shù)）轿衔，可用性就大大打折扣。 |
| 運(yùn)維成本高 | 備份/恢復(fù)與擴(kuò)展嫌褪，均需要專業(yè) DBA 團(tuán)隊(duì)運(yùn)維呀枢，每個步驟出現(xiàn)錯誤需要人工檢查。 |
云原生數(shù)據(jù)庫簡介
為了解決以上問題笼痛，需要針對云上服務(wù)的特點(diǎn)裙秋，改造或者開發(fā)新一代云數(shù)據(jù)庫，這便是云原生數(shù)據(jù)庫缨伊。
| 特點(diǎn) | 說明 |
|---|---|
| 計算存儲分離 | 對存儲與計算進(jìn)行解耦合摘刑，實(shí)現(xiàn)存儲與計算分離。 |
| 無狀態(tài) | 計算節(jié)點(diǎn)無狀態(tài)或較少狀態(tài)刻坊。 |
| 存儲集群靈巧化 | 采用小存儲塊方式組織副本枷恕，用以減少平均恢復(fù)時間，多副本共識算法谭胚，實(shí)現(xiàn)存儲的高可用與故障“自愈”能力徐块。 |
通過解耦合與少狀態(tài)，計算節(jié)點(diǎn)擴(kuò)展就會很輕量灾而，擴(kuò)展速度近乎進(jìn)程啟動的速度胡控。避免擴(kuò)展計算資源的時候，不得不浪費(fèi)存儲資源的窘境旁趟。
解耦合也使得存儲節(jié)點(diǎn)也少了一定的約束昼激，可以使用成熟的分布式存儲技術(shù)實(shí)現(xiàn)靈巧化，降低運(yùn)維成本提高可用性。
接下來將介紹目前兩種主流的技術(shù)路線和幾種知名的方案橙困。
1 Spanner 類
以 Google 的 Spanner[2] 為代表瞧掺，基于云原生開發(fā)全新的數(shù)據(jù)庫。受其影響凡傅，產(chǎn)生了CockrochDB辟狈、TiDB、YugabyteDB 等產(chǎn)品像捶。
1.1 架構(gòu)
以 TiDB[3] 架構(gòu)圖為例：
總體來說上陕，此類產(chǎn)品其特點(diǎn)都是在 key-value 存儲基礎(chǔ)上包裝一層分布式 SQL 執(zhí)行引擎桩砰，使用 2PC 提交或者其變種方案實(shí)現(xiàn)事務(wù)處理能力拓春。計算節(jié)點(diǎn)是 SQL 執(zhí)行引擎，可以徹底實(shí)現(xiàn)無狀態(tài)亚隅，本質(zhì)是一個分布式數(shù)據(jù)庫硼莽。
1.2 存儲高可用性
Spanner 將表拆分為 tablet，以 tablet 為單位使用多副本 + Paxos 算法 實(shí)現(xiàn)煮纵。
TiDB 為 Region 為單位使用多副本 + Multi-Raft 算法懂鸵，而 CockroachDB 則采用 Range 為單位進(jìn)行多副本，共識算法也是使用 Raft行疏。
Spanner 中 key-value 持久化方案匆光，邏輯上仍然是基于日志復(fù)制的狀態(tài)機(jī)模型（log-replicated state machines）上再加共識算法實(shí)現(xiàn)。
1.3 優(yōu)缺點(diǎn)
| 說明 | |
|---|---|
| 優(yōu)點(diǎn) | 1. 徹底的 Share-Nothing 2. 號稱全球部署 3. 使用 key-value 結(jié)構(gòu)與 LSM 樹酿联，以及日志復(fù)制自動機(jī)機(jī)制终息，天然無寫放大效應(yīng) 4. 不需要人為分庫分表，有很好的橫向擴(kuò)展能力 |
| 缺點(diǎn) | 1. 全新開發(fā)工作量大贞让，技術(shù)不算成熟 2. 性能不佳 3. 事務(wù)處理能力有限 ?3.1 在內(nèi)存中處理事務(wù)沖突周崭，有沖突的需要讀寫等待或者提交等待。 ?3.2 如：Spanner 對有沖突的事務(wù) TPS 能力最大只有 125 4. SQL 支持能力有限 ?4.1 如：YugabyteDB 不支持 Join 語句 |
2 Aurora 類
Aurora 是亞馬遜推出的云原生數(shù)據(jù)庫喳张。與 Google 的技術(shù)路線不同续镇，Aurora 是傳統(tǒng)的 MySQL（PostgreSQL）等數(shù)據(jù)庫進(jìn)行計算與存儲分離改造，進(jìn)而實(shí)現(xiàn)云原生的需求销部，但其本質(zhì)仍然是單體數(shù)據(jù)庫的讀寫分離集群摸航。
Aurora 論文對 Spanner 的事務(wù)處理能力并不滿意，認(rèn)為它是為 Google 重讀（read-heavy）負(fù)載定制的數(shù)據(jù)庫系統(tǒng)[1] 舅桩。這種方案得到一些數(shù)據(jù)庫廠商的認(rèn)同酱虎，出現(xiàn)了微軟 Socrates、阿里PolarDB江咳、騰訊 CynosDB逢净、極數(shù)云舟 ArkDB 以及華為 TarusDB 云原生數(shù)據(jù)庫等。
2.1 架構(gòu)
Aurora 架構(gòu)如下：
下圖綠色部分為日志流向。
由于傳統(tǒng)數(shù)據(jù)庫持久化最小單位是一個物理頁爹土，哪怕修改一行甥雕，持久化仍然是一個頁，加上需要寫 redo 日志與 undo 記錄胀茵，本身就存在一定的寫放大問題社露。如果機(jī)械的將文件系統(tǒng)替換成使用分布式文件系統(tǒng)，并且為了實(shí)現(xiàn)高可用采用多副本琼娘，則寫放大效應(yīng)進(jìn)一步放大峭弟，導(dǎo)致存儲網(wǎng)絡(luò)成為瓶頸而性能無法接受。
Aurora 繼承了 Spanner 的日志持久化的思想脱拼，甚至激進(jìn)提出“日志即數(shù)據(jù)庫”的口號瞒瘸，其核心思想是存儲網(wǎng)絡(luò)盡量傳輸日志流，對于讀操作熄浓，存儲網(wǎng)絡(luò)傳輸數(shù)據(jù)頁在所難免情臭，但是計算節(jié)點(diǎn)可以通過 buffer pool 來優(yōu)化。
它對傳統(tǒng)數(shù)據(jù)庫進(jìn)行了如下改造：
- 數(shù)據(jù)庫主實(shí)例變成計算節(jié)點(diǎn)赌蔑，數(shù)據(jù)庫主實(shí)例不再進(jìn)行刷臟頁動作俯在，僅僅向存儲寫日志，存儲應(yīng)用日志實(shí)現(xiàn)持久化娃惯，即日志應(yīng)用下沉到存儲跷乐。數(shù)據(jù)庫主實(shí)例沒有后臺寫動作，沒有 cache 強(qiáng)制刷臟替換趾浅，沒有檢查點(diǎn)愕提；
- 數(shù)據(jù)庫復(fù)制實(shí)例獲取日志內(nèi)容，通過日志應(yīng)用更新自身的 buffer/cache 等內(nèi)存對象潮孽；
- 主實(shí)例與復(fù)制實(shí)例共享存儲揪荣；
- 將崩潰恢復(fù)，備份往史、恢復(fù)仗颈、快照功能下放到存儲層。
并且椎例，以原有 S3 存儲系統(tǒng)為基礎(chǔ)挨决，對存儲進(jìn)行如下改造：
- 將存儲分段（Segment），以 10G 作為分段單位大小, 每個分段共六個副本订歪，部署于三個可用區(qū)（Available Zone）脖祈，每個可用區(qū)兩個副本，Aurora 將這六個分段稱為一個保護(hù)組（Protection Group刷晋，PG）盖高，實(shí)現(xiàn)高可用慎陵。
- 存儲節(jié)點(diǎn)能接收日志記錄應(yīng)用來實(shí)現(xiàn)數(shù)據(jù)庫物理頁的持久化，并且使用 Gossip 協(xié)議同步各個副本間的日志喻奥。
存儲能提供多版本物理頁席纽，用以適配多個復(fù)制實(shí)例的延遲。并且后臺有歷史版本頁面回收線程撞蚕。
持久化頁存儲流程圖如下：
2.2 高可用
Aurora 采用仲裁協(xié)議（Quorum）多數(shù)派投票方式來檢測故障節(jié)點(diǎn)润梯。這種高可用的前提是，10G 分段恢復(fù)時間為 10 秒甥厦，而 10 秒內(nèi)出現(xiàn)第二個節(jié)點(diǎn)故障的可能性幾乎為 0纺铭。
它采用 3 個可用區(qū)，可以形成 4/6 仲裁協(xié)議（6 個節(jié)點(diǎn)刀疙，寫需 4 個投票舶赔，讀需 3 個投票）。最壞情況是某個可用區(qū)出現(xiàn)災(zāi)害（地震庙洼，水災(zāi)顿痪，恐怖襲擊等）時镊辕，同時隨機(jī)出現(xiàn)一個節(jié)點(diǎn)故障油够，此時仍然有 3 個副本，可以使用 2/3 仲裁協(xié)議（3 個節(jié)點(diǎn)征懈，寫需 2 個投票石咬，讀需 2 個投票）繼續(xù)保持高可用性（AZ+1 高可用）。
| 說明 | |
|---|---|
| 優(yōu)點(diǎn) | 1. 在成熟的數(shù)據(jù)庫系統(tǒng)進(jìn)行改造卖哎，技術(shù)相對成熟穩(wěn)定鬼悠、工作量小 2. 事務(wù)處理能力，性能能保持傳統(tǒng)數(shù)據(jù)庫的優(yōu)勢 |
| 缺點(diǎn) | 1. 本質(zhì)仍然是改良的讀寫分離集群 2. 有修改一行寫一個頁的寫放大問題亏娜，需要小心處理 3. 需要 proxy 等組件才能支持分布式事務(wù) |
3 CynosDB 方案
CynosDB[9] 幾乎復(fù)刻了 Aurora 的實(shí)現(xiàn)方式焕窝。
但是有其自身的特點(diǎn)：
- 存儲多副本之間用 Raft 算法保證高可用，Raft 算法包含了 Quorum 仲裁算法维贺，而且更加靈活它掂；
- 與 Aurora 一樣，主從計算節(jié)點(diǎn)通過網(wǎng)絡(luò)傳輸 redo 日志溯泣，同步雙方的 buffer cache 以及其他內(nèi)存對象虐秋。
4 PolarDB 方案
PolarDB[5] 也是存儲與計算分離架構(gòu)，但與 Aurora 最大的不同垃沦，就是沒有將 redo 日志下放到存儲進(jìn)行處理客给，計算節(jié)點(diǎn)仍然要向存儲寫物理頁，僅主實(shí)例與復(fù)制實(shí)例之間使用 redo 日志進(jìn)行物理復(fù)制同步 buffer pool [4]肢簿、事務(wù)等其他內(nèi)存對象靶剑，使用現(xiàn)有的分布式文件系統(tǒng)蜻拨，不對其進(jìn)行改造。
PolarDB 目前集中于分布式文件系統(tǒng)優(yōu)化（PolarFS）桩引，以及查詢加速優(yōu)化（FPGA 加速）官觅。
5 Socrates 方案
Socrates[7] 是微軟新研發(fā)的 DaaS 架構(gòu)。與 Aurora 類似阐污，使用存儲與計算分離架構(gòu)休涤，強(qiáng)調(diào)日志的作用。但是 Socrates 采用的復(fù)用已有 SQL Server 組件：
- SQL Server 為了支持 Snapshot 隔離級笛辟，提供了多版本數(shù)據(jù)頁（Page Version Store）的功能功氨；
- 使用 SSD 存儲作為 buffer pool 的擴(kuò)展（Reslilient Cache），可以加速故障崩潰恢復(fù)過程手幢；
- RBIO Protocol 是擴(kuò)展的網(wǎng)絡(luò)協(xié)議捷凄，用以進(jìn)行遠(yuǎn)程數(shù)據(jù)頁讀取围来；
- Snapshot Backup/Restore 快速備份與恢復(fù)嬉愧；
- 新增 XLogService 模塊菩暗。
其特點(diǎn)如下：
- 盡量復(fù)用了原有 SQL Server 的特性，使用 SQL Server 組件充當(dāng) Page Server，模擬 Aurora 的存儲節(jié)點(diǎn)挂疆；
- Socrates 有一個很大的創(chuàng)新恩沽，日志與頁面存儲分離蹂析。它認(rèn)為持久性（durability）不需要使用快速存儲設(shè)備中的副本渐白，而可用性（availability）不需要有固定數(shù)量的復(fù)制節(jié)點(diǎn)。因此 XLog 和 XStore 負(fù)責(zé) durability粪狼，計算節(jié)點(diǎn)和 page server 僅用于可用性（它們失效的時候不會丟數(shù)據(jù)退腥，僅僅是不可用）；
- redo 日志傳遞均借助 Xlog Service再榄，而不是通過主從計算節(jié)點(diǎn)通過網(wǎng)絡(luò)傳輸狡刘。主實(shí)例節(jié)點(diǎn)不需要額外進(jìn)行日志緩存來適應(yīng)從實(shí)例節(jié)點(diǎn)。
6 TaurasDB 方案
TaurasDB[8] 架構(gòu)如上圖困鸥，它繼承了 Aurora 的日志下沉存儲的思想嗅蔬，也繼承了 Socrates 的日志與頁面存儲分離的思想，并且在計算節(jié)點(diǎn)添加了存儲抽象層（SAL）窝革。LogStore 與 PageStore 采用與 Aurora 類似的 Quorum 仲裁算法實(shí)現(xiàn)高可用购城。
總結(jié)
云原生數(shù)據(jù)庫的核心功能
- 計算與存儲分離，計算節(jié)點(diǎn)保持少狀態(tài)虐译，甚至無狀態(tài)瘪板；
- 基于日志的進(jìn)行持久化；
- 存儲分片/分塊漆诽，易于擴(kuò)容侮攀；
- 存儲多副本與共識算法锣枝；
- 備份、恢復(fù)兰英、快照功能下放到存儲層撇叁。
知名方案的非核心功能
【全球部署】
多機(jī)房升級版，需要考慮全球可用性畦贸，全球分布式事務(wù)能力陨闹，以及 GDPR 合規(guī)要求的地理分區(qū)（Geo-Partitioning）特性。
由于歐盟出臺通用數(shù)據(jù)保護(hù)條例（GDPR）[6]薄坏，使得數(shù)據(jù)不得隨意跨境轉(zhuǎn)移趋厉。違者最高罰款 2000 萬歐元，或者全球營收 4%胶坠。原有分布式庫處理技術(shù)君账，例如使用復(fù)制表進(jìn)行 Jion 優(yōu)化，就存在違規(guī)風(fēng)險沈善。此外乡数，國內(nèi)以及其他國家均有類似的數(shù)據(jù)保護(hù)法規(guī)，合規(guī)性將來也會是重要的需求闻牡。
云原生數(shù)據(jù)庫的核心價值
【更高的性能】
基于日志進(jìn)行持久化與復(fù)制更輕量净赴，避免寫放大效應(yīng)，各大廠商均號稱比原版 MySQL 有 5～7 倍性能澈侠。
【更好的彈性】
計算節(jié)點(diǎn)無狀態(tài)或少狀態(tài)劫侧，計算節(jié)點(diǎn)與存儲擴(kuò)展靈活。
【更好的可用性】
將數(shù)據(jù)庫持久文件分片哨啃，以小粒度方式副本方式降低 MTTR，以及共識算法來實(shí)現(xiàn)高可用写妥。
【更高的資源利用率】
計算能力與存儲容量按需伸縮拳球，減少資源浪費(fèi)。
【更小的成本】
更少的資源珍特、更少的浪費(fèi)祝峻、更少的維護(hù)，最終達(dá)到更小的成本扎筒。
云原生數(shù)據(jù)庫本質(zhì)是用現(xiàn)有技術(shù)組合莱找，實(shí)現(xiàn)云原生需求，而且也是數(shù)據(jù)庫實(shí)現(xiàn) serverless 的必由之路嗜桌。
參考文獻(xiàn)
[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技術(shù)詳解——架構(gòu)設(shè)計https://cloud.tencent.com/developer/article/1367387
- 文中圖片均來自以上參考鏈接
