作者：咪咕視訊數(shù)據(jù)庫(kù)和中間件專家 郭灝
導(dǎo)讀
近年來(lái)，用戶對(duì)視頻內(nèi)容的需求呈現(xiàn)爆炸式增長(zhǎng)，這對(duì)平臺(tái)的技術(shù)架構(gòu)和數(shù)據(jù)管理能力也提出了更高的要求。咪咕視訊作為國(guó)內(nèi)領(lǐng)先的綜合視頻服務(wù)平臺(tái)，全場(chǎng)景月活用戶高達(dá) 4.98 億。在這一龐大的用戶生態(tài)背后，咪咕采用 TiDB 作為節(jié)目分發(fā)平臺(tái)的核心數(shù)據(jù)庫(kù)，承載所有媒體資訊、節(jié)目和賽事的元數(shù)據(jù)，成功支撐了平臺(tái)的高效運(yùn)行和內(nèi)容分發(fā)，也順利完成了多項(xiàng)知名直播賽事的轉(zhuǎn)播，包括歐洲足球聯(lián)賽、NBA、CBA、中超等頂級(jí)賽事，在提升和保障用戶體驗(yàn)方面發(fā)揮重要作用。
本文將全面介紹 TiDB 在咪咕視頻的應(yīng)用及收益、數(shù)據(jù)庫(kù)選型思路與測(cè)評(píng)維度、TiDB 在咪咕視訊后續(xù)的應(yīng)用方向與計(jì)劃。
更多資料：TiDB 社區(qū)活動(dòng)（上海站）回顧 & ppt 下載
應(yīng)用場(chǎng)景與需求特點(diǎn)
TiDB 在咪咕視頻中的應(yīng)用場(chǎng)景主要集中在內(nèi)容分發(fā)平臺(tái)系統(tǒng)，采用雙中心部署架構(gòu)（共 30 節(jié)點(diǎn)）。內(nèi)容分發(fā)平臺(tái)作為后端核心系統(tǒng)之一，承載著媒體資訊、內(nèi)容分發(fā)和體育賽事等關(guān)鍵數(shù)據(jù)。該系統(tǒng)的需求特點(diǎn)如下：
- 關(guān)系型：數(shù)據(jù)結(jié)構(gòu)高度結(jié)構(gòu)化，且一致性要求極高，如球員檔案、俱樂(lè)部徽章等關(guān)聯(lián)數(shù)據(jù)需同步更新。
- 寫(xiě)偏重：數(shù)據(jù)持續(xù)大量寫(xiě)入且只增不減，影視、綜藝等內(nèi)容每日新增，對(duì)數(shù)據(jù)庫(kù)的寫(xiě)入性能要求極高。
- 彈性擴(kuò)容：在重大賽事、影視上線等高峰期需隨時(shí)擴(kuò)容，匹配公司容器化資源戰(zhàn)略，同時(shí)遵循數(shù)據(jù)不出局原則。
- 性能和可靠性：節(jié)目和賽事的露出與下線有明確時(shí)效性，數(shù)據(jù)不能亂，服務(wù)不能斷。
- 信創(chuàng)：咪咕視訊作為國(guó)有企業(yè)，需符合國(guó)產(chǎn)化政策要求。
結(jié)合上述需求及調(diào)研結(jié)果，我們認(rèn)為 TiDB 是最契合咪咕內(nèi)容分發(fā)系統(tǒng)需求的數(shù)據(jù)庫(kù)。
應(yīng)用 TiDB 的收益
顯性收益
- 設(shè)備資源節(jié)省了三分之二：用 1 套 TiDB 集群換了 4 套 MySQL MHA 集群+ 1 套 Oracle RAC + ADG 集群 ，除了可以減少高配裸金屬的數(shù)量，還去掉了諸如 SAN 存儲(chǔ)、光纖交換機(jī)、HBA 卡等特殊設(shè)備。
- 開(kāi)發(fā)和實(shí)施成本節(jié)省：項(xiàng)目系統(tǒng)工程量中數(shù)據(jù)庫(kù)開(kāi)發(fā)和實(shí)施相關(guān)人力約 4 個(gè)多人月，主要為驗(yàn)證和測(cè)試。
- CICD 整體效率提升：從原先的“至少 3 天”縮短至“只要 10 分鐘內(nèi)”。
隱性收益
- 運(yùn)維架構(gòu)復(fù)雜性降低
降低“有狀態(tài)性”（主從有別），從復(fù)雜的 MHA+Zabbix+Thanos+Log+APM+XScripts+Java... 運(yùn)維體系，轉(zhuǎn)變?yōu)?TiUP+Dashboard+Grafana，降低運(yùn)維自身的成本和風(fēng)險(xiǎn)。
- 運(yùn)維效率提高 80%：數(shù)據(jù)鄰近、可視排序、時(shí)序關(guān)聯(lián)，大大縮短故障排查時(shí)間。
- 技術(shù)運(yùn)營(yíng)改進(jìn)：通過(guò) CICD 前置時(shí)間的縮短，將技術(shù)人員從繁瑣低價(jià)值工作解放。這方面的效益不太好測(cè)量，但影響卻是相當(dāng)大。
在選擇 TiDB 的過(guò)程中，我們也會(huì)考慮以下幾個(gè)問(wèn)題：分布式數(shù)據(jù)庫(kù)能做哪些事情？有哪些是以前做不到的、分布式獨(dú)有的新功能？是否符合需求？能否以更低的代價(jià)和風(fēng)險(xiǎn)實(shí)現(xiàn)？以及一些現(xiàn)實(shí)問(wèn)題，如價(jià)格和服務(wù)支撐，目前市場(chǎng)的反應(yīng)和排名情況等等，了解完這些也讓我們對(duì) TiDB 的產(chǎn)品更有信心。
在選型過(guò)程中，我們也建立了自己的評(píng)價(jià)體系，以及具體的標(biāo)準(zhǔn)、數(shù)據(jù)模型、方法、工具和指標(biāo)，供大家參考。
咪咕每一次賽事運(yùn)營(yíng)的更新，會(huì)發(fā)生十幾個(gè)包含多表關(guān)聯(lián)和大型范圍掃描的 SQL，產(chǎn)生五位數(shù)的回表。在高并發(fā)批量更新場(chǎng)景下，索引回表會(huì)消耗大量 CPU 資源，從而可能拖慢數(shù)據(jù)庫(kù)集群的性能。究其原理，存儲(chǔ)引擎 TiKV 的 LSM 樹(shù)優(yōu)勢(shì)在于將隨機(jī)寫(xiě)轉(zhuǎn)換成順序?qū)懀瑢?xiě)吞吐可以說(shuō)是相當(dāng)強(qiáng)勁的；而在讀方面，由于會(huì)涉及對(duì) Memtable 和跨層 SortStringTable 文件的訪問(wèn)，雖然文件有內(nèi)置 Bloom 過(guò)濾器加速，但在高并發(fā)數(shù)據(jù)掃描下發(fā)揮受限，尤其面臨大量二級(jí)索引帶來(lái)的嚴(yán)重回表。另一方面，在讀寫(xiě)分離的顆粒度上，MySQL 是實(shí)例級(jí)別的，而 TiKV 是區(qū)塊（Region）級(jí)別的，即使我們開(kāi)啟了 follower read，在沒(méi)有做好充分的資源隔離下也可能會(huì)互相影響。
于是我們針對(duì)這部分?jǐn)?shù)據(jù)做了重新的設(shè)計(jì)，讓它們成為自描述的文檔結(jié)構(gòu)。數(shù)據(jù)更新的部分，則利用 TiCDC 將變更流傳遞合并到結(jié)果集上。數(shù)據(jù)訪問(wèn)時(shí)直接定位到文檔，避免了前端系統(tǒng)對(duì)后臺(tái)庫(kù)直接進(jìn)行大型關(guān)聯(lián)和掃描，負(fù)載流量顯著降低。
同時(shí)，我們也總結(jié)了三點(diǎn)實(shí)踐經(jīng)驗(yàn)：
- 數(shù)據(jù)結(jié)構(gòu)的差異往往可導(dǎo)致懸殊的性能差別；
- 存儲(chǔ)引擎也應(yīng)當(dāng)擇其長(zhǎng)處發(fā)揮；
- 應(yīng)用程序要和數(shù)據(jù)庫(kù)結(jié)合優(yōu)化。
TiDB 在咪咕分發(fā)系統(tǒng)的應(yīng)用只是我們的第一個(gè)試點(diǎn)，后續(xù)也希望能把 TiDB 應(yīng)用到更多合適的場(chǎng)景。
從 DBaaS 到容器化平臺(tái)過(guò)渡
K8S + TiDB 的過(guò)渡歷程 :直接用裸金屬構(gòu)筑的數(shù)據(jù)庫(kù)服務(wù)層只是過(guò)渡的目標(biāo)形態(tài)，它的使命是集約當(dāng)下分散的數(shù)據(jù)庫(kù)集群。我們是計(jì)劃進(jìn)一步走向容器化的數(shù)據(jù)庫(kù)服務(wù)層。具體考慮如下：
- 資源戰(zhàn)略發(fā)展需要：公司總體資源戰(zhàn)略向容器化發(fā)展
- 發(fā)揮容器化無(wú)法忽略的優(yōu)勢(shì)
- 更小的資源控制顆粒度：實(shí)現(xiàn)更精細(xì)的資源管理
- 更高的部署密度和資源利用率：提高資源利用效率
- 更強(qiáng)的自治性和集成統(tǒng)一性：簡(jiǎn)化運(yùn)維管理
- 更高效的局內(nèi)流量通信：提升系統(tǒng)性能
因此，具有成熟的容器化部署能力，也是我們?cè)谶x擇 TiDB 的一個(gè)重要考慮因素。
一二級(jí)用戶中心系統(tǒng)的遷移
用戶中心系統(tǒng)是一個(gè)包含了賬戶信息、交易訂單、權(quán)益等關(guān)鍵數(shù)據(jù)的系統(tǒng)，是核心中的核心。一級(jí)是中央系統(tǒng)，二級(jí)是前置在各個(gè)業(yè)務(wù)板塊的子集，在咪咕視訊的是二級(jí)系統(tǒng)。由于數(shù)據(jù)量異常龐大，目前采用的是縱橫結(jié)合的大型分庫(kù)分表的數(shù)據(jù)庫(kù)群落技術(shù)。縱向是指根據(jù)業(yè)務(wù)模塊單獨(dú)建立數(shù)據(jù)庫(kù)集群，橫向是指在縱向的基礎(chǔ)上對(duì)每個(gè)集群再做分庫(kù)分表，每個(gè)集群的分桶數(shù)在 48-64 個(gè)不等，單片數(shù)據(jù)在 1-10 TB，不算主備冗余。
這里帶來(lái)的挑戰(zhàn)非常嚴(yán)峻：
- 跨庫(kù)流量，高度關(guān)聯(lián)：任何業(yè)務(wù)動(dòng)作都需跨庫(kù)跨片，物理上互相獨(dú)立的數(shù)據(jù)庫(kù)需通過(guò)外部機(jī)制保證數(shù)據(jù)一致性。
- 高寫(xiě)，集中跑賬：尤其在月初月底集中跑賬時(shí)，寫(xiě)流壓力大。
- 結(jié)構(gòu)僵化：開(kāi)發(fā)新業(yè)務(wù)程序設(shè)計(jì)必須將就現(xiàn)有數(shù)據(jù)庫(kù)結(jié)構(gòu)，運(yùn)維擴(kuò)展分片和數(shù)據(jù)遷移困難。
- 旱澇不均：有些性能饑餓，有些富?？臻e。
- 復(fù)雜性傳遞：離線數(shù)據(jù)層的各種管道和接口異常復(fù)雜，牽一發(fā)動(dòng)全身。
這些挑戰(zhàn)也是我們最終要努力攻克的對(duì)象。我個(gè)人認(rèn)為，上述的挑戰(zhàn)很大程度上與 TiDB 的設(shè)計(jì)出發(fā)點(diǎn)、功能特性是非常契合的，所以也非常期待能攜手 TiDB 一起攻克咪咕后續(xù)的一些挑戰(zhàn)。
咪咕大概是 2018 年左右正式開(kāi)始對(duì)分布式數(shù)據(jù)庫(kù)進(jìn)行研究的，到現(xiàn)在為止我們看到和測(cè)試過(guò)太多的國(guó)內(nèi)產(chǎn)品。但是在當(dāng)時(shí)，敢用 LSM 樹(shù)而不是 B+ 樹(shù)做存儲(chǔ)引擎，敢做分布式存算引擎分離的，能夠行列副本共存、優(yōu)化器路由分流做 MPP shuffle 的，市面上真的真的非常非常地不多見(jiàn)。比較多的是精致的分庫(kù)分表外掛，或某些知名國(guó)外產(chǎn)品的模仿版。
TiDB 的產(chǎn)品給我的印象是極具沖擊性的，那么大膽、不隨大流。驗(yàn)證和使用下來(lái)，效果也是切實(shí)的?？梢钥吹?，它的背后是有認(rèn)真的思考的，并且是有敢于追求的魄力的，產(chǎn)品設(shè)計(jì)者一定是自信和熱情的。
法國(guó)存在主義哲學(xué)家薩特說(shuō)過(guò)，人并不是由既有的東西來(lái)決定，而是在自己持續(xù)的選擇中才成為自己。DBA、架構(gòu)師們也是一樣，我們并不是由頭銜、外部的身份或待遇來(lái)決定的，而是在對(duì)數(shù)據(jù)庫(kù)技術(shù)、對(duì)工作、對(duì)生活持續(xù)的探索，和對(duì)困難的不斷的挑戰(zhàn)中，塑造和成為自己。希望本次分享的 TiDB 在咪咕的實(shí)踐和思考能給大家?guī)?lái)有價(jià)值的參考。
熱門(mén)跟貼