PolarDB-X 2.1 新版本釋出 讓“MySQL 原生分散式”觸手可及

PolarDB-X 2.1 新版本釋出

讓“MySQL 原生分散式”觸手可及

——黃貴（曲山）

阿里雲資料首席架構師

瞭解更多PolarDB-X 內容： https://developer.aliyun.com/topic/polardbx_release

PolarDB -X  2.1  是  PolarDB-X  非常重要的版本，也是第一次  PolarDB-X  分散式資料庫的產品可以作為企業級的分散式資料庫真正部署到客戶的生產環境使用。

一、一個好的MySQL分散式資料庫應該是什麼樣的

   C++ 語言設計的概念   Z ero Overhead  A bstraction  ——0負擔抽象原則，它有兩個重要特性：

• 無須 為不用的特性付出代價：  C  類使用者升級到  C++  時， 如果不使用  C++ 裡的高階特性，則無須為這些特性付出額外的代價。比如在  C  裡面是 structure，到  C++   裡可能是 class  。對於  C  中的  structure  和 C++  中 的  class  ，如果不帶  virtual function  ，則在記憶體佈局的效能消耗上是等同的，不用付出額外的代價。
• 你所使用的程式碼，不可能手寫得更好：如果想要使用更高階的特性，用  C++  擴充套件的能力，一定比手寫的程式碼更好，即C++ 提供的語言特效能夠很好地幫助到使用者。

    C  語言的使用者升級到  C++ ，必然是因為它帶來了更新更強的能力，比如封裝、抽象的能力，可以做繼承、有多型。另外，C++ 提供了多種程式設計正規化，比如物件導向、泛型程式設計、函數語言程式設計等，這些特性都可以極大地擴充語言的抽象，帶來能力的提升。

同理，從單機的  MySQL  資料庫升級到分散式  MySQL  資料庫，我們期望它能有哪些表現？

首先是完全相容，可以由單機平滑過渡到分散式系統，無需對應用進行改造；第二，無需對資料庫的結構進行改造；第三，不使用分散式能力則無須付出額外的開銷。

單機到分散式最重要的變化是資料會分佈在多個節點上，對於資料庫中很多操作而言，尤其是事務，是需要付出一些額外代價的。如果事務涉及到多個資料的分割槽，而只是想將分散式系統作為單機資料庫來用，同樣也可以有單表的特性，無須付出分散式事務的代價。

升級到分散式系統後能夠獲得自動伸縮的能力，能夠天然地利用分散式的特性實現跨地域的高可用，還可以處理混合的負載型別，包括事務的負載以及分析的負載，提供了高價效比的解決方案。

二、讓分散式能力透明化

如何實現從單機到分散式完全透明化？

以從單機  MySQL  遷移到   PolarDB-X  2.1  版本為例：

   第一步：建表。使用單機  MySQL  上的建表語句、 DDL 語句在 新的分散式資料庫上建表， 無須 做任何修改。

第二步：讓應用跑起來。應用程式碼也 無須 做任何修改，原有的  SQL  語法、原有的客戶端驅動程式都可以直接使用，只需要更換新的資料庫連線地址。

第三步：效能調優。可以使用很多工具做壓測，包括一些視覺化工具，能夠提供對整個系統  SQL  效能的分析，  DAS 自動調優工具能夠幫助找到熱點 SQL， 還可以透過  DDL  建新的索引或對資料分割槽進行調整，對熱點  SQL  進行調優。

實現以上整個過程的大部分操作只是診斷和適配， 無須 進行過多改造工作。

對於分散式系統 而言 ，要做到透明，核心就是對分散式事務的支援。分散式資料庫與單機資料庫的關鍵差異在於，分散式資料庫 是 以一定的規則將資料做分片，然後分佈在多個節點上，其中核心點在於 如何 在事務跨了多個資料分片時，保證它的   ACID  語義。這其中會涉及到 如何 做事務的   ACID  保證， 如何 做多版本處理併發的控制。有了事務  ACID  的保證，才能在此之上建立全域性二級索引。

此外，很多其他功能比如備份恢復、時間回溯的查詢以及分散式的備份等，都需要依賴分散式事務提供的全域性一致效能力。資料的匯入和匯出也需要保證資料有全域性快照的能力，在任何時間點都能讀到一致的版本。

有了全域性二級索引和多版本的併發控制等能力的支援，即可實現透明的分散式， 無須 顯式地指定分割槽鍵 ，只需要像單機數庫一樣建立表，即能預設做資料的分割槽，也無須考慮資料分割槽帶來的跨節點事務的處理。表的修改操作 和 Online  DDL  也不會對資料庫的其他操作產生影響。

PolarDB-X  實現的是全域性一致性的分散式事務

