作者介紹

房曉樂（蔥頭巴巴），PingCAP 資深解決方案架構師，前美團資料庫專家、美團雲 CDS 架構師、前搜狗、百度資深 DBA，擅長研究各種資料庫架構，NewSQL 佈道者。

2017年，Amazon 在 SIGMOD 上發表了論文《Amazon Aurora: Design Considerations for High Throughput CloudNative Relational Databases》，本文按照該論文的主線並結合作者的理解，對Aurora進行解讀。這裡面涉及到很多知識點，筆者會在每章的末尾標註關鍵字，如果需要更好的理解，需要讀者對關鍵字進行搜尋理解。

前言

首先，Aurora 是依託於 AWS 雲高度融合 MySQL 定位於 OLTP 的企業級關係資料庫，Aurora 的設計者認為，當前海量資料處理的主要瓶頸已經從計算、儲存 IO 轉移到了網路 IO (1)，為了解決這個問題，Aurora 通過將重做日誌推到多租戶的大規模儲存服務當中（Aurora 的設計哲學是 log is database）（2），從而不僅大幅度的減少了網路 IO，而且可以資料的多副本進行快速故障恢復，以及容錯損失，建立起一套自愈儲存（Aurora 將恢復子系統委託給底層可靠的儲存系統，依賴這個來保障系統服務層級（ServiceLevel Agreement, SLA））。

Keyword：OLTP、log is database、log processing、quorum models

1. 當前資料庫在 M-S 的基礎上，產生有很多優化變種，比如 Sharding、擴容，這樣單個節點的儲存 IO 可以有效進行控制，但由於節點間的不經濟的複製、互動導致網路 IO 擴大。
2. 下文有專門闡述章節。

背景介紹

Aurora 介紹

現在 IT 逐漸在公有云遷移，其中大多需要 OLTP 資料庫系統，能夠提供一個等同或者更優的資料庫是加速這種轉型的關鍵。在現在分散式雲服務中，通過對計算與儲存的解耦，以及對儲存的多節點複製，增加系統的彈性及擴充套件性，這樣我們也能夠進行刪除問題節點、增加副本、寫節點切換等。但在這種環境下，傳統資料庫系統所面臨的 I/O 瓶頸發生變化。由於 I/O 可以在多個節點和多個磁碟傳播，單個磁碟和節點瓶頸不在。瓶頸轉移到資料庫與多節點儲存直接的網路互動，尤其在對儲存進行並行寫的時候，網路頻寬的頻寬或者流量（PPS）可能導致響應時間變慢。

同時傳統（包括分散式）資料庫需要複雜的髒資料刷機機制，事務提交也需要很多互動，事務提交普遍採用 2-phase commit 機制（2PC)，這些在雲環境下都需要進行改變（優化）（Aurora 的設計哲學是 log is database，對資料的更改只寫日誌，也即 write-once，大大簡化了傳統資料庫的寫入機制）。

Aurora 使用了一種新的體系結構（見下圖）它將 logging 和儲存從資料庫引擎中剝離到分散式的雲端儲存環境中，雖然例項還包括大部分的傳統核心元件（查詢處理器、事務、鎖、快取、訪問機制和回滾管理），但其中的幾個功能（重做日誌、資料持久化、閃崩恢復、備份/還原）則被下傳到了儲存服務層。

Keyword：2-phase commit 、write-once

Aurora 主要優勢

• 通過將儲存構建為跨多個數據中心的獨立容錯和自愈的服務，使儲存層中資料不受效能差異和單節點瞬態或永久故障的影響。
• 只寫重做日誌記錄儲存，我們可以減少一個數量級的網路 IOPS 。一旦消除了這個瓶頸，就可以積極地優化許多其它爭點，在 MySQL 基礎程式碼基礎上獲得顯著的吞吐量改進。
• Aurora 用儲存層持續非同步複製操作，替代資料庫引擎中最複雜、最關鍵、最昂貴的備份和重做恢復功能（backup and redo recovery），這是不需進行儲存檢查點（checkpoint）、不對資料庫程序處理進行干擾的低成本的備份恢復機制。

