大家可能都沒有聽過TIDB這款分布式數(shù)據(jù)庫汁政，但是它已經(jīng)出現(xiàn)很久了道偷，隨著不斷完善，也受到越來越多的企業(yè)喜愛记劈，接下來讓我們開始了解TIDB吧勺鸦！

TIDB簡介

TIDB是什么？

**TiDB **是一個分布式 NewSQL 數(shù)據(jù)庫目木。它支持水平彈性擴展换途、ACID 事務(wù)、標準 SQL刽射、MySQL 語法和 MySQL 協(xié)議军拟，具有數(shù)據(jù)強一致的高可用特性，是一個不僅適合 OLTP 場景還適合OLAP 場景的混合數(shù)據(jù)庫誓禁。

TIDB怎么來的懈息？

開源分布式緩存服務(wù) Codis 的作者，PingCAP 聯(lián)合創(chuàng)始人& CTO 摹恰，資深 infrastructure 工程師的黃東旭辫继，擅長分布式存儲系統(tǒng)的設(shè)計與實現(xiàn)，開源狂熱分子的技術(shù)大神級別人物俗慈。即使在互聯(lián)網(wǎng)如此繁榮的今天姑宽，在數(shù)據(jù)庫這片邊界模糊且不確定地帶，他還在努力尋找確定性的實踐方向闺阱。

2012 年底炮车，他看到 Google 發(fā)布的兩篇論文，得到了很大的觸動酣溃，這兩篇論文描述了 **Google **內(nèi)部使用的一個海量關(guān)系型數(shù)據(jù)庫 F1/Spanner 瘦穆，解決了關(guān)系型數(shù)據(jù)庫、彈性擴展以及全球分布的問題救拉，并在生產(chǎn)中大規(guī)模使用难审√奔穑“如果這個能實現(xiàn)亿絮，對數(shù)據(jù)存儲領(lǐng)域來說將是顛覆性的”，黃東旭為完美方案的出現(xiàn)而興奮麸拄， **PingCAP **的 **TiDB **在此基礎(chǔ)上誕生了派昧。

TIDB的架構(gòu)

TiDB在整體架構(gòu)基本是參考 Google Spanner 和 F1 的設(shè)計，上分兩層為 TiDB 和 TiKV 拢切。**TiDB **對應(yīng)的是 Google F1蒂萎， 是一層無狀態(tài)的 SQL Layer ，兼容絕大多數(shù) MySQL 語法淮椰，對外暴露 MySQL 網(wǎng)絡(luò)協(xié)議五慈，負責(zé)解析用戶的 SQL 語句纳寂，生成分布式的 Query Plan，翻譯成底層 Key Value 操作發(fā)送給 **TiKV **泻拦， **TiKV **是真正的存儲數(shù)據(jù)的地方毙芜，對應(yīng)的是 Google Spanner ，是一個分布式 Key Value 數(shù)據(jù)庫争拐，支持彈性水平擴展腋粥，自動的災(zāi)難恢復(fù)和故障轉(zhuǎn)移（高可用），以及 ACID 跨行事務(wù)架曹。值得一提的是 **TiKV **并不像 HBase 或者 BigTable 那樣依賴底層的分布式文件系統(tǒng)绑雄，在性能和靈活性上能更好，這個對于在線業(yè)務(wù)來說是非常重要。

所以一套這樣的架構(gòu)是由這樣的3類角色共同組建而成。每個部分的解釋如下：

1.TiDB Server

TiDB Server 負責(zé)接收 SQL 請求，處理 SQL 相關(guān)的邏輯曲聂，并通過 PD 找到存儲計算所需數(shù)據(jù)的 TiKV 地址膜楷，與 TiKV 交互獲取數(shù)據(jù)，最終返回結(jié)果勾缭。TiDB Server 是無狀態(tài)的，其本身并不存儲數(shù)據(jù)，只負責(zé)計算洽洁，可以無限水平擴展，可以通過負載均衡組件（如LVS、HAProxy 或 F5）對外提供統(tǒng)一的接入地址。

2.PD Server

Placement Driver (簡稱 PD) 是整個集群的管理模塊，其主要工作有三個：一是存儲集群的元信息（某個 Key 存儲在哪個 TiKV 節(jié)點）；二是對 TiKV 集群進行調(diào)度和負載均衡（如數(shù)據(jù)的遷移、Raft group leader 的遷移等）；三是分配全局唯一且遞增的事務(wù) ID驼侠。PD 是一個集群句狼，需要部署奇數(shù)個節(jié)點筹吐，一般線上推薦至少部署 3 個節(jié)點邦危。

3.TiKV Server

