摘要：選擇在經(jīng)歷了痛苦的傳統(tǒng)解決方案的折磨以及大量調(diào)研及對比后，卡思數(shù)據(jù)最終選擇了作為數(shù)據(jù)倉庫及業(yè)務(wù)數(shù)據(jù)庫。上線卡思數(shù)據(jù)目前配置了兩個(gè)的三個(gè)的四個(gè)的。卡思數(shù)據(jù)部署了數(shù)據(jù)庫監(jiān)控系統(tǒng)來實(shí)時(shí)監(jiān)控服務(wù)狀態(tài)，可以非常清晰的查看服務(wù)器問題。

作者：劉廣信，火星文化技術(shù)經(jīng)理

卡思數(shù)據(jù)是國內(nèi)領(lǐng)先的視頻全網(wǎng)數(shù)據(jù)開放平臺，依托領(lǐng)先的數(shù)據(jù)挖掘與分析能力，為視頻內(nèi)容創(chuàng)作者在節(jié)目創(chuàng)作和用戶運(yùn)營方面提供數(shù)據(jù)支持，為廣告主的廣告投放提供數(shù)據(jù)參考和效果監(jiān)測，為內(nèi)容投資提供全面客觀的價(jià)值評估。

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

起初卡思數(shù)據(jù)采用的是多個(gè) MySQL 實(shí)例和一個(gè) MongoDB 集群，如圖 2。

MySQL 存儲(chǔ)業(yè)務(wù)相關(guān)數(shù)據(jù)，直接面向用戶，對事務(wù)的要求很高，但在海量數(shù)據(jù)存儲(chǔ)方面偏弱，由于單行較大，單表數(shù)據(jù)超過千萬或 10G 性能就會(huì)急劇下降。

MongoDB 存儲(chǔ)最小單元的數(shù)據(jù)，MongoDB 有更好的寫入性能，保證了每天數(shù)據(jù)爬取存儲(chǔ)速度；對海量數(shù)據(jù)存儲(chǔ)上，MongoDB 內(nèi)建的分片特性，可以很好的適應(yīng)大數(shù)據(jù)量的需求。

但是隨著業(yè)務(wù)發(fā)展，暴露出一些問題。

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

MongoDB 對復(fù)雜事務(wù)的不支持，前臺業(yè)務(wù)需要用到數(shù)據(jù)元及連表查詢，當(dāng)前架構(gòu)支持的不太友好。

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

兼容 MySQL 協(xié)議，數(shù)據(jù)遷移成本和代碼改造成本低

插入性能強(qiáng)

大數(shù)據(jù)量下的實(shí)時(shí)查詢性能強(qiáng)，無需分庫分表

水平擴(kuò)展能力強(qiáng)

穩(wěn)定性強(qiáng)，產(chǎn)品最好有成熟的案例

未選擇 TiDB 之前我們調(diào)研了幾個(gè)數(shù)據(jù)庫，Greenplum、HybirdDB for MySQL（PetaData）以及 PolarDB。Greenplum 由于插入性能比較差，并且跟 MySQL 協(xié)議有一些不兼容，首先被排除。

HybirdDB for MySQL 是阿里云推出的 HTAP 關(guān)系型數(shù)據(jù)庫，我們在試用一段時(shí)間發(fā)現(xiàn)一些問題：

一是復(fù)雜語句導(dǎo)致計(jì)算引擎擁堵，阻塞所有業(yè)務(wù)，經(jīng)常出現(xiàn)查詢超時(shí)的情況。

二是連表查詢性能低下，網(wǎng)絡(luò) I/O 出現(xiàn)瓶頸。舉一個(gè)常見的關(guān)聯(lián)查詢，cd_video 表，2200 萬數(shù)據(jù)，cd_program_video 表，節(jié)目和視頻的關(guān)聯(lián)表，4700 萬數(shù)據(jù)，在關(guān)聯(lián)字段上都建有索引，如下 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；

當(dāng)相同查詢并發(fā)超過一定數(shù)量時(shí)，就會(huì)頻繁報(bào)數(shù)據(jù)庫計(jì)算資源不可用的錯(cuò)誤。