（使用  TSO全 局  time stamp） +  MVCC  （ 多版本併發控制機制）實現的分散式資料庫。主要的技術原理是基於   P axos  做事務日誌的同步來保證高可用。

在事務在處理的過程中，因為使用了兩階段提交的方式來做分散式事務的處理，如果發生了節點失效，也可以利用   P axos  帶來的高可用能力保證事務繼續進行下去。

另外，使用了全域性唯一的時間戳以及多版本併發控制的機制來保證它的隔離性，實現了   Snapshot   I solation  的隔離級別。

具體流程如下： GMS  元件提供全域性事務的時間戳，在發起事務的過程中，如果事務要做提交，則會獲取提交的時間戳並將其帶到所有下面儲存節點的參與者上。然後結合事務當前的狀態，根據時間戳判斷事務的可見性。每一條資料上都有其提交的時間戳，將其與當前事務的時間戳做比較，以決定這條資料在當前的事務中是否可見。

透過上述機制即可實現分散式事務的全域性一致性和快照隔離。

本次  2.1  版本釋出的最重要的功能就是自動模式資料庫的功能。PolarDB-X   在  1.0  版本時代，是利用分庫分表的模式來進行資料的自動分割槽。  2.0  的時代引入了全新的 AUTO 模式資料庫，無需指定分割槽鍵。

 

上圖展示了典型的電商交易場景，有交易記錄表，其主鍵是事務  ID  ，還有買家和賣家兩個重要角色。對於交易的流水 而言 ，通常除了按交易的流水日誌  ID  查詢以外，也有可能從買/賣家的維度查詢。

表內可能有上億條記錄，需要將它建立為分割槽表。對於分散式資料庫  PolarDB-X   而言 ，無需指定特定的分割槽鍵。因為這裡的分割槽健，如果是按照buyer _id 或者seller _id 去查詢，無法做分割槽裁剪。可以像使用單機資料庫一樣預設按主鍵  ID  做資料的分片。分片的演算法預設是一致性雜湊，也支援很多其他演算法，包括   interval  做範圍的劃分、   range   的分割槽等，此類演算法也可以透過  DDL  語句根據業務特點做調整，另外還可以透過多個查詢維度建全域性二級索引。

上圖例子中建了兩個全域性二級索引，分別是買家  ID  和 賣家  ID  。 往表裡面插入資料的時候，會針對資料根據資料的分割槽規則，將它均勻地分佈在資料節點上。上圖右側兩張索引表同樣也按照分割槽規則做了均勻的分佈。

資料自動負載均衡的功能，使得使用者無需關心資料具體分佈在哪個資料節點上，可由系統自動完成，主表以及兩張索引表都按照一定的規則做資料的拆分，分片以後按照資料的大小和容量均勻分佈到各個資料節點上。

有了自動負載均衡的能力以後，也就具備了線上擴縮容的能力，而線上擴縮容是單機到分散式平滑演進的重要基礎。

上圖有計算層的  CN  節點，也有儲存層的  DN  節點。  CN  節點 是 無狀態節點，擴容和縮容非常輕量化，因為所有  CN  的能力 都對等，將  SQL  傳送到任意  CN  節點都可以實現同樣的處理能力，得到相同的結果。出於效能的考慮，一般會將資料就近排程到臨近的  CN  節點上。

因此， CN  的擴容非常方便，只需簡單地將  CN  節點新增到叢集上，同步到   GMS   節點裡即可。

DN  是有狀態的資料節點，擴縮容需要做資料的遷移。增加了一組資料節點後，排程工作管理員會根據當前資料的分佈狀況，將一部分資料遷移到新的資料節點上，以此保證所有節點的資料處在均衡的分佈狀態。

效能和容量方面，Polar DB-X  最大可以支援  1024  個節點，單節點最大儲存  5TB  資料，能夠滿足大部分資料庫的容量需求。

縮容同理，下線資料節點後，會將它缺失的副本補足，然後重新均勻分佈到其他資料節點上。

從單機資料庫遷移到分散式資料庫，可以基於  Online  DDL  的能力動態完成單機大表切換到資料分片的模式。比如原來在單機上非常大的表，希望透過分散式系統的資料分佈能力對其進行拆分，可以透過一些  DDL  的能力動態地修改其分割槽模式，來完成單表到資料分佈表的轉換。

對於單機分散式 而言 ，PolarDB-X   完全相容了  MySQL  的語義及其行為，包括上下游對接的生態，比如全域性  CDC   可以生成全域性一致的   Binlog， 可以將其作為單機  MySQL  的日誌流來使用。不管是同步到下游大資料系統，還是作為  MySQL  的備份，都可以透過  CDC  來對接。

