蓋婭廣告匹配系統（GaeaAD）用於支撐蓋婭互娛全平臺實時廣告投放系統，需要將廣告數據和遊戲 SDK 上報的信息進行近實時匹配，本質上來說需要實時的根據各個渠道的廣告投放與相應渠道帶來的遊戲玩家數據進行計算，實現廣告轉化效果分鐘級別的展現及優化。
初期的 MySQL 存儲方案
在系統設計之初，基於對數據量的預估以及簡化實現方案考慮，我們選用了高可用的 MySQL RDS 存儲方案，當時的匹配邏輯主要通過 SQL 語句來實現，包含了很多聯表查詢和聚合操作。當數據量在千萬級別左右，系統運行良好，基本響應還在一分鐘內。
遭遇瓶頸，尋找解決方案
然而隨着業務的發展，越來越多遊戲的接入，蓋婭廣告系統系統接收數據很快突破千萬/日，高峯期每次參與匹配的數據量更是需要翻幾個番，數據庫成爲了業務的瓶頸。由於此時，整個技術架構出現了一些問題：
-
單次匹配耗時已從原本的 10 秒左右增加到 2 分鐘以上，最慢的聚合查詢甚至達到 20 分鐘，時效性受到嚴重挑戰。而且 MySQL 的問題是查詢的時間隨着數據量的增長而增長，以至於數據量越大的情況下查詢越慢。
-
隨着歷史數據的積累，單表數據很快達到億級別，此時單表的讀寫壓力已經接近極限。
-
由於第一點提到的查詢性能問題以及單機的容量限制，需要定時刪除數據，對於一些時間跨度較長的業務查詢需求沒法滿足。
根據數據量的增長情況來看，分佈式數據庫會是很好的解決方案。首先考慮的是業務的垂直及水平拆分或者基於 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 帶來的收益，主要有以下幾點：
-
用 3 個節點組成的 TiDB 集羣替換了原先的高可用 MySQL RDS 後，同樣數據量級下，單次匹配平均耗時從 2 分鐘以上降到了 30 秒左右，後續隨着 TiDB 工程師的持續優化，達到了10 秒左右。另外，我們發現，TiDB 在數據規模越大的情況下，對比 MySQL 的優勢就越明顯，應該是 TiDB 自研的分佈式 SQL 優化器帶來的優勢。不過在數據量比較輕量的情況下，因內部通信成本，優勢相比 MySQL 並不明顯。
TiDB 與 MySQL 在不同數據量下的查詢時間對比
-
TiDB 支持自動 Sharding，業務端不用切表操作，TiDB 也不需要像傳統的數據庫中間件產品設定 Sharding key 或者分區表什麼的，底層的存儲會自動根據數據的分佈，均勻的分散在集羣中，存儲空間和性能可以通過增加機器實現快速的水平擴展，極大地降低了運維成本。
-
TiDB 支持在線不中斷的滾動升級，至今直接在線升級已有 10 餘次左右，沒出現過一起導致線上服務中斷的情況，在可用性上體驗不錯。
4、TiDB 支持和 MySQL 的互備，這個功能很好的解決了我們業務遷移時候的過渡問題。
當前我們正在着手把 storm 集羣上的 BI 系統的實時計算業務的數據存儲系統從 MongoDB 替換成 TiDB（因 MongoDB 的使用門檻相對較高，運維成本大，查詢方式不如傳統的 SQL 靈活），後續也計劃把實時性要求高、數據存儲量大且存儲週期較長的業務都遷移到 TiDB 上來，看上去是一個比較合適的場景。
-
TiDB 工程師點評
蓋婭的業務使用 TiDB 做了如下優化：
-
支持更多表達式下推，充分利用 TiKV 多實例的計算資源，加快計算速度；同時也儘可能將不需要用到的數據過濾掉，減小網絡傳輸。
-
TiDB 默認支持 HashJoin，將算子儘可能並行化，能夠利用整個集羣的計算資源。
-
TiDB 採用流水線的方式讀取數據，並且優化過 IndexScan 算子，降低整個流程的啓動時間。