三是 DDL 操作比較慢，該字段等操作基本需要幾分鐘，下發(fā)至節(jié)點(diǎn)后易出現(xiàn)死鎖。

PolarDB 是阿里云新推出新一代關(guān)系型數(shù)據(jù)庫，主要思想是計(jì)算和存儲(chǔ)分離架構(gòu)，使用共享存儲(chǔ)技術(shù)。由于寫入還是單點(diǎn)寫入，插入性能有上限，未來我們的數(shù)據(jù)采集規(guī)模還會(huì)進(jìn)一步提升，這有可能成為一個(gè)瓶頸。另外由于只有一個(gè)只讀實(shí)例，在對大表進(jìn)行并發(fā)查詢時(shí)性能表現(xiàn)一般。

在經(jīng)歷了痛苦的傳統(tǒng)解決方案的折磨以及大量調(diào)研及對比后，卡思數(shù)據(jù)最終選擇了 TiDB 作為數(shù)據(jù)倉庫及業(yè)務(wù)數(shù)據(jù)庫。

TiDB 結(jié)合了傳統(tǒng)的 RDBMS 和 NoSQL 的最佳特性，高度兼容 MySQL，具備強(qiáng)一致性和高可用性，100% 支持標(biāo)準(zhǔn)的 ACID 事務(wù)。由于是 Cloud Native 數(shù)據(jù)庫，可通過并行計(jì)算發(fā)揮機(jī)器性能，在大數(shù)量的查詢下性能表現(xiàn)良好，并且支持無限的水平擴(kuò)展，可以很方便的通過加機(jī)器解決性能和容量問題。另外提供了非常完善的運(yùn)維工具，大大減輕數(shù)據(jù)庫的運(yùn)維工作。

卡思數(shù)據(jù)目前配置了兩個(gè) 32C64G 的 TiDB、三個(gè) 4C16G 的 PD、四個(gè) 32C128G 的 TiKV。數(shù)據(jù)量大約 60 億條、4TB 左右，每天新增數(shù)據(jù)量大約 5000 萬，單節(jié)點(diǎn) QPS 峰值為 3000 左右。

由于數(shù)據(jù)遷移不能影響線上業(yè)務(wù)，卡思數(shù)據(jù)在保持繼續(xù)使用原數(shù)據(jù)架構(gòu)的前提下，使用 Mydumper、Loader 進(jìn)行數(shù)據(jù)遷移，并在首輪數(shù)據(jù)遷移完成后使用 Syncer 進(jìn)行增量同步。

卡思數(shù)據(jù)部署了數(shù)據(jù)庫監(jiān)控系統(tǒng)（Prometheus/Grafana）來實(shí)時(shí)監(jiān)控服務(wù)狀態(tài)，可以非常清晰的查看服務(wù)器問題。

由于 TiDB 對 MySQL 的高度兼容性，在數(shù)據(jù)遷移完成后，幾乎沒有對代碼做任何修改，平滑實(shí)現(xiàn)了無侵入升級。

目前卡思數(shù)據(jù)的架構(gòu)如圖 3：

查詢性能，單表最小 1000 萬，最大 8 億，有比較復(fù)雜的連表查詢，整體響應(yīng)延時(shí)非常穩(wěn)定，監(jiān)控展示如圖 4、圖 5。

目前的卡思數(shù)據(jù)已全部遷移至 TiDB，但對 TiDB 的使用還局限在數(shù)據(jù)存儲(chǔ)上，可以說只實(shí)現(xiàn)了 OLTP。卡思數(shù)據(jù)準(zhǔn)備深入了解 OLAP，將目前一些需要實(shí)時(shí)返回的復(fù)雜查詢、數(shù)據(jù)分析下推至 TiDB。既減少計(jì)算服務(wù)的復(fù)雜性，又可增加數(shù)據(jù)的準(zhǔn)確性。

非常感謝 PingCAP 小伙伴們在數(shù)據(jù)庫上線過程中的大力支持，每次遇到困難都能及時(shí)、細(xì)心的給予指導(dǎo)，非常的專業(yè)和熱心。相信 PingCAP 會(huì)越來越好，相信 TiDB 會(huì)越來越完善，引領(lǐng) NewSQL 的發(fā)展。