O nline DDL  最大的特點就是在做  DDL  的過程中對當前資料庫正在處理的業務  DML  語句 沒有任何影響,極大減輕了資料庫運維人員的負擔。資料庫難免會遇到一些修改表結構、增加點索引等訴求，如果每次都要在業務的低峰期去進行，對運維會造成很大困擾，而且不夠及時。有了   O nline DDL 的支援以後，可以在任意時間點做變更。這些變更包括了建立索引、加減列、變更分割槽演算法。

值得一提的是，加列操作使用了   Instant  DDL  機制，可以只修改後設資料，無須對全部資料進行修改，操作效能極高，為毫秒級，對業務的影響可以縮減到最小。

此外，可以將資料庫由單表變成分割槽表。在分割槽表上還可以修改分割槽數、表組以及分割槽演算法等。同時也可以將它修改成廣播表，在每個資料節點上都有同樣的複製表，對於頻繁做  join  的小表非常有用。這些能力也使得使用者可以靈活調整資料表的資料分佈方式，以滿足不同業務負載的需求。

三、分散式是一種全新資料庫的模式

分散式是一種全新的資料庫模式，它不僅是對單機資料庫的完全相容，更大的作用是帶來了更多更強的能力。PolarDB-X 2.1版本帶來了以下卓越的能力：

1.  高可用容災能力

2.1  版本 正式引入了   X-Paxos ，   使用   P axos  一致性協議保證資料的可靠性以及系統節點失效時的可用性。

它實現了 99.99% 可用性：任意節點的故障都不會影響叢集的可用，資料  0  丟失。

提供了多種部署形態：

①  同城三機房，預設 2.5 副本。在   Paxos  協議框架下有幾種角色，包括 leader節點（資料事務的主節點），它帶有兩個副本，分別是  follower  節點和  logger  節點。 logger  節點為了節省成本，不儲存全量資料，只儲存日誌來保證資料的一致性，同時也減少了資料副本的儲存；另外還有  learner  節點，可以做只讀的副本。

②  兩地的三中心，預設五副本。

   擁有分散式特性：用   Paxos  協議做一致性同步時，需要傳輸日誌，而在網路上保證大量的日誌傳輸的一致性較為困難。2.1版本支援日誌分片的拆分，也做了行級熱點的寫入，支援自動合併，為很多電商的秒殺業務場景提供了保障；另外，透過對  follow er   節點開放讀，在  follow er   節點上可以將全域性  TSO  帶過去，做一致性版本的讀，利用  follow er   節點的處理能力來提升整個系統的吞吐。

高可用的架構幫助我們提供了一個很好的基礎。使得 PolarDB-X  在容災方面也提供了強有力的支撐，比如兩地三中心的部署方式。採用 5  副本（2+2+1）的機制，設定了很多規則，比如儲存副本 leader  節點失效重新選主的時候，會優先選擇同機房的主節點，對整個系統服務的可靠性和延時不會帶來太大的影響；另外，機房失效時，可以做五副本到三副本的降級操作，保證強一致性、持續的處理能力。

主可用區的概念是為了保證在同機範圍內做網路訪問時，最大可能地減小延時。

2.  冷熱分離儲存

冷熱分離儲存是基於分散式資料庫做的成本上的最佳化。利用  TTL  機制，在建立表的時候指定其過期時間，將已經過期的資料歸為冷資料，做歸檔的儲存。歸檔儲存於  OSS  裡，相對於本地的線上儲存，極大降低了成本。與此同時，  OSS  上的儲存格式進行了高度壓縮，進一步降低了成本。

歸檔到  OSS  時 採用了開放的格式，優點在於可以對接很多開源生態，比如 Spark、Flink  的生態，然後做分析、查詢。同時，其自身的查詢引擎也支援快速查詢在   OSS   歸檔的資料。

3.可觀測性

PolarDB-X 的   D ashboard  整合了開源的 Prometheus 等工具做監控、告警，分析當前系統的執行狀態。另外還建了一套做  performance  的  insight  工具，分析資料在各個節點上的分佈狀況以及他們在分割槽上的訪問頻率，幫助使用者更好地發現系統的效能瓶頸，並進行調優。

四、未來往何處去

未來我們會持續在   Polar DB-X  開源版本上做更多投入。

我們會將開源的  codebase  與當前的商業版本對齊，所有能力在核心層面完全開源。也會繼續做更多企業級能力的增強，使 PolarDB-X   完全變為企業級的分散式資料庫。

全新的  H TAP   引擎使得   PolarDB-X 同時能夠處理事務型和分析型的負載。另外還會做國產化適配調優，實現國產化替代的工作，包括深度診斷、自動化調優工具以及各種生態的對接等。