作者：劉廣信，火星文化技術經理
卡思數據是國內領先的視頻全網數據開放平臺，依託領先的數據挖掘與分析能力，爲視頻內容創作者在節目創作和用戶運營方面提供數據支持，爲廣告主的廣告投放提供數據參考和效果監測，爲內容投資提供全面客觀的價值評估。
<center>圖 1 卡思數據產品展示圖</center>
業務發展遇到的痛點
卡思數據首先通過分佈式爬蟲系統進行數據抓取，每天新增數據量在 50G - 80G 之間，並且入庫時間要求比較短，因此對數據庫寫入性能要求很高，由於數據增長比較快，對數據庫的擴展性也有很高的要求。數據抓取完成後，對數據進行清洗和計算，因爲數據量比較大，單表 5 億 + 條數據，所以對數據庫的查詢性能要求很高。
起初卡思數據採用的是多個 MySQL 實例和一個 MongoDB 集羣，如圖 2。
- MySQL 存儲業務相關數據，直接面向用戶，對事務的要求很高，但在海量數據存儲方面偏弱，由於單行較大，單表數據超過千萬或 10G 性能就會急劇下降。
- MongoDB 存儲最小單元的數據，MongoDB 有更好的寫入性能，保證了每天數據爬取存儲速度；對海量數據存儲上，MongoDB 內建的分片特性，可以很好的適應大數據量的需求。
<center>圖 2 起初卡思數據架構圖</center>
但是隨着業務發展，暴露出一些問題。
- 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：
<center>圖 3 目前卡思數據架構圖</center>
查詢性能，單表最小 1000 萬，最大 8 億，有比較複雜的連表查詢，整體響應延時非常穩定，監控展示如圖 4、圖 5。
<center>圖 4 Duration 監控展示圖</center>
<center>圖 5 QPS 監控展示圖</center>
未來展望
目前的卡思數據已全部遷移至 TiDB，但對 TiDB 的使用還侷限在數據存儲上，可以說只實現了 OLTP。卡思數據準備深入瞭解 OLAP，將目前一些需要實時返回的複雜查詢、數據分析下推至 TiDB。既減少計算服務的複雜性，又可增加數據的準確性。
感謝 PingCAP
非常感謝 PingCAP 小夥伴們在數據庫上線過程中的大力支持，每次遇到困難都能及時、細心的給予指導，非常的專業和熱心。相信 PingCAP 會越來越好，相信 TiDB 會越來越完善，引領 NewSQL 的發展。
