“當使用者使用軟體時，會需要面對的兩個鴻溝：一個是執行的鴻溝，在這裡，使用者要弄清楚如何操作，與軟體「對話」；另一個是評估的鴻溝，使用者要弄清楚操作的結果。” PingCAP 聯合創始人兼 CTO 黃東旭在《做出讓人愛不釋手的基礎軟體》中提到，“ 我們作為設計師的使命就是幫助使用者消除可觀測性和可互動性這兩個鴻溝。”
2021年 11 月 30 日，TiDB 5.3.0 版本正式上線，該版本推出持續效能分析 （Continuous Profiling) 功能（目前為實驗特性），跨越可觀測性的鴻溝，為使用者帶來資料庫原始碼水平的效能洞察，徹底解答每一個資料庫問題。
在提升資料可觀測性的同時，TiDB 5.3.0 實現了 HTAP 效能和穩定性的大幅提升，資料遷移效率、高可用性和易用性也實現了大幅提升，為所有使用者帶來重磅福利。
5.3.0 功能亮點與使用者價值
- 支援持續效能分析 (Continuous Profiling) ，引領資料庫的可觀測性潮流
- 深度優化分散式時間戳獲取技術，提升系統的整體效能
- 持續優化儲存和計算引擎，提供更敏捷更可靠的 HTAP 服務
- 進一步降低上游系統同步資料至 TiDB 的延遲，助力高峰期業務增長
- 新增並行匯入功能，提升全量資料遷移效率
- 引入臨時表，一條 SQL 語句簡化業務邏輯並提升效能
支援持續效能分析，引領資料庫的可觀測性潮流
在企業遭遇的 IT 故障中，約有 30% 與資料庫相關。當這些故障涉及到應用系統、網路環境、硬體裝置時，恢復時間可能達到數小時，對業務連續性造成破壞，影響使用者體驗甚至營收。在複雜分散式系統場景下，如何提高資料庫的可觀測性，幫助運維人員快速診斷問題，優化故障處理流程一直是困擾著企業的一大難題。在 TiDB 5.3.0 版本中，PingCAP 率先在資料庫領域推出了持續效能分析 (Continuous Profiling) 特性（目前為實驗特性），為企業提供了資料庫原始碼水平的效能洞察。
持續效能分析以低於 0.5% 的效能損耗實現了對資料庫內部執行狀態持續打快照（類似 CT 掃描），以火焰圖的形式從系統呼叫層面解讀資源開銷。 讓原本黑盒的資料庫變成白盒。在 TiDB Dashboard 上一鍵開啟持續效能分析後，運維人員可以方便快速定位效能問題的根因，無論過去現在皆可回溯。
- 當資料庫意外當機時，可降低至少 50% 診斷時間
在網際網路行業的一個案例中，當客戶叢集出現報警業務受影響時，因缺少資料庫連續效能分析結果，運維人員難以發現故障根因，耗費 3 小時才定位問題恢復叢集。如果使用 TiDB 的持續效能分析功能，運維人員可比對日常和故障的分析結果，僅需 20 分鐘就可恢復業務，極大減少損失。 - 在日常執行中，可提供叢集巡檢和效能分析服務，保障叢集持續穩定執行
持續效能分析是 TiDB 叢集巡檢服務的關鍵，為商業客戶提供了叢集巡檢和巡檢結果資料上報。客戶可以自行發現和定位潛在風險，執行優化建議，保證每個叢集持續穩定執行。 - 在資料庫選型時，提供更高效的業務匹配
在進行資料庫選型時，企業往往需要在短時間內完成功能驗證、效能驗證的流程。持續效能分析功能能夠協助企業更直觀地發現效能瓶頸，快速進行多輪優化，確保資料庫與企業的業務特徵適配，提高資料庫的選型效率。
注：效能分析結果儲存在監控節點上，不會對處理業務流量的節點產生影響。
深度優化分散式時間戳獲取技術，為海量業務資料處理提供堅強後盾
當網際網路行業的核心業務系統具有龐大的使用者數量和業務資料時，在高併發訪問的場景下，可能會出現資料庫時間戳獲取延遲增大而導致業務響應變慢、超時頻發、使用者體驗急劇下降的情況。海量的業務資料要求資料庫擁有良好的擴充套件性。TiDB 本身擁有能夠水平擴充套件的優勢，但是不斷增長的業務資料量使時間戳獲取能力逐漸成為阻礙叢集擴充套件的瓶頸，最終限制叢集整體的擴充套件。
為進一步提升時間戳獲取能力，在 TiDB 5.3.0 版本中，TiDB 在保持原有的全域性時間戳管理方式的基礎上，新增兩個時間戳處理調優引數，在 PD 負載達到瓶頸的情況下，可以有效減輕負載，降低了時間戳獲取延遲，大大提升了系統的整體效能：
- 支援引數設定 PD follower proxy 開關，開啟後允許 follower 批量轉發時間戳處理請求。
- 支援設定 PD client 批量處理時間戳的最大等待時間引數，提高時間戳請求的處理頻寬。
通過本次優化，TiDB 能夠更好地支撐百 TB 或百萬 QPS 大規模叢集的擴充套件。經過 Sysbench 512 執行緒的測試驗證，時間戳處理流程優化後，TiDB 叢集整體 QPS 吞吐提升了 100% 以上。具體測試環境如下：
| 角色 | 數量 | 規格 |
|---|---|---|
| TiDB | 26 | 8 cores |
| PD | 3 | 4 cores |
| TiKV | 5 | 12 cores |
本次優化適用於以下場景：
- 擁有百 TB 或 百萬 QPS 以上超大規模叢集，需要實現大規模叢集的擴充套件。
- 擁有中等規模叢集，但隨著業務的急速增長，資料的成倍增加，需要實現叢集的無限擴充套件。
持續優化儲存和計算引擎，提供更敏捷更可靠的 HTAP 服務
在大型物流和金融服務類企業中，線上交易和實時業務監控等應用場景對資料有較高的一致性和時效性要求，尤其是當讀寫混合負載大時，會對資料庫管理系統的效能和穩定性形成較大挑戰。在年度流量峰值時段，資料平臺的寫入/更新和分析任務往往會激增數倍。例如，某合作伙伴（物流龍頭）在雙十一期間，每天處理超 2500 億條更新和插入記錄，同時還要兼顧海量歷史資料（50 億～100 億）的分析任務。
TiDB HTAP 致力於為企業的規模化線上交易和實時分析應用提供一棧式資料服務平臺，提升關鍵業務的時效性，降低資料技術棧的複雜性。在已有產品基礎上，TiDB 5.3.0 進一步優化了 HTAP 的效能和穩定性，大幅改善了高混合負載場景下併發查詢能力和查詢任務的執行速度。主要的改進包括：
- 效能大幅提升（50%～100%），CPU /記憶體資源使用率進一步優化，查詢失敗減少：TiDB 5.3.0 優化了列式儲存引擎，調整了儲存引擎底層檔案結構和 IO 模型，優化了訪問節點副本和檔案區塊的計劃，緩和了寫放大問題以及改進了普遍的程式碼效率。總體上高負載時因資源不足造成的失敗狀況大大緩解。
- 遠端資料讀取提速，任務成功率提高，告警可讀性增強：優化了 MPP 計算引擎，支援更多的字串/時間和其他函式/運算元下推至 MPP 引擎，並改善了儲存層寫入/更新事務量較大時資料等待造成內部程式超時的問題，同時還優化了查詢請求的告警資訊，便於追蹤和定位問題。
- 輕鬆擴充套件節點：在 TiDB 5.3.0 中，TiDB HTAP 架構可隨業務增長輕鬆擴充套件到 200 節點甚至更大的叢集規模，並且確保 OLTP 與 OLAP 之間原則上不產生資源衝突和相互效能影響。
- 增強運維能力：完善了資料校驗，解決了節點重啟時內部處理可能出現的問題；同時進一步提升了 SQL 告警資訊和增強了日誌收集、檢索功能。
低延遲同步至 TiDB，助力企業業務持續增長
伴隨著業務持續增長，企業訂單系統的資料庫壓力也不斷增加。核心交易庫寫流量巨大，造成訂單提交時間變長，影響網站使用者體驗。面對這一典型的業務場景，為了幫助提升企業縮短訂單提交時間，TiDB 支援作為下游只讀從庫提供業務查詢服務，為核心交易系統減壓。
TiDB Data Migration (DM) 作為一款實時的資料同步工具，支援將資料從與 MySQL 協議相容的資料庫同步到 TiDB，實現業務分流，減輕高峰期前端訂單寫入時的壓力。而交易場景高度的即時性，要求業務查詢延遲極低、資料實時性極高，這給 DM 的同步效能帶來了極大挑戰。
為了保證低延遲，資料遷移工具 DM 在 v5.3.0 實現了兩項優化：
- 合併單行資料的多次變更，減少同步到下游的 SQL 數量，提高遷移效率，降低資料延遲，為網站使用者更快地提供業務查詢服務；
- 批量的點查更新合併為單一的語句操作，減少遠端過程呼叫請求的數量，同樣數量的 binlog 可以更快地同步完成，進而降低延遲，為網站使用者更準確地提供業務查詢服務。
極低的同步延遲保障了下游 TiDB 資料查詢實時性，企業在保持現有架構的情況下，無需進行大規模改造，就能快速引入 TiDB 以增強實時查詢分析能力，更好更快萃取資料價值。
經場景實測，在 300K QPS 資料同步流量下，99.9% 時間內 DM 同步延遲降低至 1 秒以內，尤其適用於高負載業務壓力下 TiDB 作為只讀從庫的場景。
新增並行匯入功能，提升全量資料遷移效率
目前 MySQL 分庫分表架構日益普遍，很多企業的資料量已經達到百 TB 級別。隨著企業資料量的增長，從集中式資料庫遷移到以 TiDB 為代表的分散式資料庫已經成為必然，然而存量系統裡面的 100 TB 資料沒有方便高效的工具進行遷移。
為解決此問題，TiDB 5.3.0 釋出了 [TiDB Lightning](https://docs.pingcap.com/zh/t...
) 並行匯入功能，提供了高效的 TiDB 叢集初始化能力。使用者可以同時啟動多個 TiDB Lightning 例項，並行地將單表或者多表資料遷移到 TiDB，速度可以橫向擴充套件，極大地提高了資料遷移效率。
並行匯入示意圖如下。使用者可以使用多個 TiDB Lightning 例項匯入 MySQL 的分表到下游的 TiDB 叢集。
並行匯入功能支援多種資料來源，包括：CSV/SQL 格式的文字資料、MySQL 分表匯出資料 。支援的最大單表規模在 20 TB ～ 30 TB 之間，匯入單表資料建議使用 1 個 ～ 8 個 TiDB Lightning 例項，每個例項最佳規模保持在 2 TB～ 5 TB 。對於多表總規模和使用 Lightning 的個數沒有上限要求。
經測試，使用 10 臺 TiDB Lightning，20 TB 規模的 MySQL 資料可以在 8 小時內匯入到 TiDB，單臺 TiDB Lightning 可以支援 250 GB/s 的匯入速度，整體效率提升了 8 倍。
引入臨時表，一條 SQL 語句簡化業務邏輯並提升效能
業務臨時中間資料儲存不易
在資料量大的場景下，使用者業務常常需要處理龐大的中間資料。如果業務需要反覆使用資料中的一部分子集，使用者通常會臨時儲存這部分資料，用完後釋放。因此，DBA 不得不頻繁地建表和刪表，可能還需要自行設計資料儲存結構，把中間資料儲存至業務模組中。這不僅增加了業務複雜度，也造成了龐大的記憶體開銷，而且如果管理不善，還存在記憶體洩漏導致系統崩潰的風險。
TiDB 臨時表幫助使用者簡化業務邏輯並提升效能
為幫助使用者解決以上痛點，TiDB 在 5.3.0 版本中引入了臨時表功能。該功能針對業務中間計算結果的臨時儲存問題，讓使用者免於頻繁地建表和刪表等操作。使用者可將業務上的中間計算資料存入臨時表，用完後自動清理回收，避免業務過於複雜，減少表管理開銷，並提升效能。
TiDB 臨時表主要應用於以下業務場景：
- 快取業務的中間臨時資料，計算完成後將資料轉儲至常規表，臨時表會自動釋放。
- 短期內對同一資料進行多次 DML 操作。例如在電商購物車應用中，新增、修改、刪除商品及完成結算，並移除購物車資訊。
- 快速批量匯入中間臨時資料，提升匯入臨時資料的效能。
批量更新資料。將資料批量匯入到資料庫的臨時表，修改完成後再匯出到檔案。
一條 SQL 語句輕鬆建立臨時表
可通過 CREATE [GLOBAL] TEMPORARY TABLE 語句建立臨時表。臨時表中的資料均儲存在記憶體中，使用者可通過 tidb_tmp_table_max_size 變數限制臨時表的記憶體大小。
TiDB 提供的臨時表分為 Global 和 Local 兩類，無論使用哪種臨時表，都能有效幫助使用者簡化業務邏輯並提升效能：
- Global 臨時表：
- 對叢集內所有 Session 可見，表結構持久化。
- 提供事務級別的資料隔離，資料只在事務內有效，事務結束後自動刪除資料。
- Local 臨時表：
- 只對當前 Session 可見，表結構不持久化。
- 支援重名，使用者無需為業務設計複雜的表命名規則。
提供會話級別的資料隔離，降低業務設計複雜度，會話結束後刪除臨時表。
結語
本次釋出的 5.3.0 版本進一步完善了系統的可觀測性、提升了分散式資料庫可擴充套件性、保證了資料的低延遲同步、大幅提升了全量資料遷移效率、提升了實時分析的穩定性，是 TiDB 邁向成熟企業級 HTAP 平臺的一個重要里程碑。
PingCAP 首席架構師唐劉表示：TiDB HTAP 的使命不僅僅侷限於對傳統資料庫的升級或者是交易和分析處理效能的提升，本質上 TiDB HTAP 是一個開放的生態體系，在企業中承擔著支援資料服務消費化和構建統一實時資料服務平臺的角色，為使用者帶來業務與架構的創新與提升。
TiDB 的每一次發版和進步都離不開每一位使用者的反饋、每一位開發者的 PR 合併、每一位質量保證人員的測試。感謝所有人的貢獻，TiDB 在後續版本中會不斷加強大規模場景下的穩定性和易用性，不忘初心，砥礪前行，成為一款讓人愛不釋手的基礎軟體，給使用者帶來更好的使用體驗。
檢視 TiDB 5.3.0 Release Notes，立即下載試用，開啟 TiDB 5.3.0 之旅。