Aurora 三個問題

但同時同樣引入三個問題：

1. 如何在雲端儲存上進行資料永續性，以及如何對節點故障進行選舉仲裁。
2. 如何使用這個自動同步儲存系統，併發揮其最大作用。
3. 如何消除分散式儲存中的多階段同步、崩潰恢復和檢查點。

Keyword：checkpoint、crash recovery、redo log、redo recovery、quorum model

傳統資料體系背景知識

在解決上面三個問題前，我們先回顧下傳統關係資料庫體系結構，DB 在處理事務的過程通常被視為一種分層的行為。系統在頂層對 SQL 語句進行解析，然後將得到的語法樹傳遞給查詢優化器層。查詢優化器通過統計資訊進行最優路徑選擇（CBO），這個階段產生的物理執行計劃與邏輯儲存層互動，完成相應的操作。

在本文中，將事務處理引擎簡化為兩層模型：SQL 解析、SQL 執行以及優化視為查詢處理引擎（Process Engine，PE）；邏輯層儲存和物理層儲存統稱儲存引擎（Storage Engine，SE）。這對應 MySQL 可插拔儲存的兩層架構。

定義資料庫伺服器叢集的架構決策的關鍵點在於叢集共享、複製發生的階段，協調動作發生在什麼層以及哪個層。這不僅確定了系統在可擴充套件性和靈活性上的權衡，而且關係到每一種架構在現成的資料庫伺服器上的適用性。以下是具有代表性的架構：

資料庫架構分類整理

我們對這四種主要的架構進行下整理彙總（除此之外還有 shared nothing 純分散式架構）：

Aurora 的架構可謂獨樹一幟，它的體系架構類似 SDP，但是它將更新限制在一個 DB 例項上，避免了分散式併發控制協議。Aurora 設計者們認為，傳統的資料庫實現可擴充套件不管是做 Sharding、還是分散式、或者共享儲存（Oracle RAC），本質上都是在資料庫的不同層面耦合（SNA 在應用層連線層，SDP 是在程序和快取層），擴充套件後的每個例項的程式棧仍然是原來的多層結構。Aurora 認為從成本、部署靈活性及可用性等因素考慮，應該考慮把資料庫的各層開啟，然後在每個層單獨做擴充套件。傳統的資料庫系統，例如 MySQL、PostgreSQL 以及Oracle，將所有的功能模組封裝成一個整體，而 Aurora則是將資料庫的緩衝區管理、恢復系統（recovery）從這個整體剝離出來，單獨定製擴充套件。

Keyword：Shared Nothing、Shared disk、Garela、Group Replicatio、dbproxy、Oracle RAC

Aurora 多節點持久化

Aurora 複製及相關失敗處理：

磁碟、網路、機櫃、機房等都有一定的故障率，並且日常維護重啟、升級等操作會增加這類臨時不可用時間。一般採用多副本選舉來解決該問題：例如 3 個副本的情況下，寫必須要有 2 個以上（Majority）副本寫成功才可以，在讀的情況下也必須保證有 2 個:V-Read + V-Write> V-Copy。Aruora 設計中使用了 3 AZ（可用區），每個 AZ 下 2 Copy 的設定，共計 6 個副本。AWS 傳統的服務，例如 S3、Kinesis 等都是 3 副本設計。這樣的設定主要從實際觀察情況出發：

1. 在同一個 AZ 下下硬碟、節點損壞、維修等是常態。在同一個 AZ 下設定 2 Copy 可以儘可能減少這類操作對用可用性影響。
2. 機房級  AZ 問題不常發生，例如水災、火災、地震等故障。

在寫入場景下 6 Copy 需要保證 4 個副本完成，在讀場景下只要 7-4=3 個副本一致就可以了。

段儲存（segmented storage）

