TiDB概覽

先來(lái)一段官網(wǎng)的描述

TiDB server：無(wú)狀態(tài)SQL解析層，支持二級(jí)索引，在線ddl,兼容MySQL協(xié)議，數(shù)據(jù)轉(zhuǎn)儲(chǔ)
SQL輸入->解析語(yǔ)法樹(shù)（AST）->邏輯計(jì)劃分析->執(zhí)行計(jì)劃優(yōu)化
->cost-base model->物理計(jì)劃選擇->計(jì)算下推tikv->聚合tikv執(zhí)行結(jié)果

PD server: 協(xié)調(diào)層，存儲(chǔ)集群元數(shù)據(jù),region調(diào)度，事務(wù)時(shí)間戳TSO。存儲(chǔ)每個(gè) TiKV 節(jié)點(diǎn)實(shí)時(shí)的數(shù)據(jù)分布情況和集群的整體拓?fù)浣Y(jié)構(gòu)，內(nèi)置儀表盤(pán)dashboard.

TiKV/TiFlash：存儲(chǔ)層,tikv行存儲(chǔ)引擎，事務(wù)類處理走tikv；tiFlash列存儲(chǔ)引擎，分析類處理走tiFlash。tikv，基于LSM算法的RocksDB單機(jī)Key-Value 存儲(chǔ)引擎，TiDB 的 SQL 層做完 SQL 解析后，會(huì)將 SQL 的執(zhí)行計(jì)劃轉(zhuǎn)換為對(duì) TiKV API 的實(shí)際調(diào)用。
tikv存儲(chǔ)單位為region，關(guān)于region的介紹可以參考這里同時(shí)里面還有raft的相關(guān)介紹，目前最主要記住TIKV以 Region 為單位做 Raft 的復(fù)制和成員管理同時(shí)只需要同步復(fù)制到多數(shù)節(jié)點(diǎn)，即可安全地認(rèn)為數(shù)據(jù)寫(xiě)入成功

特性：
易拓展：計(jì)算能力(TiDB)和存儲(chǔ)能力(TiKV)均可水平拓展，但集群中只有一個(gè)PD能被選舉為leader
高可用：TiDB/TiKV/PD 三大組件均可cluster模式部署
高效存儲(chǔ)：基于LSM算法的RocksDB單機(jī)存儲(chǔ)引擎，lz4、zstd等高效壓縮算法,除了 RocksDB之外，TiDB 還支持一些流行的單機(jī)存儲(chǔ)引擎，比如 GolevelDB、BoltDB 等
安全存儲(chǔ)：采用Raft 協(xié)議復(fù)制數(shù)據(jù)，多副本防止單機(jī)失效
分布式事務(wù)：支持ACID事務(wù)，不同于XA,客戶端調(diào)用無(wú)需設(shè)置數(shù)據(jù)源為xa，天然分布式事務(wù)
易用性：支持MySQL協(xié)議，使用MySQL語(yǔ)法，MySQL客戶端均可直接連接登陸

因測(cè)試環(huán)境受限，我們的環(huán)境較多軟硬件都不符合官方配置要求，啊哈哈哈。。。但這并不影響我們對(duì)技術(shù)的研究和使用，再窮也要?jiǎng)?chuàng)造條件頂硬上。

一、部署環(huán)境

其余硬件，實(shí)際部署環(huán)境CPU 8核，內(nèi)存16G，千兆網(wǎng)卡。

TiDB 和 PD 可以部署在同一臺(tái)服務(wù)器上。
如對(duì)性能和可靠性有更高的要求，應(yīng)盡可能分開(kāi)部署。
官網(wǎng)參考
雖然實(shí)際測(cè)試環(huán)境，使用的raid掛載的是機(jī)械硬盤(pán)，但是讀寫(xiě)能力并不弱，dd指令數(shù)據(jù)如下：

本次使用主機(jī)11臺(tái)（10.248.7.154-164）

二、拓?fù)?/h2>

查看集群狀態(tài)
tiup cluster display tidb-test

