作者：RadonDB 開(kāi)源社區(qū)

來(lái)源：SegmentFault 思否社區(qū)

作者：柯煜昌顧問(wèn)軟件工程師

目前從事 RadonDB 容器化研發(fā)，華中科技大學(xué)研究生畢業(yè)，有多年的數(shù)據(jù)庫(kù)內(nèi)核開(kāi)發(fā)經(jīng)驗(yàn)。

你將 Pick 這些內(nèi)容：

云原生的概念
云原生數(shù)據(jù)庫(kù)的概念
兩種主流技術(shù)路線分析
六種云原生數(shù)據(jù)庫(kù)方案和功能介紹
云原生數(shù)據(jù)庫(kù)的核心功能和價(jià)值

背景

隨著云計(jì)算的蓬勃發(fā)展，IT 應(yīng)用轉(zhuǎn)向云端，云服務(wù)出現(xiàn)如下若干特點(diǎn)：

提供按需服務(wù)；
用戶只愿支付運(yùn)營(yíng)費(fèi)用而不愿支付資產(chǎn)費(fèi)用；
云服務(wù)提供商集群規(guī)模越來(lái)越大，甚至遍布全球，集群達(dá)到云級(jí)規(guī)模（Cloud-Scale）。

根據(jù)以上特點(diǎn)，要求云產(chǎn)品需要提供一定 “彈性”（Elastic），而且達(dá)到云級(jí)規(guī)模；節(jié)點(diǎn)故障如同噪聲” 一樣不可避免，這又要求云服務(wù)有一定的 “自愈”（Resilience）能力。

起初，通過(guò)借助 IaaS，直接將傳統(tǒng)的數(shù)據(jù)庫(kù) “搬遷” 到云上，于是出現(xiàn)了關(guān)系型數(shù)據(jù)庫(kù)服務(wù)（RDS）。這樣雖然能部分實(shí)現(xiàn) “彈性” 與 “自愈”，但是這種方案存在資源利用率低，維護(hù)成本高，可用性低等問(wèn)題。于是，設(shè)計(jì)適應(yīng)云特點(diǎn)的云原生數(shù)據(jù)庫(kù)就至關(guān)重要。

RDS 的挑戰(zhàn)

以 MySQL 為例，如果要實(shí)現(xiàn)高可用或者讀寫分離集群，則需要搭建 binlog 復(fù)制集群。

MySQL 復(fù)制架構(gòu)

如上圖所示，除了頁(yè)寫入與 double write，redo log 寫入操作外，還有 binlog 與 relay log 的寫入。

云原生數(shù)據(jù)庫(kù)簡(jiǎn)介

為了解決以上問(wèn)題，需要針對(duì)云上服務(wù)的特點(diǎn)，改造或者開(kāi)發(fā)新一代云數(shù)據(jù)庫(kù)，這便是云原生數(shù)據(jù)庫(kù)。

通過(guò)解耦合與少狀態(tài)，計(jì)算節(jié)點(diǎn)擴(kuò)展就會(huì)很輕量，擴(kuò)展速度近乎進(jìn)程啟動(dòng)的速度。避免擴(kuò)展計(jì)算資源的時(shí)候，不得不浪費(fèi)存儲(chǔ)資源的窘境。

解耦合也使得存儲(chǔ)節(jié)點(diǎn)也少了一定的約束，可以使用成熟的分布式存儲(chǔ)技術(shù)實(shí)現(xiàn)靈巧化，降低運(yùn)維成本提高可用性。

接下來(lái)將介紹目前兩種主流的技術(shù)路線和幾種知名的方案。

1 Spanner 類

以 Google 的 Spanner[2] 為代表，基于云原生開(kāi)發(fā)全新的數(shù)據(jù)庫(kù)。受其影響，產(chǎn)生了CockrochDB、TiDB、YugabyteDB 等產(chǎn)品。

1.1 架構(gòu)

以 TiDB[3] 架構(gòu)圖為例：

TiDB 架構(gòu)圖

總體來(lái)說(shuō)，此類產(chǎn)品其特點(diǎn)都是在 key-value 存儲(chǔ)基礎(chǔ)上包裝一層分布式 SQL 執(zhí)行引擎，使用 2PC 提交或者其變種方案實(shí)現(xiàn)事務(wù)處理能力。計(jì)算節(jié)點(diǎn)是 SQL 執(zhí)行引擎，可以徹底實(shí)現(xiàn)無(wú)狀態(tài)，本質(zhì)是一個(gè)分布式數(shù)據(jù)庫(kù)。

1.2 存儲(chǔ)高可用性

