【阿裡雲 MVP 分享】POLARDB for MySQL 版評測及同類橫向對比

前言

在資料庫的選擇上, MySQL成為中國開發者的最愛。相比 SQL Server相對保守的資料庫特點,中國開發者更喜歡開放性的資料庫,同時又考慮到價格問題,那麼 Oracle不菲的價格也擋住了很大一批開發者。由于開源、價格等因素,在資料庫選擇上,要麼是低價、開源的 MySQL,要麼就是高大上的 Oracle。 —— 雲栖社群《2017中國開發者調查報告》

根據雲栖社群《2017中國開發者調查報告》我們可以了解到在全球範圍内特别是國内 MySQL 都有着非常高的使用率，有大量的産品和項目是依賴于 MySQL 作為關系型資料庫的，是以在 MySQL 上進行進一步的優化和改造是大有可為的，于是便有了 MySQL 的衍生版包括有：MariaDB、Percona、AliSQL、PhxSQL 等等，但 MySQL 本身其實是一款“輕量級”資料庫，相較 SQL Server 和 Oracle 等商業資料庫其實是有所不足的。是以各類相容 MySQL 生态的新型資料庫開始出現。

2017年是各類新型資料庫的落地年，各種NewSQL紛紛結束蟄伏期并開始商業化輸出，特别是各類基于 MySQL 生态和相容 MySQL 協定的新資料庫産品也開始不斷發展并開始商業輸出，有包括在 OLTP 上進一步優化的 POLARDB、Aurora、X-DB等等，還有相容 OLTP 和 OLAP 場景的 HTAP 上優化的 HybridDB、TiDB、BaikalDB 等等。

本文要将的主角是 —— POLARDB ，POLARDB 是在2017年9月釋出并進入公測階段的，并在18年4月結束公測正式進入商業階段并不斷釋出新功能完善體驗。值得一提的是同樣也在17年10月騰訊雲聯合 PingCAP 釋出基于 TiDB 的 HTAP 資料庫，但截至發文依舊停留在測試階段。

介紹

POLARDB 是阿裡雲自研的全新一代雲資料庫，與 MySQL 100%相容，性能最高提升至MySQL的6倍，滿足企業級OLTP（線上事務處理）并兼顧結構化資料并發查詢場景。既融合了商業資料庫穩定可靠、高性能、可擴充的特征，又具有開源資料庫簡潔開放的優勢，而成本隻有商用資料庫的 1/10。POLARDB采用存儲和計算分離架構，能提供存儲自動擴容、計算規格彈性升降、故障快速恢複和資料備份容災服務。

POLARDB 對 MySQL 進行了一定改造，MySQL 其實至釋出以來就是基于單機開發的資料庫，但是單機單節點勢必是會遭遇性能瓶頸。于是乎，對于 MySQL 有了兩個方向的改造。

一種是讀寫分離方案，因為在很多網站常見下其實大家走的讀請求更多，就女士逛淘寶，看了非常多的商品可能才下那麼一單甚至單都不下就添加了一個收藏。

痛點舉例

再介紹 POLARDB 的優越性之前，我們先看看已經是使用體驗業内頂尖了的雲資料庫 MySQL 的一些痛點（友商的其他競品痛點可能會更多~）：

一、 當資料存儲容量足夠大的時候，備份成為了一件非常複雜的事情，費時費力。

二、 主備模式下，如果主庫不出現問題并不會切換到備庫，備庫僅僅起到了一個以防萬一的作用平時并不能分擔壓力，但是卻不得不承擔備庫部分的成本。

三、 在讀寫分離場下，每添加一個隻讀庫基本上就得購買一個一模一樣的存儲空間，如果是一個1T的主庫，那麼兩個隻讀庫的成本就是2個1T。

四、 還是讀寫分離場景，一個上TB的資料庫容量加個隻讀副本就需要一到兩天時間，非常的麻煩。

五、 傳統模式下為了保障資料庫不會到達 100% 都會預留10%~20% 的容量作為門檻值，到了 80% 就進行更新或者擴容，其實這個時候那個預留的門檻值是浪費了的，但是又不得不浪費。

六、 存儲容量瓶頸，雲計算廠商提供的關系型資料庫基本上都有一個問題，那就是存儲容量存在瓶頸，當資料量達到 2T 左右的時候就已經是瓶頸了無法進一步上升，而部分資料庫應用場景恰恰就是需要大容量大存儲的。

