日均數據量千萬級，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 集羣，完成平滑的上線。

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

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

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

1. TiDB 支持自動 Sharding，業務端不用切表操做，TiDB 也不須要像傳統的數據庫中間件產品設定 Sharding key 或者分區表什麼的，底層的存儲會自動根據數據的分佈，均勻的分散在集羣中，存儲空間和性能能夠經過增長機器實現快速的水平擴展，極大地下降了運維成本。

2. TiDB 支持在線不中斷的滾動升級，至今直接在線升級已有 10 餘次左右，沒出現過一塊兒致使線上服務中斷的狀況，在可用性上體驗不錯。
   四、TiDB 支持和 MySQL 的互備，這個功能很好的解決了咱們業務遷移時候的過渡問題。

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

• TiDB 工程師點評

蓋婭的業務使用 TiDB 作了以下優化：

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

2. TiDB 默認支持 HashJoin，將算子儘量並行化，可以利用整個集羣的計算資源。

3. TiDB 採用流水線的方式讀取數據，而且優化過 IndexScan 算子，下降整個流程的啓動時間。

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