Spanner 將表拆分為 tablet，以 tablet 為單位使用多副本 + Paxos 算法實(shí)現(xiàn)。

TiDB 為 Region 為單位使用多副本 + Multi-Raft 算法，而 CockroachDB 則采用 Range 為單位進(jìn)行多副本，共識(shí)算法也是使用 Raft。

Spanner 中 key-value 持久化方案，邏輯上仍然是基于日志復(fù)制的狀態(tài)機(jī)模型（log-replicated state machines）上再加共識(shí)算法實(shí)現(xiàn)。

multi-Raft 存儲(chǔ)架構(gòu)

1.3 優(yōu)缺點(diǎn)

2 Aurora 類

Aurora 是亞馬遜推出的云原生數(shù)據(jù)庫(kù)。與 Google 的技術(shù)路線不同，Aurora 是傳統(tǒng)的 MySQL（PostgreSQL）等數(shù)據(jù)庫(kù)進(jìn)行計(jì)算與存儲(chǔ)分離改造，進(jìn)而實(shí)現(xiàn)云原生的需求，但其本質(zhì)仍然是單體數(shù)據(jù)庫(kù)的讀寫分離集群。

Aurora 論文對(duì) Spanner 的事務(wù)處理能力并不滿意，認(rèn)為它是為 Google 重讀（read-heavy）負(fù)載定制的數(shù)據(jù)庫(kù)系統(tǒng)[1] 。這種方案得到一些數(shù)據(jù)庫(kù)廠商的認(rèn)同，出現(xiàn)了微軟 Socrates、阿里PolarDB、騰訊 CynosDB、極數(shù)云舟 ArkDB 以及華為 TarusDB 云原生數(shù)據(jù)庫(kù)等。

2.1 架構(gòu)

Aurora 架構(gòu)如下：

Aurora 架構(gòu)

下圖綠色部分為日志流向。

Aurora 網(wǎng)絡(luò) IO

由于傳統(tǒng)數(shù)據(jù)庫(kù)持久化最小單位是一個(gè)物理頁(yè)，哪怕修改一行，持久化仍然是一個(gè)頁(yè)，加上需要寫 redo 日志與 undo 記錄，本身就存在一定的寫放大問(wèn)題。如果機(jī)械的將文件系統(tǒng)替換成使用分布式文件系統(tǒng)，并且為了實(shí)現(xiàn)高可用采用多副本，則寫放大效應(yīng)進(jìn)一步放大，導(dǎo)致存儲(chǔ)網(wǎng)絡(luò)成為瓶頸而性能無(wú)法接受。

Aurora 繼承了 Spanner 的日志持久化的思想，甚至激進(jìn)提出“日志即數(shù)據(jù)庫(kù)”的口號(hào)，其核心思想是存儲(chǔ)網(wǎng)絡(luò)盡量傳輸日志流，對(duì)于讀操作，存儲(chǔ)網(wǎng)絡(luò)傳輸數(shù)據(jù)頁(yè)在所難免，但是計(jì)算節(jié)點(diǎn)可以通過(guò) buffer pool 來(lái)優(yōu)化。

它對(duì)傳統(tǒng)數(shù)據(jù)庫(kù)進(jìn)行了如下改造：

數(shù)據(jù)庫(kù)主實(shí)例變成計(jì)算節(jié)點(diǎn)，數(shù)據(jù)庫(kù)主實(shí)例不再進(jìn)行刷臟頁(yè)動(dòng)作，僅僅向存儲(chǔ)寫日志，存儲(chǔ)應(yīng)用日志實(shí)現(xiàn)持久化，即日志應(yīng)用下沉到存儲(chǔ)。數(shù)據(jù)庫(kù)主實(shí)例沒(méi)有后臺(tái)寫動(dòng)作，沒(méi)有 cache 強(qiáng)制刷臟替換，沒(méi)有檢查點(diǎn)；
數(shù)據(jù)庫(kù)復(fù)制實(shí)例獲取日志內(nèi)容，通過(guò)日志應(yīng)用更新自身的 buffer/cache 等內(nèi)存對(duì)象；
主實(shí)例與復(fù)制實(shí)例共享存儲(chǔ)；
將崩潰恢復(fù)，備份、恢復(fù)、快照功能下放到存儲(chǔ)層。

并且，以原有 S3 存儲(chǔ)系統(tǒng)為基礎(chǔ)，對(duì)存儲(chǔ)進(jìn)行如下改造：

