MySQL、TiDB 兩種存儲方案對比，日均數(shù)據(jù)量千萬級
初期的 MySQL 存儲方案
在系統(tǒng)設計之初，基于對數(shù)據(jù)量的預估以及簡化實現(xiàn)方案考慮，我們選用了高可用的 MySQL RDS 存儲方案，當時的匹配邏輯主要通過 SQL 語句來實現(xiàn)，包含了很多聯(lián)表查詢和聚合操作。當數(shù)據(jù)量在千萬級別左右，系統(tǒng)運行良好，基本響應還在一分鐘內。
遭遇瓶頸，尋找解決方案
然而隨著業(yè)務的發(fā)展，越來越多游戲的接入，蓋婭廣告系統(tǒng)系統(tǒng)接收數(shù)據(jù)很快突破千萬/日，高峰期每次參與匹配的數(shù)據(jù)量更是需要翻幾個番，數(shù)據(jù)庫成為了業(yè)務的瓶頸。由于此時，整個技術架構出現(xiàn)了一些問題：
單次匹配耗時已從原本的 10 秒左右增加到 2 分鐘以上，最慢的聚合查詢甚至達到 20 分鐘，時效性受到嚴重挑戰(zhàn)。而且 MySQL 的問題是查詢的時間隨著數(shù)據(jù)量的增長而增長，以至于數(shù)據(jù)量越大的情況下查詢越慢。
隨著歷史數(shù)據(jù)的積累，單表數(shù)據(jù)很快達到億級別，此時單表的讀寫壓力已經(jīng)接近極限。
由于第一點提到的查詢性能問題以及單機的容量限制，需要定時刪除數(shù)據(jù)，對于一些時間跨度較長的業(yè)務查詢需求沒法滿足。
根據(jù)數(shù)據(jù)量的增長情況來看，分布式數(shù)據(jù)庫會是很好的解決方案。首先考慮的是業(yè)務的垂直及水平拆分或者基于 MySQL 的數(shù)據(jù)庫中間件方案和一些主流的 NoSQL 方案。
但是仔細評估后，最先排除掉的是業(yè)務水平拆分的方案，因為業(yè)務邏輯中包含大量的關聯(lián)查詢和子查詢，如果拆表后這些查詢邏輯就沒有辦法透明的兼容，而且是比較核心的業(yè)務系統(tǒng)，時間精力的關系也不允許整體做大的重構。中間件的問題和分庫分表的問題類似，雖然解決了大容量存儲和實時寫入的問題，但是查詢的靈活度受限，而且多個 MySQL 實例的維護成本也需要考慮。
第二個方案就是采用 NoSQL，因為此系統(tǒng)需要接收業(yè)務端并發(fā)的實時寫入和實時查詢，所以使用類似 Greenplum，Hive 或者 SparkSQL 這樣的系統(tǒng)不太合適，因為這幾個系統(tǒng)并不是針對實時寫入設計的， MongoDB 的問題是文檔型的查詢訪問接口對業(yè)務的修改太大，而且 MongoDB 是否能滿足在這么大數(shù)據(jù)量下高效的聚合分析可能是一個問題。
所以很明顯，我們當時的訴求就是能有一款數(shù)據(jù)庫既能像 MySQL 一樣便于使用，最好能讓業(yè)務幾乎不用做任何修改，又能滿足分布式的存儲需求，還要保證很高的復雜查詢性能。
當時調研了一下社區(qū)的分布式數(shù)據(jù)庫解決方案，找到了 TiDB 這個項目，因為協(xié)議層兼容 MySQL，而且對于復雜查詢的支持不錯，業(yè)務代碼完全不用修改直接就能使用，使遷移使用成本降到極低。
技術轉身，使用 TiDB
在部署測試的過程中，我們使用 TiDB 提供的 Syncer 工具將 TiDB 作為 MySQL Slave 接在原業(yè)務的 MySQL 主庫后邊觀察，確保讀寫的兼容性以及穩(wěn)定性，經(jīng)過一段時間觀察后，確認讀寫沒有任何問題，業(yè)務層的讀請求切換至 TiDB，隨后把寫的流量也切換至 TiDB 集群，完成平滑的上線。
GaeaAD 系統(tǒng)從 2016 年 10 月上線以來，已經(jīng)穩(wěn)定運行了一季度多，結合實際的使用體驗，我們總結了 TiDB 帶來的收益，主要有以下幾點：
用 3 個節(jié)點組成的 TiDB 集群替換了原先的高可用 MySQL RDS 后，同樣數(shù)據(jù)量級下，單次匹配平均耗時從 2 分鐘以上降到了 30 秒左右，后續(xù)隨著 TiDB 工程師的持續(xù)優(yōu)化，達到了10 秒左右。另外，我們發(fā)現(xiàn)，TiDB 在數(shù)據(jù)規(guī)模越大的情況下，對比 MySQL 的優(yōu)勢就越明顯，應該是 TiDB 自研的分布式 SQL 優(yōu)化器帶來的優(yōu)勢。不過在數(shù)據(jù)量比較輕量的情況下，因內部通信成本，優(yōu)勢相比 MySQL 并不明顯。
TiDB 與 MySQL 在不同數(shù)據(jù)量下的查詢時間對比
TiDB 支持自動 Sharding，業(yè)務端不用切表操作，TiDB 也不需要像傳統(tǒng)的數(shù)據(jù)庫中間件產品設定 Sharding key 或者分區(qū)表什么的，底層的存儲會自動根據(jù)數(shù)據(jù)的分布，均勻的分散在集群中，存儲空間和性能可以通過增加機器實現(xiàn)快速的水平擴展，極大地降低了運維成本。
TiDB 支持在線不中斷的滾動升級，至今直接在線升級已有 10 余次左右，沒出現(xiàn)過一起導致線上服務中斷的情況，在可用性上體驗不錯。
4、TiDB 支持和 MySQL 的互備，這個功能很好的解決了我們業(yè)務遷移時候的過渡問題。
當前我們正在著手把 storm 集群上的 BI 系統(tǒng)的實時計算業(yè)務的數(shù)據(jù)存儲系統(tǒng)從 MongoDB 替換成 TiDB（因 MongoDB 的使用門檻相對較高，運維成本大，查詢方式不如傳統(tǒng)的 SQL 靈活），后續(xù)也計劃把實時性要求高、數(shù)據(jù)存儲量大且存儲周期較長的業(yè)務都遷移到 TiDB 上來，看上去是一個比較合適的場景。
TiDB 工程師點評
蓋婭的業(yè)務使用 TiDB 做了如下優(yōu)化：
支持更多表達式下推，充分利用 TiKV 多實例的計算資源，加快計算速度；同時也盡可能將不需要用到的數(shù)據(jù)過濾掉，減小網(wǎng)絡傳輸。
TiDB 默認支持 HashJoin，將算子盡可能并行化，能夠利用整個集群的計算資源。
TiDB 采用流水線的方式讀取數(shù)據(jù)，并且優(yōu)化過 IndexScan 算子，降低整個流程的啟動時間。
