# 引言 在當今互聯網時代，數據的規模和複雜性不斷增長，傳統關係型資料庫面臨著無法滿足高併發和大規模數據存儲需求的挑戰。為瞭解決這一問題，開源社區涌現出了一系列分散式資料庫解決方案，其中TiDB作為一種新興的分散式資料庫引起了廣泛的關註。本文將介紹TiDB的基本概念、特點以及適用的應用場景。 TiD ...
引言
在當今互聯網時代，數據的規模和複雜性不斷增長，傳統關係型資料庫面臨著無法滿足高併發和大規模數據存儲需求的挑戰。為瞭解決這一問題，開源社區涌現出了一系列分散式資料庫解決方案，其中TiDB作為一種新興的分散式資料庫引起了廣泛的關註。本文將介紹TiDB的基本概念、特點以及適用的應用場景。
TiDB官方文檔地址：https://docs.pingcap.com/zh/tidb/stable
什麼是TiDB？
TiDB 是 PingCAP 公司自主設計、研發的開源分散式關係型資料庫，是一款同時支持線上事務處理與線上分析處理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分散式資料庫產品，具備水平擴容或者縮容、金融級高可用、實時 HTAP、雲原生的分散式資料庫、相容 MySQL 5.7 協議和 MySQL 生態等重要特性。目標是為用戶提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解決方案。TiDB 適合高可用、強一致要求較高、數據規模較大等各種應用場景。
TiDB特點
-
一鍵水平擴容或者縮容
得益於 TiDB 存儲計算分離的架構的設計，可按需對計算、存儲分別進行線上擴容或者縮容，擴容或者縮容過程中對應用運維人員透明。 -
金融級高可用
數據採用多副本存儲，數據副本通過 Multi-Raft 協議同步事務日誌，多數派寫入成功事務才能提交，確保數據強一致性且少數副本發生故障時不影響數據的可用性。可按需配置副本地理位置、副本數量等策略滿足不同容災級別的要求。 -
實時 HTAP
提供行存儲引擎 TiKV、列存儲引擎 TiFlash 兩款存儲引擎，TiFlash 通過 Multi-Raft Learner 協議實時從 TiKV 複製數據，確保行存儲引擎 TiKV 和列存儲引擎 TiFlash 之間的數據強一致。TiKV、TiFlash 可按需部署在不同的機器，解決 HTAP 資源隔離的問題。 -
雲原生的分散式資料庫
專為雲而設計的分散式資料庫，通過 TiDB Operator 可在公有雲、私有雲、混合雲中實現部署工具化、自動化。 -
相容 MySQL 5.7 協議和 MySQL 生態
相容 MySQL 5.7 協議、MySQL 常用的功能、MySQL 生態，應用無需或者修改少量代碼即可從 MySQL 遷移到 TiDB。提供豐富的數據遷移工具幫助應用便捷完成數據遷移。
TiDB基礎架構
在內核設計上，TiDB 分散式資料庫將整體架構拆分成了多個模塊，各模塊之間互相通信，組成完整的 TiDB 系統。對應的架構圖如下：
TiDB Server
SQL 層，對外暴露 MySQL 協議的連接 endpoint，負責接受客戶端的連接，執行 SQL 解析和優化，最終生成分散式執行計劃。TiDB 層本身是無狀態的，實踐中可以啟動多個 TiDB 實例，通過負載均衡組件（如 LVS、HAProxy 或 F5）對外提供統一的接入地址，客戶端的連接可以均勻地分攤在多個 TiDB 實例上以達到負載均衡的效果。TiDB Server 本身並不存儲數據，只是解析 SQL，將實際的數據讀取請求轉發給底層的存儲節點 TiKV（或 TiFlash）。
PD (Placement Driver) Server
整個 TiDB 集群的元信息管理模塊，負責存儲每個 TiKV 節點實時的數據分佈情況和集群的整體拓撲結構，提供 TiDB Dashboard 管控界面，併為分散式事務分配事務 ID。PD 不僅存儲元信息，同時還會根據 TiKV 節點實時上報的數據分佈狀態，下發數據調度命令給具體的 TiKV 節點，可以說是整個集群的“大腦”。此外，PD 本身也是由至少 3 個節點構成，擁有高可用的能力。建議部署奇數個 PD 節點。
TiKV Server
TiKV Server：負責存儲數據，從外部看 TiKV 是一個分散式的提供事務的 Key-Value 存儲引擎。存儲數據的基本單位是 Region，每個 Region 負責存儲一個 Key Range（從 StartKey 到 EndKey 的左閉右開區間）的數據，每個 TiKV 節點會負責多個 Region。TiKV 的 API 在 KV 鍵值對層面提供對分散式事務的原生支持，預設提供了 SI (Snapshot Isolation) 的隔離級別，這也是 TiDB 在 SQL 層面支持分散式事務的核心。TiDB 的 SQL 層做完 SQL 解析後，會將 SQL 的執行計劃轉換為對 TiKV API 的實際調用。所以，數據都存儲在 TiKV 中。另外，TiKV 中的數據都會自動維護多副本（預設為三副本），天然支持高可用和自動故障轉移。
TiFlash：TiFlash 是一類特殊的存儲節點。和普通 TiKV 節點不一樣的是，在 TiFlash 內部，數據是以列式的形式進行存儲，主要的功能是為分析型的場景加速。
TiDB相容Mysql協議
TiDB 高度相容 MySQL 5.7 協議、MySQL 5.7 常用的功能及語法。MySQL 5.7 生態中的系統工具（PHPMyAdmin、Navicat、MySQL Workbench、mysqldump、Mydumper/Myloader）、客戶端等均適用於 TiDB。
但 TiDB 尚未支持一些 MySQL 功能，可能的原因如下：
有更好的解決方案，例如 JSON 取代 XML 函數。
目前對這些功能的需求度不高，例如存儲流程和函數。
一些功能在分散式系統上的實現難度較大。
除此以外，TiDB 不支持 MySQL 複製協議，但提供了專用工具用於與 MySQL 複製數據：
從 MySQL 複製：TiDB Data Migration (DM) 是將 MySQL/MariaDB 數據遷移到 TiDB 的工具，可用於增量數據的複製。
向 MySQL 複製：TiCDC 是一款通過拉取 TiKV 變更日誌實現的 TiDB 增量數據同步工具，可通過 MySQL sink 將 TiDB 增量數據複製到 MySQL。
TiDB應用場景
MySQL分片與合併
對於已經在用 MySQL 的業務，分庫、分表、分片、中間件是常用手段，隨著分片的增多，跨分片查詢是一大難題。
TiDB 在業務層相容 MySQL 的訪問協議，PingCAP 做了一個數據同步的工具——Syncer，它可以把TiDB 作為一個 MySQL Slave，將 TiDB 作為現有資料庫的從庫接在主 MySQL 庫的後方，在這一層將數據打通，可以直接進行複雜的跨庫、跨表、跨業務的實時 SQL 查詢。
直接替換MySQL
在一個 TiDB 的資料庫上，所有業務場景不需要做分庫分表，所有的分散式工作都由資料庫層完成。TiDB 相容 MySQL 協議，所以可以直接替換 MySQL，而且基本做到了開箱即用，完全不用擔心傳統分庫分表方案帶來繁重的工作負擔和複雜的維護成本，友好的用戶界面讓常規的技術人員可以高效地進行維護和管理。另外，TiDB 具有 NoSQL 類似的擴容能力，在數據量和訪問流量持續增長的情況下能夠通過水平擴容提高系統的業務支撐能力，並且響應延遲穩定。
數據倉庫
TiDB 本身是一個分散式系統，第三種使用場景是將 TiDB 當作數據倉庫使用，使用一些T+1的業務。TPC-H 是數據分析領域的一個測試集，TiDB 2.0 在 OLAP 場景下的性能有了大幅提升，原來只能在數據倉庫裡面跑的一些複雜的 Query，在 TiDB 2.0 裡面跑，時間基本都能控制在 10 秒以內。當然，因為 OLAP 的範疇非常大，
TiDB 的 SQL 也有搞不定的情況，為此 PingCAP 開源了 TiSpark，TiSpark 是一個 Spark 插件，用戶可以直接用 Spark SQL 實時地在 TiKV 上做大數據分析。
