TiDB 助力卡思數據視頻大數據業務創新

做者：劉廣信，火星文化技術經理

卡思數據是國內領先的視頻全網數據開放平臺，依託領先的數據挖掘與分析能力，爲視頻內容創做者在節目創做和用戶運營方面提供數據支持，爲廣告主的廣告投放提供數據參考和效果監測，爲內容投資提供全面客觀的價值評估。

<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 億，有比較複雜的連表查詢，總體響應延時很是穩定，監控展現如圖 四、圖 5。

<center>圖 4 Duration 監控展現圖</center>

<center>圖 5 QPS 監控展現圖</center>

將來展望

目前的卡思數據已所有遷移至 TiDB，但對 TiDB 的使用還侷限在數據存儲上，能夠說只實現了 OLTP。卡思數據準備深刻了解 OLAP，將目前一些須要實時返回的複雜查詢、數據分析下推至 TiDB。既減小計算服務的複雜性，又可增長數據的準確性。

感謝 PingCAP

很是感謝 PingCAP 小夥伴們在數據庫上線過程當中的大力支持，每次遇到困難都能及時、細心的給予指導，很是的專業和熱心。相信 PingCAP 會愈來愈好，相信 TiDB 會愈來愈完善，引領 NewSQL 的發展。