一、TiDB數(shù)據(jù)庫(kù)的簡(jiǎn)介

• TiDB是開(kāi)源分布式關(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)景。

二、五大核心特性

一鍵水平擴(kuò)容或者縮容

• 得益于 TiDB 存儲(chǔ)計(jì)算分離的架構(gòu)的設(shè)計(jì)，可按需對(duì)計(jì)算、存儲(chǔ)分別進(jìn)行在線擴(kuò)容或者縮容，擴(kuò)容或者縮容過(guò)程中對(duì)應(yīng)用運(yùn)維人員透明。

金融級(jí)高可用

• 數(shù)據(jù)采用多副本存儲(chǔ)，數(shù)據(jù)副本通過(guò) Multi-Raft 協(xié)議同步事務(wù)日志，多數(shù)派寫入成功事務(wù)才能提交，確保數(shù)據(jù)強(qiáng)一致性且少數(shù)副本發(fā)生故障時(shí)不影響數(shù)據(jù)的可用性?？砂葱枧渲酶北镜乩砦恢?、副本數(shù)量等策略滿足不同容災(zāi)級(jí)別的要求。

實(shí)時(shí) HTAP

• 提供行存儲(chǔ)引擎 TiKV、列存儲(chǔ)引擎 TiFlash 兩款存儲(chǔ)引擎，TiFlash 通過(guò) Multi-Raft Learner 協(xié)議實(shí)時(shí)從 TiKV 復(fù)制數(shù)據(jù)，確保行存儲(chǔ)引擎 TiKV 和列存儲(chǔ)引擎 TiFlash 之間的數(shù)據(jù)強(qiáng)一致。TiKV、TiFlash 可按需部署在不同的機(jī)器，解決 HTAP 資源隔離的問(wèn)題。

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

• 專為云而設(shè)計(jì)的分布式數(shù)據(jù)庫(kù)，通過(guò) TiDB Operator 可在公有云、私有云、混合云中實(shí)現(xiàn)部署工具化、自動(dòng)化。

兼容 MySQL 5.7 協(xié)議和 MySQL 生態(tài)

• 兼容 MySQL 5.7 協(xié)議、MySQL 常用的功能、MySQL 生態(tài)，應(yīng)用無(wú)需或者修改少量代碼即可從 MySQL 遷移到 TiDB。提供豐富的數(shù)據(jù)遷移工具幫助應(yīng)用便捷完成數(shù)據(jù)遷移。

三、四大核心應(yīng)用場(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) 無(wú)法真實(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ù)無(wú)法滿足因數(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ì)越來(lái)越多，其規(guī)?？赡苓_(dá)到數(shù)百 TB 甚至 PB 級(jí)別，傳統(tǒng)的解決方案是通過(guò) OLTP 型數(shù)據(jù)庫(kù)處理在線聯(lián)機(jī)交易業(yè)務(wù)，通過(guò) ETL 工具將數(shù)據(jù)同步到 OLAP 型數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)分析，這種處理方案存在存儲(chǔ)成本高、實(shí)時(shí)性差等多方面的問(wèn)題。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)中，沒(méi)有一個(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)常見(jiàn)的解決方案是采用 ETL + Hadoop 來(lái)完成，但 Hadoop 體系太復(fù)雜，運(yùn)維、存儲(chǔ)成本太高無(wú)法滿足用戶的需求。與 Hadoop 相比，TiDB 就簡(jiǎn)單得多，業(yè)務(wù)通過(guò) ETL 工具或者 TiDB 的同步工具將數(shù)據(jù)同步到 TiDB，在 TiDB 中可通過(guò) SQL 直接生成報(bào)表。

四、TiDB數(shù)據(jù)庫(kù)與MySQL數(shù)據(jù)庫(kù)的兼容性

TiDB 高度兼容 MySQL 5.7 協(xié)議、MySQL 5.7 常用的功能及語(yǔ)法。

TiDB 不支持 MySQL 復(fù)制協(xié)議，但提供了專用工具用于與 MySQL 復(fù)制數(shù)據(jù)：

• 從 MySQL 復(fù)制：TiDB Data Migration (DM) 是將 MySQL/MariaDB 數(shù)據(jù)遷移到 TiDB 的工具，可用于增量數(shù)據(jù)的復(fù)制。
• 向 MySQL 復(fù)制：TiCDC 是一款通過(guò)拉取 TiKV 變更日志實(shí)現(xiàn)的 TiDB 增量數(shù)據(jù)同步工具，可通過(guò) MySQL sink 將 TiDB 增量數(shù)據(jù)復(fù)制到 MySQL。