POLARDB與其餘關係型數據庫對比

https://baijiahao.baidu.com/s?id=1610828839695075926&wfr=spider&for=pc

前言

在數據庫的選擇上,MySQL成爲中國開發者的最愛。相比SQLServer相對保守的數據庫特色,中國開發者更喜歡開放性的數據庫,同時又考慮到價格問題,那麼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 的一些痛點（友商的其餘競品痛點可能會更多~）：

1、 當數據存儲容量足夠大的時候，備份成爲了一件很是複雜的事情，費時費力。

2、 主備模式下，若是主庫不出現問題並不會切換到備庫，備庫僅僅起到了一個以防萬一的做用平時並不能分擔壓力，可是卻不得不承擔備庫部分的成本。

3、 在讀寫分離場下，每添加一個只讀庫基本上就得購買一個如出一轍的存儲空間，若是是一個1T的主庫，那麼兩個只讀庫的成本就是2個1T。

4、 仍是讀寫分離場景，一個上TB的數據庫容量加個只讀副本就須要一到兩天時間，很是的麻煩。

5、 傳統模式下爲了保障數據庫不會到達 100% 都會預留10%~20% 的容量做爲閾值，到了 80% 就進行升級或者擴容，其實這個時候那個預留的閾值是浪費了的，可是又不得不浪費。

6、 存儲容量瓶頸，雲計算廠商提供的關係型數據庫基本上都有一個問題，那就是存儲容量存在瓶頸，當數據量達到 2T 左右的時候就已是瓶頸了沒法進一步上升，而部分數據庫應用場景偏偏就是須要大容量大存儲的。

7、 性能瓶頸，當使用數據庫遭遇性能瓶頸的時候實際上是很糟心的，若是是能經過升級配置解決的那倒還行，若是是由於數據庫軟件自己的問題而更換數據庫軟件又意味着更高額的成本和風險。

 

產品特性

那麼接下來介紹 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 生態絕對是一大特性，讓客戶能夠無痛的就使用高性能的數據庫產品來解決現有遭遇的數據庫性能、功能瓶頸或者說是使用期新特性來提升業務可靠性和穩定性。

 

混淆OLTP和OLAP

POLARDB 的百TB級的存儲和高規格軟硬件帶來的低延時必定程度上模糊了 OLTP 和 OLAP 的邊界，在追求數據量實時性的場景下能夠更好的進行 OLAP 分析，而避免要將數據庫放到數倉而後再進行 OLAP 分析。

 

性能測試

這裏使用 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 讀場景結果（越大越好）

 

 

 

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 也是使人嚮往。