Aurora 下儲存最小單位叫 Segment，每個 Segment 大小為 10GB，Protection Group（PG）是一個邏輯單位，代表的是 6 個Segment，Segment 是維護與排程的最小單元，一個Segment 故障時，同 AZ 的萬兆網路可以在 10 秒內就完成修復（這也是選擇 10G 的原因），儲存節點 Segement 這種設計對於日常運維比較重要，例如在熱點問題上（Heat Management)，我們可以在一個熱磁碟或節點上標記一個片段是壞的，衝裁系統（quorum）可以通過快速遷移到另一個較冷的節點，作業系統和安全修補程式甚至儲存機群升級都是該節點的一個簡短的不可用事件，一次執行一次，確保各 PG 的成員不同時被修補。實現了在儲存服務中使用敏捷和快速部署。

Log is database

傳統資料庫中的在寫入頁面物件（如堆表、B-TREE 等）之前，都需要先寫入重做日誌，（wirite-ahead log WAL機制）。並且每個重做日誌記錄還包含修改前、修改後的資料。除此之外，其它資料也需要寫入，在下面基於多資料中心的熱備架構（active-standy）（構建在 EBS 上）（下圖）中，一個簡單的寫入被放大很多倍（自己算吧）。

1. Redo Log
2. Binlog（臨時儲存最後 N個）
3. Data（最新資料庫結構資料，記憶體中定時 Dump）
4. FRM Files（這個資料量一般比較小）
5. Double-Write  ( MySQL 資料重新整理的一個優化，將 dirty page 拷貝到 double write buffer 記憶體區域，便於髒資料重新整理過程中失敗恢復。)

keywords：DOUBLE-WRITE、Binlog

為了解決這個寫入放大的問題，Aurora 提出的思路是，唯一的寫入只包括通過網路寫入 Redo log（不在有後臺的寫入、checkpoint、髒資料），直接將 Redo log 下推到儲存節點，每個儲存節點根據 Redo log 來構成本地（Local Segment）儲存狀態，多個儲存可靠性通過副本數來保障。每個儲存節點也可以將Segment 定時同步到 S3 上增加可靠性。

下圖顯示了一個主多從的叢集。主庫只將日誌記錄寫入儲存服務，並將這些日誌記錄傳送到從例項。IO 批量流入一個共同的目的地（邏輯段，即一個 PG）來完全記錄日誌記錄，並將每個批次傳給所有 6 個副本繼續持久化，資料庫引擎從從 4 處（4/6）等待確認，從庫使用重做日誌將更改應用到其緩衝區快取。

閃崩處理，在傳統資料庫中，閃崩後資料庫需要從最近的一次 checkpoint 開始應用所有重做日誌進行恢復，在 Aurora 中，持久化重做日誌會多節點連續的、非同步同步，任何一個讀請求都有可觸發重做日誌對舊的頁進行應用（重做日誌隨時應用），所以正常情況下，資料啟動後基本上不用做什麼恢復操作。

在 Aurora 的設計思路中，儲存服務的核心設計原則是最小化前臺寫請求的延遲（快速響應），將大多數儲存處理移到後臺，同時他也有機制去避免後臺儲存高峰導致前臺延遲，例如，當儲存節忙於處理前臺寫請求時，不需要執行舊版本資料頁的收集（GC），除非磁碟接近容量，在 Aurora 後臺處理與前臺處理是負相關的（傳統資料庫往往是正相關），後臺頁面和檢查點的後臺寫入與系統上的前臺負載正相關，如果在儲存系統上建立了一個積壓，將關閉前臺活動，以防止長時間的佇列堆積（這個思想，類似單例項的重新整理機制，會自動選擇空閒情況下進行髒資料持久化）。由於在系統中的各個儲存節點上放置了高熵值，所以在一個儲存節點上的節流很容易被 4/6 次仲裁寫入處理，以慢節點的形式出現。（有點類似傳統的 M-S 架構中，從庫延遲後，摘掉讀流量）（這裡面隱含另外一個問題，如果是整體負載導致的儲存積壓，關閉一個節點可能導致雪崩，在論文裡沒有發現相關的解讀，可能 Aurora 的設計者認為這種情況概率很低，或者認為儲存處理能力應用遠大於計算節點。）

