TiDB 助力卡思資料視訊大資料業務創新
作者：劉廣信，火星文化技術經理
卡思資料是國內領先的視訊全網資料開放平臺，依託領先的資料探勘與分析能力，為視訊內容創作者在節目創作和使用者運營方面提供資料支援，為廣告主的廣告投放提供資料參考和效果監測，為內容投資提供全面客觀的價值評估。
業務發展遇到的痛點
卡思資料首先通過分散式爬蟲系統進行資料抓取，每天新增資料量在 50G - 80G 之間，並且入庫時間要求比較短，因此對資料庫寫入效能要求很高，由於資料增長比較快，對資料庫的擴充套件性也有很高的要求。資料抓取完成後，對資料進行清洗和計算，因為資料量比較大，單表 5 億 + 條資料，所以對資料庫的查詢效能要求很高。
起初卡思資料採用的是多個 MySQL 例項和一個 MongoDB 叢集，如圖 2。
-
MySQL 儲存業務相關資料，直接面向用戶，對事務的要求很高，但在海量資料儲存方面偏弱，由於單行較大，單表資料超過千萬或 10G 效能就會急劇下降。
-
MongoDB 儲存最小單元的資料，MongoDB 有更好的寫入效能，保證了每天資料爬取儲存速度；對海量資料儲存上，MongoDB 內建的分片特性，可以很好的適應大資料量的需求。
但是隨著業務發展，暴露出一些問題。
-
MySQL 在大資料量的場景下，查詢效能難以滿足要求，並且擴充套件能力偏弱，如果採用分庫分表方式，需要對業務程式碼進行全面改造，成本非常高。
-
MongoDB 對複雜事務的不支援，前臺業務需要用到資料元及連表查詢，當前架構支援的不太友好。
架構優化
1. 需求
針對我們遇到的問題，我們急需這樣一款資料庫：
-
相容 MySQL 協議，資料遷移成本和程式碼改造成本低
-
插入效能強
-
大資料量下的實時查詢效能強，無需分庫分表
-
水平擴充套件能力強
-
穩定性強，產品最好有成熟的案例
2. 方案調研
未選擇 TiDB 之前我們調研了幾個資料庫，Greenplum、HybirdDB for MySQL（PetaData）以及 PolarDB。Greenplum 由於插入效能比較差，並且跟 MySQL 協議有一些不相容，首先被排除。
HybirdDB for MySQL 是阿里雲推出的 HTAP 關係型資料庫，我們在試用一段時間發現一些問題：
-
一是複雜語句導致計算引擎擁堵，阻塞所有業務，經常出現查詢超時的情況。
-
二是連表查詢效能低下，網路 I/O 出現瓶頸。舉一個常見的關聯查詢，cd_video 表，2200 萬資料，cd_program_video 表，節目和視訊的關聯表，4700 萬資料，在關聯欄位上都建有索引，如下 SQL：
select v.id,v.url,v.extra_id,v.title fromcd_video v join cd_program_video pv on v.id = pv.video_id where program_id =xxx；
當相同查詢併發超過一定數量時，就會頻繁報資料庫計算資源不可用的錯誤。
-
三是 DDL 操作比較慢，該欄位等操作基本需要幾分鐘，下發至節點後易出現死鎖。
PolarDB 是阿里雲新推出新一代關係型資料庫，主要思想是計算和儲存分離架構，使用共享儲存技術。由於寫入還是單點寫入，插入效能有上限，未來我們的資料採集規模還會進一步提升，這有可能成為一個瓶頸。另外由於只有一個只讀例項，在對大表進行併發查詢時效能表現一般。
3. 選擇 TiDB
在經歷了痛苦的傳統解決方案的折磨以及大量調研及對比後，卡思資料最終選擇了 TiDB 作為資料倉庫及業務資料庫。
TiDB 結合了傳統的 RDBMS 和 NoSQL 的最佳特性，高度相容 MySQL，具備強一致性和高可用性，100% 支援標準的 ACID 事務。由於是 Cloud Native 資料庫，可通過平行計算發揮機器效能，在大數量的查詢下效能表現良好，並且支援無限的水平擴充套件，可以很方便的通過加機器解決效能和容量問題。另外提供了非常完善的運維工具，大大減輕資料庫的運維工作。
上線 TiDB
卡思資料目前配置了兩個 32C64G 的 TiDB、三個 4C16G 的 PD、四個 32C128G 的 TiKV。資料量大約 60 億條、4TB 左右，每天新增資料量大約 5000 萬，單節點 QPS 峰值為 3000 左右。
由於資料遷移不能影響線上業務，卡思資料在保持繼續使用原資料架構的前提下，使用 Mydumper、Loader 進行資料遷移，並在首輪資料遷移完成後使用 Syncer 進行增量同步。
卡思資料部署了資料庫監控系統（Prometheus/Grafana）來實時監控服務狀態，可以非常清晰的檢視伺服器問題。
由於 TiDB 對 MySQL 的高度相容性，在資料遷移完成後，幾乎沒有對程式碼做任何修改，平滑實現了無侵入升級。
目前卡思資料的架構如圖 3：
查詢效能，單表最小 1000 萬，最大 8 億，有比較複雜的連表查詢，整體響應延時非常穩定，監控展示如圖 4、圖 5。
未來展望
目前的卡思資料已全部遷移至 TiDB，但對 TiDB 的使用還侷限在資料儲存上，可以說只實現了 OLTP。卡思資料準備深入瞭解 OLAP，將目前一些需要實時返回的複雜查詢、資料分析下推至 TiDB。既減少計算服務的複雜性，又可增加資料的準確性。
感謝 PingCAP
非常感謝 PingCAP 小夥伴們在資料庫上線過程中的大力支援，每次遇到困難都能及時、細心的給予指導，非常的專業和熱心。相信 PingCAP 會越來越好，相信 TiDB 會越來越完善，引領 NewSQL 的發展。