七、 性能瓶頸，當使用資料庫遭遇性能瓶頸的時候其實是很糟心的，如果是能通過更新配置解決的那倒還行，如果是因為資料庫軟體本身的問題而更換資料庫軟體又意味着更高額的成本和風險。

産品特性

那麼接下來介紹 POLARDB 的産品特性大家就會覺得舒服的多。

快照式備份

POLARDB 采用快照（Snapshot）形式的備份模式，并不是說将資料完完整整的備份一份，而是把備份資料的負載均分到建立Snapshot之後的實際資料寫發生的時間視窗，以此實作備份、恢複的快速響應。

Snapshot是一種流行的基于存儲塊裝置的備份方案。其本質是采用Copy-On-Write的機制，通過記錄塊裝置的中繼資料變化，對于發生寫操作的塊裝置進行寫時複制，将寫操作内容改動到新複制出的塊裝置上，來實作恢複到快照時間點的資料的目的。Snapshot是一個典型的基于時間以及寫負載模型的後置處理機制。

POLARDB提供基于Snapshot以及Redo log的機制，在按時間點恢複使用者資料的功能上，比傳統的全量資料結合Binlog增量資料的恢複方式更加高效。

實測的話，POLARDB 的備份在分鐘級，兩三分鐘就可以實作備份，相比雲資料庫小時級的等待可以說是體驗非常棒了。在備份恢複的體驗上 POLARDB 基本上和雲資料庫體驗一緻，按備份集和按時間點或者執行個體備份都可以

FailOver 多活

POLARDB 預設購買就是一個主執行個體+隻讀執行個體形成 Active-Active 模式，其 FailOver 多活機制 可以在主執行個體當機後立馬選擇一個隻讀執行個體“賦予”其讀寫能力，成為一個新的主執行個體。這樣的模式下每一個隻讀執行個體都是“備庫”，但是這個備庫是參與工作的，并不存在浪費的現象。

得益于資料共享（後面會提到）的模式，隻讀節點的增加無需再進行資料的完全複制，共用一份全量資料和 Redo log，隻需要同步中繼資料資訊，支援基本的 MVCC，保證資料讀取的一緻性即可。這使得系統在主節點發生故障進行 Failover 時候，切換到隻讀節點的故障恢複時間能縮短到 30 秒以内。

分布式共享存儲架構

POLARDB使用了第三代分布式共享存儲架構，實作了計算節點(主要做SQL解析以及存儲引擎計算的伺服器)與存儲節點(主要做資料塊存儲，資料庫快照的伺服器)的分離，提供了即時生效的可擴充能力和運維能力。

由上圖我們可以看到，POLARDB通過将資料庫檔案以及 Redolog 等存放在共享儲存設備（POLATSTORE）上而不是一個庫一個本地存儲。由于資料共享，隻讀執行個體的添加就再也不需要對資料進行完全複制了，而是共用一份全量資料和 Redo log，隻需要同步中繼資料資訊，這使得系統在主節點發生故障進行Failover時候，切換到隻讀節點的故障恢複時間能縮短到30秒以内（有沒有發現這一句話FailOver那邊提過）。系統的高可用能力進一步得到增強。而且，隻讀節點和主節點之間的資料延遲也可以降低到毫秒級别。

存儲費用按量付費

POLARDB 的存儲計費是按量付費的模式，也就是用多少扣多少，而不是預付費的模式。 雲計算方法論中很重要的兩點就是 彈性和按量 。相對于 ECS 叢集的後付費和流量的按量後付費，資料庫的按量後付費其實更可控和可預估，并不會出現天價費用，而且在資料庫容量的擴容上使用者也的确會遇到不好的體驗（痛點那裡有提到）。

是以使用者會很願意接受 POLARDB 的按量付費模式。再也不需要為那10%的擴容門檻值浪費成本了。

大容量存儲

POLARDB 支援高達 100TB 的存儲容量，是雲資料庫 2T 容量上限的 50 倍。如果資料庫的使用場景中的确需要超大存儲再也無須擔心了。

超高性能

POLARDB 作為一款 雲原生 的資料庫，在軟體設計、産品架構、基礎設施上都是頂尖的（如果用最頂尖的可能會違反廣告法~）。 在性能上 POLARDB 遠超 MySQL ，在特殊場景下最高可以實作6倍于 MySQL。

