華為《Taurus MM: bringing multi-master to the cloud》論文被國際數(shù)據(jù)庫頂會(huì)VLDB 2023錄用，這篇論文里講述了符合云原生數(shù)據(jù)庫特點(diǎn)的超燃技術(shù)，介紹了如何通過各種黑科技減少云原生數(shù)據(jù)庫的網(wǎng)絡(luò)消耗，進(jìn)而提升云原生數(shù)據(jù)庫的性能和穩(wěn)定性。下面就讓我們抽絲剝繭，細(xì)細(xì)品味技術(shù)的魅力，揭開華為云數(shù)據(jù)庫多主技術(shù)的面紗。

注：技術(shù)論文中的Taurus在華為云商用的產(chǎn)品名是GaussDB(for MySQL)，是GaussDB(for MySQL)的云原生架構(gòu)技術(shù)版本。

一、引言

現(xiàn)下，大型高性能數(shù)據(jù)庫通常采用一寫（主）多讀（副本）這種標(biāo)準(zhǔn)部署方式來提高業(yè)務(wù)吞吐量。然而，單主會(huì)導(dǎo)致單點(diǎn)故障，同時(shí)限制了寫擴(kuò)展性，也就是說帶來了可用性和性能的雙重挑戰(zhàn)。而性能和可用性是衡量一個(gè)企業(yè)級(jí)數(shù)據(jù)庫是否優(yōu)秀的最關(guān)鍵的兩個(gè)方面。因此，多主數(shù)據(jù)庫應(yīng)運(yùn)而生。
多主數(shù)據(jù)庫有Shared-nothing和Shared-storage兩種架構(gòu)。谷歌Spanner、亞馬遜DynamoDB、CockroachDB、OceanBase及其他一些數(shù)據(jù)庫采用了Shared-nothing架構(gòu)。亞馬遜Aurora多主數(shù)據(jù)庫、Oracle RAC和IBM DB2 pureScale采用了Shared-storage架構(gòu)。
對(duì)于Shared-nothing架構(gòu)的多主，每個(gè)節(jié)點(diǎn)對(duì)一個(gè)小數(shù)據(jù)子集執(zhí)行計(jì)算和存儲(chǔ)。在高度分區(qū)的工作負(fù)載場景下，這類架構(gòu)可以提供非常高的可擴(kuò)展性。但在如下不均衡的工作負(fù)載場景中，其優(yōu)勢受限——節(jié)點(diǎn)數(shù)越多可能意味著節(jié)點(diǎn)間數(shù)據(jù)交換越多：

• 數(shù)據(jù)無明顯分區(qū)特征；

• 工作負(fù)載隨時(shí)間變化；

• 存在熱點(diǎn)數(shù)據(jù)場景。

同時(shí)，Shared-nothing架構(gòu)使用分布式提交協(xié)議，信息同步多輪交換，降低了多主系統(tǒng)的性能。
對(duì)于傳統(tǒng)的Shared-storage架構(gòu)，計(jì)算層與存儲(chǔ)層分離。這類架構(gòu)由于其高度集成及密集網(wǎng)絡(luò)通信的特點(diǎn)，需要高端和專用的網(wǎng)絡(luò)硬件，更適用于對(duì)成本不敏感的線下數(shù)據(jù)中心部署，不適用于云原生數(shù)據(jù)庫。云的最核心特點(diǎn)是通過多用戶共享基礎(chǔ)設(shè)施平攤成本（包括網(wǎng)絡(luò)硬件）來實(shí)現(xiàn)高成本收益。
云數(shù)據(jù)庫性能的關(guān)鍵是對(duì)共享網(wǎng)絡(luò)的優(yōu)化。華為云數(shù)據(jù)庫多主（Multi-Master）專注于從消息的數(shù)量和大小兩方面減少網(wǎng)絡(luò)流量，這一目標(biāo)的達(dá)成并不容易，很多公司嘗試過，但目前還沒有看到成功案例。

二、華為云數(shù)據(jù)庫多主黑科技解析

那究竟如何實(shí)現(xiàn)多主上云呢？華為云數(shù)據(jù)庫多主有哪些硬核技術(shù)突破呢？
通過對(duì)網(wǎng)絡(luò)流量消耗進(jìn)行分析和歸類后，我們發(fā)現(xiàn)主要的網(wǎng)絡(luò)消耗是由于主節(jié)點(diǎn)寫頁面、時(shí)鐘同步和鎖信息交互三個(gè)方面。華為云數(shù)據(jù)庫在如上三個(gè)方面進(jìn)行了探索和嘗試，并取得了可喜成績。下面詳細(xì)討論在每類開銷上，華為云數(shù)據(jù)庫是如何盡最大可能減少網(wǎng)絡(luò)計(jì)算開銷的。

