日均數據量千萬級，MySQL、TiDB 兩種存儲方案的落地對比

蓋婭廣告匹配系統（GaeaAD）用於支撐蓋婭互娛全平台實時廣告投放系統，需要將廣告數據和遊戲 SDK 上報的信息進行近實時匹配，本質上來說需要實時的根據各個渠道的廣告投放與相應渠道帶來的遊戲玩家數據進行計算，實現廣告轉化效果分鐘級別的展現及優化。

初期的 MySQL 存儲方案

在系統設計之初，基於對數據量的預估以及簡化實現方案考慮，我們選用了高可用的 MySQL RDS 存儲方案，當時的匹配邏輯主要通過 SQL 語句來實現，包含了很多聯表查詢和聚合操作。當數據量在千萬級別左右，系統運行良好，基本響應還在一分鐘內。

遭遇瓶頸，尋找解決方案

然而隨著業務的發展，越來越多遊戲的接入，蓋婭廣告系統系統接收數據很快突破千萬/日，高峰期每次參與匹配的數據量更是需要翻幾個番，資料庫成為了業務的瓶頸。由於此時，整個技術架構出現了一些問題：

1. 單次匹配耗時已從原本的 10 秒左右增加到 2 分鐘以上，最慢的聚合查詢甚至達到 20 分鐘，時效性受到嚴重挑戰。而且 MySQL 的問題是查詢的時間隨著數據量的增長而增長，以至於數據量越大的情況下查詢越慢。

2. 隨著歷史數據的積累，單表數據很快達到億級別，此時單表的讀寫壓力已經接近極限。

3. 由於第一點提到的查詢性能問題以及單機的容量限制，需要定時刪除數據，對於一些時間跨度較長的業務查詢需求沒法滿足。

根據數據量的增長情況來看，分散式資料庫會是很好的解決方案。首先考慮的是業務的垂直及水平拆分或者基於 MySQL 的資料庫中間件方案和一些主流的 NoSQL 方案。

但是仔細評估後，最先排除掉的是業務水平拆分的方案，因為業務邏輯中包含大量的關聯查詢和子查詢，如果拆表後這些查詢邏輯就沒有辦法透明的兼容，而且是比較核心的業務系統，時間精力的關係也不允許整體做大的重構。中間件的問題和分庫分表的問題類似，雖然解決了大容量存儲和實時寫入的問題，但是查詢的靈活度受限，而且多個 MySQL 實例的維護成本也需要考慮。

第二個方案就是採用 NoSQL，因為此系統需要接收業務端並發的實時寫入和實時查詢，所以使用類似 Greenplum，Hive 或者 SparkSQL 這樣的系統不太合適，因為這幾個系統並不是針對實時寫入設計的， MongoDB 的問題是文檔型的查詢訪問介面對業務的修改太大，而且 MongoDB 是否能滿足在這麼大數據量下高效的聚合分析可能是一個問題。

所以很明顯，我們當時的訴求就是能有一款資料庫既能像 MySQL 一樣便於使用，最好能讓業務幾乎不用做任何修改，又能滿足分散式的存儲需求，還要保證很高的複雜查詢性能。

當時調研了一下社區的分散式資料庫解決方案，找到了 TiDB 這個項目，因為協議層兼容 MySQL，而且對於複雜查詢的支持不錯，業務代碼完全不用修改直接就能使用，使遷移使用成本降到極低。

技術轉身，使用 TiDB

在部署測試的過程中，我們使用 TiDB 提供的 Syncer 工具將 TiDB 作為 MySQL Slave 接在原業務的 MySQL 主庫後邊觀察，確保讀寫的兼容性以及穩定性，經過一段時間觀察後，確認讀寫沒有任何問題，業務層的讀請求切換至 TiDB，隨後把寫的流量也切換至 TiDB 集群，完成平滑的上線。

GaeaADn系統從 2016 年 10 月上線以來，已經穩定運行了一季度多，結合實際的使用體驗，我們總結了 TiDB 帶來的收益，主要有以下幾點：

1. 用 3 個節點組成的 TiDB 集群替換了原先的高可用 MySQL RDS 後，同樣數據量級下，單次匹配平均耗時從 2 分鐘以上降到了 30 秒左右，後續隨著 TiDB 工程師的持續優化，達到了10 秒左右。另外，我們發現，TiDB 在數據規模越大的情況下，對比 MySQL 的優勢就越明顯，應該是 TiDB 自研的分散式 SQL 優化器帶來的優勢。不過在數據量比較輕量的情況下，因內部通信成本，優勢相比 MySQL 並不明顯。

TiDB 與 MySQL 在不同數據量下的查詢時間對比

2. TiDBn支持自動 Sharding，業務端不用切表操作，TiDB 也不需要像傳統的資料庫中間件產品設定 Sharding key 或者分區表什麼的，底層的存儲會自動根據數據的分布，均勻的分散在集群中，存儲空間和性能可以通過增加機器實現快速的水平擴展，極大地降低了運維成本。

3. TiDBn支持在線不中斷的滾動升級，至今直接在線升級已有 10 余次左右，沒出現過一起導致線上服務中斷的情況，在可用性上體驗不錯。

4. TiDBn支持和 MySQL 的互備，這個功能很好的解決了我們業務遷移時候的過渡問題。

當前我們正在著手把 storm 集群上的 BI 系統的實時計算業務的數據存儲系統從 MongoDB 替換成 TiDB（因 MongoDB 的使用門檻相對較高，運維成本大，查詢方式不如傳統的 SQL 靈活），後續也計劃把實時性要求高、數據存儲量大且存儲周期較長的業務都遷移到 TiDB 上來，看上去是一個比較合適的場景。

TiDB 工程師點評

蓋婭的業務使用 TiDB 做了如下優化：

1. 支持更多表達式下推，充分利用 TiKV 多實例的計算資源，加快計算速度；同時也儘可能將不需要用到的數據過濾掉，減小網路傳輸。

2. TiDB 默認支持 HashJoin，將運算元儘可能並行化，能夠利用整個集群的計算資源。

3. TiDB 採用流水線的方式讀取數據，並且優化過 IndexScan 運算元，降低整個流程的啟動時間。

作者簡介：劉玄，蓋婭互娛數據平台高級開發工程師，主要負責實時數據業務和數據流方向。畢業於湖南大學軟體工程系，曾任百度高級運維工程師，負責大搜建庫運維。