當(dāng)然還有更直觀的儀表盤(pán)（PD內(nèi)置，訪問(wèn)PD服務(wù)http:ip+port/dashboard）.也可以先在部署TiUP的機(jī)器執(zhí)行 tiup cluster display tidb-test --dashboard得到，即

使用數(shù)據(jù)庫(kù)用戶root登陸

還可以使用額外部署的grafana:http://10.248.7.163:3000

三、測(cè)試與優(yōu)化

場(chǎng)景：大文件,多文件數(shù)據(jù)入庫(kù)，入庫(kù)首先保證速度，最終一致即可（CAP中的AP）文件有備份，可重新入庫(kù)。入庫(kù)后簡(jiǎn)單OLAP操作。
測(cè)試準(zhǔn)備：入庫(kù)應(yīng)用（可配置單次入庫(kù)記錄數(shù)），500萬(wàn)行數(shù)據(jù)文件（寫(xiě)成6個(gè)文件）

這里先來(lái)說(shuō)一個(gè)異常場(chǎng)景，這個(gè)場(chǎng)景剛好可以對(duì)比磁盤(pán)性能差異引起的tidb性能差異，同時(shí)對(duì)理解熱點(diǎn)問(wèn)題和對(duì)應(yīng)調(diào)優(yōu)有一定幫助。

在最開(kāi)始?jí)簻y(cè)的時(shí)候，tikv節(jié)點(diǎn)的三臺(tái)主機(jī)（raid 22塊磁盤(pán)），其中有兩臺(tái)主機(jī)raid cache電池故障，導(dǎo)致raid cache失效，這兩臺(tái)主機(jī)的IO性能嚴(yán)重受影響

當(dāng)然，在測(cè)試的時(shí)候，事先是并不知道這個(gè)問(wèn)題的，并在此基礎(chǔ)上做了一些研究和調(diào)優(yōu)。接下來(lái)簡(jiǎn)要說(shuō)下過(guò)程（以下過(guò)程均訪問(wèn)單個(gè)TiDB-server）：

1、首次壓測(cè)（單批次5000行記錄，5線程）

由于擴(kuò)展tikv前的圖已丟失（現(xiàn)raid電池問(wèn)題已修復(fù)，無(wú)法重現(xiàn)），只能貼上4tikv的圖了，不過(guò)除了加多一個(gè)節(jié)點(diǎn)，現(xiàn)象差不多，后面再做擴(kuò)縮容的演示

由圖可以看出，除了正常的161外，其余的tikv節(jié)點(diǎn)，IO均已跑滿（163為應(yīng)用部署主機(jī)）?？紤]兩點(diǎn)，磁盤(pán)性能差異、region分布不均勻。
再來(lái)看下熱點(diǎn)region的圖：

可以看出，hot region leader的分布非常不均勻。以三副本（peer）為例，根據(jù)raft協(xié)議，當(dāng)寫(xiě)入時(shí)，首先寫(xiě)入到region leader，寫(xiě)完leader之后再同步拷貝到其余兩個(gè)節(jié)點(diǎn)的region follower 參考官網(wǎng)說(shuō)明。這里就考慮兩個(gè)熱點(diǎn)部分不均勻的可能：1、單批次提交事務(wù)過(guò)大，導(dǎo)致同一時(shí)間內(nèi)數(shù)據(jù)集中在一個(gè)region，在未超過(guò)一定大小時(shí)（默認(rèn) 96M）并沒(méi)有分裂region；2、主鍵有序程度高，導(dǎo)致排序分裂region時(shí)，數(shù)據(jù)在region中比較集中。
入庫(kù)結(jié)果：

平均一百萬(wàn)行需要6-7分鐘。從文件數(shù)據(jù)看，先慢后快，這跟初始化時(shí)只有單個(gè)region有關(guān)，只有達(dá)到單個(gè)region限制后才會(huì)分裂。參考這里可先不對(duì)此過(guò)度優(yōu)化。