減少直接頁面寫入帶來的網(wǎng)絡(luò)消耗

此問題已有解決方案——2020年SIGMOD會(huì)議上我們向會(huì)議研究團(tuán)體介紹了華為云原生數(shù)據(jù)庫單主解決方案：“Log As Database”（日志即數(shù)據(jù)庫）。

簡單說就是華為云數(shù)據(jù)庫計(jì)算與存儲(chǔ)分離，計(jì)算層包含一寫（主）多讀（副本）。計(jì)算層的作用是執(zhí)行數(shù)據(jù)庫的修改，主要功能有：接入連接、執(zhí)行查詢、管理事務(wù)以及生成WAL日志記錄（日志用于描述對(duì)數(shù)據(jù)庫頁所做的修改）。事務(wù)更新時(shí)先生成日志記錄，主節(jié)點(diǎn)將這些日志記錄傳送到存儲(chǔ)層的Log Stores中進(jìn)行存儲(chǔ)，通過日志回放生成數(shù)據(jù)，從而無需通過網(wǎng)絡(luò)執(zhí)行整個(gè)數(shù)據(jù)頁面的寫入，節(jié)省了所需的網(wǎng)絡(luò)帶寬。詳細(xì)見圖1。

圖1：華為云數(shù)據(jù)庫組件及分層架構(gòu)

華為云數(shù)據(jù)庫多主重用了一主多讀架構(gòu)中的思想，采用Shared-storage體系結(jié)構(gòu)，所有Master之間共享日志存儲(chǔ)和頁面存儲(chǔ)，繼續(xù)沿用悲觀并發(fā)控制，且引入了全局鎖管理器GLM（Global Lock Manager）。

各Master維護(hù)自己的預(yù)寫日志（WAL）。用戶事務(wù)在單主上執(zhí)行——沒有分布式事務(wù)。日志記錄寫入執(zhí)行事務(wù)的主機(jī)中。每個(gè)Master會(huì)定期將帶有位置信息標(biāo)識(shí)（哪個(gè)Master生成的）的新生成日志提交給所有其他Master。通過位置信息，各Master讀取其他所有Master上生成的日志記錄，并更新進(jìn)自己的緩沖池頁面中。詳細(xì)如圖2所示。

圖2：華為云數(shù)據(jù)庫多主組件及分層架構(gòu)

減少時(shí)鐘同步帶來的網(wǎng)絡(luò)消耗

多主數(shù)據(jù)庫特有的第二個(gè)網(wǎng)絡(luò)開銷來源是時(shí)鐘同步。在單主數(shù)據(jù)庫上，事務(wù)時(shí)鐘信息可以直接使用本地物理時(shí)鐘。然而，在分布式系統(tǒng)中，不同節(jié)點(diǎn)上的物理時(shí)鐘很難精確保持一致。而通過網(wǎng)絡(luò)連接同步和獲取時(shí)間戳，會(huì)帶來無法容忍的時(shí)間延遲。因此，對(duì)于分布式數(shù)據(jù)庫物理時(shí)鐘這種方法不再適用。

這在業(yè)界不是一個(gè)新近才提出的問題。早在20世紀(jì)70年代，萊斯利·蘭伯特就為了解決此問題，提出并發(fā)明了標(biāo)量時(shí)鐘（常稱為邏輯時(shí)鐘，或蘭伯特時(shí)鐘）。此標(biāo)量時(shí)鐘由一個(gè)數(shù)字組成時(shí)間戳，僅在消息交換期間進(jìn)行不同計(jì)算機(jī)間的時(shí)鐘同步。蘭伯特時(shí)鐘的算法簡單而優(yōu)雅，但要通過它創(chuàng)建數(shù)據(jù)庫的分布式快照基本不可能，而分布式快照對(duì)分布式數(shù)據(jù)庫的性能又是非常重要的。同時(shí)，邏輯時(shí)鐘無法保存事務(wù)間的因果關(guān)系。簡單說，就是假設(shè)???? (??) < ???? (??)，也就是事務(wù)a早于事務(wù)b，使用邏輯時(shí)鐘，無法識(shí)別是a導(dǎo)致了b，還是a和b間僅是并發(fā)無因果關(guān)系。

