TiDB 6.0 實戰分享丨冷熱儲存分離解決方案

語言: CN / TW / HK
時間 2022-06-09 03:16:26
主題:

結論先行

TiDB 6.0 正式提供了資料放置框架（Placement Rules in SQL ）功能，使用者通過 SQL 配置資料在 TiKV 叢集中的放置位置，可以對資料進行直接的管理，滿足不同的業務場景需要。如：

1.冷熱分離儲存，降低儲存成本

  • TiDB 6.0 正式支援資料冷熱儲存分離，可以降低 SSD 使用成本。使用 TiDB 6.0 的資料放置功能，可以在同一個叢集實現海量資料的冷熱儲存，將新的熱資料存入 SSD，歷史冷資料存入 HDD，降低歷史歸檔資料儲存成本。
  • 將熱資料從 ssd 遷移到 hdd，每小時可歸檔約 3000 萬行，總體來看效率還是比較高的
  • 將冷資料從 hdd 遷移到 ssd，每小時可遷移約 6300 萬行，大約是從 ssd 遷移到 hdd 速度的 2 倍
  • 分離儲存過程，ssd 和 hdd 用於歸檔的 IO 消耗都在 10%以內，叢集訪問 QPS 表現平穩，對業務訪問的影響較小
  • 在補寫冷資料場景，每小時寫入約 1500 萬行到 hdd，資料可正確地直接寫入 hdd，不會經過 ssd

2.業務底層物理隔離，實現同一叢集不同儲存

  • 通過放置規則管理將不同資料庫下的資料排程到不同的硬體節點上，實現業務間資料的物理資源隔離，避免因資源爭搶，硬體故障等問題造成的相互干擾
  • 通過賬號許可權管理避免跨業務資料訪問，提升資料質量和資料安全。

3.合併MySQL業務，降低運維壓力，提升管理效率

  • 使用少數 TiDB 叢集替換大量的 MySQL 例項，根據不同業務底層設定不同的物理儲存隔離需求，讓資料庫數量大大減少，原本的升級、備份、引數設定等日常運維工作將大幅縮減，在資源隔離和價效比上達到平衡，大幅減少 DBA 日常的運維管理成本。

我們的 HTAP 叢集目前有一個數據歸檔需求，整個叢集共約 330TB，考慮到成本和訪問頻率、效能等各方面需求，要求至少儲存 3 個月共約 80TB 到 ssd，250TB 存到 hdd，現在基於我們的大資料冷熱分離歸檔業務場景，本文重點探討冷熱資料歸檔儲存的功能和特性，以方便下一步我們正式應用到生產環境。

概述

TiDB 叢集通過 PD 節點（Placement Driver 元件）在系統內基於熱點、儲存容量等策略自動完成 region 的排程，從而實現叢集資料均衡、分散儲存在各個節點的目標，這些排程操作是叢集的自身管理行為，對使用者而已幾乎是透明的，在之前的版本使用者無法精確控制資料的儲存方式和位置。

TiDB 6.0 正式提供了資料放置框架（Placement Rules in SQL ）功能，使用者通過 SQL 配置資料在 TiKV 叢集中的放置位置，可以對資料進行直接的管理，以滿足不同的業務場景需要。使用者可以將庫、表和分割槽指定部署至不同的地域、機房、機櫃、主機。還支援針對任意資料提供副本數、角色型別等維度的靈活排程管理能力，這使得在多業務共享叢集、跨中心部署、冷熱資料歸檔儲存等場景下，TiDB 得以提供更靈活更強大的資料管理能力。

該功能可以實現以下業務場景：

  • 動態指定重要資料的副本數，提高業務可用性和資料可靠性
  • 將最新資料存入 SSD，歷史資料存入 HDD，降低歸檔資料儲存成本
  • 把熱點資料的 leader 放到高效能的 TiKV 例項上，提供高效訪問
  • 不同業務共用一個叢集，而底層按業務實現儲存物理隔離，互不干擾，極大提升業務穩定性
  • 合併大量不同業務的 MySQL 例項到統一叢集，底層實現儲存隔離，減少管理大量資料庫的成本

原理簡介