讓我們更詳細地看下儲存節點上的各步驟。如上圖所示，它包括以下步驟：

1. 接收日誌記錄並新增到記憶體中的佇列
2. 記錄在磁碟上並進行 ack 返回
3. 對於批量 Redo log 進行整理，確定沒有批次丟失
4. 與其它副本儲存節點進行對齊（通過 Gossip 協議，它們可以知道叢集中有哪些節點，以及這些節點的狀態，每一條 Gossip 訊息上都有一個版本號，節點可以對接收到的訊息進行版本比對，確保二者得到的資訊相同）
5. 日誌記錄合併到新的資料頁
6. 定期將日誌和新的頁面複製到 S3
7. 定期進行過期版本垃圾資料回收
8. 定期驗證 CRC 碼頁，如果發現損壞資料塊，與相鄰節點進行通訊獲取完好的資料塊。這是 Aurora 實現可自主修復損壞資料塊的關鍵技術

注意，只有步驟 1 和 2 完成，前臺即完成（commit），其它操作都是非同步進行。

Aurora 讀寫處理過程

術語解釋

這塊內容比較燒腦，有些地方原論文寫得也很模糊，需要加上一些猜測和理解，其中裡面也有很多術語，我們先把主要的進行簡單解釋：

• LSN：LogSequence Number 日誌順序號，每個日誌都有一個自動增長順序號（傳統的MySQL 也有這個概念，類似 Oracle 的 SCN）
• VCL：VolumeComplete LSN 儲存可以保障的可用的最高 LSN
• CPLs：ConsistencyPoint LSNs  一致點的 LSN
• VDL：VolumeDurable LSN 已經持久化最大的 LSN，最大的 CPLs
• SCL：SegmentComplete LSN 已經完成的段的日誌號

Aurora 寫操作

在 Aurora 中，資料庫不斷與儲存服務互動，並維護節點狀態以便進行仲裁、更新最新的持久化的卷（VDL)。在正常情況下，資料庫根據每個節點的重做日誌記錄，來更新目前 VDL 。資料庫隨時都會有大量併發事務，它們各自生成自己的重做日誌記錄。資料庫為每個節點分配唯一順序的 LSN 對其進行約束，該 LSN 等於當前 VDL 和定量 LSN Allocation Limit (LAL)之和（目前為 1000 萬）（VDL + LAL）。此限制確保資料庫不會超前於儲存系統很多，如果儲存或網路無法跟上，則可降低傳入寫入的壓力。注意，每個 PG 片段只看到已影響該卷中日誌記錄的一個子集（affect the pagesresiding on that segment）。每個日誌記錄包含一個連結，指向之前的記錄，通過這個反向連結，可用於跟蹤已經在每個段建都完成的日誌點，並根據這個確定已經完成的 LSN 終點（SCL），最終知道哪些記錄已經到達該節點上。每個儲存節點互相通訊（gossip），通過 SCL 用於查詢和交換丟失的日誌記錄。

Aurora 提交

在 Aurora 中，事務提交是非同步完成的。當用戶提交一個事務，執行緒將事務移動到提交列表，寫下該事務的 commit LSN ，然後執行緒繼續執行其它工作（和傳統不一樣）。這相當於在 WAL 的基礎上，完成一個承諾，當且僅當新的 VDL 大於或等於事務提交 LSN（commitLSN ≤ VDL）。等待提交會使用專用執行緒傳送到儲存節點，收到對應批次的日誌記錄的 4 個 ACK。

在傳統 MySQL 資料庫中，為了減少磁碟 IO 採用成組提交技術。第一個寫日誌緩衝區的執行緒需要等待預先設定的時間，然後再執行磁碟 IO 操作；或者等到日誌緩衝區頁寫滿以後再執行 IO 操作。這樣子做的結果是第一個寫日誌緩衝區的執行緒需要掛起等待，耗費時間。這是一個同步操作，在持久層儲存的 ACK 返回之前不能進行其它工作。

