乾貨 | DRDS 與TiDB淺析

乾貨 | DRDS 與TiDB淺析

北京it爺們兒 京東雲開發者社區  4月17日

在談論數據庫架構和數據庫優化的時候，會常聽到「分庫分表」、「分片」、「Sharding」…等關鍵詞。值的高興的是，這部分公司的業務量應該正在實現（或者即將面臨）高速增加，或技術方面也面臨着一些挑戰。但讓人擔心的部分是，他們的系統「分庫分表」真的有選擇正確嗎？

隨着業務規模的不斷擴大，用戶須要選擇合適的方案去應對數據規模的增加，以應對逐漸增加的訪問壓力和數據量。關於數據庫的擴展主要包括：業務拆分、主從複製、數據庫分庫與分表等，本篇文章的靈感就來源自做者與朋友關於數據庫分庫分表問題的討論。

DRDS vs  TiDB

起源

DRDS

• 數據庫中間件Cobar、MyCat、Amoeba

Tidb

• Google Spanner/F1

架構

DRDS架構

TiDB架構

分片機制

DRDS

• 支持HASH、RANGE_HASH、MMDD等多種分片類型

• 原理上都是基於HASH分片

• 須要在建表時指點分片Key以及分片方式

• 不支持全局惟一索引

TiDb

• 經過multi-raft協議，將數據Region（按範圍分區）分佈於不一樣節點，分片不須要應用干預

• 因爲按照範圍對數據進行分片，在某些範圍數據被集中訪問時易形成熱點問題，業務上能夠經過對主鍵進行散列編碼打散數據或者熱點數據經過cache方式解決該問題

應用限制

DRDS

• Sharding 後對應用和 SQL 的侵入都很大，須要 SQL 足夠簡單，這種簡單的應用致使 DB 弱化爲存儲。

• SQL 不能跨維度 join、聚合、子查詢等。

• 每一個分片只能實現 Local index，不能實現諸如惟一鍵、外鍵等全局約束。

TiDB

• 不支持外鍵

• 自增主鍵保證惟一但不保證連續

支持的事務模型

DRDS

• DRDS本質上是DB Proxy，事務基本上是指Proxy層的事務，原則上並不涉及RDS數據庫級別的事務

• FREE:容許多寫;不保證原子性;無性能損耗;數據批量導入、表初始化等場景

• 2PC:兩階段提交事務;保證原子性，不保證可見性;推薦 MySQL 5.6 用戶使用

• XA:XA強一致事務;保證原子性;保證可見性;推薦 MySQL 5.7 及更高版本用戶使用

• FLEXIBLE:柔性事務;補償型事務;適用於性能要求較高、高併發的業務場景

TiDB

• TiDB參考Percolator 事務模型，事務下沉到TiKV（存儲引擎）

• 經過2PC(Prewrite階段和Commit階段)提交以及樂觀鎖保證分佈系統中的ACID

• TiDB提供的事務隔離級別（Snapshot Isolation）與MySQL提供的事務隔離級別保持一致

高可用保障

DRDS

• 經過下游RDS主備方案保證數據高可用

• 數據冗餘兩副本以上，基本上從節點不參與計算只進行數據備份，資源上比較浪費

• 跨機房多地部署實施困難，須要藉助同步工具或業務上實現數據雙寫

TiDB

• tidb的元數據存儲在pd中，經過pd調度數據分片

• 分片最低三副本，經過multi-raft調度

• 經過節點標籤影響pd調度，實現兩地三中心部署

從架構來說TiDB的原生三副本機制要優於DRDS經過異步數據同步實現高可用的機制。異步同步主要的缺點是切換週期長，存在數據丟失的風險。對於DRDS當業務系統使用XA或者GTS這種強一致性協議時，某節點宕機會致使服務總體不可用

擴縮容再平衡機制

橫向擴索容主要考慮數據再平衡的效率和對在線業務系統的影響問題。考慮到DRDS分庫分表採用哈希切分，那麼在數據再平衡時須要針對分片key將全部數據進行從新分片，形成網絡及系統開銷較大；TiDB採用Range分片機制，當節點數發生變化，根據pd調度，只對部分Region進行遷移，系統開銷理論上小的多.

運維成本

DRDS

• 因爲DRDS多由雲廠商開發，本質上是一種服務，不存在運維成本，只有溝通成本

• 因爲Proxy層技術不透明，數據又基於RDS，系統性能優化須要與廠商溝通解決