2、第二次壓測(cè)（單批次2000行記錄，10線程）

基于第一次的壓測(cè)結(jié)果，修改單批次提交記錄數(shù)，并加大線程分散提交的事務(wù)。修改后tikv節(jié)點(diǎn)的IO使用率并無(wú)太多變化。入庫(kù)速度略有上升：

3、第三次壓測(cè)（單批次2000行記錄，10線程，亂序）

在修改了批次大小后，繼續(xù)修改使主鍵亂序，同上，IO使用率依舊沒(méi)有多大變化。不過(guò)入庫(kù)速度有較大提升（平均一百萬(wàn)3分鐘）：

到目前為止，一直忽略了一個(gè)事情，沒(méi)有觀察總的region leader情況：

從圖看，總的leader分布是很均勻的,且寫(xiě)入字節(jié)總量各個(gè)tikv節(jié)點(diǎn)也大致相同，但是hot leader為什么這么不均勻而且為什么其中一個(gè)tikv IO使用率低這么多呢，矛頭指向了磁盤(pán)性能問(wèn)題，經(jīng)排查后發(fā)現(xiàn)，磁盤(pán)電池故障，raid cache失效。

4、第四次壓測(cè)（單批次2000行記錄，10線程，亂序，sync-log = false）

在磁盤(pán)問(wèn)題修復(fù)前，我們找到一處關(guān)于sync-log的說(shuō)明

以三副本為例，需要至少寫(xiě)完兩個(gè)副本之后，才能向客戶端返回ack。因此關(guān)閉同步日志，異步寫(xiě)follower的副本，相當(dāng)于寫(xiě)單機(jī)的時(shí)間。這里犧牲了CAP中的C，只需最終一致即可。我們的應(yīng)用場(chǎng)景適用，同時(shí)我們文件有備份，即便出錯(cuò)可以重新導(dǎo)入。但是對(duì)于實(shí)時(shí)性較強(qiáng)，對(duì)一致性要求較高的金融場(chǎng)景，不建議關(guān)閉同步日志。
操作需使用Tiup:
執(zhí)行tiup cluster edit-config tidb-test

修改完成后執(zhí)行：tiup cluster reload tidb-test -R tikv 重啟tikv
修改后入庫(kù)效率如下：

一百萬(wàn)行記錄入庫(kù)時(shí)間優(yōu)化到2分鐘。

不過(guò)在修復(fù)磁盤(pán)后發(fā)現(xiàn)，這個(gè)參數(shù)在我們的場(chǎng)景影響并不是很大，良好的io性能使得這個(gè)參數(shù)設(shè)置變得不那么重要，因此在修復(fù)磁盤(pán)后的測(cè)試中，我們都是基于開(kāi)啟同步日志的場(chǎng)景

修復(fù)磁盤(pán)后測(cè)試

修復(fù)后的tikv 磁盤(pán)性能均有如下表現(xiàn)：

修復(fù)磁盤(pán)后，我們測(cè)試的條件為：3TiKV3副本，單批次2000行記錄，10線程，亂序?；謴?fù)同步日志配置的修改。
來(lái)看下修復(fù)后的TiDB表現(xiàn)：

hot region leader 均勻分布，peer（副本）也是均勻分布

入庫(kù)效率如下（平均100萬(wàn)行記錄1.5分鐘）：

直覺(jué)告訴我們，事情肯定還沒(méi)有結(jié)束，應(yīng)該還有優(yōu)化的空間。似乎到目前為止，我們都沒(méi)有好好看看TiDB-server的情況:

到目前為止，我們都是直接訪問(wèn)單個(gè)的TiDB-server。因此出現(xiàn)了如圖的CPU負(fù)載情況，只有157的tidb CPU快到7個(gè)核的使用率。由于tidb-server是無(wú)狀態(tài)的，可以通過(guò)負(fù)載來(lái)給另外兩個(gè)tidb-server分活了。本例使用NGINX，配置如下：

