TiDB原了解析系列（一）---Why Do We Use it？

TiDB

是

PingCAP

公司設計的開源分布式

NewSQL

資料庫。由于它相容

MySQL

協定，并支援絕大多數

SQL

功能（比如

joins

，

subqueries

,

transaction

等）。業務能夠直接通過

MySQL connector

去使用它來替換

MySQL

。

TiDB

适合場景：

• 資料量大，

  MySQL

  複雜查詢很慢。

  Online DDL

  影響業務的使用。

• MySQL

  單機容量或者性能達到瓶頸，不想分庫分表或者使用資料庫中間件等對業務侵入性較大、對業務有限制的

  Sharding

  方案。
• 有高并發實時寫入、實時查詢、實時統計分析的需求。
• 有分布式事務、多資料中心的資料

  100%

  強一緻性、

  auto-failover

  的高可用的需求。

TiDB

與

MySQL

相比，有什麼優勢，讓它更适合上述場景？接下來将從以下六個方面進行對比。

1.

TiDB

實作分布式的

SQL

引擎和存儲

MySQL

水準擴充一般是主從複制，典型的就是一主多從模式。但這種隻适合讀多寫少的業務。碰到大寫入量的業務，這種模式反而會成為瓶頸。那麼就必須尋求其他的分布式方案，有以下兩種思路：

• 基于修改

  MySQL

  的分布式方案。通過

  MySQL

  的

  Server

  把

  InnoDB

  變成分布式資料庫，但由于

  MySQL

  生成的執行計劃是單機的，這不是一個分布式的

  Plan

  。不了解底層分布式存儲，是無法選擇一個最高效率的執行計劃。
• 基于中間件方式的分布式方案，比如 ProxySQL 。做一款中間件需要考慮很多，比如通過解析

  SQL

  解析出

  ShardKey

  ，然後根據

  ShardKey

  分發請求，再合并結果。另外在中間件這層還需要維護

  Session

  并儲存緩存結果。大多數方案并不支援分布式

  Transaction

  ，不支援跨節點

  Join

  ，無法處理複雜

  Plan

  ，也不會處理

  Subqueries

  。同時業務需要維護

  ShardKey

  ，不支援

  ORM

  導緻業務開發效率降低。

以上

MySQL

的問題是由傳統架構模式本身帶來的，而

TiDB

的模式是不一樣的。它在

TiDB Server

層實作了分布式的SQL引擎，依賴

TiKV

來提供分布式存儲和

分布式事務支援

，分布式的設計也友善做水準擴充。以上

MySQL

分布式方案帶來的問題，

TiDB

都能做很好的解決，這是架構本身帶來的優勢。

如上圖所示，

TiDB

叢集主要分為以下三個元件：

• TiDB Server

  TiDB Server

  負責接收

  SQL

  請求，處理

  SQL

  相關的邏輯，并通過

  PD

  找到存儲計算所需資料的

  TiKV

  位址，與

  TiKV

  互動擷取資料，最終傳回結果。

  TiDB Server

  本身并不存儲資料，隻負責計算，可以無限水準擴充。通過負載均衡元件（如

  LVS

  、

  HAProxy

  或

  F5

  ）對外提供統一的接入位址。

• PD Server

  Placement Driver

  (簡稱

  PD

  )是整個叢集的管理子產品。其主要工作有三個：一是存儲叢集的元資訊（某個

  Key

  存儲在哪個 TiKV節點）；二是對

  TiKV

  叢集進行排程和負載均衡（如資料的遷移、

  Raft group leader

  成員變更等）；三是配置設定全局唯一且遞增的事務

  ID

  （支援分布式事務）。

• TiKV Server

  

TiKV Server

負責存儲資料，從外部看

TiKV

是一個分布式的提供事務的

Key-Value

存儲引擎。存儲資料的基本機關是

Region

，每個

Region

負責存儲一個

Key Range

（從

StartKey

到

EndKey

的左閉右開區間）的資料，每個

TiKV

節點會負責多個

Region

TiKV

使用

Raft

協定做複制，保持資料的一緻性和容災。副本以

Region

為機關進行管理，不同節點上的多個

Region

構成一個

Raft Group

。資料在多個

TiKV

之間的負載均衡由

PD

排程，是以

Region

為機關進行排程。

2.

TiDB

金融級的高可用

MySQL

的複制方式是半同步或者是異步，半同步也可以降級成異步。也就是說任何時候資料出了問題是不敢切換的，因為有可能是異步複制，有一部分資料還沒有同步過來，這時候切換資料就不一緻了。多資料中心的複制和資料中心的容災，

MySQL

在這上面是做不好的。

而

TiDB/TiKV/PD

的三個元件都能容忍部分執行個體失效，并且不影響整個叢集的可用性，支援

跨中心部署

下面分别說明這三個元件的單個執行個體失效後的服務狀态，以及如何進行恢複。

• TiDB Server

  TiDB Server

  是無狀态的，推薦至少部署兩個執行個體。當單個執行個體失效時，會影響正在這個執行個體上進行的服務，從應用的角度看，會出現單次請求失敗的情況，重新連接配接成功後即可繼續獲得服務。單個執行個體失效後，可以重新開機這個執行個體或者部署一個新的執行個體。

