當(dāng)我們使用 Mysql數(shù)據(jù)庫到達(dá)一定量級(jí)以后，性能就會(huì)逐步下降，而解決此類問題，常用的手段就是引入數(shù)據(jù)庫中間件進(jìn)行分庫分表處理，比如使用 Mycat、ShadingShpere、tddl，但是這種都是過去式了，現(xiàn)在使用分布式數(shù)據(jù)庫可以避免分庫分表

為什么不建議分庫分表呢？

分庫分表以后，會(huì)面臨以下問題

• 分頁問題，例如：使用傳統(tǒng)寫法，隨著頁數(shù)過大性能會(huì)急劇下降
• 分布式事務(wù)問題
• 數(shù)據(jù)遷移問題，例如：需要把現(xiàn)有數(shù)據(jù)通過分配算法導(dǎo)入到所有的分庫中
• 數(shù)據(jù)擴(kuò)容問題，分庫分表的數(shù)據(jù)總有一天也會(huì)到達(dá)極限，需要增大分片
• 開發(fā)模式變化，比如在請(qǐng)求數(shù)據(jù)時(shí)，需要帶分片鍵，否則就會(huì)導(dǎo)致所有節(jié)點(diǎn)執(zhí)行
• 跨庫跨表查詢問題
• 業(yè)務(wù)需要進(jìn)行一定取舍，由于分庫分表的局限性，有些場(chǎng)景下需要業(yè)務(wù)進(jìn)行取舍

以上只是列舉了一部分問題，為了避免這些問題，可以使用分布式數(shù)據(jù)庫TiDB來處理

TiDB介紹

TiDB 是 PingCAP 公司研發(fā)的一款開源分布式關(guān)系型數(shù)據(jù)庫，從 2015年 9 月開源，至今已經(jīng)有9 年時(shí)間，可以說已經(jīng)非常成熟，它是一款同時(shí)支持OLTP（在線事務(wù)處理）和OLAP（在線分析處理）的融合型分布式數(shù)據(jù)庫產(chǎn)品，具備水平擴(kuò)縮容，金融級(jí)高可用、實(shí)時(shí) HTAP（Hybrid Transactional and Analytical Processing）、云原生的分布式數(shù)據(jù)庫，兼容 MySQL 5.7 協(xié)議和 MySQL 生態(tài)等重要特性，它適合高可用、強(qiáng)一致要求較高、數(shù)據(jù)規(guī)模較大等各種應(yīng)用場(chǎng)景。

核心特性

• 金融級(jí)高可用
• 在線水平擴(kuò)容或者縮容，并且存算分離
• 云原生的分布式數(shù)據(jù)庫，支持部署在公有云，私有云，混合云中
• 實(shí)時(shí)HTAP，提供TIKV行存儲(chǔ)引擎和TiFlash列存儲(chǔ)引擎
• 兼容MySQL協(xié)議和MySQL生態(tài)
• 分布式事務(wù)強(qiáng)一致性
• 從 MySQL 無縫切換到 TiDB，幾乎無需修改代碼，遷移成本極低
• PD在分布式理論CAP方面滿足CP，是強(qiáng)一致性的

應(yīng)用場(chǎng)景

• 對(duì)數(shù)據(jù)一致性及高可靠、系統(tǒng)高可用、可擴(kuò)展性、容災(zāi)要求較高的金融行業(yè)屬性的場(chǎng)景
• 對(duì)存儲(chǔ)容量、可擴(kuò)展性、并發(fā)要求較高的海量數(shù)據(jù)及高并發(fā)的OLTP場(chǎng)景
• 數(shù)據(jù)匯聚、二次加工處理的場(chǎng)景

案例

TiDB 有1500 多家不同行業(yè)的企業(yè)應(yīng)用在了生產(chǎn)環(huán)境，以下是一些有代表性企業(yè)，要想查看更多案例，可以訪問TiDB 官網(wǎng)查詢

圖片

系統(tǒng)架構(gòu)

圖片

TIDB Server

