摘要：選擇在經歷了痛苦的傳統解決方案的折磨以及大量調研及對比后，卡思數據最終選擇了作為數據倉庫及業務數據庫。上線卡思數據目前配置了兩個的三個的四個的。卡思數據部署了數據庫監控系統來實時監控服務狀態，可以非常清晰的查看服務器問題。

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

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

卡思數據首先通過分布式爬蟲系統進行數據抓取，每天新增數據量在 50G - 80G 之間，并且入庫時間要求比較短，因此對數據庫寫入性能要求很高，由于數據增長比較快，對數據庫的擴展性也有很高的要求。數據抓取完成后，對數據進行清洗和計算，因為數據量比較大，單表 5 億 + 條數據，所以對數據庫的查詢性能要求很高。

起初卡思數據采用的是多個 MySQL 實例和一個 MongoDB 集群，如圖 2。

MySQL 存儲業務相關數據，直接面向用戶，對事務的要求很高，但在海量數據存儲方面偏弱，由于單行較大，單表數據超過千萬或 10G 性能就會急劇下降。

MongoDB 存儲最小單元的數據，MongoDB 有更好的寫入性能，保證了每天數據爬取存儲速度；對海量數據存儲上，MongoDB 內建的分片特性，可以很好的適應大數據量的需求。

但是隨著業務發展，暴露出一些問題。

MySQL 在大數據量的場景下，查詢性能難以滿足要求，并且擴展能力偏弱，如果采用分庫分表方式，需要對業務代碼進行全面改造，成本非常高。

MongoDB 對復雜事務的不支持，前臺業務需要用到數據元及連表查詢，當前架構支持的不太友好。

針對我們遇到的問題，我們急需這樣一款數據庫：

兼容 MySQL 協議，數據遷移成本和代碼改造成本低

插入性能強

大數據量下的實時查詢性能強，無需分庫分表

水平擴展能力強

穩定性強，產品最好有成熟的案例

未選擇 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 是阿里云新推出新一代關系型數據庫，主要思想是計算和存儲分離架構，使用共享存儲技術。由于寫入還是單點寫入，插入性能有上限，未來我們的數據采集規模還會進一步提升，這有可能成為一個瓶頸。另外由于只有一個只讀實例，在對大表進行并發查詢時性能表現一般。

在經歷了痛苦的傳統解決方案的折磨以及大量調研及對比后，卡思數據最終選擇了 TiDB 作為數據倉庫及業務數據庫。

TiDB 結合了傳統的 RDBMS 和 NoSQL 的最佳特性，高度兼容 MySQL，具備強一致性和高可用性，100% 支持標準的 ACID 事務。由于是 Cloud Native 數據庫，可通過并行計算發揮機器性能，在大數量的查詢下性能表現良好，并且支持無限的水平擴展，可以很方便的通過加機器解決性能和容量問題。另外提供了非常完善的運維工具，大大減輕數據庫的運維工作。

卡思數據目前配置了兩個 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 會越來越好，相信 TiDB 會越來越完善，引領 NewSQL 的發展。