TiKV Server 負責(zé)存儲數(shù)據(jù)陵且，從外部看 TiKV 是一個分布式的提供事務(wù)的 Key-Value 存儲引擎脓钾。存儲數(shù)據(jù)的基本單位是 Region，每個 Region 負責(zé)存儲一個 Key Range （從 StartKey 到 EndKey 的左閉右開區(qū)間）的數(shù)據(jù)谨胞，每個 TiKV 節(jié)點會負責(zé)多個 Region 逢防。TiKV 使用 Raft 協(xié)議做復(fù)制局嘁，保持數(shù)據(jù)的一致性和容災(zāi)。副本以 Region 為單位進行管理谓谦，不同節(jié)點上的多個 Region 構(gòu)成一個 Raft Group才顿，互為副本忙芒。數(shù)據(jù)在多個 TiKV 之間的負載均衡由 PD 調(diào)度，這里也是以 Region 為單位進行調(diào)度德谅。

TIDB五大核心特性

一鍵水平擴縮容

得益于 TiDB 存儲計算分離的架構(gòu)的設(shè)計萨螺，可按需對計算窄做、存儲分別進行在線擴容或者縮容，擴容或者縮容過程中對應(yīng)用運維人員透明慰技。

金融級高可用

數(shù)據(jù)采用多副本存儲椭盏，數(shù)據(jù)副本通過 Multi-Raft 協(xié)議同步事務(wù)日志，多數(shù)派寫入成功事務(wù)才能提交吻商，確保數(shù)據(jù)強一致性且少數(shù)副本發(fā)生故障時不影響數(shù)據(jù)的可用性掏颊。可按需配置副本地理位置艾帐、副本數(shù)量等策略滿足不同容災(zāi)級別的要求乌叶。

實時HTAP

提供行存儲引擎 TiKV、列存儲引擎 TiFlash 兩款存儲引擎柒爸，TiFlash 通過 Multi-Raft Learner 協(xié)議實時從 TiKV 復(fù)制數(shù)據(jù)准浴，確保行存儲引擎 TiKV 和列存儲引擎 TiFlash 之間的數(shù)據(jù)強一致。TiKV捎稚、TiFlash 可按需部署在不同的機器乐横，解決 HTAP 資源隔離的問題。

云原生的分布式數(shù)據(jù)庫

專為云而設(shè)計的分布式數(shù)據(jù)庫今野，通過 TiDB Operator 可在公有云葡公、私有云、混合云中實現(xiàn)部署工具化条霜、自動化催什。

兼容MYSQL5.7

專為云而設(shè)計的分布式數(shù)據(jù)庫，通過 TiDB Operator 可在公有云蛔外、私有云蛆楞、混合云中實現(xiàn)部署工具化、自動化夹厌。

TIDB四大核心應(yīng)用場景

HTAP 給開發(fā)者提供了一個實時數(shù)據(jù)分析方面的新思路豹爹，不需要再去維護另一個離線的數(shù)據(jù)倉庫，既減輕了 ETL 的工作矛纹，又能節(jié)省很大一部分建立數(shù)據(jù)倉庫所用到的存儲和計算成本臂聋，HTAP 將是未來的重要趨勢。

黃東旭介紹了 TiDB 的四個主要應(yīng)用場景，一是 MySQL 分片與合并孩等；二是直接替換 MySQL艾君；三是用做數(shù)據(jù)倉庫；四是作為其他系統(tǒng)的一個模塊肄方。

MySQL分片與合并

image

image

Syncer：

TiDB 應(yīng)用的第一類場景是 MySQL 的分片與合并冰垄。對于已經(jīng)在用 MySQL 的業(yè)務(wù)，分庫权她、分表虹茶、分片、中間件是常用手段隅要，隨著分片的增多蝴罪，跨分片查詢是一大難題。TiDB 在業(yè)務(wù)層兼容 MySQL 的訪問協(xié)議步清，PingCAP 做了一個數(shù)據(jù)同步的工具——Syncer要门，它可以把 TiDB 作為一個 MySQL Slave，將 **TiDB **作為現(xiàn)有數(shù)據(jù)庫的從庫接在主 MySQL 庫的后方廓啊，在這一層將數(shù)據(jù)打通欢搜，可以直接進行復(fù)雜的跨庫、跨表崖瞭、跨業(yè)務(wù)的實時 SQL 查詢狂巢。黃東旭提到，過去的數(shù)據(jù)庫都是一主多從书聚，有了 **TiDB **以后唧领，可以反過來做到多主一從。

替換MySQL

image

第二類場景是用 **TiDB **直接去替換 MySQL雌续。如果你的IT架構(gòu)在搭建之初并未考慮分庫分表的問題斩个，全部用了 MySQL，隨著業(yè)務(wù)的快速增長驯杜，海量高并發(fā)的 OLTP 場景越來越多受啥，如何解決架構(gòu)上的弊端呢?