早期版本的 Placement rule 使用時需要通過 pd-ctl 工具設定和檢視，操作繁瑣且晦澀難懂。經過幾個版本的迭代和優化，推出的 PlacementRules in SQL 對使用者更加友好，到了 v6.0.0 總體來說還是很方便理解和使用的，避免了使用 pd-ctl 工具配置的複雜性，大大降低使用門檻。

放置策略的實現依賴於 TiKV 叢集 label 標籤配置，需提前做好規劃（設定 TiKV 的 labels）。可通過show placement labels檢視當前叢集所有可用的標籤。

```sql mysql> show placement labels ; +------+-----------------------------------------------------------------+ | Key | Values | +------+-----------------------------------------------------------------+ | disk | ["ssd"] | | host | ["tikv1", "tikv2", "tikv3"] | | rack | ["r1"] | | zone | ["guangzhou"] | +------+-----------------------------------------------------------------+ 4 rows in set (0.00 sec)

```

使用時有基礎用法和高階用法兩種方式。

(1) 基礎放置策略

基礎放置策略主要是控制 Raft leader 和 followers 的排程。

```sql #建立放置策略 CREATE PLACEMENT POLICY myplacementpolicy PRIMARY_REGION="guangzhou" REGIONS="guangzhou,shenzhen";

#將規則繫結至表或分割槽表，這樣指定了放置規則 CREATE TABLE t1 (a INT) PLACEMENT POLICY=myplacementpolicy; CREATE TABLE t2 (a INT); ALTER TABLE t2 PLACEMENT POLICY=myplacementpolicy;

#檢視放置規則的排程進度，所有繫結規則的物件都是非同步排程的。 SHOW PLACEMENT;

#檢視放置策略 SHOW CREATE PLACEMENT POLICY myplacementpolicy\G select * from information_schema.placement_policies\G

#修改放置策略，修改後會傳播到所有繫結此放置策略的物件 ALTER PLACEMENT POLICY myplacementpolicy FOLLOWERS=5;

#刪除沒有繫結任何物件的放置策略 DROP PLACEMENT POLICY myplacementpolicy;

```

(2) 高階放置策略

基礎放置策略主要是針對 Raft leader 、Raft followers 的排程策略，如果需要更加靈活的方式，如不區分 region 角色將資料指定儲存在 hdd，需要使用高階放置策略。使用高階放置策略主要有兩個步驟，首先建立策略，然後在庫、表或分割槽上應用策略。

```sql # 建立策略，指定資料只儲存在ssd CREATE PLACEMENT POLICY storeonfastssd CONSTRAINTS="[+disk=ssd]";

# 建立策略，指定資料只儲存在hdd CREATE PLACEMENT POLICY storeonhdd CONSTRAINTS="[+disk=hdd]";

# 在分割槽表應用高階放置策略，指定分割槽儲存在hdd或者ssd上，未指定的分割槽由系統自動排程 CREATE TABLE t1 (id INT, name VARCHAR(50), purchased DATE) PARTITION BY RANGE( YEAR(purchased) ) ( PARTITION p0 VALUES LESS THAN (2000) PLACEMENT POLICY=storeonhdd, PARTITION p1 VALUES LESS THAN (2005), PARTITION p2 VALUES LESS THAN (2010), PARTITION p3 VALUES LESS THAN (2015), PARTITION p4 VALUES LESS THAN MAXVALUE PLACEMENT POLICY=storeonfastssd );

```

高階放置策略具體內容，請看官網介紹http://docs.pingcap.com/zh/tidb/stable/placement-rules-in-sql#%E9%AB%98%E7%BA%A7%E6%94%BE%E7%BD%AE。

環境

| 角色 | 機器數 | 記憶體 | 資料盤 | CPU | OS | | --------- | ------ | ---- | ------------------ | ------------------------- | ----------------------------------------------- | | TiDB&TiPD | 3 | 256G | 1TB hdd | 40 cpu (20 core2 thread) | Debian 4.19.208-1 (2021-09-29) x86_64 GNU/Linux | | TiKV | 3 | 256G | 800GB ssd，1TB hdd | 40 cpu (20 core2 thread) | Debian 4.19.208-1 (2021-09-29) x86_64 GNU/Linux |