軟體設計上的删繁就簡，僅能更進一步。 下面那張圖上門出現過，可以看到傳統的MySQL下讀寫分離其實非常的繁瑣，而且要寫入大量的邏輯日志。POLARDB 在 MySQL 上進行了大量的修改包括有：使用共享存儲實體複制、鎖優化、日志送出優化、複制性能優化、讀節點性能 等等。 同時 POLARDB 是基于 Docker 來隔離資源的，免去了一次虛拟化帶來不必要的性能損耗。

超規格底層硬體提供更高性能。3D Xpoint、NVMe、RDMA網卡這些名詞都是在極客玩家中經常有聽到的，它們都意味着超高的性能，同時也意味着高昂的價格。前文中有提到的 POLARSTORE 存儲，就是基于這些極緻的硬體裝置而來的，但是阿裡雲将他們內建到 POLARSTORE 并以雲計算的形式普惠輸出，讓大家可以用低廉的價格享受最前沿的技術和産品。

軟硬體一體化設計，但是軟體、硬體單方面的提升都無法成就 600% 于 MySQL 的性能表現，POLARDB 将全新的軟體針對最酷的硬體進行優化實作軟硬體一體，是以也是非常推薦大家可以閱讀一下關于 PolarFS VLDB2018 的 Paper。

我是傳送門

（猜測）未來的 多主進群（Multi-Master） 機制，這個純屬我瞎猜，但是 POLARDB 大機率是會做的，那就是在多個可用區中建立多個讀取主執行個體。這樣一來，應用程式就可以在叢集的多個資料庫執行個體中讀取和寫入資料，極大的擴充分布式寫的性能，這簡直就是搶 DRDS 的飯碗嘛！ 多主叢集還會進一步提高高可用性，如果其中的一個主執行個體發生故障，叢集中的其他執行個體将立即接替該執行個體，進而在發生執行個體故障甚至完全 AZ 故障時保持讀寫可用性，應該是可以做到将應用程式停機時間降到零。

100% MySQL 相容

POLARDB 針對 MySQL 生态 100% 相容。 為什麼這個都要拿出來說呢？ 舉兩個例子：

一是在本文的第一張圖中可以看到 Oracle 在中國有不小的份額并占據第二的位置，為什麼？根據我對客戶上雲的一些經驗來看，使用 Oracle 的客戶大多都是政企客戶，系統依賴 Oracle 有曆史包袱，貿然遷出要面臨不小的工作量而且出問題了勢必會背鍋，是以盡管有什麼高度相容 Oracle 的方案，95%也好 99% 也好，勢必意味着不可預知的風險。

二是像谷歌的 CLOUD SPANNER 就不相容已有的資料庫生态，這就導緻使用者必須針對其全新開發而且未來勢必對GCP有非常強的依賴，難以脫身。

是以 POLARDB 的 100% 相容 MySQL 生态絕對是一大特性，讓客戶可以無痛的就使用高性能的資料庫産品來解決現有遭遇的資料庫性能、功能瓶頸或者說是使用期新特性來提高業務可靠性和穩定性。

性能測試

這裡使用 SysBench 1.0.15 進行小規格版本的測試。

測試準備

ECS 自建： 自建 MariaDB 10.1 （基于 MySQL 5.6）， 底層伺服器：計算型C5 2C4G 150G

SSD雲盤

RDS 主執行個體： 雲資料庫 MySQL 版 5.6 高可用，2C4G 版

RDS 讀寫分離： 雲資料庫 MySQL 版 5.6 高可用，2C4G 版，主執行個體 + 1個 隻讀執行個體

POLARDB 主執行個體： POLARDB 2C4G ，主執行個體，不使用隻讀執行個體

POLARDB 讀寫分離： POLARDB 2C4G ，主執行個體 + 1個隻讀執行個體

由于 ECS 自建讀寫分離場景太費時費力了，就不建立了。

測試指令

sysbench --test=./tests/include/oltp_legacy/oltp.lua --mysql-host=`雲資料庫連結位址` --mysql-port=3306 --mysql-user=mf8press --mysql-password=sbtest --oltp-tables-count=250 --db-driver=mysql --oltp-tablesize=25000 --mysql-db=sbtest --max-requests=0 --oltp_simple_ranges=0 --oltp-distinct-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --max-time=600 --oltp-read-only=on --num-threads=500 run           