TiDB

• 社區提供了ansible爲基礎的安裝運維包，能夠說單純運維門檻不高，基於prometheus和grafana提供比較完善的監控系統

• 性能優化一部分靠生態提供的工具，pd-ctl、tidb-ctl等。另外一方面靠社區的相應

• 源碼透明，能夠深刻了解其實現

應用場景

DRDS

• 順時高峯且易造成數據熱點的場景 DRDS的分片機制爲hash分片，自然將數據打散到各個節點，藉助RDS自己的緩存機制能夠很好的緩解數據熱點。好比企業的考勤系統或銀行的櫃員系統，在早上上班高峯併發量多，幾分鐘到一個小時的時間內員工會集中打卡或者登陸單例數據庫會瞬間達到性能瓶頸。

TiDB

• 多租戶SaaS應用：

  該場景多爲多租戶場景，SAAS供應商爲每個用戶提供單獨的庫，每一個數據庫的數據量不均衡。若是使用MySQL單實例掛載多庫的方式只能縱向擴展；多實例多庫方式要麼在應用層爲每一個應用程序配置不一樣的數據庫URL，要麼實現業務數據Router；採用TiDB能夠統一管理數據資源，將多個實例轉化爲一個集羣維護，同時藉助TiDB的數據分片機制避免單一用戶造成實例熱點。

• 微服務架構統一管理數據資源：

  微服務架構的一個原則是數據可拆分，但若是每一個微服務使用MySQL主備方式維護一組MySQL實例不只不便於管理，並且因爲每一個服務對數據庫資源使用的不均衡及易形成資源浪費。應用TiDB集羣不只能夠很好的解決上述問題，並且便於維護，同時就業務來說比較容易造成數據服務中間層。

備份機制

DRDS  依賴於RDS自己的備份機制

TiDB

• Tidb遵循MySQL協議，全量狀況下能夠經過MyDumper等邏輯備份工具有份數據

• 增量數據能夠經過社區提供的TiDB-Binlog實時生成增量備份文件

應用改形成本

DRDS

• 分片鍵的選擇，實際開發中一般會存在說幹業務依賴於同一張表的狀況，經過某一個列做爲分片條件提升某項業務性能時可能隱性下降某些業務的性能。

• 分片算法的選，DRDS的拆分算法不少，擇簡單取模、數值向右移、雙拆分列哈希等等，須要開發者先弄清楚這些概念再根據業務狀況進行選擇

• 拆分後的表不支持全局惟一約束，若是因爲業務需求必須維護全局惟一隻能經過創建中間表的方式維護惟一性，增長開發成本和數據庫調用次數

• 拆分後的表部分SQL要根據DRDS的擴展語法重寫

TiDB

• TiDB的SQL實質上是MySQL語法的一個徹底子集，若是業務沒有用到MySQL的內建函數和外鍵約束的話基本能夠平滑遷移，只須要對部分SQL根據TiDB架構特性進行優化

• 若是重度應用MySQL的系統存在某些TiDB不支持的函數，那麼這部分功能須要應用端實現

整體上來說，DRDS的應用改形成本主要集中在業務數據拆分上，以及因爲數據拆分帶來的業務應用重構；Tidb因爲自身架構原生支持分片因此不存在數據拆分問題，應用重用主要因爲對MySQL的私有內建函數依賴重。

我的觀點總結

DRDS起源於DB中間件，經過hash算法作數據分片用於擴展單機數據庫的不足，屬於過分產品，擴展時數據再平衡的時間會隨着數據及節點數量的增長而增長。從應用改造後續維護的角度來說，性價比不高。從場景上來說DRDS的hash分片機制能夠更好的散列數據，更加不易造成數據熱點；TiDB在頻發訪問的數據量小於64M時易造成熱點，當數據的範圍大於64M的時候幾乎能夠數據會被分配到其餘節點熱點也隨之消除。從應用架構來考慮，這個量級的熱數據徹底能夠經過緩存解決。TiDB從架構來說是一個很優雅的數據庫系統，社區及公司歷史不長但發展很快，在實際使用過程當中會遇到一些坑，這些坑一部分是因爲產品成長過程當中的bug或者待優化feature形成，另外一部分是因爲單機環境和分佈式環境的差別形成的。敢於嘗試新事物，也許將來收益會更大。

[文章轉載自公衆號

  北京IT爺們兒]( mp.weixin.qq.com/s?__biz=MzU…)

閱讀原文