TiDB 在小米的應用實踐

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

1、應用場景介紹

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

圖 1  MIUI Android 系統界面圖

目前 TiDB 主要應用在：

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

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

2、TiDB 特色

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

具備以下的特性：

• 高度兼容 MySQL，大多數狀況下無需修改代碼便可從 MySQL 輕鬆遷移至 TiDB，即便已經分庫分表的 MySQL 集羣亦可經過 TiDB 提供的遷移工具進行實時遷移。

• 水平彈性擴展，經過簡單地增長新節點便可實現 TiDB 的水平擴展，按需擴展吞吐或存儲，輕鬆應對高併發、海量數據場景。

• 分佈式事務，TiDB 100% 支持標準的 ACID 事務。

• 真正金融級高可用，相比於傳統主從（M-S）複製方案，基於 Raft 的多數派選舉協議能夠提供金融級的 100% 數據強一致性保證，且在不丟失大多數副本的前提下，能夠實現故障的自動恢復（auto-failover），無需人工介入。

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

圖 2  TiDB 基礎架構圖

3、背景

跟絕大數互聯網公司同樣，小米關係型存儲數據庫首選 MySQL，單機 2.6T 磁盤。因爲小米手機銷量的快速上升和 MIUI 負一屏用戶量的快速增長，致使負一屏快遞業務數據的數據量增加很是快，**天天的讀寫量級均分別達到上億級別，數據快速增加致使單機出現瓶頸，好比性能明顯降低、可用存儲空間不斷下降、大表 DDL 沒法執行等，不得不面臨數據庫擴展的問題。**好比，咱們有一個業務場景（智能終端），須要定時從幾千萬級的智能終端高頻的向數據庫寫入各類監控及採集數據，MySQL 基於 Binlog 的單線程複製模式，很容易形成從庫延遲，而且堆積愈來愈嚴重。

**對於 MySQL 來說，最直接的方案就是採用分庫分表的水平擴展方式，綜合來看並非最優的方案，好比對於業務來說，對業務代碼的侵入性較大；對於 DBA 來說提高管理成本，後續須要不斷的拆分擴容，即便有中間件也有必定的侷限性。**一樣是上面的智能終端業務場景，從業務需求看，須要從多個業務維度進行查詢，而且業務維度可能隨時進行擴展，分表的方案基本不能知足業務的需求。

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

4、兼容性對比

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 選項都是在解析後忽略。

• 詳細信息能夠訪問官網：pingcap.com/docs-cn/sql… 。

5、壓測

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 壓測圖

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

圖 4  標準 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 壓測圖

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

6、遷移過程

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

6.1 數據遷移

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

• 對於存量數據，可使用邏輯備份、導入的方式，除了傳統的邏輯導入外，官方還提供一款物理導入的工具 TiDB Lightning。

• 對於增量備份可使用 TiDB 提供的 Syncer （新版已經改名爲 DM - Data Migration）來保證數據同步。

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

圖 6  Syncer 結構圖

使用 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、集羣情況

7.1 配置

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

7.2 監控

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

圖 7  監控圖

8、遇到的問題、緣由及解決辦法

問題	緣由及解決辦法
在一個 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 以減小空間放大。

9、後續和展望

目前 TiDB 在小米主要提供 OLTP 服務，小米手機負一屏快遞業務爲使用 TiDB 作了一個良好的開端，然後商業廣告也有接入，2 個業務均已上線數月，TiDB 的穩定性經受住了考驗，帶來了很棒的體驗，對於後續大致的規劃以下：

• MIUI 生態業務中存在大量的相似場景的業務，後續將會與業務開發積極溝通，從 MySQL 遷移到 TiDB。

• 針對某些業務場景，以資源合理利用爲目標，推出歸檔集羣，利用 Syncer 實現數據歸檔的功能。

• 數據分析，結合 TiDB 提供的工具，將支持離線、實時數據分析支持。

• 將 TiDB 的監控融合到小米公司開源的監控系統 Falcon 中。

10、致謝

很是感謝 TiDB 官方在遷移及業務上線期間給予咱們的支持，爲每個 TiDB 人專業的精神、及時負責的響應點贊。

更多 TiDB 用戶實踐： www.pingcap.com/cases-cn/