1鉴分、背景
傳統(tǒng)的數(shù)據(jù)庫(kù)單表超過千萬級(jí)別性能會(huì)急劇下降哮幢，不滿足某些行業(yè)的業(yè)務(wù)需求（電商之類數(shù)據(jù)量巨大的）。
那么怎么解決這種大數(shù)據(jù)量的存儲(chǔ)呢志珍，大體有2種方式：1橙垢、使用分布式存儲(chǔ)來解決這個(gè)問題（nosql，大數(shù)據(jù)hadoop的hdfs）伦糯；2柜某、數(shù)據(jù)庫(kù)分庫(kù)分表。
NoSQL敛纲，泛指非關(guān)系型的數(shù)據(jù)庫(kù)喂击，具體分類如下：
數(shù)據(jù)庫(kù)分庫(kù)分表有不少成熟的框架，具體如下：
其中用得比較多的應(yīng)該是MyCAT（需要服務(wù)端）淤翔，官網(wǎng)地址http://www.mycat.org.cn/翰绊。
還有以前當(dāng)當(dāng)?shù)膕hardingjdbc（不需要服務(wù)端），現(xiàn)在改名成shardingsphere（也有支持服務(wù)端的sharding-proxy）旁壮，官網(wǎng)地址http://shardingsphere.apache.org/监嗜。
其中nosql的方案不支持?jǐn)?shù)據(jù)庫(kù)的ACID，只能保證最終一致性抡谐；
分庫(kù)分表可以解決問題裁奇，但是會(huì)引進(jìn)不少其他的問題需要解決，而且對(duì)運(yùn)維的難度有所提升麦撵；這里有一篇介紹分庫(kù)分表方案的不足的帖子https://dbaplus.cn/news-11-1854-1.html
2刽肠、TiDB簡(jiǎn)介
在各種解決方案都不是非常好的情況下，誕生了一種新的數(shù)據(jù)庫(kù)newsql：NewSQL 是對(duì)各種新的可擴(kuò)展/高性能數(shù)據(jù)庫(kù)的簡(jiǎn)稱厦坛，這類數(shù)據(jù)庫(kù)不僅具有NoSQL對(duì)海量數(shù)據(jù)的存儲(chǔ)管理能力五垮，還保持了傳統(tǒng)數(shù)據(jù)庫(kù)支持ACID和SQL等特性乍惊。
這里有一篇關(guān)于newsql的帖子可以了解下：https://cloud.tencent.com/developer/article/1445846
其中TiDB是用go開發(fā)的一款newsql杜秸，官網(wǎng)地址是https://pingcap.com/。git地址https://github.com/pingcap
TiDB 是 PingCAP 公司自主設(shè)計(jì)润绎、研發(fā)的開源分布式關(guān)系型數(shù)據(jù)庫(kù)撬碟，是一款同時(shí)支持在線事務(wù)處理與在線分析處理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式數(shù)據(jù)庫(kù)產(chǎn)品，具備水平擴(kuò)容或者縮容莉撇、金融級(jí)高可用呢蛤、實(shí)時(shí) HTAP、云原生的分布式數(shù)據(jù)庫(kù)棍郎、兼容 MySQL 5.7 協(xié)議和 MySQL 生態(tài)等重要特性其障。目標(biāo)是為用戶提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)涂佃、HTAP 解決方案励翼。TiDB 適合高可用蜈敢、強(qiáng)一致要求較高、數(shù)據(jù)規(guī)模較大等各種應(yīng)用場(chǎng)景汽抚。
2.1抓狭、TiDB 整體架構(gòu)
與傳統(tǒng)的單機(jī)數(shù)據(jù)庫(kù)相比，TiDB 具有以下優(yōu)勢(shì)：
- 純分布式架構(gòu)造烁，擁有良好的擴(kuò)展性否过，支持彈性的擴(kuò)縮容
- 支持 SQL，對(duì)外暴露 MySQL 的網(wǎng)絡(luò)協(xié)議惭蟋，并兼容大多數(shù) MySQL 的語法苗桂，在大多數(shù)場(chǎng)景下可以直接替換 MySQL
- 默認(rèn)支持高可用，在少數(shù)副本失效的情況下敞葛，數(shù)據(jù)庫(kù)本身能夠自動(dòng)進(jìn)行數(shù)據(jù)修復(fù)和故障轉(zhuǎn)移誉察，對(duì)業(yè)務(wù)透明
- 支持 ACID 事務(wù)，對(duì)于一些有強(qiáng)一致需求的場(chǎng)景友好惹谐，例如：銀行轉(zhuǎn)賬
- 具有豐富的工具鏈生態(tài)持偏，覆蓋數(shù)據(jù)遷移、同步氨肌、備份等多種場(chǎng)景
在內(nèi)核設(shè)計(jì)上鸿秆，TiDB 分布式數(shù)據(jù)庫(kù)將整體架構(gòu)拆分成了多個(gè)模塊，各模塊之間互相通信怎囚，組成完整的 TiDB 系統(tǒng)卿叽。對(duì)應(yīng)的架構(gòu)圖如下：
TiDB Server：SQL 層，對(duì)外暴露 MySQL 協(xié)議的連接 endpoint恳守，負(fù)責(zé)接受客戶端的連接考婴，執(zhí)行 SQL 解析和優(yōu)化，最終生成分布式執(zhí)行計(jì)劃催烘。TiDB 層本身是無狀態(tài)的沥阱，實(shí)踐中可以啟動(dòng)多個(gè) TiDB 實(shí)例，通過負(fù)載均衡組件（如 LVS伊群、HAProxy 或 F5）對(duì)外提供統(tǒng)一的接入地址考杉，客戶端的連接可以均勻地分?jǐn)傇诙鄠€(gè) TiDB 實(shí)例上以達(dá)到負(fù)載均衡的效果。TiDB Server 本身并不存儲(chǔ)數(shù)據(jù)舰始，只是解析 SQL崇棠，將實(shí)際的數(shù)據(jù)讀取請(qǐng)求轉(zhuǎn)發(fā)給底層的存儲(chǔ)節(jié)點(diǎn) TiKV（或 TiFlash）。
PD Server：整個(gè) TiDB 集群的元信息管理模塊丸卷，負(fù)責(zé)存儲(chǔ)每個(gè) TiKV 節(jié)點(diǎn)實(shí)時(shí)的數(shù)據(jù)分布情況和集群的整體拓?fù)浣Y(jié)構(gòu)枕稀，提供 TiDB Dashboard 管控界面，并為分布式事務(wù)分配事務(wù) ID。PD 不僅存儲(chǔ)元信息萎坷，同時(shí)還會(huì)根據(jù) TiKV 節(jié)點(diǎn)實(shí)時(shí)上報(bào)的數(shù)據(jù)分布狀態(tài)范抓，下發(fā)數(shù)據(jù)調(diào)度命令給具體的 TiKV 節(jié)點(diǎn)，可以說是整個(gè)集群的“大腦”食铐。此外匕垫，PD 本身也是由至少 3 個(gè)節(jié)點(diǎn)構(gòu)成，擁有高可用的能力虐呻。建議部署奇數(shù)個(gè) PD 節(jié)點(diǎn)象泵。
-
存儲(chǔ)節(jié)點(diǎn)
- TiKV Server：負(fù)責(zé)存儲(chǔ)數(shù)據(jù)，從外部看 TiKV 是一個(gè)分布式的提供事務(wù)的 Key-Value 存儲(chǔ)引擎斟叼。存儲(chǔ)數(shù)據(jù)的基本單位是 Region偶惠，每個(gè) Region 負(fù)責(zé)存儲(chǔ)一個(gè) Key Range（從 StartKey 到 EndKey 的左閉右開區(qū)間）的數(shù)據(jù)，每個(gè) TiKV 節(jié)點(diǎn)會(huì)負(fù)責(zé)多個(gè) Region朗涩。TiKV 的 API 在 KV 鍵值對(duì)層面提供對(duì)分布式事務(wù)的原生支持忽孽，默認(rèn)提供了 SI (Snapshot Isolation) 的隔離級(jí)別，這也是 TiDB 在 SQL 層面支持分布式事務(wù)的核心谢床。TiDB 的 SQL 層做完 SQL 解析后兄一，會(huì)將 SQL 的執(zhí)行計(jì)劃轉(zhuǎn)換為對(duì) TiKV API 的實(shí)際調(diào)用。所以识腿，數(shù)據(jù)都存儲(chǔ)在 TiKV 中出革。另外，TiKV 中的數(shù)據(jù)都會(huì)自動(dòng)維護(hù)多副本（默認(rèn)為三副本）渡讼，天然支持高可用和自動(dòng)故障轉(zhuǎn)移骂束。
- TiFlash：TiFlash 是一類特殊的存儲(chǔ)節(jié)點(diǎn)。和普通 TiKV 節(jié)點(diǎn)不一樣的是成箫，在 TiFlash 內(nèi)部展箱，數(shù)據(jù)是以列式的形式進(jìn)行存儲(chǔ)，主要的功能是為分析型的場(chǎng)景加速蹬昌。
2.2混驰、與 MySQL 兼容性對(duì)比概覽
基本上mysql的基本功能都支持：
- TiDB 100% 兼容 MySQL 5.7 協(xié)議、MySQL 5.7 常用的功能及語法凳厢。MySQL 5.7 生態(tài)中的系統(tǒng)工具（PHPMyAdmin账胧、Navicat竞慢、MySQL Workbench先紫、mysqldump、Mydumper/Myloader）筹煮、客戶端等均用于 TiDB遮精。
- 由于 TiDB 是一款分布式數(shù)據(jù)庫(kù)，MySQL 5.7 中的部分特性因工程實(shí)現(xiàn)難度較大，投入產(chǎn)出比較低等多種原因在 TiDB 中未能實(shí)現(xiàn)或者僅兼容語法但功能并沒有實(shí)現(xiàn)本冲，因此使用過程中請(qǐng)?zhí)貏e注意准脂。例如：
CREATE TABLE語句中ENGINE，僅兼容語法檬洞，功能并沒有實(shí)現(xiàn)狸膏，因此 TiDB 中沒有ENGINE這類的概念。
不支持的功能特性：
- 存儲(chǔ)過程與函數(shù)
- 觸發(fā)器
- 事件
- 自定義函數(shù)
- 外鍵約束
- 全文/空間函數(shù)與索引
- 非
ascii/latin1/binary/utf8/utf8mb4的字符集 - SYS schema
- MySQL 追蹤優(yōu)化器
- XML 函數(shù)
- X Protocol
- Savepoints
- 列級(jí)權(quán)限
-
XA語法（TiDB 內(nèi)部使用兩階段提交添怔，但并沒有通過 SQL 接口公開） -
CREATE TABLE tblName AS SELECT stmt語法 -
CREATE TEMPORARY TABLE語法 -
CHECK TABLE語法 -
CHECKSUM TABLE語法
更詳細(xì)的內(nèi)容查看官網(wǎng)：https://docs.pingcap.com/zh/tidb/stable/mysql-compatibility
2.3湾戳、TiDB 軟件和硬件環(huán)境建議配置
TiDB對(duì)于硬件的要求不是很低，存儲(chǔ)的TiKv和TiFlash都需要固態(tài)硬盤广料，尤其是用于分析的TiFlash內(nèi)存和cpu要求比較高（這里暫時(shí)就不介紹怎么安裝了）：
其他配置詳見：https://pingcap.com/docs-cn/stable/hardware-and-software-requirements/
2.4砾脑、適用場(chǎng)景
- 對(duì)數(shù)據(jù)一致性及高可靠、系統(tǒng)高可用艾杏、可擴(kuò)展性韧衣、容災(zāi)要求較高的金融行業(yè)屬性的場(chǎng)景
眾所周知，金融行業(yè)對(duì)數(shù)據(jù)一致性及高可靠购桑、系統(tǒng)高可用畅铭、可擴(kuò)展性、容災(zāi)要求較高勃蜘。傳統(tǒng)的解決方案是同城兩個(gè)機(jī)房提供服務(wù)顶瞒、異地一個(gè)機(jī)房提供數(shù)據(jù)容災(zāi)能力但不提供服務(wù)，此解決方案存在以下缺點(diǎn)：資源利用率低元旬、維護(hù)成本高榴徐、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 無法真實(shí)達(dá)到企業(yè)所期望的值。TiDB 采用多副本 + Multi-Raft 協(xié)議的方式將數(shù)據(jù)調(diào)度到不同的機(jī)房匀归、機(jī)架坑资、機(jī)器，當(dāng)部分機(jī)器出現(xiàn)故障時(shí)系統(tǒng)可自動(dòng)進(jìn)行切換穆端，確保系統(tǒng)的 RTO <= 30s 及 RPO = 0 袱贮。 - 對(duì)存儲(chǔ)容量、可擴(kuò)展性体啰、并發(fā)要求較高的海量數(shù)據(jù)及高并發(fā)的 OLTP 場(chǎng)景
隨著業(yè)務(wù)的高速發(fā)展攒巍，數(shù)據(jù)呈現(xiàn)爆炸性的增長(zhǎng)，傳統(tǒng)的單機(jī)數(shù)據(jù)庫(kù)無法滿足因數(shù)據(jù)爆炸性的增長(zhǎng)對(duì)數(shù)據(jù)庫(kù)的容量要求荒勇，可行方案是采用分庫(kù)分表的中間件產(chǎn)品或者 NewSQL 數(shù)據(jù)庫(kù)替代柒莉、采用高端的存儲(chǔ)設(shè)備等，其中性價(jià)比最大的是 NewSQL 數(shù)據(jù)庫(kù)沽翔，例如：TiDB兢孝。TiDB 采用計(jì)算窿凤、存儲(chǔ)分離的架構(gòu)，可對(duì)計(jì)算跨蟹、存儲(chǔ)分別進(jìn)行擴(kuò)容和縮容雳殊，計(jì)算最大支持 512 節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)最大支持 1000 并發(fā)窗轩，集群容量最大支持 PB 級(jí)別夯秃。 - Real-time HTAP 場(chǎng)景
隨著 5G、物聯(lián)網(wǎng)痢艺、人工智能的高速發(fā)展寝并，企業(yè)所生產(chǎn)的數(shù)據(jù)會(huì)越來越多，其規(guī)母贡福可能達(dá)到數(shù)百 TB 甚至 PB 級(jí)別衬潦，傳統(tǒng)的解決方案是通過 OLTP 型數(shù)據(jù)庫(kù)處理在線聯(lián)機(jī)交易業(yè)務(wù)，通過 ETL 工具將數(shù)據(jù)同步到 OLAP 型數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)分析植酥，這種處理方案存在存儲(chǔ)成本高镀岛、實(shí)時(shí)性差等多方面的問題。TiDB 在 4.0 版本中引入列存儲(chǔ)引擎 TiFlash 結(jié)合行存儲(chǔ)引擎 TiKV 構(gòu)建真正的 HTAP 數(shù)據(jù)庫(kù)友驮，在增加少量存儲(chǔ)成本的情況下漂羊，可以同一個(gè)系統(tǒng)中做聯(lián)機(jī)交易處理、實(shí)時(shí)數(shù)據(jù)分析卸留，極大地節(jié)省企業(yè)的成本走越。 - 數(shù)據(jù)匯聚、二次加工處理的場(chǎng)景
當(dāng)前絕大部分企業(yè)的業(yè)務(wù)數(shù)據(jù)都分散在不同的系統(tǒng)中耻瑟，沒有一個(gè)統(tǒng)一的匯總旨指，隨著業(yè)務(wù)的發(fā)展，企業(yè)的決策層需要了解整個(gè)公司的業(yè)務(wù)狀況以便及時(shí)做出決策喳整，故需要將分散在各個(gè)系統(tǒng)的數(shù)據(jù)匯聚在同一個(gè)系統(tǒng)并進(jìn)行二次加工處理生成 T+0 或 T+1 的報(bào)表谆构。傳統(tǒng)常見的解決方案是采用 ETL + Hadoop 來完成，但 Hadoop 體系太復(fù)雜框都，運(yùn)維搬素、存儲(chǔ)成本太高無法滿足用戶的需求。與 Hadoop 相比魏保，TiDB 就簡(jiǎn)單得多熬尺，業(yè)務(wù)通過 ETL 工具或者 TiDB 的同步工具將數(shù)據(jù)同步到 TiDB，在 TiDB 中可通過 SQL 直接生成報(bào)表谓罗。
最后粱哼，一些合作案例和PingCAP公司相關(guān)的文章地址http://www.ctoutiao.com/c/74735854/