sysbench --test=./tests/include/oltp_legacy/oltp.lua --mysql-host=`雲資料庫連結位址` --mysql-port=3306 --mysql-user=mf8press --mysql-password=A123456a --oltp-tables-count=250 --db-driver=mysql --oltp-tablesize=25000 --mysql-db=sbtest --max-requests=0 --max-time=600 --oltp_simple_ranges=0 --oltp-distinct-ranges=0 --oltp-sum-ranges=0 --oltporder-ranges=0 --oltp-point-selects=0 --num-threads=128 --randtype=uniform run           

測試結果

SysBench 讀場景結果（越大越好）

SysBench 寫場景結果（越大越好）

SysBench 超過95%平均耗時場景結果（越小越好）

無論是 POLARDB 還是 RDS 都是配置越高執行個體越多性能越好的，這裡測試的都是入門款，是以評測效果并不是怪獸級的。

不過我們依然可以看到這是 POLARDB 的碾壓局，同配置下 POLARDB 較 RDS 有近一倍的性能提升，和自建 ECS 并且是我的“弱雞”調參比幾乎是碾壓。

值得一提的是，我貌似讀寫場景都沒有把讀寫分離和單主執行個體的性能差異測出來，如果有測試方式有問題歡迎大家斧正。

橫向“雲評測”

在科技産品界有一種說法較“雲評測”，那就是明明某小編産品實際沒摸過，但是小編還是能一本正經的能來波橫向測評。 這次我也來一波雲測評~

目前阿裡雲平台上的 MySQL 相容産品就有： 雲資料庫 MySQL 版（RDS）、分布式關系型資料庫（DRDS）、雲資料庫POLARDB、HybridDB for MySQL (原PetaData)。 那麼有人就會問，四款 MySQL 怎麼選怎麼用呢？

首先，我們可以看一下一張加入了 POLARDB 的阿裡雲資料庫家族上雲指導圖：

大緻的我們就可以知道，HybridDB for MySQL (原PetaData) 是專門用于 HTAP 場景的，有強 OLAP 需求還是得考慮 HybridDB，不過其為了 OLAP 相容還是喪失了一些 MySQL 特性的，比如說不支援限制和一些進階特性。

接下來三個資料庫當中，都是常見的 MySQL OLTP 場景，而且都可以添加隻讀執行個體，同質化很嚴重。

雲資料庫 MySQL 版依舊是最簡單的 MySQL 目前支援的功能最多，但是性能略有不足，而且所有更新操作都是小時級的操作體驗相對不太好。未來的話我認為更适合小規格資料庫的入門級使用。

DRDS 和 POLARDB 都有分布式的屬性，DRDS 的分布式是執行個體級的，POLARDB 是共享分布式存儲。

DRDS 是集合多台 RDS 的性能來提升性能避免單台資料庫的性能瓶頸，适合非常大規模的業務，但是分庫分表等操作對操作人員要求較高，必須得需要有一定的資料庫功底，要對資料庫進行更改，對使用者來說有一定學習成本。DRDS 本身是一款中間件産品（盡管已經劃分到資料庫分類下了），底層還是依賴于 RDS 執行個體的，是以 DRDS 離不開 RDS，是以在大規模存儲的情況下，我覺得超過2T的存儲，DRDS 也吃力，其亮點還是分布式的性能表現優異。

POLARDB 則是一款全新的類型，對 MySQL 有了核心級的改造，在讀的能力上大大提升并且性能優異，但是相對來說 寫 還是依賴于主執行個體，DRDS 的分布式可以提升寫的能力。 如果 POLARDB 完成了 多主進群（Multi-Master） 的支援的話，寫的能力也會大大提升。 并且 POLARDB 不需要修改資料庫，使用者可以無痛的切換，而且先進的分布式存儲可以讓其實作百T級的存儲能力。 是以未來 POLARDB 和 DRDS 的競争也是大有看頭。

展望

POLARDB 的特性使得 MySQL 性能有了極大的提高，POLARDB 是一個分布式的理念，POLARDB 的 POLARSOTRE 架構其實是可以延伸到其他開源資料庫上的。

未來 POLARDB for PostgreSQL、POLARDB for MongoDB、POLARDB for PPAS 都是非常可期的，未來更高性能的 PG、MongoDB 也是令人向往。