下圖提交佇列裡面有 3 個掛起的提交請求，分別是 Pending commit group1，Pending commit group2，以及 Pending commitgroup3。主例項收到針對 Pending group commit1 的 4 個以上的日誌持久化 ACK以後，將系統 VDL 前移至 22，第一組的狀態從pending 變成 committed。此時後臺執行緒檢查提交佇列，然後成批提交 LSN 小於等於 22 的事務 T1，T2，T3。

注意，即使後面 Pending commit group3 先於 Pending commitgroup2 收集 4 個以上的儲存節點返回的持久化 ACK，那麼也不能移動資料庫持久化位點。因為，這個資料庫持久化位點是 Aurora 崩潰恢復以後決定開始重做的位點。跳過前面的成組提交的 LSN 會導致資料庫丟失某些資料。在系統崩潰恢復的時候，系統檢索最新的資料快照與相應的日誌記錄（其 LSN 大於資料庫持久化位點），即可將資料庫恢復到最新的一致性狀態。

Aurora 讀操作

和大多數資料庫一樣，Aurora 讀操作首先會在快取區裡進行掃描，如果快取裡沒有對應資料，才會將請求下發到儲存系統，如果快取區滿了，則需要將一些頁面進行擠出（部分頁面是受保護的），如果快取區裡有髒資料，則需要像將髒資料持久化到磁碟，這樣才能確保其他的事務可以讀到最新的資料。

只有當快取區頁面的 LSN （標記該頁面的最新版本日誌號）大於或等於 VDL 時，該頁面才可能被刷出，在這之前這個頁面是受保護的，這個機制確保了：

1. 所有頁面的更新都已經持久化到日誌。
2. 在快取區沒有該資料頁的情況下，可以根據 VDL 獲取最新版本資料。

正常情況下，資料庫讀操作並不需要採用多數投票的方式，當從磁碟讀取資料時，會分配一個讀位點（read point），這個點代表產生時刻的 VDL，同時資料庫在儲存節點維護 SCL，系統根據讀位點和 SCL 來確定從哪個儲存節點進行讀取，只有當故障恢復或者必要的時候，才會根據多數投票的方式來確定系統的 VDL。

Aurora 複製

在 Aurora 中，多達 15 個副本都可以裝入單個共享儲存卷。因此，讀副本不會在寫操作方面增加額外的開銷。為了最小化延遲，寫入同時傳送到所有副本上。

Aurora 恢復

Aurora 將資料庫檔案切分成 10GB 大小的塊，每個塊都有專屬的日誌記錄。在崩潰恢復的時候，系統利用多數派讀，確定執行時的一致性狀態。恢復模組首先確定最大 VCL（最大的順序 LSN），截斷此後日誌。進一步，可以將需要重放的日誌限制在其 LSN ≤ CPL。VDL 取最大的CPL，LSN 大於 VDL 的日誌記錄都可以安全地截斷。例如，最大已完成的日誌記錄的 LSN 為 1007（尚未提交），但是系統的 CPL為 990,1000, 1100。系統可以確定 LSN 大於 1000 的日誌記錄都可以忽略。確定完重放日誌的 LSN 最大值以後，Redo 操作就可以並行在不同 Segment 上執行了。

部署

在原論文裡，該章節的標題直接寫成了 PUTTING IT ALL TOGETHER，筆者的理解是它想表達 Aurora 和 AWS 現有框架下的多種雲產品進行整合，形成了一個整體資料庫雲服務。先來幅鳥瞰圖：

如圖，應用通過 VPC（私有虛擬網路） 接入，然後可以讀寫位於不同 AZ ( 可用區 ) 的資料庫。資料庫的部署是一主多從的叢集架構，一個寫入的主節點（ Aurora 不屬於完全的分散式架構），多個只讀的從節點，從節點+備節點最多可以有 15 個（為啥？AWS共享儲存系統可以讓 15 個副本裝入單個共享儲存卷）。節點之間通過 RDS ( RelationalDatabase Service ) 來互動，RDS 在這裡充當 HM ( Host Manager ) 角色，它通過 Agent 來獲取主從叢集的狀態監控、當主節點 Failover 的時候，它會進行 HA 排程、或者某個從節點 Failover 它會進行下線替換。這個負責監控、管理的節點，稱為 Controlplane 。

