突破容量極限：TiDB 的海量數據「無感擴容」祕籍

對於任何一家業務快速成長的企業來講，應對峯值流量衝擊，一直是擺在技術團隊面前的一大難題。面對海量數據，數據庫及業務團隊都但願作到「無感擴容」，但流行的分庫、分表方案在擴容速度和一致性上常常不能知足需求。行業期待着性能強大、簡單易用的全新數據庫方案，從根本上解決企業面對流量高峯時的數據庫性能瓶頸。

行業需求是技術創新的最大推進力。近年來，由 PingCAP 開發的 TiDB 分佈式數據庫異軍突起，在海量數據處理領域具備很大的優點。在此背景下， 2020 年初京東智聯雲聯合 PingCAP，基於 TiDB 打造了雲端分佈式數據庫——Cloud-TiDB 。

11 月 26 日，京東智聯雲與英特爾聯合舉辦了主題爲「突破極限，TiDB 在京東智聯雲的技術架構與實踐」的線上直播活動。直播邀請到 京東智聯云云產品研發部架構師葛集斌老師，和 PingCAP TiDB 生態技術佈道專家戚錚老師 分別帶來分享，但願藉此機會幫助更多企業和開發人員拓展思路，提供一個分庫分表途徑以外的新選擇，並瞭解如何在生產實踐中發揮 TiDB 的價值。

本文總結自本場直播分享，內容有調整。

1、TiDB在京東智聯雲的技術架構與實踐

直播第一部分，葛老師深刻分析了京東智聯云爲什麼選擇 TiDB 數據庫，並介紹了 TiDB 在京東智聯雲上的技術架構和技術生態細節。

1，TiDB數據庫但願解決哪些問題

傳統單機數據庫在當下的大數據時代暴露出了愈來愈多的侷限性，對於一家快速增加的企業來講，因爲數據量會隨着企業規模有序擴大，單機數據庫很快就會遭遇多個瓶頸：

• 單表、單庫數據量過大；
• 單機存儲容量達到上限；
• 單機處理能力達到瓶頸。
• 讀取延遲和存儲需求上升，而且沒法擴展寫入性能。
• 想要繼續提高性能，傳統方法就是對數據庫進行分庫分表，但分庫分表也存在數日然約束。
• 在高可用性方面，MySQL 須要集成外部程序來處理。
• MySQL 的故障檢測、主從判斷和轉移都須要定製策略。
• 異步和半同步複製是非強一致性的，增長了數據丟失的風險。
• 此外，MySQL 的 OLAP 數據處理能力較弱，數據分析需求還須要 ETL 到外部分析系統。以上這些都是傳統數據庫方案現實存在的瓶頸。TiDB 的誕生，就是爲了解決這些傳統數據庫常見的問題，但願可以從根本上突破單機數據庫的能力極限。

具體到技術層面，TiDB 數據庫有哪些良藥來應對上述問題呢？首先要明確的是，TiDB 不一樣於傳統單機架構，而是一個真正意義上的分佈式數據庫。採用計算、存儲分離的架構設計，提供水平線性擴展能力。它還具有強一致性、高可用性，支持自動故障恢復，能夠對數據進行實時分析。另外它還高度兼容 MySQL 協議。總體架構來看，TiDB 分爲 TiDB Server、分佈式存儲層和 PD 三大部分：

• TiDB Server 兼容 MySQL 協議，能夠水平擴展，所以用戶能夠將 TiDB 看成 MySQL 使用。
• TiDB 存儲層 TiKV 是分佈式 KV 存儲，能夠線性擴展，並經過多副本和 Raft 協議保證強一致性。TiKV 還分爲多個 region，以 region 爲單位進行管理。數據分佈在各個 TiKV 節點上，節點能夠水平擴展。
• PD 負責集羣管理，包括調度和負載均衡工做，並負責生成全局的 TSO 時間戳。PD 自己也是無單點故障的集羣。

TiDB 使用 TiFlash 列存儲引擎來支持實時數據分析。它經過 Raft learner 進行異步複製，配合 MVCC 提供強一致性讀取，還支持計算下推，使得其 AP/TP 功能相互無干擾。使用 TiFlash 時 TiDB 優化器會計算查詢代價，根據結果自動選擇 TiKV 行存或 TiFlash 列存。

基於這樣的架構設計，TiDB 集羣實現了總體的高可用性和數據強一致性，即便少數副本丟失也能自動完成數據修復和故障轉移，不會干擾業務層。TiDB 能夠實現跨中心的異地多活部署。

2，雲上TiDB的實現和功能

近年來，京東智聯雲的客戶對數據處理能力的需求不斷提高。針對這樣的需求， 京東智聯雲與 PingCAP 聯合，基於 TiDB 打造了雲端分佈式數據庫——Cloud-TiDB ，主要面向高性能、高可靠、高可用場景。