冷熱歸檔儲存

  • 目標：對給定的表按日期分割槽，將最新分割槽的資料存入 SSD，歷史資料存入 HDD

功能驗證

1.部署叢集並建立放置策略

  • 部署 TiDB v6.0.0 叢集，具體參考部署叢集操作

  • 建立資料落盤策略，以備使用

```sql # 應用該策略的庫、表、分割槽，資料會儲存在ssd上 CREATE PLACEMENT POLICY storeonssd CONSTRAINTS="[+disk=ssd]" ;

# 應用該策略的庫、表、分割槽，資料會儲存在hdd上 CREATE PLACEMENT POLICY storeonhdd CONSTRAINTS="[+disk=hdd]";

#檢視叢集已有策略 mysql> show placement \G ***** 1. row **** Target: POLICY storeonhdd Placement: CONSTRAINTS="[+disk=hdd]" Scheduling_State: NULL *** 2. row ****** Target: POLICY storeonssd Placement: CONSTRAINTS="[+disk=ssd]" Scheduling_State: NULL 2 rows in set (0.02 sec)

```

2.建立庫表並應有放置策略

建立目標表為TiDB分割槽表並且按 Range 分割槽。

```sql # 建立資料庫tidb_ssd_hdd_test，並設定該庫預設落盤策略，設定後新建的表都會預設繼承該策略 create database tidb_ssd_hdd_test PLACEMENT POLICY=storeonssd;

# 檢視策略已經應用到指定庫上 mysql> show placement \G ***** 1. row **** Target: POLICY storeonhdd Placement: CONSTRAINTS="[+disk=hdd]" Scheduling_State: NULL *** 2. row *** Target: POLICY storeonssd Placement: CONSTRAINTS="[+disk=ssd]" Scheduling_State: NULL *** 3. row ****** Target: DATABASE tidb_ssd_hdd_test Placement: CONSTRAINTS="[+disk=ssd]" Scheduling_State: SCHEDULED 3 rows in set (0.02 sec)

# 建立分割槽表，可以看到表建立後預設繼承和庫一樣的落盤策略，關鍵標識為“/T![placement] PLACEMENT POLICY=storeonssd /” CREATE TABLE logoutrole_log ( doc_id varchar(255) NOT NULL, gameid varchar(255) DEFAULT NULL , -- some fields logdt timestamp DEFAULT '1970-01-01 08:00:00' , updatetime varchar(255) DEFAULT NULL , UNIQUE KEY doc_id (doc_id,logdt), -- some index KEY logdt_gameid (logdt,gameid) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin /T![placement] PLACEMENT POLICY=storeonssd / PARTITION BY RANGE ( UNIX_TIMESTAMP(logdt) ) ( PARTITION p20220416 VALUES LESS THAN (UNIX_TIMESTAMP('2022-04-17 00:00:00')), PARTITION p20220417 VALUES LESS THAN (UNIX_TIMESTAMP('2022-04-18 00:00:00')), PARTITION p20220418 VALUES LESS THAN (UNIX_TIMESTAMP('2022-04-19 00:00:00')), PARTITION p20220419 VALUES LESS THAN (UNIX_TIMESTAMP('2022-04-20 00:00:00')), PARTITION p20220420 VALUES LESS THAN (UNIX_TIMESTAMP('2022-04-21 00:00:00')), PARTITION p20220421 VALUES LESS THAN (UNIX_TIMESTAMP('2022-04-22 00:00:00')), PARTITION p20220422 VALUES LESS THAN (UNIX_TIMESTAMP('2022-04-23 00:00:00')) );

```

3.寫入熱資料到 ssd 盤並擴容 hdd 儲存節點

  • 叢集只有 3 個 ssd 的 tikv 節點，啟動 flink 流往目標表匯入資料，可以看到這 3 個 ssd 節點的 region 數和空間使用在不斷增長

1650964998281.png

1650965222072.png

  • 在原有基礎上再擴容 3 個 hdd tikv 例項

1650965633758.png

4.冷熱分離

為了方便模擬資料的遷移，flink 匯入的資料是全部落在 2022-04-16 這一天：