邏輯時(shí)鐘之后又出現(xiàn)了矢量時(shí)鐘，用于解決邏輯時(shí)鐘的局限性。然而，雖然矢量時(shí)鐘能夠創(chuàng)建分布式快照，但是，矢量時(shí)鐘有一個(gè)很大的缺點(diǎn)——加大了消息的大小。數(shù)據(jù)庫之間的消息本來很小，矢量時(shí)間戳的加入使消息的大小增大為原來的兩至三倍，從而加大了網(wǎng)絡(luò)開銷。

華為云數(shù)據(jù)庫團(tuán)隊(duì)發(fā)明了一種新型的時(shí)鐘——VS時(shí)鐘（VECTOR-SCALAR CLOCKS）。其關(guān)鍵的創(chuàng)新是，它既可以產(chǎn)生矢量時(shí)間戳，又可以產(chǎn)生標(biāo)量時(shí)間戳，實(shí)現(xiàn)優(yōu)勢互補(bǔ)。VS時(shí)鐘的應(yīng)用，既達(dá)成了較小的網(wǎng)絡(luò)消耗又保證了數(shù)據(jù)庫全局快照的創(chuàng)建能力。例如，由于每個(gè)節(jié)點(diǎn)對(duì)同一頁面的修改必須是串行的，無需關(guān)注因果（先后）關(guān)系，因此對(duì)單個(gè)頁面修改的日志記錄添加時(shí)間戳?xí)r，發(fā)放標(biāo)量時(shí)間戳即可；當(dāng)為全局快照的創(chuàng)建發(fā)放時(shí)間戳?xí)r，需要使用完整的矢量時(shí)間戳以便理清各主節(jié)點(diǎn)事務(wù)間的先后關(guān)系。由于全局快照這一類事件的數(shù)量級(jí)遠(yuǎn)小于日志記錄，故而全局快照矢量時(shí)間戳所帶來的空間開銷可以忽略不計(jì)。

優(yōu)化鎖協(xié)議減少網(wǎng)絡(luò)消耗

多主數(shù)據(jù)庫的第三個(gè)主要網(wǎng)絡(luò)開銷是鎖信息交互帶來的開銷。

對(duì)數(shù)據(jù)庫的某些更改需要被視為原子更改，例如對(duì)內(nèi)部數(shù)據(jù)庫頁的修改，或事務(wù)對(duì)記錄行的修改。通常，數(shù)據(jù)庫使用鎖來實(shí)現(xiàn)原子性。通過觀察我們得到一個(gè)重要結(jié)論：鑒于所有行都是存儲(chǔ)在頁面上的，因此要修改或讀取對(duì)應(yīng)行，就意味著必須修改或讀取此行所在的頁面。

由此，我們提出了，對(duì)于數(shù)據(jù)庫最底層的行頁混合鎖定，行鎖信息不再作為單獨(dú)的消息進(jìn)行傳遞，而是作為頁鎖的一部分來傳遞。這種方案，會(huì)將鎖信息的數(shù)量顯著減少，從而進(jìn)一步降低了網(wǎng)絡(luò)負(fù)載。

數(shù)據(jù)庫系統(tǒng)的行鎖類型有：（普通）共享和獨(dú)占行鎖、間隙鎖、next-key鎖和意向鎖，在華為云數(shù)據(jù)庫多主中討論的“行鎖”包括了所有這些類型的鎖。行鎖可以以不同的方式管理，我們?cè)诜治龊蛯?duì)比了下面的三種不同方法后，選擇了行鎖跟隨頁鎖的方法。

?GLM管理行鎖

讓全局鎖管理器GLM同時(shí)管理頁鎖和行鎖。這種方法每次行鎖獲取時(shí)都需要走GLM，因而會(huì)增加網(wǎng)絡(luò)負(fù)載。DB2 pureScale采用了這種方法，并進(jìn)行了各種優(yōu)化。GLM管理行鎖的方案，網(wǎng)絡(luò)流量很高，即使在工作負(fù)載大部分是分區(qū)的場景下，也依然很高；此外，GLM還必須要能支持底層系統(tǒng)使用的所有行鎖類型及這些鎖之間的復(fù)雜交互。

在頁面上存儲(chǔ)行鎖

