【TIDB】四、業界使用狀況

1、小米

一、背景

小米關係型存儲數據庫首選 MySQL，單機 2.6T 磁盤。因爲小米手機銷量的快速上升和 MIUI 負一屏用戶量的快速增長，致使負一屏快遞業務數據的數據量增加很是快， 天天的讀寫量級均分別達到上億級別，數據快速增加致使單機出現瓶頸，好比性能明顯降低、可用存儲空間不斷下降、大表 DDL 沒法執行等，不得不面臨數據庫擴展的問題。

對於 MySQL 來說，最直接的方案就是採用分庫分表的水平擴展方式，綜合來看並非最優的方案，好比對於業務來說，對業務代碼的侵入性較大；對於 DBA 來說提高管理成本，後續須要不斷的拆分擴容，即便有中間件也有必定的侷限性

二、遷移過程

整個遷移分爲 2 大塊：

數據遷移

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

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

流量遷移

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

• 讀流量切換到 TiDB，這個過程當中回滾比較簡單，灰度無問題，則全量切換。

• 再將寫入切換到 TiDB，須要考慮好數據回滾方案或者採用雙寫的方式（須要斷掉 Syncer）。

 2、美團點評

對於初期上線的業務，咱們比較謹慎，基本的原則是：離線業務 -> 非核心業務 -> 核心業務

一、寫入量大、讀 QPS 高的離線業務

1.一、如今 TiDB 的 GC 對於每一個 kv-instance 是單線程的，當業務刪除數據的量很是大時，會致使 GC 速度較慢，極可能 GC 的速度跟不上寫入。目前能夠經過增多 TiKV 個數來解決，長期須要靠 GC 改成多線程執行

1.二、Insert 響應時間愈來愈慢。業務上線初期，insert 的響應時間 80 線（Duration 80 By Instance）在 20ms 左右，隨着運行時間增長，發現響應時間逐步增長到 200ms+。期間排查了多種可能緣由，定位在因爲 Region 數量快速上漲，Raftstore 裏面要作的事情變多了，而它又是單線程工做，每一個 Region 按期都要 heartbeat，帶來了性能消耗

臨時解決：增長 Heartbeat 的週期，從 1s 改成 2s，效果比較明顯

完全解決：須要減小 Region 個數，Merge 掉空 Region，官方在 2.1 版本中已經實現了 Region Merge 功能，咱們在升級到 2.1 後，獲得了完全解決

              另外，等待 Raftstore 改成多線程，能進一步優化

二、在線 OLTP，對響應時間敏感的業務

執行計劃偶爾不許

3、摩拜單車

一、場景一：開關鎖日誌成功率統計

按照咱們的估計，這個業務一年的量在數百億

• 使用單機的 MySQL 庫須要頻繁的進行歸檔
• 特別是遇到單機數據庫瓶頸的狀況下，擴容更是帶來了很是大的挑戰
• 其次，根據咱們以前使用分庫分表的經驗，對於這類須要頻繁更新表結構進行 DDL 操做的業務，一旦數據量過大，很很容易出現數據庫假死的狀況，不只影響服務的可用性，更嚴重的是極可能致使數據不一致的狀況出現

最終經過對比分析，咱們選擇了 TiDB 做爲開關鎖日誌成功率統計項目的支撐數據庫

二、場景二：實時在線 OLTP 業務

因爲是典型 OLTP 場景，可選項並很少，並且數據量增加極快，這些數據庫的數據在一年內輕鬆達到數百億量級。這些場景在咱們有了 TiDB 的使用經驗之後，發現 TiDB 的全部特性都很是契合這種海量高併發的 OLTP 場景。TiDB 的容量/併發可隨意擴展的特性不在贅述，支持在線 DDL 這個特性特別適合這些業務，有須要業務更改不會阻塞業務，這是咱們業務快速迭代比較須要的特性。

目前，這兩個在線 OLTP 集羣擁有數十個節點，百億級數據，上線之後很是穩定，PingCAP 客戶支持團隊也協助咱們進行該集羣的平常運維工做。

 三、訂單集羣（P0 級業務）

TiDB 合庫做爲 readonly 負責其餘多維度的查詢

TiDB 的出現，不只彌補了 MySQL 單機容量上限、傳統 Sharding 方案查詢維度單一等缺點，並且其計算存儲分離的架構設計讓集羣水平擴展變得更容

4、頭條

一、活動場景

忽然接了一個元旦的活動，這個時候上傳的圖片就比較多，數據增加的就太大了，這種活動中 S3 系統壓力比較大。咱們 MySQL 的單盤基本上穩定的在 2.0TB 以上（盤總計 2.8TB），對此咱們就只能刪數據（一些很老的數據），跟業務部門溝通說，這個數據不要了，從 MySQL 的單盤裏刪掉，經過這種方式來支撐。

但即便這麼作，單盤仍是扛不住如今數據增加的需求。而後當時就想幹脆激進點，把一些寫進來後當即就讀、而且之後都不會讀的一些流量切到 TiDB 裏。由於 S3 存儲分不少 bucket ，作活動的人就去新建一些 bucket， 這些 bucket 的元數據就直接存在 TiDB 裏面，就不存 MySQL 了。

二、遇到的問題

Row id 的打散。這個問題正好是咱們這邊碰到的一個性能上的問題。由於 TiDB 存儲數據是這麼存的：我要插入一行數據，他會有兩行，第一行是索引，索引是 Key ，而後 value 是 row id；第二行是 row id 是 Key，value 是整行的數據，至關於第二行有點像彙集索引這種東西。可是這個彙集索引的 Key 是 row id。原來的版本實現上是說這個 row id 是個遞增了，因此這種就致使無論你插入什麼數據，這個 row id 都是遞增的，由於 row id 一遞增，這些數據都會打到一個 TiKV 的一個 region 上面。由於個人 TiKV 是一個有序的 Map，因此說 row id 若是遞增的話，確定你們插入的時候都是打到一個 TiKV 上面。咱們當時業務的壓力比較大，致使客戶發現他把這個業務的機器實例數給擴容上去以後，會發現這個 insert 的 TPS 大概也就在兩萬，一行大概就一百多個字節吧，你再怎麼加他上不去了，也就是說 insert 的這個 QPS 上不去了。

這一點 TiDB 新版本的方案就是，row id 不是單調遞增，而是把 row id 打的很散，這種方案性能會比較好，沒有熱點。

 

內容出處：

https://www.pingcap.com/cases-cn/