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

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

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

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

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

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

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

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

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

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

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

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

插入性能強(qiáng)

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

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

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

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

HybirdDB for MySQL 是阿里云推出的 HTAP 關(guān)系型數(shù)據(jù)庫(kù)，我們?cè)谠囉靡欢螘r(shí)間發(fā)現(xiàn)一些問(wèn)題：

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

二是連表查詢(xún)性能低下，網(wǎng)絡(luò) I/O 出現(xiàn)瓶頸。舉一個(gè)常見(jiàn)的關(guān)聯(lián)查詢(xún)，cd_video 表，2200 萬(wàn)數(shù)據(jù)，cd_program_video 表，節(jié)目和視頻的關(guān)聯(lián)表，4700 萬(wàn)數(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)相同查詢(xún)并發(fā)超過(guò)一定數(shù)量時(shí)，就會(huì)頻繁報(bào)數(shù)據(jù)庫(kù)計(jì)算資源不可用的錯(cuò)誤。

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

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

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

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

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

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

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

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

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

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

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

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