將頁面的行鎖信息存儲(chǔ)在本身所在的頁面上。Oracle RAC采用這種方法。華為云數(shù)據(jù)庫未采用這種方法，有兩個(gè)原因：1)它需要將行鎖獲取/釋放記錄寫入日志，從而增加了網(wǎng)絡(luò)負(fù)載；2)它需要更改磁盤上的頁面格式，華為云數(shù)據(jù)庫由單主升級(jí)到多主時(shí)必須做這種數(shù)據(jù)庫格式轉(zhuǎn)換，將損失華為云數(shù)據(jù)庫的原有優(yōu)勢。

?行鎖跟隨頁鎖

當(dāng)Master獲取頁面鎖時(shí)，一并獲取該頁面上的行鎖列表，包括持有的鎖和掛起的鎖請(qǐng)求。之后，Master可以在頁面上授予額外的行鎖，當(dāng)然前提是這些行鎖要與其頁鎖兼容。當(dāng)Master向GLM釋放頁鎖時(shí)，同時(shí)會(huì)將頁面上當(dāng)前行鎖的信息發(fā)送給GLM。需要說明的是，鎖請(qǐng)求掛起的信息雖不是很關(guān)鍵，但它對(duì)GLM和Master上的鎖調(diào)度決策很有用，因此也會(huì)傳遞給GLM。華為云數(shù)據(jù)庫最終選擇了這種方法。

在華為云數(shù)據(jù)庫中，GLM只管理頁鎖，不授予或釋放行鎖，但頁鎖信息中跟隨有行鎖信息。GLM將頁面上的鎖授予Master時(shí)，會(huì)將頁的版本號(hào)（如果有）發(fā)給Master，從而該Master將擁有頁的最新版本，以及頁上的行鎖列表。接收了頁鎖的Master會(huì)將行鎖信息添加到其本地鎖管理器LLM中。當(dāng)Master釋放頁鎖（自愿或響應(yīng)請(qǐng)求）時(shí)，它向GLM遞交頁面版本號(hào)和頁面上的行鎖列表。

在不涉及數(shù)據(jù)一致性的前提下，Master上的行鎖更改不需要立即與其他Master同步。除非另外的Master要請(qǐng)求鎖定的頁面與當(dāng)前Master是有鎖沖突的同一個(gè)頁面。這種情況下頁鎖釋放和回收流程將被啟用，行鎖信息被一并發(fā)送到GLM，將很好地避免行鎖授予或等待時(shí)頻繁聯(lián)系GLM，可以顯著減少行鎖網(wǎng)絡(luò)流量。以下是更詳細(xì)的流程：

??釋放頁鎖時(shí)（自愿或被動(dòng)響應(yīng)回收）：

–Master上：有關(guān)頁面上所有行鎖的信息將發(fā)送到GLM。

–GLM上：接收到的行鎖信息緩存在內(nèi)存中。

??請(qǐng)求和授予頁鎖時(shí)：

–Master上：為了響應(yīng)本地事務(wù)的行鎖請(qǐng)求，Master必須持有行所在頁上的鎖。如果Master沒有拿到所需的頁鎖，它會(huì)首先向GLM發(fā)送頁鎖請(qǐng)求。

–GLM上：當(dāng)頁面鎖請(qǐng)求到達(dá)時(shí)，GLM會(huì)判斷同一頁面是否有其他沖突鎖或者掛起的其他Master鎖請(qǐng)求，如果有，新的Master所請(qǐng)求需要等待。當(dāng)GLM準(zhǔn)備好授予頁鎖時(shí)，它首先回收頁面上的沖突鎖（如果有），并捕獲新接收到的行鎖信息；之后將頁面鎖授予Master，并將響應(yīng)消息、行鎖信息及頁面的最新版本號(hào)一并發(fā)給Master。

–Master上：收到頁鎖授權(quán)響應(yīng)消息后，將行鎖信息添加到LLM（Local Lock Manager）中，并刷新頁面版本號(hào)。本地事務(wù)再次嘗試后可以成功獲取所需的行鎖。

三、華為云數(shù)據(jù)庫多主架構(gòu)效果驗(yàn)證

