TiDB 在小米的應用實踐

作者：張良，小米 DBA 負責人；潘友飛，小米 DBA；王必文，小米開發工程師。

一、應用場景介紹

MIUI 是小米公司旗下基于 Android 系統深度優化、定制、開發的第三方手機操作系統，也是小米的第一個產品。MIUI 在 Android 系統基礎上，針對中國用戶進行了深度定制，在此之上孕育出了一系列的應用，比如主題商店、小米音樂、應用商店、小米閱讀等。

圖 1 ?MIUI Android 系統界面圖

<center>圖 1 ?MIUI Android 系統界面圖</center>

目前 TiDB 主要應用在：

小米手機桌面負一屏的快遞業務
商業廣告交易平臺素材抽審平臺

這兩個業務場景每天讀寫量均達到上億級，上線之后，整個服務穩定運行；接下來我們計劃逐步上線更多的業務場景，小米閱讀目前正在積極的針對訂單系統做遷移測試。

二、TiDB 特點

TiDB 結合了傳統的 RDBMS 和 NoSQL 的最佳特性，兼容 MySQL 協議，支持無限的水平擴展，具備強一致性和高可用性。

具有如下的特性：

高度兼容 MySQL，大多數情況下無需修改代碼即可從 MySQL 輕松遷移至 TiDB，即使已經分庫分表的 MySQL 集群亦可通過 TiDB 提供的遷移工具進行實時遷移。
水平彈性擴展，通過簡單地增加新節點即可實現 TiDB 的水平擴展，按需擴展吞吐或存儲，輕松應對高并發、海量數據場景。
分布式事務，TiDB 100% 支持標準的 ACID 事務。
真正金融級高可用，相比于傳統主從（M-S）復制方案，基于 Raft 的多數派選舉協議可以提供金融級的 100% 數據強一致性保證，且在不丟失大多數副本的前提下，可以實現故障的自動恢復（auto-failover），無需人工介入。

TiDB 的架構及原理在官網里有詳細介紹，這里不再贅述。

圖 2 ?TiDB 基礎架構圖

<center>圖 2 ?TiDB 基礎架構圖</center>

三、背景

跟絕大數互聯網公司一樣，小米關系型存儲數據庫首選 MySQL，單機 2.6T 磁盤。由于小米手機銷量的快速上升和 MIUI 負一屏用戶量的快速增加，導致負一屏快遞業務數據的數據量增長非常快，每天的讀寫量級均分別達到上億級別，數據快速增長導致單機出現瓶頸，比如性能明顯下降、可用存儲空間不斷降低、大表 DDL 無法執行等，不得不面臨數據庫擴展的問題。比如，我們有一個業務場景（智能終端），需要定時從幾千萬級的智能終端高頻的向數據庫寫入各種監控及采集數據，MySQL 基于 Binlog 的單線程復制模式，很容易造成從庫延遲，并且堆積越來越嚴重。

對于 MySQL 來講，最直接的方案就是采用分庫分表的水平擴展方式，綜合來看并不是最優的方案，比如對于業務來講，對業務代碼的侵入性較大；對于 DBA 來講提升管理成本，后續需要不斷的拆分擴容，即使有中間件也有一定的局限性。同樣是上面的智能終端業務場景，從業務需求看，需要從多個業務維度進行查詢，并且業務維度可能隨時進行擴展，分表的方案基本不能滿足業務的需求。

了解到 TiDB 特點之后，DBA 與業務開發溝通確認當前 MySQL 的使用方式，并與 TiDB 的兼容性做了詳細對比，經過業務壓測之后，根據壓測的結果，決定嘗試將數據存儲從 MySQL 遷移到 TiDB。經過幾個月的線上考驗，TiDB 的表現達到預期。

四、兼容性對比

TiDB 支持包括跨行事務、JOIN、子查詢在內的絕大多數 MySQL 的語法，可以直接使用 MySQL 客戶端連接；對于已用 MySQL 的業務來講，基本可以無縫切換到 TiDB。