```sql mysql> select date(logdt) as day,count(0) from logoutrole_log group by day order by day ;
+------------+----------+ | day | count(0) | +------------+----------+ | 2022-04-16 | 1109819 | +------------+----------+ 1 row in set (1.09 sec)

```

停止 Flink 寫入後，設定資料分離放置策略，將儲存在 ssd 上的 2022-04-16 這一天的資料，轉存到 hdd 上，模擬冷資料歸檔操作：

sql mysql> alter table tidb_ssd_hdd_test.logoutrole_log partition p20220416 placement policy storeonhdd; Query OK, 0 rows affected (0.52 sec)

在應用 hdd 轉存策略後，如下圖可以看到排程規則裡 2022-04-16 這一天的分割槽 Placement 由 ssd 變為了 hdd，即叢集已經知曉最新的排程策略是將這一天的分割槽資料排程到 hdd 去，Scheduling_State 處於 PENDING 狀態，表示 Follower 的 raft log 與 Leader 有較大差距，在這裡可以理解為是正在處於排程的過程。

1650341702179.png

隨著時間的推移，資料在不斷從 ssd 遷移到 hdd 上。從叢集 grafana 監控面板可以看到 ssd 節點上的 region 資料在不斷下降，直到降到接近於 0；相反，hdd 上的 region 數不斷上升，直到資料全部遷出 ssd 節點。110 萬行資料從 ssd 遷移到 hdd，大約耗時 3min 。

1650342094048.png

在資料全部遷如 hdd 節點後，檢視排程進度，此時 Scheduling_State 處於 SCHEDULED 完成排程狀態：

1650342133243.png

結論：

  • 證明冷熱資料隔離儲存策略已經生效，ssd 上的資料完成遷移到 hdd 上，且 ssd 的空間得以釋放，符合資料歸檔的目標。

靜態叢集冷熱儲存分離（無外部訪問）

ssd->hdd

繼續通過 flink 寫入資料到 2022-04-17 分割槽，然後停流使叢集沒有外部訪問流量，將此分割槽上 ssd 資料遷移到 hdd。

alter table tidb_ssd_hdd_test.logoutrole_log partition p20220417 placement policy storeonhdd;

1650970144694.png

ssd 上的 region 全部遷移到 hdd 上，ssd 空間被釋放，hdd 空間使用逐漸增加，遷移過程中 ssd 和 hdd 的 IO 消耗都在 5%左右，記憶體和網路頻寬使用不變、保持平穩。 約 6 千萬行 130GB 資料從 ssd 資料遷移到 hdd 大概需要 2 個小時

結論：

  • 在將大規模資料從 ssd 資料遷移到 hdd 過程，叢集資源消耗比較低，可以有效避免過多佔用叢集資源。
  • 在叢集沒有外部訪問壓力時，在預設配置下，叢集以每小時約 3000 萬行的速度從 ssd 遷移到 hdd 節點。

hdd->ssd

在沒有外部流量訪問時，將資料從 hdd 遷移回 ssd，從監控圖可以看到，hdd 節點的 tikv 的 leader 數、region 數在此期間都在下降，分別從 850、2500 逐漸下降直到為 0，磁碟空間也從 62GB 下降為 0，表示資料在持續遷移出 hdd 節點；

1652425488812.png

1652425944226.png

相反地，由於資料不斷遷入到 ssd 中，ssd 節點的 tikv 的 leader 數、region 數在此期間都在上升，分別從 1500、4200 逐漸上升到 2200、6700，直到資料遷入完成，然後保持數量不變，ssd 的磁碟空間消耗也從 100GB 上升到 161GB。

遷移的過程中，ssd 和 hdd 節點的 IO 使用率都比較低，如下圖：

1652426155311.png

結論：

  • 將冷資料從 hdd 遷移至 ssd，遷移 1.7 億行共約 200GB 資料，大約耗時 2 小時 40 分鐘，平均每小時遷移 6300 萬行，速度約為將熱資料從 ssd 遷到 hdd 的 2 倍（每小時約 3000 萬行）
  • 將資料從 hdd 遷移至 ssd 的過程，不管是對 ssd 還是 hdd，其平均 IO 使用率都不高，不會佔用過多叢集的資源，可以認為資料遷移過程對叢集正在執行的業務影響不大