上圖爲京東智聯雲 Cloud-TiDB 的總體架構，基於這樣的架構，Cloud-TiDB 提供了一些業務價值較高的功能，包括水平彈性擴容、備份和恢復、實時數據分析、數據遷移和同步、雲端監控告警等。

• 水平彈性擴容。TiDB 能夠在線動態增減存儲和計算節點，具有接近無限的水平擴展能力。伸縮操做後，數據庫還能夠自動實現數據再均衡。
• 備份和恢復。TiDB 支持自動 / 手動全量備份，並將數據備份在 OSS 中。恢復時數據不會覆蓋原有集羣，可有效防止誤操做。
• 實時數據分析。在支持 OLTP 的同時提供業務數據的實時分析和處理。
• 數據遷移和同步。支持全量 / 增量遷移，能夠將數據同步到 MySQL、Kafka 下游存儲中。
• 監控與告警。TiDB 提供了豐富的監控指標，支持瀏覽器直接訪問。雲監控提供資源 / 業務層面的監控告警，雲日誌能夠配置錯誤日誌監控報警。除上述能力外，在實踐應用中 Cloud-TiDB 的另外一大優點就是更低的運維成本。Cloud-TiDB 能夠很好地知足雲服務按需伸縮的需求，使用戶能夠精確地控制資源使用量，避免資源浪費。

選擇一項新技術的同時也是在選擇一個生態，生態越完善，開發和運維效率也會越高。TiDB 生態的一大特色就是兼容 MySQL 協議，從而能夠受惠於成熟的 MySQL 生態資源。MySQL 的全部數據庫驅動、第三方開發 / 管理工具、數據交換 / 遷移工具等，均可以用於 TiDB 數據庫。

TiDB 與其餘主流數據處理技術也能夠方便地互聯互通。例如 TiDB 數據能夠導入 Kafka，接入 Flink，乃至 Hive、HDFS、Amazon S三、Spark 等。用戶無需擔憂技術鎖定風險，這也爲 TiDB 的生態繁榮打下了基礎。

在分享的最後，葛老師對雲端數據庫的發展趨勢作了展望：

分佈式是將來技術發展的重要趨勢之一，包括操做系統、應用程序和數據庫都在向分佈式轉變。TiDB 做爲分佈式數據庫，比較符合這一技術發展趨勢。與此同時，數據庫上雲能夠帶來不少好處，例如彈性調度、與 AI 結合，還能更好地理解用戶的業務視角，實現數據處理的智能優化。

長遠來看，數據庫上雲能夠在開發、運維和穩定性層面得到很大收益。正因如此，京東智聯雲選擇 TiDB 上雲，就是但願能給用戶帶來更好的使用體驗。

2、TiDB在大數據量和高併發場景下的應用

葛老師的演講結束後，來自 PingCAP 的 TiDB 生態技術佈道專家戚錚分享了 TiDB 在大數據量和高併發場景下的應用實踐。

1，TiDB與SHARDING 在 OLTP場景下的解決方案對比

當企業遇到海量數據需求時，每每伴隨數據量短時間內急劇增加的壓力。這樣的業務須要數據庫具有快速擴容能力和高併發能力，在響應延遲和吞吐量指標上都有足夠高的水平以應對突發流量。而 OLTP 場景主要涉及線上 2C 交易，對數據庫穩定性要求較高，數據庫性能波動會直接影響用戶體驗。

針對這樣的需求特色，業內常見的解決方案分爲 Sharding、New SQL 和中間的 DB-Based 幾大類型。其中，ShardingSphere 和 TiDB，就是第一和第三種類型中的兩個典型。二者都是當下活躍的開源項目，分別表明了應對海量數據需求的兩大思路。所謂 Sharding 就是分庫分表，實踐中主要分爲水平拆分和垂直拆分兩大緯度。垂直緯度通常按照業務模塊或者數據系列來拆分，水平緯度能夠按取模、時間、冷熱庫等方式拆分。Sharding Sphere 做爲分庫分表思路的表明，其架構大體以下：

與前文列舉的 TiDB 架構相比，Sharding 架構的數據備份、高可用、監控告警等需求，都須要周邊第三方工具來配置解決。而 TiDB 自身就是完整的解決方案，能夠一站式知足用戶對高性能數據庫的各項要求。現在 ShardingSphere 也開始在新版中開始向總體分佈式數據庫方案轉型，從側面印證了分佈式數據庫是將來的必然趨勢。

2，TiDB的海量數據應用案例