基準測試

這個直接轉載自論文的資料，目前還無從實測，不過從上面的設計理念上，有可能是會大幅度提升的，不做過多評論，我們只關心寫入效能。

Aurora vs TiDB（Spanner&F1）

回顧資料庫的發展歷史，我們可以簡單分成三個階段，從上實際 70 年代 E.F. Codd 提出關係模型到本世紀初，基本上是以單機關係型資料庫為主，如 Oracle、MySQL、PostgreSQL，但隨著網際網路搜尋、社交的發展、資料量爆發增長，傳統資料庫高成本，無法線性擴充套件問題日益凸顯，分散式 NoSQL 快速發展，如 HBase、MongoDB，近幾年來，大家發現很多的業務並沒有辦法直接使用 NoSQL 的模型，應用需要很複雜的開發才能實現 SQL 和事務能很簡單實現的功能，所以新一輪的資料庫開始了 SQL 迴歸，這種可擴充套件、高效能、支援 SQL 和事務的資料庫被大家泛稱為 NewSQL。

NewSQL 又分為不同的方向，除了本文提到的雲端計算 RDS，還有分散式關係資料庫，其中的代表產品如谷歌的 Spanner&F1，還有國內人氣廠商 PingCAP 的 TiDB，TiDB 具有支援 SQL、水平彈性擴充套件、資料強一致性的高可用等特性，篇幅限制，這裡不展開，詳情可參考 TiDB 的官方文件 (https://pingcap.com)。

雖然 Aurora、TiDB 是兩個不同方向的產物，但作為兩個引領潮流的資料庫產品，筆者按照體系結構、資料格式、儲存引擎、容量能力、擴充套件性、相容性、移植性、靈活性、讀寫效能、記憶體機制、異地多活等若干維度進行下對比：

Aurora

• 架構：屬於 Shared disk 架構（儲存可以簡單理解為共享，實際上是一套多副本複製儲存）。
• 儲存：資料格式屬於傳統的表結構（InnoDB 引擎）。
• 寫擴充套件：單點寫入，系統寫入效能有上限（雖然正在計劃中的 Multimaster 理論上也會提升寫吞吐，但是仍然受限於例項之間的記憶體互動及儲存之間的 Apply log），從寫流量看不屬於真正的 Scale out。
• 讀擴充套件：例項可彈性擴充套件。
• 大小限制：資料大小上限 64 T。
• 讀寫響應：大大簡化 commit 的機制，讀寫響應時間很好。
• 相容性：由於例項層本身就源於 MySQL，所以對 MySQL 相容性好（100%）。
• 移植性：移植性很差，它依賴 AWS 很多元件，尤其是底層的共享儲存系統，所以基本不具有移植性，它定位就是一套雲環境下 RDS。
• 靈活性：架構可改造性很差。
• 記憶體互動：日誌會在例項節點 Buffer 之間進行復制應用，通過這種“記憶體互動”方式讀效能會更優。
• 事務效能：不存在 2 PC 及寫擴大的問題，寫入效能上更優。
• 高可用：不是強一致機制，極端情況下通過其它節點可能讀不到最新的資料。
• 節點狀態：例項分主次，只能通過從庫選舉方式來進行例項層的高可用。
• 適合場景：主要解決的 OLTP 場景，它的優化器和 MySQL 一樣，不是為分散式系統設計。目前還不支援Hashjoin 、並行等技術（從2017 AWS Re:Invent 最新訊息看，後面會逐步支援，包括 Pushdown query），但綜合比較看仍不適合 OLAP 分析場景。
• 開源狀態：商業資料庫。

TiDB

• 架構：屬於 Shared nothing 的分散式架構，他通過 Raft 協議進 同步，實現每個 Raft group 內的資料強一致性。
• 儲存：資料格式是 KV，資料模型是基於 LSMTree 的模型，底層（Rocksdb）。
• 寫擴充套件：寫入分散式寫入，線性擴充套件，寫入容量理論上限很高，LSM 寫入效能更好。
• 讀擴充套件：儲存節點、例項節點都可進行線性擴充套件（讀寫擴充套件），屬於典型的 Scale out。
• 大小限制：理論無上限。
• 讀寫響應：兩階段提交、Raft 複製對響應時間都會有一定延遲成本。
• 相容性：高相容 MySQL 連線協議，但和 Aurora 比，不支援儲存過程，觸發器，相容性略差。
• 移植性：具有很好的移植性，支援多種部署方式，可以在公有云、私有云、私有環境下快速搭建。
• 靈活性：例項層、儲存層拆分的很清晰，獨立，可在 TiKV 上直接調研 API 、或者部署諸如 Tispark 完成架構的靈活多樣性。
• 記憶體互動：例項節點 Buffer 不存在互動機制，不能共享記憶體。
• 事務效能：分散式事務鎖機制，寫入效能，尤其是衝突比較多寫入場景效能較差。
• 高可用：只要網路條件允許，可以建立真正意義的異地多活分散式資料庫。
• 節點狀態：例項層無狀態，例項層的高可用更勝一籌。
• 適合場景：首先解決了 OLTP 場景，同時通過 Tispark 可以比較好的支援 OLAP 場景，而且由於共用一份 TiKV 叢集或者實時同步機制，能實現實時分析場景。
• 開源狀態：開源資料庫，社群活躍。

對比總結

兩個產品作為 NewSQL 的兩個方向，都屬於跨時代的產品，也都有很多令人激動的 Feature，他們用各自的方式提升、擴充套件了資料庫的寫入容量，都是替換 Sharding + Proxy 很好的方案，Sharding + Proxy 雖然是目前主流方案，但它存在很多問題，具體可關注筆者近期將釋出的另一篇文章《資料庫 Sharding +Proxy 方案成本彙總》。

Aurora 在記憶體一致性、讀寫效能、MySQL 相容性、事務限制、記憶體管理、Cash recovery 等方面優於 TiDB。但反過來 TiDB 在彈性擴充套件、架構的解耦性、靈活性、場景覆蓋等方面更勝一籌，更重要的是 TiDB 移植性很好，筆者覺得這點會成為兩類產品普及度一個很重要的因素，同時 TiDB是可以真正實現跨區域的異地多活的分散式資料庫。

總結

雲端計算的發展為儲存分離的提供了更多可能，也加速了這種趨勢，傳統關係型資料庫需要在單機層面花費了昂貴的成本去實現 ACID，這樣導致單機的容量非常有限，以 MySQL 為例，M-S 的架構雖然解決了讀流量的擴充套件問題，但寫流量成了最大的瓶頸（雖然有各種 Sharding、多主等方案，但本質上並未解決寫流量擴充套件問題），Aurora 依託自身的雲產品，把資料庫這個盒子開啟進行抽繭剝絲，通過把寫入、恢復等昂貴操作下沉到儲存服務中的方式，很大程度了提升了叢集的寫入容量，粗略估計可能會提升一個數量級，在這個容量範圍內的 OLTP 業務覆蓋量還是非常大的，但反過來說，這種架構本質上還是單節點寫入，而且從目前看上去 Aurora 在例項層改動很少，這麼看上去有點小馬拉大車的感覺，筆者把它理解為變向的Scale up。同時，Aurora 在自動拓展儲存容量、自動修復資料、閃崩恢復、將快取從例項中分離持久化進而解決了熱資料問題上都是值得借鑑的很好創新。Aurora 可以說是在雲環境下（AWS）量身定做的產物，它所依賴的共享儲存，不是簡單的共享，而是一個包含計算，能自動複製的共享儲存服務系統，但這一點就就很難進行復制。

最後，不管是計算與儲存分離的雲資料庫，還是分散式資料庫，NewSQL 的時代已經來臨。

原文來自微信公眾號：DBAplus社群