在一個 **TiDB 的數(shù)據(jù)庫上，所有業(yè)務(wù)場景不需要做分庫分表鸽心，所有的分布式工作都由數(shù)據(jù)庫層完成滚局。TiDB **兼容 MySQL 協(xié)議，所以可以直接替換 MySQL顽频，而且基本做到了開箱即用藤肢，完全不用擔(dān)心傳統(tǒng)分庫分表方案帶來繁重的工作負擔(dān)和復(fù)雜的維護成本，友好的用戶界面讓常規(guī)的技術(shù)人員可以高效地進行維護和管理糯景。另外嘁圈，TiDB 具有 NoSQL 類似的擴容能力省骂，在數(shù)據(jù)量和訪問流量持續(xù)增長的情況下能夠通過水平擴容提高系統(tǒng)的業(yè)務(wù)支撐能力，并且響應(yīng)延遲穩(wěn)定最住。

黃東旭在演講中提到了摩拜單車的案例钞澳，摩拜早期的數(shù)據(jù)庫全部用 MySQL，隨著業(yè)務(wù)的快速增長涨缚，MySQL 的弊端逐漸顯現(xiàn)轧粟，摩拜單車于 2017 年初開始使用 **TiDB **替換 MySQL。如今仗岖，摩拜的 IT 系統(tǒng)中已部署了數(shù)套 **TiDB **集群逃延，近百個節(jié)點览妖，承載著數(shù)十 TB 的各類數(shù)據(jù)轧拄。

數(shù)據(jù)倉庫

image

image

**TiDB 本身是一個分布式系統(tǒng)，第三種使用場景是將 TiDB 當(dāng)作數(shù)據(jù)倉庫使用讽膏。TPC-H 是數(shù)據(jù)分析領(lǐng)域的一個測試集檩电，TiDB 2.0 在 OLAP 場景下的性能有了大幅提升，原來只能在數(shù)據(jù)倉庫里面跑的一些復(fù)雜的 Query府树，在 TiDB 2.0 里面跑俐末，時間基本都能控制在 10 秒以內(nèi)。當(dāng)然奄侠，因為 OLAP 的范疇非常大卓箫，TiDB 的 SQL 也有搞不定的情況，為此 PingCAP 開源了 TiSpark垄潮，TiSpark **是一個 Spark 插件烹卒，用戶可以直接用 Spark SQL 實時地在 **TiKV **上做大數(shù)據(jù)分析。

作為其他系統(tǒng)的模塊

image

**TiDB 是一個傳統(tǒng)的存儲跟計算分離的項目弯洗，其底層的 Key-Value 層旅急，可以單獨作為一個 HBase 的 Replacement 來用，它同時支持跨行事務(wù)牡整。TiDB **對外提供兩個 API 接口藐吮，一個是 ACID Transaction 的 API，用于支持跨行事務(wù)逃贝；另一個是 Raw API谣辞，它可以做單行的事務(wù)，換來的是整個性能的提升沐扳，但不提供跨行事務(wù)的 ACID 支持泥从。用戶可以根據(jù)自身的需求在兩個 API 之間自行選擇。例如有一些用戶直接在 **TiKV **之上實現(xiàn)了 Redis 協(xié)議迫皱，將 **TiKV **替換一些大容量歉闰，對延遲要求不高的 Redis 場景辖众。

與MySQL兼容性對比

**TiDB **支持包括跨行事務(wù)，JOIN 及子查詢在內(nèi)的絕大多數(shù) MySQL 的語法和敬，用戶可以直接使用現(xiàn)有的 MySQL 客戶端連接凹炸。如果現(xiàn)有的業(yè)務(wù)已經(jīng)基于 MySQL 開發(fā)，大多數(shù)情況不需要修改代碼即可直接替換單機的 MySQL昼弟。

包括現(xiàn)有的大多數(shù) MySQL 運維工具（如 PHPMyAdmin, Navicat, MySQL Workbench 等）啤它，以及備份恢復(fù)工具（如 mysqldump, mydumper/myloader）等都可以直接使用。

不過一些特性由于在分布式環(huán)境下沒法很好的實現(xiàn)舱痘，目前暫時不支持或者是表現(xiàn)與 MySQL 有差異变骡。

一些 MySQL 語法在 **TiDB **中可以解析通過，但是不會做任何后續(xù)的處理芭逝，例如 Create Table 語句中 Engine 以及 Partition 選項塌碌，都是解析并忽略。

不支持的特性有以下這些：

存儲過程旬盯，視圖台妆，觸發(fā)器，自定義函數(shù)胖翰，外鍵約束接剩，全文索引，空間索引萨咳，非 UTF8 字符集等

總結(jié)

本文帶你了解了TIDB這款分布式數(shù)據(jù)庫懊缺，它的特性，應(yīng)用場景以及與MySQl的兼容性對比培他，下篇將會介紹TIDB的部署搭建鹃两，計算，存儲靶壮，調(diào)度方面的知識怔毛！

假如面試中你被問到這些，我相信你看了這篇一定能撥動面試官的心腾降！

希望你們是我最好的觀眾拣度！

https://zhuanlan.zhihu.com/p/334669357