• PD Server

  PD

  是一個叢集，通過

  Raft

  協定保持資料的一緻性，單個執行個體失效時，如果這個執行個體不是

  Raft

  leader

  ，那麼服務完全不受影響；如果這個執行個體是

  Raft

  leader

  ，會重新選出新的

  Raft leader

  ，自動恢複服務。

  PD

  在選舉的過程中無法對外提供服務，這個時間大約是3秒鐘。推薦至少部署三個

  PD

  執行個體，單個執行個體失效後，重新開機這個執行個體或者添加新的執行個體。

• TiKV Server

  TiKV

  Raft

  協定保持資料的一緻性（副本數量可配置，預設儲存三副本），并通過

  PD

  做負載均衡排程。單個節點失效時，會影響這個節點上存儲的所有

  Region

  。對于

  Region

  中的

  Leader

  結點，會中斷服務，等待重新選舉；對于

  Region

  Follower

  節點，不會影響服務。當某個

  TiKV

  節點失效，并且在一段時間内（預設

  10

  分鐘）無法恢複，

  PD

  會将其上的資料遷移到其他的

  TiKV

  節點上。

3.

TiDB

存儲引擎

RocksDB

MySQL

預設存儲引擎從2010年起就一直是

InnoDB

InnoDB

B+

樹資料結構，這與傳統的商業資料庫相似。

TiDB

RocksDB

作為

TiKV

的存儲引擎。

讀寫性能的測試對比：

• RocksDB

  讀性能隻有

  InnoDB-Compress

  性能的

  70%

  。但在高并發下，

  RocksDB

  平均響應時間表現要比

  InnoDB-Compress好

  。但與未壓縮的

  InnoDB

  還是差不少。

• RocksDB

  寫性能表現優異，

  QPS

  大概是

  InnoDB-Compress

  10

  倍。

RocksDB

優勢是在于處理大型資料集，因為它可以更有效地壓縮資料并且插入資料性能優秀。

6億4千萬資料導入

MySQL

InnoDB

未經壓縮大小為

160GB

InnoDB-Compress

為

86GB

RocksDB

62GB

TiDB

更加适合大規模資料場景。資料條數少于

5000w

的場景下通常用不到

TiDB

，單機

MySQL

能滿足的場景也不需要用到

TiDB

4.

TiDB

更好的解決了

Online DDL

問題

業務發展迅速，應用模式頻繁更改是常态。相應地，資料庫通路模式和

Schema

也随之變化。

DDL

SQL

的一類，主要作用是建立和更改資料的

Schema

資訊，最常見的操作包括：加減列、更改列類型、加減索引等。

5.6

版本以後，

MySQL

内部開始支援

Online DDL

。但

MySQL

Online DDL

方案始終沒有解決下面問題：

MySQL

主備副本之間通過

Binlog

同步，主的

Schema

變更成功後，才會寫

BinLog

同步給備庫，然後備庫才開始做

DDL

。假設一個

DDL

變更需要一個小時，那麼備庫最多可能會延遲兩倍的變更時間。若變更期間，主庫發生故障，備庫資料還未追平，則無法提供服務的。

TiDB

Google F1

論文介紹的協定實作

線上DDL

Tikv

基本不感覺

DDL

操作。對于

Tikv

來說，所有的操作都是

PUT/GET/DELETE

，是以副本間的變更也與普通

DML

沒有差異。任何時候，隻要底層

raft

協定能正常

work

，三副本高可用和強一緻就能得到保證。這個方案雖然

Schema

變更比較麻煩，但對于

Tikv

存儲層特别友好，不用感覺

DDL

，共用一套機制保證高可用和強一緻。不會出現類似

MySQL

主備延遲和主備

Schema

不一緻問題。

DDL

更改也被分解成更小的轉換階段，這樣它們可以防止資料損壞場景，并且系統允許單個節點一次最多支援一個

DDL

版本。

5.

TiDB

提供一站式

HTAP

解決方案

MySQL

團隊把注意力放在優化聯機事務處理（

OLTP

）查詢的性能上。也就是說，

MySQL

團隊花費更多的時間使簡單查詢執行得更好，而不是使所有或複雜查詢執行得更好。這種方法沒有錯，因為許多應用程式隻使用簡單的查詢。

TiDB

設計目标在處理混合事務/分析處理（

HTAP

）的性能上。對于那些希望對資料進行實時分析的應用來說，這是一個主要的賣點，因為它消除了在

MySQL

資料庫和分析資料庫之間進行的批量加載。一份存儲同時處理

OLTP & OLAP

，無需傳統繁瑣的

ETL

過程。

6.

TiDB

可視化監控與告警

這一點對運維非常友好。

MySQL

将關鍵監控名額放在記憶體表中，擷取它需要通過

SQL

查詢，可視化與告警部分都需要額外開發。而TiDB提供

Metrics接口

，使用

Prometheus

記錄元件中各種操作的詳細資訊，使用

Grafana

進行可視化展示。無須其他開發額外，根據需要，即可配置定制化自己的監控圖表和報警。

總結

在替代

MySQL

的場景中，

TiDB

MySQL

相比更加适合大數量的場景；同時也補充了

MySQL

的不足，比如處理

Online DDL

問題；在

MySQL

不适合的場景中，比如

HTAP

場景中也能發揮很好的優勢。如果你想更多了解

TiDB

作者的初衷，參閱

How do we build TiDB Meet TiDB: An open source NewSQL database