修改訪問(wèn)地址，客戶端通過(guò)連接NGINX訪問(wèn)tidb 10.248.7.154:4000

通過(guò)NGINX負(fù)載后，每個(gè)tidb-server的cpu都得到了利用，同時(shí)平均一百萬(wàn)行記錄入庫(kù)時(shí)間優(yōu)化到1分鐘。

按照對(duì)官方文檔的理解，tidb的計(jì)算能力和存儲(chǔ)能力都可以擴(kuò)展，目前我們通過(guò)NGINX負(fù)載實(shí)現(xiàn)了tidb-server計(jì)算能力的負(fù)載。但是計(jì)算不僅僅在tidb-server。tidb-server 解析SQL生成執(zhí)行計(jì)劃之后，會(huì)有一部分的計(jì)算下推到tikv。這也是為何tikv和tidb 這兩個(gè)組件的實(shí)例不能部署在同一臺(tái)主機(jī)。那么擴(kuò)充tikv節(jié)點(diǎn)后，性能會(huì)有多大程度提高？另外擴(kuò)充的節(jié)點(diǎn)會(huì)不會(huì)自動(dòng)協(xié)調(diào)原有節(jié)點(diǎn)的region呢？

擴(kuò)展tikv節(jié)點(diǎn)
擴(kuò)展前，肯定要先看看原有的磁盤(pán)占用情況：

擴(kuò)容過(guò)程中，正逐漸轉(zhuǎn)移數(shù)據(jù)到新的tikv節(jié)點(diǎn)。穩(wěn)定后如下圖：

不過(guò)在入庫(kù)效率上，提升并不明顯，時(shí)間上和擴(kuò)容前相差不多。有以下原因，原本的三節(jié)點(diǎn)并行入庫(kù)性能還有較多可利用空間，相當(dāng)于只是把部分處理遷移到新節(jié)點(diǎn)，單原先節(jié)點(diǎn)的處理能力還有很多富余，需要原先的節(jié)點(diǎn)IO和CPU有較高使用率時(shí)，擴(kuò)充節(jié)點(diǎn)才能有較多的性能提升region調(diào)度策略

CPU和IO使用率都不大。

同等主機(jī)環(huán)境的MySQL入庫(kù)情況如下：

在主鍵無(wú)序的情況下，隨著數(shù)據(jù)量的增大，入庫(kù)性能急劇下滑，這跟索引樹(shù)葉子節(jié)點(diǎn)在主鍵無(wú)序時(shí)，頻繁分裂調(diào)整樹(shù)結(jié)構(gòu)有關(guān)。主鍵有序時(shí)，入庫(kù)性能中 規(guī)中矩，不過(guò)即便是有序，在數(shù)據(jù)量多了以后，入庫(kù)性能也會(huì)下滑。所以MySQL單表有大小要求，超過(guò)一定大小之后最好選擇分庫(kù)分表，但是這也會(huì)引入另外的問(wèn)題，業(yè)務(wù)應(yīng)用測(cè)也要對(duì)此做大量的改造。

同等主機(jī)環(huán)境MySQL與tidb查詢性能對(duì)比：
當(dāng)前分區(qū)500萬(wàn)行記錄查詢,查詢SQL

select SETTLE_DATE AS "賬期日",COUNT(0) AS 成功條數(shù),SUM(JSON_EXTRACT(JSON,'$.Payment')) AS 成功總金額（分）
  FROM BL_BATCH_TEST TDP
WHERE TDP.SETTLE_DATE = '20201201' and JSON_EXTRACT(JSON,'$.IsSuccess') = '0' and JSON_EXTRACT(JSON,'$.Result') = '0' group by SETTLE_DATE; 

TIDB

mysql