將存儲(chǔ)分段（Segment），以 10G 作為分段單位大小, 每個(gè)分段共六個(gè)副本，部署于三個(gè)可用區(qū)（Available Zone），每個(gè)可用區(qū)兩個(gè)副本，Aurora 將這六個(gè)分段稱為一個(gè)保護(hù)組（Protection Group，PG），實(shí)現(xiàn)高可用。
存儲(chǔ)節(jié)點(diǎn)能接收日志記錄應(yīng)用來(lái)實(shí)現(xiàn)數(shù)據(jù)庫(kù)物理頁(yè)的持久化，并且使用 Gossip 協(xié)議同步各個(gè)副本間的日志。

存儲(chǔ)能提供多版本物理頁(yè)，用以適配多個(gè)復(fù)制實(shí)例的延遲。并且后臺(tái)有歷史版本頁(yè)面回收線程。

持久化頁(yè)存儲(chǔ)流程圖如下：

持久化存儲(chǔ)流程

2.2 高可用

Aurora 采用仲裁協(xié)議（Quorum）多數(shù)派投票方式來(lái)檢測(cè)故障節(jié)點(diǎn)。這種高可用的前提是，10G 分段恢復(fù)時(shí)間為 10 秒，而 10 秒內(nèi)出現(xiàn)第二個(gè)節(jié)點(diǎn)故障的可能性幾乎為 0。

它采用 3 個(gè)可用區(qū)，可以形成 4/6 仲裁協(xié)議（6 個(gè)節(jié)點(diǎn)，寫需 4 個(gè)投票，讀需 3 個(gè)投票）。最壞情況是某個(gè)可用區(qū)出現(xiàn)災(zāi)害（地震，水災(zāi)，恐怖襲擊等）時(shí)，同時(shí)隨機(jī)出現(xiàn)一個(gè)節(jié)點(diǎn)故障，此時(shí)仍然有 3 個(gè)副本，可以使用 2/3 仲裁協(xié)議（3 個(gè)節(jié)點(diǎn)，寫需 2 個(gè)投票，讀需 2 個(gè)投票）繼續(xù)保持高可用性（AZ+1 高可用）。

3 CynosDB 方案

CynosDB[9] 幾乎復(fù)刻了 Aurora 的實(shí)現(xiàn)方式，但是有其自身的特點(diǎn)：

存儲(chǔ)多副本之間用 Raft 算法保證高可用，Raft 算法包含了 Quorum 仲裁算法，而且更加靈活；
與 Aurora 一樣，主從計(jì)算節(jié)點(diǎn)通過(guò)網(wǎng)絡(luò)傳輸 redo 日志，同步雙方的 buffer cache 以及其他內(nèi)存對(duì)象。

4 PolarDB 方案

PolarDB 架構(gòu)

PolarDB[5] 也是存儲(chǔ)與計(jì)算分離架構(gòu)，但與 Aurora 最大的不同，就是沒(méi)有將 redo 日志下放到存儲(chǔ)進(jìn)行處理，計(jì)算節(jié)點(diǎn)仍然要向存儲(chǔ)寫物理頁(yè)，僅主實(shí)例與復(fù)制實(shí)例之間使用 redo 日志進(jìn)行物理復(fù)制同步 buffer pool [4]、事務(wù)等其他內(nèi)存對(duì)象，使用現(xiàn)有的分布式文件系統(tǒng)，不對(duì)其進(jìn)行改造。

PolarDB 目前集中于分布式文件系統(tǒng)優(yōu)化（PolarFS），以及查詢加速優(yōu)化（FPGA 加速）。

5 Socrates 方案

Socrates 架構(gòu)

Socrates[7] 是微軟新研發(fā)的 DaaS 架構(gòu)。與 Aurora 類似，使用存儲(chǔ)與計(jì)算分離架構(gòu)，強(qiáng)調(diào)日志的作用。但是 Socrates 采用的復(fù)用已有 SQL Server 組件：

SQL Server 為了支持 Snapshot 隔離級(jí)，提供了多版本數(shù)據(jù)頁(yè)（Page Version Store）的功能；
使用 SSD 存儲(chǔ)作為 buffer pool 的擴(kuò)展（Reslilient Cache），可以加速故障崩潰恢復(fù)過(guò)程；
RBIO Protocol 是擴(kuò)展的網(wǎng)絡(luò)協(xié)議，用以進(jìn)行遠(yuǎn)程數(shù)據(jù)頁(yè)讀取；
Snapshot Backup/Restore 快速備份與恢復(fù)；
新增 XLogService 模塊。

其特點(diǎn)如下：

