引言
在當今互聯網時代，資料的規模和復雜性不斷增長，傳統關系型資料庫面臨著無法滿足高并發和大規模資料存盤需求的挑戰，為了解決這一問題，開源社區涌現出了一系列分布式資料庫解決方案，其中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 上做大資料分析，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/555966.html
標籤：MySQL
上一篇：Spark簡介
下一篇：返回列表