TiDB 的初衷就是解決分庫分表存在的許多問題，但某些場景並不太適合向 TiDB 遷移。具體來講，這樣的場景中業務不會有快速增加，業務請求比較簡單，也沒有分佈式事務需求。除了這樣的場景之外，大部分海量數據需求均可以經過向 TiDB 遷移獲得較好的解決。戚老師這裏列舉了幾個實踐案例。

某社區個性化首頁和推送業務。因爲海量用戶的個性化推送業務特性，數據庫天天須要生成 30 億條數據，歷史數據高達萬億量級，業務對吞吐量和延遲也高度敏感。該用戶原有的 MySQL 方案基於分庫分表，但 MySQL 實例總量達到上百個，風險和延遲都難以知足需求。通過調研，用戶認爲 TiDB 是惟一能知足他們對高擴展、強一致、高可用需求的解決方案，所以決定全面遷移。在遷移過程當中，PingCAP 開發了一個快速導入工具 Lightning 結合 DM 工具來平滑轉移數據，遷移完成後又作出了一系列優化，最終很好地知足了需求。尤爲令用戶滿意的是新架構具有很強的擴展能力，遷移後數據量從 1.3 萬億逐漸增加至 1.8 萬億，性能、可用性依舊保持在很高的水平上，成本相比過去也沒有明顯增長。

某電信我的帳單系統。該用戶帳單總表有 80 億數據，對性能要求很高，而原有的 MyCAT 方案已接近擴展極限，只能存儲不足一年的歷史數據。因爲 MySQL 分庫分表的處理瓶頸，繼續分片會出現很多問題，故此用戶選擇了 TiDB 進行升級換代。向 TiDB 遷移後，單表數據量便可達到 100 億，數據存儲週期由半年延長至 3-5 年，QPS 和延遲都有顯著改善。

戚老師還介紹了某 O2O 平臺 PMC 訂單流水業務、某金融核心帳務系統和某互金營銷平臺向 TiDB 遷移的案例。這些案例的共同點都是用戶原有的數據庫分庫分表遇到了增加瓶頸，對業務形成了愈來愈多的負面影響，而遷移到 TiDB 後徹底解決了原有瓶頸，遷移過程沒有遇到嚴重故障，成本投入也在可控範圍內。

3，TiDB 5.0 亮點解析

分享的最後環節，戚老師介紹了 TiDB 5.0 版本的性能優化亮點和細節，主要包括如下幾項特性。

Async Commit。舊版 TiDB 採用兩階段提交模式，開銷相對較大。Async Commit 主要在第二階段實現了異步提交，對於小事務達到相似 1PC 的效果，從而帶來了必定的性能提高。

Clustered Index。新版的這一特性很適合條件範圍包含主鍵列的查詢，相似 Innodb 聚簇索引，能夠節省這類查詢的回表成本。根據 TPCC 測試，新版在這方面能夠帶來必定性能增幅。

Compaction Filter。該特性主要針對後臺自動整理壓縮數據引發的性能抖動進行優化，開啓後 QPS 的波動標準差下降到了 5% 之內。

SATA SSD 優化。結合 compaction filter，fsync control，compaction guard 等這些新增特性，5.0 版本在 SATA SSD 上的性能吞吐和延遲表現都比 4.0 有了較大改善，因爲 SATA 盤自己抖動致使的 QPS 抖動也有明顯降低。

3、突破容量極限，TiDB打破企業數據庫性能瓶頸

相比傳統的分庫分表，TiDB 是真正一站式的分佈式數據庫總體解決方案，可以充分知足企業業務快速增加、海量數據高併發、實時數據分析和金融數據高可用等場景的苛刻需求。經過本場直播兩位老師的精彩分享，聽衆對 TiDB 數據庫的能力、實現細節和業務落地實踐都有了更深刻的認知，也瞭解了 TiDB 數據庫服務的各項突出優點。

正如兩位老師所言，分佈式數據庫是業內必然的發展趨勢，而 TiDB 順應了這一潮流，將成爲愈來愈多企業根治數據庫性能瓶頸的良方。與此同時，TiDB 在京東智聯雲的應用，爲企業快速採用 TiDB、儘早享受 TiDB 收益和價值開闢了一條便捷通道。

想要了解更多京東智聯雲與 TiDB 相關內容，獲取演講PPT，可在評論區評論PPT，咱們會及時回覆獲取方式。

點擊 【 閱讀原文 】 查看視頻回放連接。

推薦閱讀:

• 京東智聯雲新一代分佈式數據庫TIDB架構揭祕
• 比MySQL快839倍！揭開分析型數據庫JCHDB的神祕面紗
• 11.11 TECH TALK | 支撐2715億元海量訂單 揭祕京東大促背後的數據庫基石

歡迎點擊【京東智聯雲】，瞭解開發者社區

更多精彩技術實踐與獨家乾貨解析

歡迎關注【京東智聯雲開發者】公衆號