我們首先測試了華為云數(shù)據(jù)庫多主架構(gòu)自身的性能和可擴(kuò)展性。同時(shí)，我們將華為云數(shù)據(jù)庫多主與亞馬遜的Aurora 多主（我們所知的唯一一個(gè)云原生Shared-storage數(shù)據(jù)庫）進(jìn)行了對(duì)比。最后，我們還將華為云數(shù)據(jù)庫多主與Shared-nothing架構(gòu)的CockroachDB進(jìn)行了對(duì)比。

優(yōu)化鎖協(xié)議減少網(wǎng)絡(luò)消耗，測試環(huán)境說明

實(shí)驗(yàn)驗(yàn)證運(yùn)行在一個(gè)最多8個(gè)主節(jié)點(diǎn)的集群上，并在4個(gè)具有相同硬件配置的節(jié)點(diǎn)上部署了存儲(chǔ)層（數(shù)據(jù)存儲(chǔ)和日志存儲(chǔ)）。詳細(xì)見表1。

在所有實(shí)驗(yàn)中均使用了兩個(gè)標(biāo)準(zhǔn)工作負(fù)載：Sysbench和Percona TPC-C。

Sysbench是一個(gè)流行的基準(zhǔn)測試，它可以生成插入、刪除、更新、點(diǎn)查、范圍查詢及這些類型的各種組合。我們擴(kuò)展了Sysbench，以便控制數(shù)據(jù)共享的程度。

在一個(gè)由N個(gè)主節(jié)點(diǎn)組成的集群上，實(shí)驗(yàn)將表邏輯上分為N+1組。前N組中的表是私有表，即每個(gè)組被分配給一個(gè)單獨(dú)的主節(jié)點(diǎn)，只有指定的主節(jié)點(diǎn)可以訪問對(duì)應(yīng)組中的表。最后一個(gè)組是共享的，即任何主節(jié)點(diǎn)都可以訪問此組中的表。

當(dāng)實(shí)驗(yàn)指定共享程度為X%時(shí)，表示X%的數(shù)據(jù)庫讀寫訪問是針對(duì)共享表進(jìn)行的，其余的讀寫訪問是針對(duì)私有表進(jìn)行的。完全分區(qū)的工作負(fù)載對(duì)應(yīng)于X=0%，完全共享的工作負(fù)載對(duì)應(yīng)于X=100%。實(shí)驗(yàn)設(shè)置中，對(duì)于共享工作負(fù)載場景，每個(gè)組包括100個(gè)表，每個(gè)主節(jié)點(diǎn)訪問100個(gè)私有表以及100個(gè)共享表。對(duì)于完全分區(qū)的工作負(fù)載，每個(gè)組包含200個(gè)完全分區(qū)的表。每個(gè)表有2.35M行數(shù)據(jù)，每行約200字節(jié)， 因此對(duì)于所有的實(shí)驗(yàn)，每個(gè)主節(jié)點(diǎn)都可以訪問約100GB的數(shù)據(jù)。

TPC-C是評(píng)估OLTP系統(tǒng)性能的行業(yè)標(biāo)準(zhǔn)性基準(zhǔn)。數(shù)據(jù)按倉庫跨主節(jié)點(diǎn)分區(qū)，但10%的事務(wù)訪問了遠(yuǎn)程的數(shù)據(jù)分區(qū)。除非另有說明，我們使用的是1000個(gè)倉庫配置。

?華為云數(shù)據(jù)庫多主性能測試結(jié)果

華為云數(shù)據(jù)庫多主在Sysbench只寫、Sysbench讀寫（80%讀取，20%寫入）和TPC-C基準(zhǔn)測試上的性能表現(xiàn)如圖3所示，3(a-c)。

• 在X軸上，集群大小從1個(gè)主節(jié)點(diǎn)到8個(gè)主節(jié)點(diǎn)。

• 在Y軸上，顯示了絕對(duì)吞吐量以及相對(duì)于單個(gè)主節(jié)點(diǎn)的吞吐量。

• Sysbench測試結(jié)果的每條線對(duì)應(yīng)不同程度的數(shù)據(jù)共享。TPC-C使用的是固定的10%共享查詢。

• 對(duì)于只讀工作負(fù)載，由于多版本的存在，其可以完美地?cái)U(kuò)展，因此這里略去不顯示

從圖中可以看出，對(duì)于完全分區(qū)的工作負(fù)載，隨著主節(jié)點(diǎn)數(shù)量的增加其性能幾乎線性擴(kuò)展。8個(gè)主節(jié)點(diǎn)集群規(guī)模下，10%共享的Sysbench只寫和讀寫場景，相較單個(gè)主節(jié)點(diǎn)，分別實(shí)現(xiàn)了3.5倍、4.5倍的加速；TPC-C工作負(fù)載下，相較單個(gè)主節(jié)點(diǎn)，實(shí)現(xiàn)了5倍的加速。

