PolarDB-X 2.0:使用一個透明的分散式資料庫是一種什麼體驗

程式碼派就是我發表於2021-06-24

透明分散式,是PolarDB-X即將釋出的能力,它能讓應用在使用PolarDB-X的過程中,猶如使用單機資料庫一般的體驗。

與傳統的中介軟體型別的“分散式資料庫”相比,有了透明分散式能力的PolarDB-X,不再需要應用考慮分割槽鍵的概念,應用可以完全將單機MySQL上開發的建表語句、應用程式碼直接遷移到PolarDB-X上執行起來。

本文將為大家介紹PolarDB-X透明分散式的新體驗。

在PolarDB-X上安裝一個WordPress

WordPress是一個開源的部落格軟體,它使用MySQL作為其資料庫。操作是在PolarDB-X上安裝一個WordPress,來體驗PolarDB-X的透明分散式能力。

我們將遵循簡單的三步走:

  1. 不修改DDL直接建表

  2. 不修改應用直接跑起來

  3. 做下壓測,做下調優

總結如下:

  1. 使用官方的WordPress映象,不做任何修改,其安裝程式就能自動的在PolarDB-X上完成建表、資料初始化等工作,其使用的都是標準的MySQL語法。

  2. 對此WordPress進行壓測,PolarDB-X的各項監控資料顯示,各節點處於的負載、資料量均處於均衡的狀態。

  3. 透過PolarDB-X提供的SQL分析、DAS等工具,可以方便的找到系統中熱點SQL。

  4. DBA可以直接透過建立索引、修改資料分佈等DDL語句對系統效能做進一步的最佳化,不需要修改應用。

PolarDB-X實現透明分散式的武器

下面為大家分享下,PolarDB-X是如何實現透明分散式的。

透明資料分割槽

PolarDB-X是一個典型的Share Nothing的分散式資料庫,其簡化架構如下:

img

其核心元件為無狀態的計算節點CN,與有狀態的儲存節點DN。

要了解PolarDB-X的透明分散式能力,首先要了解資料在PolarDB-X上是如何分佈的。

在PolarDB-X中,一個表由多個索引組成,包括主鍵、二級索引等。PolarDB-X會對每個索引進行獨立的進行分割槽,其分割槽鍵為索引的key。

例如一個典型的電商場景,訂單表,擁有一個主鍵(id),兩個索引(seller_id與buyer_id):

create table orders (

  id bigint,
  buyer_id varchar comment '買家',
  seller_id varchar comment '賣家',
  primary key(id),
  index sdx(seller_id),
  index bdx(buyer_id)
)
  • 對於主鍵索引,會按照id對其進行分割槽

  • 對於索引sdx,會按照seller_id進行分割槽

  • 對於索引bdx,會按照buyer_id進行分割槽

如下圖所示:

img

對索引進行分片之後,PolarDB-X會將這些分片打散到不同的儲存節點裡,並會按照資料量等資訊進行負載均衡,如下圖所示:

img

在PolarDB-X中,建表語句中可以不考慮分割槽鍵,PolarDB-X也能自動的對錶進行分片與負載均衡。

因此,應用遷移PolarDB-X時,可以將單機MySQL中的建表語句匯出,不需要修改直接在PolarDB-X中執行即可。

透明的分散式事務

分散式事務是PolarDB-X中的最重要的基礎能力,它廣泛的應用於業務內,避免了業務對事務程式碼進行改造;同時,PolarDB-X內部也用事務來實現索引。

PolarDB-X的分散式事務有以下幾個特徵:

  1. 與Spanner一樣,滿足外部一致性這種最強的一致性級別

  2. 語法與MySQL完全相容,無需對應用進行改造

  3. 行為上支援相容MySQL的RC與RR級別

img

PolarDB-X分散式事務的原理我們專欄有很多介紹的文章,在此不再贅述。對其原理感興趣的同學可以參考這幾篇文章:

Online DDL

PolarDB-X支援型別豐富的Online DDL,這裡介紹一些有代表性的DDL型別。

索引維護

與單機MySQL的索引有所差異,PolarDB-X的索引均為全域性索引,包含以下幾種型別:

  • 普通索引

  • 唯一索引

  • 聚簇索引

其中聚簇索引是PolarDB-X相對於MySQL的一種新型別的索引,它會包含表中的所有列,從而避免了回表的代價。

PolarDB-X中對索引的建立都透過DDL來完成,並且都是Online的,不會阻塞業務。

例如:

  • 建立一個普通的索引:CREATE INDEX idx1 ON t1(name)

  • 建立一個聚簇的索引:CREATE CLUSTERED INDEX idx1 ON t1(name)

INSTANT ADD COLUMN

加列操作是業務中最為常見的DDL型別。在MySQL中,加列操作的耗時是與資料量相關的(MySQL8.0中在表的最後面加列是INSTANT的)。

在PolarDB-X中,在任意位置加列都是INSTANT的,這個代表加列操作為恆定的秒級耗時,與資料量無關,不會對業務產生任何影響。

分割槽調整

PolarDB-X支援4種表的分佈策略,Hash、Range、List、Broadcast。由於Hash能避免連續寫入的熱點,PolarDB-X預設使用Hash策略,大多數情況下,此策略能夠很好的滿足系統的效能需要。

但是如果業務在執行期間,希望選擇合適的分割槽策略來提升系統效能,在PolarDB-X中可以方便的透過DDL語句進行調整,PolarDB-X會按照新的分割槽策略重新組織表的資料。

例如:

  • 修改表的分割槽策略為Hash:ALTER TABLE t1 PARTITION BY HASH(name)

  • 修改表的分片數為32:ALTER TABLE t1 PARTITION BY HASH(name) PARTITIONS 32

  • 將表變為廣播表:ALTER TABLE t1 BROADCAST

  • 修改表的分割槽策略為RANGE:ALTER TABLE t1 PARTITION BY RANGE(id)

任意兩種分割槽策略之間都可以透過DDL語句進行轉換:

img

回填速度自適應

想必很多同學有過這樣的經驗:一個超大的表進行DDL操作,由於資料量比較大,這個DDL操作無法在一天內完成,為了避免對業務影響,人肉在白天業務高峰期來臨的時候,調整引數,降低DDL的回填速度,晚上在業務高峰期結束後,提高DDL的回填速度。

PolarDB-X中的回填,會根據當前的系統負載,自動調節速度。

例如:

img

img

在這個例子中,分了四個階段:

  1. 開始沒有業務負載,DDL回填速度上升到25W行/s

  2. 業務負載開始上升,DDL回填速度迅速下降到13W行/s

  3. 業務TPS穩定在1W5,DDL回填速度穩定在13W行/s

  4. DDL結束後,業務TPS穩定在1W6

從這個例子中,我們可以看到PolarDB-X DDL的回填速度會自動根據業務負載進行調整,並且DDL期間,對業務的TPS影響很小。

讓Online更Online

為了進一步減少DDL期間對業務的影響,PolarDB-X還使用了多項技術,例如:

  • 後設資料多版本,詳見:

  • 可暫停、可取消

  • MDL死鎖檢測

總結

PolarDB-X的透明分散式能力,將極大的減少應用從單機資料庫遷移分散式資料庫的成本。同時,我們未來也會讓它變得更透明,我們正在做的一些事情包括:

  • 更精細的排程策略

  • 熱點資料的視覺化展示,與SQL審計分析聯動的智慧診斷

  • 在有全域性索引的情況下,支援分割槽級的truncate

  • 資料的按時間滾動、清理

  • 等等


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31550522/viewspace-2778155/,如需轉載,請註明出處,否則將追究法律責任。

相關文章