熱叢集冷熱儲存分離（外部持續訪問）

繼續持續寫入資料到 2022-04-18 和 2022-04-19 的 ssd 分割槽，然後不停流保持持續的寫入壓力，遷移 2022-04-18 資料從 ssd 到 hdd，觀察叢集表現。

```sql

應用放置策略將2022-04-18資料從ssd歸檔到hdd

alter table tidb_ssd_hdd_test.logoutrole_log partition p20220418 placement policy storeonhdd; ```

在歸檔過程，flink 同時持續以 2100 的 QPS 寫入熱資料，期間 ssd IO 接近 100%，hdd 的 IO 消耗在 10%以下，各節點 CPU 在 500%以下，網路頻寬在 200MB/s 以下，記憶體使用保持平穩。

從 region 數變化的角度來看：

  • 在歸檔資料時，ssd 的 tikv region 數從 6300 下降到 3500 左右，當遷移完成後是淨寫入資料，此時 ssd 節點的 region 數量又持續上升；
  • hdd 節點的 region 數從開始的 2600 上升到 6500 左右，隨著資料遷移完成，hdd 的 region 數不再增加，一直保持 6500 不變。

1650971789523.png

從磁碟使用空間變化的角度來看：

  • 歸檔資料時，ssd 節點的磁碟使用空間從 152GB 下降到 88GB，當遷移完成後，此時是淨寫入資料，ssd 空間開始上升；
  • 資料在不斷寫入到 hdd 節點，所以其使用空間從 61GB 上升到 154GB，隨著資料遷移完成，一直保持不變

1650593578630.png

1650593565818.png

1650593789799.png

結論：

  • 在有外部幾乎是滿 IO 的寫入壓力時，歸檔約 2 億行、400GB 資料從 ssd 到 hdd 節點，大概需要 6 個小時，即約 3300 萬行/小時，可以說冷資料的歸檔效率還是比較高的
  • 集群后臺在進行資料歸檔時，flink 的 sink QPS 變化不大，可以認為歸檔的過程對叢集正常寫入影響不大

歸檔資料補寫

業務上有補全歷史資料的場景，比如資料重算等，這裡模擬補全歷史冷資料，寫入到 hdd。

  • 2022-04-16 這一天的資料已經全部轉存到 hdd 冷盤中。啟動 flink 流，繼續對 2022-04-16 分割槽寫入資料，這些只會寫 hdd，不會寫入 ssd。flink 流以 2000 左右的 sink QPS 補全冷資料，hdd tikv 節點 IO 打滿，SSD 的 IO 使用率比較低。

1650969265594.png

從下圖可以看到，在補全冷資料的時候， hdd 節點的 region 數在不斷上升，hdd tikv 的空間消耗也在不斷增加，而 ssd 的空間使用和 region 數均保持不變，說明資料並不會寫入 ssd 中，符合預期。

1650969430703.png

結論：

  • 說明 TiDB 冷熱資料分離儲存功能，在補全歷史冷資料的場景，即歸檔資料補寫，資料可以正確地直接寫入到 hdd，期間資料不會經過 ssd
  • 補全冷資料，hdd tikv 節點 IO 打滿，ssd 的 IO 使用率比較低，也說明資料不會經過 ssd

同一叢集業務隔離

除了冷熱資料歸檔外，我們線上不同的業務線通常採用一套或多套 MySQL 來管理，但因為業務多導致 MySQL 有數百個，日常的監控、診斷、版本升級、安全防護等工作對運維團隊造成了巨大的壓力，且隨著業務規模越來越大，管理的成本不斷上升。

使用 Placement rule 功能可以很容易靈活的叢集共享規則。可以將不同 MySQL 上的業務遷移到同一個 TiDB 叢集，實現多個不同業務的共用一個叢集而底層提供物理儲存隔離，有效減少大量 MySQL 的管理成本。這個也是我們接下來會繼續推進優化的地方。

舉例說明，業務 A和B 共享資源，降低儲存和管理成本，而業務 C 和 D 獨佔資源，提供最高的隔離性。由於多個業務共享一套 TiDB 叢集，升級、打補丁、備份計劃、擴縮容等日常運維管理頻率可以大幅縮減，降低管理負擔提升效率。