正如預(yù)期的一樣，可擴(kuò)展性受數(shù)據(jù)共享程度的影響較大。同樣8個(gè)主節(jié)點(diǎn)集群上，30%共享負(fù)載下的只寫和50%共享負(fù)載下的讀寫，相較單個(gè)主節(jié)點(diǎn)，均實(shí)現(xiàn)了不到2倍的加速。

由于可用的硬件有限，我們未驗(yàn)證16個(gè)主節(jié)點(diǎn)集群的結(jié)果，但從圖中不難看出，8個(gè)主節(jié)點(diǎn)的可擴(kuò)展性已接近線性。

圖3. 華為云數(shù)據(jù)庫多主Sysbench和TPC-C性能測試結(jié)果

?與Aurora多主的性能對(duì)比

圖4對(duì)比了基于相同CPU核數(shù)和內(nèi)存緩沖池情況下華為云數(shù)據(jù)庫多主和Aurora多主的性能。在所有測試中，我們觀察到單主情況下，華為云數(shù)據(jù)庫的性能超過了Aurora。由于Aurora多主除了計(jì)算層之外，未暴露其他硬件細(xì)節(jié)，因此我們只測試對(duì)比了各自相對(duì)于其單主的性能數(shù)據(jù)。鑒于Aurora不允許超過4個(gè)主節(jié)點(diǎn)，因此8個(gè)主節(jié)點(diǎn)性能測試僅在華為云數(shù)據(jù)庫多主上進(jìn)行。對(duì)于完全分區(qū)的工作負(fù)載，兩個(gè)數(shù)據(jù)庫的擴(kuò)展幾乎相同，故測試時(shí)省略了不同分區(qū)負(fù)載的差異對(duì)比，而是選取了具有代表性的10%共享負(fù)載做性能對(duì)比測試。在此較小的共享負(fù)載場景下，華為云數(shù)據(jù)庫處理工作負(fù)載的能力要好得多。在共享寫入工作負(fù)載場景下，我們發(fā)現(xiàn)Aurora中所有主節(jié)點(diǎn)上存在大量因沖突導(dǎo)致的被中止事務(wù)，從而帶來主節(jié)點(diǎn)之間的性能不均衡。華為云數(shù)據(jù)庫的多主由于其基于混合行頁鎖的并發(fā)控制，未發(fā)生任何事務(wù)中止。

圖4 華為云數(shù)據(jù)庫多主 VS Aurora多主

?與CockroachDB的性能對(duì)比

我們還將華為云數(shù)據(jù)庫多主與基于Shared-nothing架構(gòu)的CockroachDB（簡稱CRDB）進(jìn)行了比較。之所以選擇CRDB，是因?yàn)樗情_源的，且根據(jù)相關(guān)報(bào)告分析，其性能比Spanner和TiDB更好。

實(shí)驗(yàn)使用兩種配置規(guī)格，即分別將CRDB和華為云數(shù)據(jù)庫部署在相同的6節(jié)點(diǎn)和12節(jié)點(diǎn)集群上，從而比較相同硬件條件下雙方的性能。

由于華為云數(shù)據(jù)庫專門使用4個(gè)節(jié)點(diǎn)用于存儲(chǔ)層，而CRDB為Shared-nothing架構(gòu)，每個(gè)節(jié)點(diǎn)上既有計(jì)算層又有存儲(chǔ)層，因此將6個(gè)和12個(gè)節(jié)點(diǎn)CRDB分別與2個(gè)主節(jié)點(diǎn)和8個(gè)主節(jié)點(diǎn)的華為云數(shù)據(jù)庫多主進(jìn)行了比較。

對(duì)于CRDB和華為云數(shù)據(jù)庫多主，實(shí)驗(yàn)時(shí)使用了盡可能大的連接數(shù)來提高吞吐量。對(duì)于華為云數(shù)據(jù)庫多主來說，每個(gè)主節(jié)點(diǎn)上的連接數(shù)為64個(gè)；對(duì)于CRDB，每個(gè)主節(jié)點(diǎn)上的連接數(shù)從128到512不等。