(mysql的數(shù)據(jù)同事幫我跑的，啊哈哈)
對(duì)比來(lái)看，tidb查詢性能較為穩(wěn)定，即便重啟所有組件清楚緩存后（圖中第二次查詢 ），單個(gè)分區(qū)500萬(wàn)行記錄，查詢8s,再次查詢時(shí)間減半，MySQL第一次查詢耗時(shí)80+s,第二次查詢也能維持較好的性能。通常業(yè)務(wù)查詢（OLAP），最重要的是首次時(shí)間，第二次的查詢時(shí)間參考意義不大，因此穩(wěn)定的查詢時(shí)間尤為重要。MySQL和tidb在重啟后，首次查詢時(shí)間都相對(duì)要久一點(diǎn)，這跟加載磁盤(pán)數(shù)據(jù)到內(nèi)存耗費(fèi)有關(guān)，tikv幾個(gè)節(jié)點(diǎn)堆起來(lái)的內(nèi)存跟MySQL單機(jī)的內(nèi)存比，是不太公平的，但這也正是tidb的優(yōu)勢(shì)。

總結(jié)：
1、TiDB-server是計(jì)算密集型組件，同時(shí)也會(huì)將部分計(jì)算下推到TiKV，而TiKV是IO密集型組件，因此TiDB和TiKV不能在同一臺(tái)主機(jī)部署。PD存儲(chǔ)元數(shù)據(jù)會(huì)頻繁寫(xiě)磁盤(pán)，對(duì)磁盤(pán)IO要求高，因此也不能和TiKV同部署，PD可以和TiDB-server同主機(jī)部署。
2、TiKV （集成raft協(xié)議）以region為存儲(chǔ)單位，超過(guò)默認(rèn)96M后會(huì)分裂，通過(guò)raft協(xié)議做leader選舉和副本（即peer）復(fù)制，每個(gè)region都會(huì)有l(wèi)eader 副本，其余的副本為follower，客戶端讀寫(xiě)只會(huì)通過(guò)region的leader節(jié)點(diǎn)，寫(xiě)入時(shí)，寫(xiě)完leader后再?gòu)?fù)制到follower，超半數(shù)以上副本寫(xiě)入完成即認(rèn)為寫(xiě)入成功。
增減tikv節(jié)點(diǎn)，或者修改replication.max-replicas后，PD會(huì)通過(guò)region的心跳判斷當(dāng)前副本情況，從而調(diào)度副本到新節(jié)點(diǎn)或者增減副本。
3、通過(guò)grafana和PD自帶的dashBoard可以實(shí)時(shí)查看當(dāng)前系統(tǒng)的問(wèn)題，比如TIDB節(jié)點(diǎn)的CPU使用率、QPS;TIKV節(jié)點(diǎn)的CPU、IO使用率;通過(guò)PD查看熱點(diǎn)分布和region分布于調(diào)度情況;通過(guò)PD 的dashBoard查看慢sql,集群狀態(tài)，調(diào)用?；鹧鎴D等等。
CPU使用率單核不要超過(guò)80%，超過(guò)不管是TIDB節(jié)點(diǎn)和TIKV都要考慮擴(kuò)容
tikv節(jié)點(diǎn)內(nèi)存不要超過(guò)60%使用率，IO達(dá)到80%可視為到達(dá)瓶頸
4、region數(shù)量單個(gè)tikv小于50K, grpc延遲盡可能小于100ms。過(guò)多的region會(huì)導(dǎo)致調(diào)度頻繁影響性能，grpc延遲增大?？煽紤]設(shè)置region合并參數(shù)

以下配置意為：key數(shù)目小于200000，region大小小于20M的合并（默認(rèn)）
set config pd `schedule.max-merge-region-keys`=200000;
set config pd `schedule.max-merge-region-size`=20;