SQL 層，對(duì)外暴露 MySQL 協(xié)議的連接 endpoint，負(fù)責(zé)接收SQL請(qǐng)求，處理SQL相關(guān)的邏輯，并通過PD找到存儲(chǔ)計(jì)算所需數(shù)據(jù)的TiKV地址，與TiKV交互獲取數(shù)據(jù)，最終返回結(jié)果。TiDB Server 是無狀態(tài)的，其本身并不存儲(chǔ)數(shù)據(jù)，只負(fù)責(zé)計(jì)算，可以無限水平擴(kuò)展，可以通過負(fù)載均衡組件（LVS、HAProxy或F5）對(duì)外提供統(tǒng)一的接入地址，客戶端的連接可以均勻地分?jǐn)傇诙鄠€(gè) TiDB 實(shí)例上以達(dá)到負(fù)載均衡的效果。

PD Server

整個(gè)集群的管理模塊，其主要工作有三個(gè)：

1. 存儲(chǔ)集群的元信息（某個(gè)Key存儲(chǔ)在那個(gè)TiKV節(jié)點(diǎn)）；
2. 對(duì)TiKV集群進(jìn)行調(diào)度和負(fù)載均衡、Leader選舉；
3. 分配全局唯一且遞增的事務(wù)ID。

PD 是一個(gè)集群，需要部署奇數(shù)個(gè)節(jié)點(diǎn)，一般線上推薦至少部署3個(gè)節(jié)點(diǎn)。PD在選舉的過程中無法對(duì)外提供服務(wù)，這個(gè)時(shí)間大約是3秒。

TIKV Server

圖片

TiDB 現(xiàn)在同時(shí)支持OLTP 和 OLAP，而TiKV負(fù)責(zé)存儲(chǔ)OLTP數(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如何做到數(shù)據(jù)不丟失？

圖片

簡(jiǎn)單理解，就是把數(shù)據(jù)復(fù)制到多臺(tái)機(jī)器上，這樣一個(gè)節(jié)點(diǎn)down 機(jī)，其他節(jié)點(diǎn)上的副本還能繼續(xù)提供服務(wù)；復(fù)雜理解，需要這個(gè)數(shù)據(jù)可靠并且高效復(fù)制到其他節(jié)點(diǎn)，并且能處理副本失效的情況，那怎么做呢，就是使用 Raft一致性算法

Region 與副本之間通過 Raft 協(xié)議來維持?jǐn)?shù)據(jù)一致性，任何寫請(qǐng)求都只能在 Leader 上寫入，并且需要寫入多數(shù)副本后（默認(rèn)配置為 3 副本，即所有請(qǐng)求必須至少寫入兩個(gè)副本成功）才會(huì)返回客戶端寫入成功。

分布式事務(wù)支持

TiKV 支持分布式事務(wù)，我們可以一次性寫入多個(gè) key-value 而不必關(guān)心這些 key-value 是否處于同一個(gè)數(shù)據(jù)切片 (Region) 上，TiKV 的分布式事務(wù)參考了Google 在 BigTable 中使用的事務(wù)模型Percolator，具體可以訪問論文了解

與MySQL的對(duì)比

支持的特性

• 支持分布式事務(wù)，原理是基于Google Percolator，Percolator是基于Bigtable的，所以數(shù)據(jù)結(jié)構(gòu)直接使用了Bigtable的Tablet。詳情可參考https://zhuanlan.zhihu.com/p/39896539
• 支持鎖，TIDB是樂觀鎖 +MVCC ，MySQL是悲觀鎖+MVCC，要注意TIDB執(zhí)行Update、Insert、Delete時(shí)不會(huì)檢查沖突，只有在提交時(shí)才會(huì)檢查寫寫沖突，所以在業(yè)務(wù)端執(zhí)行SQL語句后，要注意檢查返回值，即使執(zhí)行沒有出錯(cuò)，提交的時(shí)候也可能出錯(cuò)。

不支持的功能特性

• 不支持存儲(chǔ)過程、函數(shù)、觸發(fā)器
• 自增id只支持在單個(gè)TIDB Server的自增，不支持多個(gè)TIDB Server的自增。
• 外鍵約束
• 臨時(shí)表
• Mysql追蹤優(yōu)化器
• XA 語法（TiDB 內(nèi)部使用兩階段提交，但并沒有通過 SQL 接口公開）

資源使用情況

以下內(nèi)容參考：https://pingcap.medium.com/an-8x-system-performance-boost-why-we-migrated-from-mysql-to-a-newsql-database-a42570ab765a

TiDB 具有很高的數(shù)據(jù)壓縮比，MySQL 中的 10.8 TB 數(shù)據(jù)在 TiDB 中變成了 3.2 TB，還是三副本的總數(shù)據(jù)量。因此，MySQL 與 TiDB 的空間使用比例為 3.4:1。