二者簡單對比如下幾方面：

功能支持
- TiDB 尚不支持如下幾項：
  - 增加、刪除主鍵
  - 非 UTF8 字符集
  - 視圖（即將支持）、存儲過程、觸發器、部分內置函數
  - Event
  - 全文索引、空間索引
默認設置
- 字符集、排序規則、sql_mode、lower_case_table_names 幾項默認值不同。
事務
- TiDB 使用樂觀事務模型，提交后注意檢查返回值。
- TiDB 限制單個事務大小，保持事務盡可能的小。
TiDB 支持絕大多數的 Online DDL。
另，一些 MySQL 語法在 TiDB 中可以解析通過，不會產生任何作用，例如： create table 語句中 engine、partition 選項都是在解析后忽略。
詳細信息可以訪問官網：https://pingcap.com/docs-cn/sql/mysql-compatibility/?。

五、壓測

5.1 目的

通過壓測 TiDB 了解一下其 OLTP 性能，看是否滿足業務要求。

5.2 機器配置

組件	實例數量	CPU 型號	內存	磁盤	版本	操作系統
TiDB	3	Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz	128G	SSD Raid 5	2.0.3	CentOS Linux release 7.3.1611
PD	3	Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz	128G	SSD Raid 5	2.0.3	CentOS Linux release 7.3.1611
TiKV	4	Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz	128G	SSD Raid 5	2.0.3	CentOS Linux release 7.3.1611

5.3 壓測內容以及結果

5.3.1 標準 Select 壓測

Threads	QPS	Latency (avg / .95 / max)
8	12650.81	0.63 / 0.90 / 15.62
16	21956.21	0.73 / 1.50 / 15.71
32	31534.8	1.01 / 2.61 / 25.16
64	38217	1.67 / 5.37 / 49.80
128	39943.05	3.20 / 8.43 / 58.60
256	40920.64	6.25 / 13.70 / 95.13

圖 3 ?標準 Select 壓測圖

<center>圖 3 ?標準 Select 壓測圖</center>

5.3.2 標準 OLTP 壓測

Threads	TPS	QPS	Latency (avg / .95 / max)
8	428.9	8578.09	18.65 / 21.89 / 116.06
16	731.67	14633.35	21.86 / 25.28 / 120.59
32	1006.43	20128.59	31.79 / 38.25 / 334.92
64	1155.44	23108.9	55.38 / 71.83 / 367.53
128	1121.55	22431	114.12 / 161.51 / 459.03
256	941.26	18825.1	271.94 / 369.77 / 572.88

更正-oltp壓測

5.3.3 標準 Insert 壓測

Threads	QPS	Latency (avg / .95 / max)
8	3625.75	2.20 / 2.71 / 337.94
16	6527.24	2.45 / 3.55 / 160.84
32	10307.66	3.10 / 4.91 / 332.41
64	13662.83	4.68 / 7.84 / 467.56
128	15100.44	8.47 / 16.41 / 278.23
256	17286.86	14.81 / 25.74 / 3146.52

圖 5 ?標準 Insert 壓測圖

<center>圖 5 ?標準 Insert 壓測圖</center>

通過壓測發現 TiDB 穩定性上與預期稍有差別，不過壓測的 Load 會明顯高于生產中的業務 Load，參考低 Threads 時 TiDB 的表現，基本可以滿足業務對 DB 的性能要求，決定灰度一部分 MySQL 從庫讀流量體驗一下實際效果。

六、遷移過程

整個遷移分為 2 大塊：數據遷移、流量遷移。

6.1 數據遷移

數據遷移分為增量數據、存量數據兩部分。

對于存量數據，可以使用邏輯備份、導入的方式，除了傳統的邏輯導入外，官方還提供一款物理導入的工具 TiDB Lightning。
對于增量備份可以使用 TiDB 提供的 Syncer （新版已經更名為 DM - Data Migration）來保證數據同步。