5、當(dāng)TIDB節(jié)點(diǎn)CPU過(guò)高時(shí)，如是正常SQL執(zhí)行需要，可考慮增加TIDB節(jié)點(diǎn)，并通過(guò)Nginx，HaProxy等負(fù)載工具分發(fā)到不同節(jié)點(diǎn)執(zhí)行。當(dāng)Tikv 出現(xiàn)較高水平的cpu使用率或者IO使用率，可考慮增加TiKV節(jié)點(diǎn)。TiKV對(duì)磁盤(pán)要求較高，盡量使用SSD磁盤(pán)，或者多磁盤(pán)raid。
6、出現(xiàn)熱點(diǎn)region的時(shí)候，有幾個(gè)地方可以查看，比如grafana監(jiān)控中的PD可以看相關(guān)的hot region分布情況，這是最直觀的方式；還可以通過(guò)監(jiān)控中的tikv，查看各節(jié)點(diǎn)CPU和IO使用情況，當(dāng)出現(xiàn)熱點(diǎn)問(wèn)題是，這兩個(gè)指標(biāo)在各個(gè)節(jié)點(diǎn)時(shí)很不均勻的，尤其THread cpu的corprocessor 或 scheduler（負(fù)責(zé)讀/寫(xiě)模塊的線程）。
7、解決熱點(diǎn)region的問(wèn)題，主要在于分散region數(shù)據(jù)的分布，減少頻繁讀寫(xiě)同一個(gè)region。通過(guò)減少單批次提交記錄數(shù)（小事務(wù)），非自增亂序的主鍵（官網(wǎng)要求int類型的主鍵。5.0之后將支持vchar），頻繁訪問(wèn)相同數(shù)據(jù)通過(guò)內(nèi)存訪問(wèn)，從業(yè)務(wù)層面拆分熱點(diǎn)數(shù)據(jù)等手段減少熱點(diǎn)。但在所有的tikv都出現(xiàn)較多熱點(diǎn)region時(shí)，這時(shí)應(yīng)考慮擴(kuò)充tikv節(jié)點(diǎn)。當(dāng)tikv節(jié)點(diǎn)region分布不均勻，CPU和IO使用率不均勻時(shí)，還應(yīng)考慮硬件性能問(wèn)題，部分硬件性能會(huì)影響整體系統(tǒng)性能。
8、RocksDB默認(rèn)使用snappy壓縮算法，不過(guò)TiKV有分層使用壓縮算法，默認(rèn)["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]當(dāng)數(shù)據(jù)量超過(guò) 500G 時(shí) RocksDB 的層數(shù)才會(huì)超過(guò) 4， 超過(guò) 500G 部分的數(shù)據(jù)才會(huì)啟動(dòng) ZSTD 壓縮算法。lz4解壓縮速度及壓縮比都優(yōu)于snappy；ZSTD壓縮比更高，解壓縮比lz4慢，適合層級(jí)高的老數(shù)據(jù)。
9、RocksDB的LSM樹(shù)，

如圖：wal相當(dāng)于MySQL 的redo log。從wal->menorytable(可修改Memtable--》不可修改immutable Memtable)->SST，讀放大和寫(xiě)放大問(wèn)題都會(huì)存在，寫(xiě)放大在于sst逐漸往下compact（異步線程）；而讀放大在于需要逐層查找，且層數(shù)越往下，壓縮率越高，效率越低。
10、理論上，tidb-server節(jié)點(diǎn)和tikv節(jié)點(diǎn)都可以無(wú)限擴(kuò)充，但是PD整個(gè)集群只能有一個(gè)leader，因此擴(kuò)充能力受限于PD節(jié)點(diǎn)的處理能力，此外網(wǎng)絡(luò)帶寬也是限制因素之一。

未完待續(xù)......
raft算法與分布式事務(wù)percolator、兩階段提交
為何使用kv存儲(chǔ)引擎
兩個(gè)tidb集群間實(shí)時(shí)同步（異地雙中心雙活）

參考資料

TiDB官網(wǎng)
官網(wǎng)FAQ
TiDB in action
在線修改配置，非持久化配置
LSM && RocksDB compaction策略
RocksDB解析
region調(diào)度策略
TiDB 高并發(fā)寫(xiě)入場(chǎng)景最佳實(shí)踐
TiDB 熱點(diǎn)問(wèn)題處理
海量 Region 集群調(diào)優(yōu)
Percolator 和 TiDB 事務(wù)算法
TiDB 集群推薦使用 SSD 的原因