可否對比一下 TiDB 與 AWS Aurora ？

01-15

可否對比一下 TiDB 與 AWS Aurora ？

這是兩種分散式架構的不同實現（產品）。

AWS Aurora 是典型的shared disk架構，存儲層共享從而解決了一致性問題，上層的MySQL Cluster實例本身無狀態，一寫多讀，底層存儲架構在共享存儲上，S3做備份。數據模型跟MySQL一樣是基於Page的模型，總的來講，是一個基於共享存儲的優化的RDS.

TiDB是比較典型的shared nothing架構，SQL層需要感知replica元數據信息，多點寫入，通過raft來同步log，實現一個raft group內的數據一致性。數據模型是基於LSMTree的模型。

理論上Aurora的底層存儲可以無限擴展，考慮性能多個Aurora實例也可以再通過分庫分表的中間件(DRDS、MyCAT)來實現自動的sharding。而理論上TiDB也可以不分裂，退化成一個一寫多讀的RDS，不過storage層還是通過raftlog來維持一致。

圖引用自PPT:Deep Dive on Amazon Aurora

aurora和tidb可以說是兩個不同的參考方向的產物。

1. aurora引擎層仍是單機的，用了共享存儲的技術，提高了容災，寫入總容量，但他的協議層，事務管理，parser等等，只要不涉及存儲的部分，仍是如假包換的mysql源代碼。這樣的改變後，aurora變成了小馬拉大車的單機引擎，oltp，olap都是走單機計算，共享存儲的路線，本質上不涉及分散式事務和分散式計算

2. tidb 走的是newsql路線，引擎和存儲都是分散式的，存儲還經過sharding，不共享內容，plan計算過程就涉及多機器，經常需要分散式事務和分散式計算

說完這些，再來說說各自的優缺點，aurora優點就是mysql 100%一致，你一個mysql 應用，啥都不改直接上都沒問題，因為它協議parser，plan全是原封不動的源碼，而tidb的話肯定是沒法直接從mysql應用搬過來的，說的90%兼容是一回事，所有sql返回結果集一毛一樣是另一回事。

而aurora肯定是不適合做olap的，不過它設計的本意就是解決容量問題，olap，數據導出來自己算吧，也算是瞄準一個痛點單點突破。

Aurora解決的是mysql/pg的高可用、讀寫分離、存儲計算分離部署的問題，寫入節點還是一個，本質上還是單機實例資料庫，與mysql/pg兼容性高，而可用性和只讀節點的彈性擴展能力比原生方案要高不少。

TiDB/Spanner/oceanbase是內部自動維護sharding的newsql資料庫，事務性能、彈性擴展能力更強，並且還有混合olap的潛力，是終極完美方案。局限是，再怎麼做，畢竟不是mysql代碼，兼容客戶端協議容易，兼容行為難，兼容bug更難，用戶不能毫無負擔的從mysql遷移過來。

換個角度看Aurora：緣何「萬能」？對比TiDB有何不同？這是我司一位同學寫的 Aurora 解讀文章，最後做了一些簡單的比較，供參考

這篇 ppt 講 spanner 與 aws aurora 做了下對比，挺有參考意義的： http://news.cs.nyu.edu/~jinyang/fa17-ds/notes/ds-spanneraurora.pdf

個人感覺論先進肯定是 spanner 先進，但是 aurora 的設計更討巧。

一般公司做選型的話，相對於財大氣粗的 "擴展性"，機器的 "利用率" 的實惠更容易看得到。兩者都做到存儲計算分離，不過 aurora 方案的成本似乎能更低一些。

spanner 先進的另一面是更高的複雜性，寫入操作經過分散式事務做協調，傳統資料庫做 shard 以 scale 寫入能力的取捨在這方面會打一絲折扣。分散式事務在語義上也不可能與單機事務的語義一致。

aurora 對 mysql 的改動集中在 log 與 data space 訪問上，能保留 mysql 事務語義。只讀 replica 可以無狀態擴，replica 的 buffer cache 能允許 hot path 的性能與單機無異。雖然是單點寫入，但是下層 quorum 的存儲有助於容掉 outlier，經過他們做的一些類似幹掉 binlog 幹掉 double write buffer 只寫 redo log 之類的優化後，寫入性能相對需要各種 fsync 物理磁碟的 mysql 反而能有優勢，而且隨著硬體進步，單機的寫入性能很大程度上能 scale up。

其他人說的很詳細了，補充一下自己對aurora的理解：下面的storage system是一個quorum system，每個節點自己有本地存儲(為了擴展性，掛的有可能是是EBS，1副本)，aurora寫時，只會把redo log寫入quorum system，quorum system之間通過gossip協議同步redo log, 每個節點會對redo log進行歸檔生成data block，存在本地，定期會backup到S3上。aurora 實例之間cache需要同步

TiDB 整體架構脫胎於 Google 2012 年的 Spanner 論文。用一致性協議確保數據一致性，true time api 來保證 external consistency。

相比於 Spanner，Auora 的思路就是十分的簡單粗暴了，就是把整個存儲層都複製一遍。畢竟 Amazon 內部有很多成熟的技術可以直接拿過來用。

給我的感覺就是：Spanner 是 make things right； Auora 則是 get things done。

我來回答

1.每個系統都是在演進中，比較最好要帶時間點。

2.如果現在2018年的時間，spanner演變為一個基於分散式共享存儲的htap系統，做了很多針對OLAP負載的優化，比如查詢優化，編譯執行，長查詢斷點繼續，行列混合存儲等，OLTP負載的優化相對少。但兼容性，對數據模型高內聚的約束等始終是阻礙企業用戶採納的動因。

3.Aurora發布了跨az和跨region的multi master，這個意味著和spanner比，在OLTP負載場景，更有優勢，兼容性和生態壓倒性優勢，多活數據中心也都有，初步判斷Aurora更勝一籌，原因還是對關係型的支持和SQL兼容性上。除了沒有pb級，萬級節點擴展性，但這對現在的用戶不是問題。