圖片

同等量級(jí)，使用2 年以后，資源使用情況

• MySQL使用32 個(gè)節(jié)點(diǎn)，而 TiDB 只有 14 個(gè)
• MySql 用了 512 個(gè) CPU 核心，而 TiDB 將僅使用 224 個(gè)，不到 MySQL 的一半。
• MySQL 使用 48 TB 存儲(chǔ)空間，而 TiDB 將使用 16 TB，僅為 MySQL 的 1/3。

圖片

圖片

性能測(cè)試

測(cè)試報(bào)告 1

來源:https://www.percona.com/blog/a-quick-look-into-tidb-performance-on-a-single-server/

五個(gè) ecs 實(shí)例，使用了不同配置，以此測(cè)試

• t2.medium：2 個(gè) CPU 核心
• x1e.xlarge：4 個(gè) CPU 核心
• r4.4xlarge：16 個(gè) CPU 核心
• m4.16xlarge：64 個(gè) CPU 核心
• m5.24xlarge：96 個(gè) CPU 核心

MySQL 中的數(shù)據(jù)庫大小為 70Gb，TiDB 中的數(shù)據(jù)庫大小為 30Gb（壓縮）。該表沒有二級(jí)索引（主鍵除外）。

測(cè)試用例

1. 簡(jiǎn)單計(jì)數(shù)(*):

select count(*) from ontime;

1. 簡(jiǎn)單分組依據(jù)

select count(*), year from ontime group by year order by year;

1. 用于全表掃描的復(fù)雜過濾器

select * from ontime where UniqueCarrier = 'DL' and TailNum = 'N317NB' and FlightNum = '2' and Origin = 'JFK' and Dest = 'FLL' limit 10;

1. 復(fù)雜的分組依據(jù)和排序依據(jù)查詢

select SQL_CALC_FOUND_ROWS 
FlightDate, UniqueCarrier as carrier,
FlightNum, 
Origin, 
Dest 
FROM ontime 
WHERE 
DestState not in ('AK', 'HI', 'PR', 'VI')
and OriginState not in ('AK', 'HI', 'PR', 'VI')
and flightdate > '2015-01-01' 
and ArrDelay < 15 
and cancelled = 0 and Diverted = 0  
and DivAirportLandings = '0'    
ORDER by DepDelay DESC
LIMIT 10;

下圖表示結(jié)果（條形表示查詢響應(yīng)時(shí)間，越小越好）：

系統(tǒng)基準(zhǔn)測(cè)試

在 m4.16xlarge 實(shí)例上使用 Sysbench 進(jìn)行點(diǎn)選擇（意味著通過主鍵選擇一行，線程范圍從 1 到 128）（內(nèi)存限制：無磁盤讀?。＝Y(jié)果在這里。條形代表每秒的交易數(shù)量，越多越好：

圖片

系統(tǒng)測(cè)試報(bào)告 2

來源：https://www.dcits.com/show-269-4103-1.html

硬件配置

圖片

圖片

測(cè)試場(chǎng)景

圖片

測(cè)試分兩階段進(jìn)行，第一階段測(cè)試數(shù)據(jù)為100萬單，第二階段測(cè)試數(shù)據(jù)為1300萬單。在此基礎(chǔ)上，使用Jmeter壓力測(cè)試10萬單結(jié)果如下：

圖片

圖片

從測(cè)試結(jié)果來看，在小數(shù)據(jù)量mysql性能是好于TiDB，因?yàn)?TiDB 是分布式架構(gòu)，如果小數(shù)據(jù)量，在網(wǎng)絡(luò)通訊節(jié)點(diǎn)分發(fā)一致性等方面花的時(shí)間就很多，然后各個(gè)節(jié)點(diǎn)執(zhí)行完還要匯總返回，所以開銷是比較大的，但是數(shù)據(jù)量一上來TiDB 優(yōu)勢(shì)就體現(xiàn)出來了，因此數(shù)據(jù)量比較小，沒必要使用 TiDB

總結(jié)

以上介紹了 TiDB架構(gòu)，以及它的一些特性，同時(shí)也與 mysql 進(jìn)行了對(duì)比，如果貴司的數(shù)據(jù)量比較大，正在考慮要分庫分表，那么完全可以使用它，來避免分庫分表，分庫分表是一個(gè)過渡方案，使用分布式數(shù)據(jù)庫才是終極方案。