Syncer 結構如圖 6，主要依靠各種 Rule 來實現不同的過濾、合并效果，一個同步源對應一個 Syncer 進程，同步 Sharding 數據時則要多個 Syncer 進程。

圖 6? Syncer 結構圖

<center>圖 6? Syncer 結構圖</center>

使用 Syncer 需要注意：

做好同步前檢查，包含 server-id、log_bin、binlog_format 是否為 ROW、binlog_row_image 是否為 FULL、同步相關用戶權限、Binlog 信息等。
使用嚴格數據檢查模式，數據不合法則會停止。數據遷移之前最好針對數據、表結構做檢查。
做好監控，TiDB 提供現成的監控方案。
對于已經分片的表同步到同一個 TiDB 集群，要做好預先檢查。確認同步場景是否可以用 route-rules 表達，檢查分表的唯一鍵、主鍵在數據合并后是否沖突等。

6.2 流量遷移

流量切換到 TiDB 分為兩部分：讀、寫流量遷移。每次切換保證灰度過程，觀察周期為 1~2 周，做好回滾措施。

讀流量切換到 TiDB，這個過程中回滾比較簡單，灰度無問題，則全量切換。
再將寫入切換到 TiDB，需要考慮好數據回滾方案或者采用雙寫的方式（需要斷掉 Syncer）。

七、集群狀況

7.1 配置

集群配置采用官方推薦的 7 節點配置，3 個 TiDB 節點，3 個 PD 節點，4 個 TiKV 節點，其中每個 TiDB 與 PD 為一組，共用一臺物理機。后續隨著業務增長或者新業務接入，再按需添加 TiKV 節點。

7.2 監控

監控采用了 TiDB 的提供的監控方案，并且也接入了公司開源的 Falcon，目前整個集群運行比較穩定，監控如圖 7。 ?????

圖 7? 監控圖

八、遇到的問題、原因及解決辦法

問題	原因及解決辦法
在一個 DDL 里不能對多個列或者多個索引做操作。	ADD/DROP INDEX/COLUMN 操作目前不支持同時創建或刪除多個索引或列，需要拆分單獨執行，官方表示 3.0 版本有計劃改進。
部分操作符查詢優化器支持不夠好，比如 or 操作符會使用 TableScan，改寫成 union all 可避免。	官方表示目前使用 or 操作符確實在執行計劃上有可能不準確，已經在改進計劃中，后續 3.0 版本會有優化。
重啟一個 PD 節點的時候，業務能捕捉到 PD 不可用的異常，會報 PD server timeout 。	因為重啟的是 Leader 節點，所以重啟之前需要手動切換 Leader，然后進行重啟。官方建議這里可以通過重啟前做 Leader 遷移來減緩，另外后續 TiDB 也會對網絡通訊相關參數進行梳理和優化。
建表語句執行速度相比 MySQL 較慢	多臺 TiDB 的時候，Owner 和接收 create table 語句的 TiDB Server 不在一臺 Server 上時，可能比 MySQL 慢一些，每次操作耗時在 0.5s 左右，官方表示會在后續的版本中不斷完善。
pd-ctl 命令行參數解析嚴格，多一個空格會提示語法錯誤。	官方表示低版本中可能會有這個問題，在 2.0.8 及以上版本已經改進。
tikv-ctl 命令手動 compact region 失敗。	在低版本中通常是因為 tikv-ctl 與集群版本不一致導致的，需要更換版本一致的 tikv-ctl，官方表示在 2.1 中已經修復。
大表建索引時對業務有影響	官方建議在業務低峰期操作，在 2.1 版本中已經增加了操作優先級以及并發讀的控制，情況有改善。
存儲空間放大問題	該問題屬于 RocksDB，RocksDB 的空間放大系數最理想的值為 1.111，官方建議在某些場景下通過 TiKV 開啟 RocksDB 的 dynamic-level-bytes 以減少空間放大。