盡量復(fù)用了原有 SQL Server 的特性，使用 SQL Server 組件充當(dāng) Page Server，模擬 Aurora 的存儲(chǔ)節(jié)點(diǎn)；
Socrates 有一個(gè)很大的創(chuàng)新，日志與頁(yè)面存儲(chǔ)分離。它認(rèn)為持久性（durability）不需要使用快速存儲(chǔ)設(shè)備中的副本，而可用性（availability）不需要有固定數(shù)量的復(fù)制節(jié)點(diǎn)。因此 XLog 和 XStore 負(fù)責(zé) durability，計(jì)算節(jié)點(diǎn)和 page server 僅用于可用性（它們失效的時(shí)候不會(huì)丟數(shù)據(jù)，僅僅是不可用）；
redo 日志傳遞均借助 Xlog Service，而不是通過(guò)主從計(jì)算節(jié)點(diǎn)通過(guò)網(wǎng)絡(luò)傳輸。主實(shí)例節(jié)點(diǎn)不需要額外進(jìn)行日志緩存來(lái)適應(yīng)從實(shí)例節(jié)點(diǎn)。

6 TaurasDB 方案

TaurasDB 架構(gòu)

TaurasDB[8] 架構(gòu)如上圖，它繼承了 Aurora 的日志下沉存儲(chǔ)的思想，也繼承了 Socrates 的日志與頁(yè)面存儲(chǔ)分離的思想，并且在計(jì)算節(jié)點(diǎn)添加了存儲(chǔ)抽象層（SAL）。LogStore 與 PageStore 采用與 Aurora 類似的 Quorum 仲裁算法實(shí)現(xiàn)高可用。

總結(jié)

云原生數(shù)據(jù)庫(kù)的核心功能

計(jì)算與存儲(chǔ)分離，計(jì)算節(jié)點(diǎn)保持少狀態(tài)，甚至無(wú)狀態(tài)；
基于日志的進(jìn)行持久化；
存儲(chǔ)分片/分塊，易于擴(kuò)容；
存儲(chǔ)多副本與共識(shí)算法；
備份、恢復(fù)、快照功能下放到存儲(chǔ)層。

知名方案的非核心功能

非核心性能支持情況

【全球部署】

多機(jī)房升級(jí)版，需要考慮全球可用性，全球分布式事務(wù)能力，以及 GDPR 合規(guī)要求的地理分區(qū)（Geo-Partitioning）特性。

由于歐盟出臺(tái)通用數(shù)據(jù)保護(hù)條例（GDPR）[6]，使得數(shù)據(jù)不得隨意跨境轉(zhuǎn)移。違者最高罰款 2000 萬(wàn)歐元，或者全球營(yíng)收 4%。原有分布式庫(kù)處理技術(shù)，例如使用復(fù)制表進(jìn)行 Jion 優(yōu)化，就存在違規(guī)風(fēng)險(xiǎn)。此外，國(guó)內(nèi)以及其他國(guó)家均有類似的數(shù)據(jù)保護(hù)法規(guī)，合規(guī)性將來(lái)也會(huì)是重要的需求。

云原生數(shù)據(jù)庫(kù)的核心價(jià)值

【更高的性能】

基于日志進(jìn)行持久化與復(fù)制更輕量，避免寫放大效應(yīng)，各大廠商均號(hào)稱比原版 MySQL 有 5～7 倍性能。

【更好的彈性】

計(jì)算節(jié)點(diǎn)無(wú)狀態(tài)或少狀態(tài)，計(jì)算節(jié)點(diǎn)與存儲(chǔ)擴(kuò)展靈活。

【更好的可用性】

將數(shù)據(jù)庫(kù)持久文件分片，以小粒度方式副本方式降低 MTTR，以及共識(shí)算法來(lái)實(shí)現(xiàn)高可用。

【更高的資源利用率】

計(jì)算能力與存儲(chǔ)容量按需伸縮，減少資源浪費(fèi)。

【更小的成本】

更少的資源、更少的浪費(fèi)、更少的維護(hù)，最終達(dá)到更小的成本。

云原生數(shù)據(jù)庫(kù)本質(zhì)是用現(xiàn)有技術(shù)組合，實(shí)現(xiàn)云原生需求，而且也是數(shù)據(jù)庫(kù)實(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
【5】: PolarDB Architecture
【6】: GDPR
【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ù)庫(kù)CynosDB技術(shù)詳解——架構(gòu)設(shè)計(jì)

點(diǎn)擊左下角閱讀原文，到 SegmentFault 思否社區(qū) 和文章作者展開(kāi)更多互動(dòng)和交流，掃描下方”二維碼“或在“公眾號(hào)后臺(tái)“回復(fù)“ 入群 ”即可加入我們的技術(shù)交流群，收獲更多的技術(shù)文章~

- END -

盤點(diǎn) | 主流云原生數(shù)據(jù)庫(kù)技術(shù)方案

背景