1651723818212.png

```sql CREATE PLACEMENT POLICY 'shared_nodes' CONSTRAINTS = "[+region=shared_nodes]"; CREATE PLACEMENT POLICY 'business_c' CONSTRAINTS = "[+region=business_c]"; CREATE PLACEMENT POLICY 'business_d' CONSTRAINTS = "[+region=business_d]";

ALTER DATABASE a POLICY=shared_nodes; ALTER DATABASE b POLICY=shared_nodes; ALTER DATABASE c POLICY=business_c; ALTER DATABASE d POLICY=business_d; ```

基於 SQL 介面的資料放置規則，你僅僅使用少數 TiDB 叢集管理大量的 MySQL 例項，不同業務的資料放置到不同的 DB，並通過放置規則管理將不同 DB 下的資料排程到不同的硬體節點上，實現業務間資料的物理資源隔離，避免因資源爭搶，硬體故障等問題造成的相互干擾。通過賬號許可權管理避免跨業務資料訪問，提升資料質量和資料安全。在這種部署方式下，叢集數量大大減小，原本的升級，監控告警設定等日常運維工作將大幅縮減，在資源隔離和價效比上達到平衡，大幅減少日常的 DBA 運維管理成本。

總結

1.冷熱分離儲存，降低儲存成本

  • TiDB 6.0 正式支援資料冷熱儲存分離，可以降低 SSD 使用成本。使用 TiDB 6.0 的資料放置功能，可以在同一個叢集實現海量資料的冷熱儲存，將新的熱資料存入 SSD，歷史冷資料存入 HDD，降低歷史歸檔資料儲存成本。
  • 將熱資料從 ssd 遷移到 hdd，每小時可歸檔約 3000 萬行，總體來看效率還是比較高的
  • 分離儲存過程，ssd 和 hdd 用於歸檔的 IO 消耗都在 10%以內，叢集訪問 QPS 表現平穩，對業務訪問的影響較小
  • 在補寫冷資料到 hdd 場景，資料可正確地直接寫入 hdd，不會經過 ssd。flink 補寫冷資料時滿 IO 每秒寫入約 4000 行，每小時寫入約 1500 萬行。

2.業務底層物理隔離，實現同一叢集不同儲存

  • 通過放置規則管理將不同資料庫下的資料排程到不同的硬體節點上，實現業務間資料的物理資源隔離，避免因資源爭搶，硬體故障等問題造成的相互干擾
  • 通過賬號許可權管理避免跨業務資料訪問，提升資料質量和資料安全。

3.合併MySQL業務，降低運維壓力，提升管理效率

  • 使用少數 TiDB 叢集替換大量的 MySQL 例項，根據不同業務底層設定不同的物理儲存隔離需求，讓資料庫數量大大減少，原本的升級、備份、引數設定等日常運維工作將大幅縮減，在資源隔離和價效比上達到平衡，大幅減少 DBA 日常的運維管理成本。

4.放置策略應用操作步驟

  • 對已有叢集應用 Placement Rules
  • 將叢集升級到 6.0.0 版本
  • 建立預設 SSD 策略
  • 開啟放置策略預設開關，使得叢集已有庫表都預設儲存在 ssd 上 （該功能依賴官方釋出新版本支援）
  • 目前只能用指令碼 alter 全部庫設定這個預設策略，如果有新增的庫也需要提前進行設定
  • 申請新機器並擴容新的 hdd tikv
  • 建立 hdd 放置策略
  • 在目標表的目標分割槽上指定 ssd 或 hdd 策略

  • 定期將過期分割槽宣告 hhd 放置策略

  • 對新建的叢集應用 Placement Rules

  • 部署 6.0.0 叢集版本
  • 建立預設 SSD 策略
  • 建立的全部庫都先設定這個預設策略
  • 申請新機器並擴容新的 hdd tikv
  • 建立 hdd 放置策略
  • 在目標表或目標分割槽上指定 ssd 或 hdd 策略
  • 定期將過期分割槽宣告 hhd 放置策略
「」