在CRDB上，我們運(yùn)行了CRDB附帶的類似TPC-C的基準(zhǔn)測試。對(duì)于華為云數(shù)據(jù)庫多主，我們運(yùn)行了Percona TPC-C。在表2中列出了1000和5000個(gè)倉庫的結(jié)果。對(duì)于每次運(yùn)行，我們記錄了每秒可處理的新訂單事務(wù)數(shù)（tpmC）、事務(wù)平均請(qǐng)求時(shí)延和95%事務(wù)的請(qǐng)求時(shí)延。在所有測試場景下：

• 華為云數(shù)據(jù)庫多主吞吐量都明顯更高，從6節(jié)點(diǎn)、5000個(gè)倉庫的吞吐量高出60%，到12個(gè)節(jié)點(diǎn)、1000個(gè)倉庫的吞吐量高出320%。

• 華為云數(shù)據(jù)庫雙主的交易延遲也要低得多，平均請(qǐng)求時(shí)延和95%事務(wù)的請(qǐng)求時(shí)延均低得多。

• 我們還計(jì)算了一個(gè)擴(kuò)展比，即12節(jié)點(diǎn)相較6節(jié)點(diǎn)其吞吐量的增加比例，華為云數(shù)據(jù)庫多主要優(yōu)于CRDB。

正如引言中所指出的，Shared-nothing架構(gòu)的開銷受分布式事務(wù)提交的影響更明顯，分布式事務(wù)提交的開銷隨著事務(wù)中涉及的節(jié)點(diǎn)數(shù)量的增加而增長。對(duì)于給定的工作負(fù)載，效率受限于事務(wù)復(fù)雜性。

表2 華為云數(shù)據(jù)庫多主 VS CockroachDB: TPC-C結(jié)果

四、總結(jié)

華為云數(shù)據(jù)庫多主是專門為云環(huán)境設(shè)計(jì)的云原生多主OLTP數(shù)據(jù)庫系統(tǒng)。它是一個(gè)存算分離的云原生數(shù)據(jù)庫系統(tǒng)，使用全局鎖管理器來協(xié)調(diào)對(duì)數(shù)據(jù)庫頁和行的讀寫訪問?，F(xiàn)實(shí)業(yè)務(wù)中的許多OLTP工作負(fù)載大多是可分區(qū)的，其中只有一小部分頁面在多個(gè)主節(jié)點(diǎn)之間共享。例如，在TPC-C中，只有10%的訪問是對(duì)遠(yuǎn)程倉庫的訪問。華為云數(shù)據(jù)庫多主設(shè)計(jì)的一個(gè)關(guān)鍵目標(biāo)是為了在共享程度低的工作負(fù)載上實(shí)現(xiàn)良好的性能和可擴(kuò)展性。

華為云數(shù)據(jù)庫多主采用了兩個(gè)關(guān)鍵創(chuàng)新技術(shù)：VS（vector-scalar）時(shí)鐘和混合行頁鎖，旨在降低網(wǎng)絡(luò)負(fù)載和提高性能。VS時(shí)鐘通過對(duì)系統(tǒng)中更頻繁的消息（日志記錄）使用單個(gè)標(biāo)量時(shí)間戳，而數(shù)量很少的消息使用矢量時(shí)間戳來降低網(wǎng)絡(luò)負(fù)載。同時(shí)，使用VS時(shí)鐘，系統(tǒng)保留了查看系統(tǒng)級(jí)事務(wù)一致性狀態(tài)的能力?；旌闲许撴i技術(shù)通過減少發(fā)送到全局鎖管理器的鎖請(qǐng)求數(shù)量來提高事務(wù)吞吐量和減少延遲。特別是，如果頁面被主節(jié)點(diǎn)訪問一段時(shí)間后，行頁鎖將自動(dòng)委托給單一的主節(jié)點(diǎn)。我們的實(shí)驗(yàn)結(jié)果證實(shí)了華為云數(shù)據(jù)庫多主系統(tǒng)的性能和可擴(kuò)展性。在TPC-C基準(zhǔn)測試中，4個(gè)主節(jié)點(diǎn)的最大擴(kuò)展效率為84%， 8個(gè)主節(jié)點(diǎn)的最大擴(kuò)展效率為62%。在最大8個(gè)計(jì)算節(jié)點(diǎn)的集群上，華為云數(shù)據(jù)庫多主在TPC-C上展示了優(yōu)于Aurora多主和CRDB的性能。