一、小米
1、背景
小米關系型存儲數據庫首選 MySQL，單機 2.6T 磁盤。由於小米手機銷量的快速上升和 MIUI 負一屏用戶量的快速增加，導致負一屏快遞業務數據的數據量增長非常快， 每天的讀寫量級均分別達到上億級別，數據快速增長導致單機出現瓶頸，比如性能明顯下降、可用存儲空間不斷降低、大表 DDL 無法執行等，不得不面臨數據庫擴展的問題。
對於 MySQL 來講，最直接的方案就是采用分庫分表的水平擴展方式，綜合來看並不是最優的方案，比如對於業務來講，對業務代碼的侵入性較大；對於 DBA 來講提升管理成本，后續需要不斷的拆分擴容，即使有中間件也有一定的局限性
2、遷移過程
整個遷移分為 2 大塊：
數據遷移
-
對於存量數據，可以使用邏輯備份、導入的方式，除了傳統的邏輯導入外，官方還提供一款物理導入的工具 TiDB Lightning。
-
對於增量備份可以使用 TiDB 提供的 Syncer （新版已經更名為 DM - Data Migration）來保證數據同步。
流量遷移
流量切換到 TiDB 分為兩部分：讀、寫流量遷移。每次切換保證灰度過程，觀察周期為 1~2 周，做好回滾措施。
-
讀流量切換到 TiDB，這個過程中回滾比較簡單，灰度無問題，則全量切換。
-
再將寫入切換到 TiDB，需要考慮好數據回滾方案或者采用雙寫的方式（需要斷掉 Syncer）。
二、美團點評
對於初期上線的業務，我們比較謹慎，基本的原則是：離線業務 -> 非核心業務 -> 核心業務
1、寫入量大、讀 QPS 高的離線業務
1.1、現在 TiDB 的 GC 對於每個 kv-instance 是單線程的，當業務刪除數據的量非常大時，會導致 GC 速度較慢，很可能 GC 的速度跟不上寫入。目前可以通過增多 TiKV 個數來解決，長期需要靠 GC 改為多線程執行
1.2、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 改為多線程，能進一步優化
2、在線 OLTP，對響應時間敏感的業務
執行計划偶爾不准
三、摩拜單車
1、場景一：開關鎖日志成功率統計
按照我們的估計，這個業務一年的量在數百億
- 使用單機的 MySQL 庫需要頻繁的進行歸檔
- 特別是遇到單機數據庫瓶頸的情況下，擴容更是帶來了非常大的挑戰
- 其次，根據我們之前使用分庫分表的經驗，對於這類需要頻繁更新表結構進行 DDL 操作的業務，一旦數據量過大，很很容易出現數據庫假死的情況，不僅影響服務的可用性，更嚴重的是很可能導致數據不一致的情況出現
最終通過對比分析，我們選擇了 TiDB 作為開關鎖日志成功率統計項目的支撐數據庫
2、場景二：實時在線 OLTP 業務
由於是典型 OLTP 場景，可選項並不多，而且數據量增長極快，這些數據庫的數據在一年內輕松達到數百億量級。這些場景在我們有了 TiDB 的使用經驗以后，發現 TiDB 的所有特性都非常契合這種海量高並發的 OLTP 場景。TiDB 的容量/並發可隨意擴展的特性不在贅述，支持在線 DDL 這個特性特別適合這些業務，有需要業務更改不會阻塞業務，這是我們業務快速迭代比較需要的特性。
目前，這兩個在線 OLTP 集群擁有數十個節點，百億級數據，上線以后非常穩定，PingCAP 客戶支持團隊也協助我們進行該集群的日常運維工作。
3、訂單集群（P0 級業務）
TiDB 合庫作為 readonly 負責其他多維度的查詢
TiDB 的出現，不僅彌補了 MySQL 單機容量上限、傳統 Sharding 方案查詢維度單一等缺點，而且其計算存儲分離的架構設計讓集群水平擴展變得更容
四、頭條
1、活動場景
突然接了一個元旦的活動，這個時候上傳的圖片就比較多，數據增長的就太大了，這種活動中 S3 系統壓力比較大。我們 MySQL 的單盤基本上穩定的在 2.0TB 以上（盤總計 2.8TB），對此我們就只能刪數據（一些很老的數據），跟業務部門溝通說，這個數據不要了，從 MySQL 的單盤里刪掉，通過這種方式來支撐。
但即使這么做，單盤還是扛不住現在數據增長的需求。然后當時就想干脆激進點，把一些寫進來后立即就讀、並且以后都不會讀的一些流量切到 TiDB 里。因為 S3 存儲分很多 bucket ，做活動的人就去新建一些 bucket， 這些 bucket 的元數據就直接存在 TiDB 里面，就不存 MySQL 了。
2、遇到的問題
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 打的很散，這種方案性能會比較好，沒有熱點。
內容出處：