Amazon 在 SIGMOD 發表了 Aurora 技術論文,揭秘部分底層的實現方式。

重點摘錄:

  1. 主要是由 MySQL 5.6 修改而來,而非 MySQL 5.7。
  2. HTAP / NewSQL 常見的形成有三種,一為傳統 RDBMS 修改成 NewSQL;二為 NoSQL 修改成 NewSQL;三為全然 NewSQL 起家。Aurora 屬於第一種方式,採取最穩健 / 相容的發展。
  3. 使用計算與儲存方離的模式。為了符合 HTAP / NewSQL 高效能所需,通常有兩種發展,一為計算與儲存方離;二為計算儲存合一 (例如 ClickHouse),佐以分布一致性協調。Aurora 屬於第一種。
  4. 承上,MySQL 本體弱化為無狀態節點 (stateless),儲存拆離至 EBS,Redo log 拆離至 S3。總體上,利用 AWS 本身良好的共享儲存層來解決擴展問題。
  5. 承上,共享儲存層的問題在於,把原本效能瓶頸為 I/O,轉移為 Network。所以對於 Network bandwidth / latency 特別敏感。
  6. 承上,因為 MySQL 本體弱化為無狀態節點,所以 MySQL 軟體升級更容易做到不停機升級 (Zero downtime patching)。
  7. 為了妥善保存資料,Quorum 不採用 23 的設計,而改用 46 更高的容錯。換來的代價就是,耗用更多的儲存空間。
  8. 分布式事務沒有使用 2PC (二階段提交),而是使用 Gossip + Quorum 這種類似 AWS Dynamo 所採用的機制,暴力但有效。

Aurora Internal