摘要:選擇在經(jīng)歷了痛苦的傳統(tǒng)解決方案的折磨以及大量調(diào)研及對比后,卡思數(shù)據(jù)最終選擇了作為數(shù)據(jù)倉庫及業(yè)務數(shù)據(jù)庫。上線卡思數(shù)據(jù)目前配置了兩個的三個的四個的。卡思數(shù)據(jù)部署了數(shù)據(jù)庫監(jiān)控系統(tǒng)來實時監(jiān)控服務狀態(tài),可以非常清晰的查看服務器問題。
作者:劉廣信,火星文化技術經(jīng)理
卡思數(shù)據(jù)是國內(nèi)領先的視頻全網(wǎng)數(shù)據(jù)開放平臺,依托領先的數(shù)據(jù)挖掘與分析能力,為視頻內(nèi)容創(chuàng)作者在節(jié)目創(chuàng)作和用戶運營方面提供數(shù)據(jù)支持,為廣告主的廣告投放提供數(shù)據(jù)參考和效果監(jiān)測,為內(nèi)容投資提供全面客觀的價值評估。
卡思數(shù)據(jù)首先通過分布式爬蟲系統(tǒng)進行數(shù)據(jù)抓取,每天新增數(shù)據(jù)量在 50G - 80G 之間,并且入庫時間要求比較短,因此對數(shù)據(jù)庫寫入性能要求很高,由于數(shù)據(jù)增長比較快,對數(shù)據(jù)庫的擴展性也有很高的要求。數(shù)據(jù)抓取完成后,對數(shù)據(jù)進行清洗和計算,因為數(shù)據(jù)量比較大,單表 5 億 + 條數(shù)據(jù),所以對數(shù)據(jù)庫的查詢性能要求很高。
起初卡思數(shù)據(jù)采用的是多個 MySQL 實例和一個 MongoDB 集群,如圖 2。
MySQL 存儲業(yè)務相關數(shù)據(jù),直接面向用戶,對事務的要求很高,但在海量數(shù)據(jù)存儲方面偏弱,由于單行較大,單表數(shù)據(jù)超過千萬或 10G 性能就會急劇下降。
MongoDB 存儲最小單元的數(shù)據(jù),MongoDB 有更好的寫入性能,保證了每天數(shù)據(jù)爬取存儲速度;對海量數(shù)據(jù)存儲上,MongoDB 內(nèi)建的分片特性,可以很好的適應大數(shù)據(jù)量的需求。
但是隨著業(yè)務發(fā)展,暴露出一些問題。
MySQL 在大數(shù)據(jù)量的場景下,查詢性能難以滿足要求,并且擴展能力偏弱,如果采用分庫分表方式,需要對業(yè)務代碼進行全面改造,成本非常高。
MongoDB 對復雜事務的不支持,前臺業(yè)務需要用到數(shù)據(jù)元及連表查詢,當前架構支持的不太友好。
架構優(yōu)化 1. 需求針對我們遇到的問題,我們急需這樣一款數(shù)據(jù)庫:
兼容 MySQL 協(xié)議,數(shù)據(jù)遷移成本和代碼改造成本低
插入性能強
大數(shù)據(jù)量下的實時查詢性能強,無需分庫分表
水平擴展能力強
穩(wěn)定性強,產(chǎn)品最好有成熟的案例
2. 方案調(diào)研未選擇 TiDB 之前我們調(diào)研了幾個數(shù)據(jù)庫,Greenplum、HybirdDB for MySQL(PetaData)以及 PolarDB。Greenplum 由于插入性能比較差,并且跟 MySQL 協(xié)議有一些不兼容,首先被排除。
HybirdDB for MySQL 是阿里云推出的 HTAP 關系型數(shù)據(jù)庫,我們在試用一段時間發(fā)現(xiàn)一些問題:
一是復雜語句導致計算引擎擁堵,阻塞所有業(yè)務,經(jīng)常出現(xiàn)查詢超時的情況。
二是連表查詢性能低下,網(wǎng)絡 I/O 出現(xiàn)瓶頸。舉一個常見的關聯(lián)查詢,cd_video 表,2200 萬數(shù)據(jù),cd_program_video 表,節(jié)目和視頻的關聯(lián)表,4700 萬數(shù)據(jù),在關聯(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;
當相同查詢并發(fā)超過一定數(shù)量時,就會頻繁報數(shù)據(jù)庫計算資源不可用的錯誤。
三是 DDL 操作比較慢,該字段等操作基本需要幾分鐘,下發(fā)至節(jié)點后易出現(xiàn)死鎖。
PolarDB 是阿里云新推出新一代關系型數(shù)據(jù)庫,主要思想是計算和存儲分離架構,使用共享存儲技術。由于寫入還是單點寫入,插入性能有上限,未來我們的數(shù)據(jù)采集規(guī)模還會進一步提升,這有可能成為一個瓶頸。另外由于只有一個只讀實例,在對大表進行并發(fā)查詢時性能表現(xiàn)一般。
3. 選擇 TiDB在經(jīng)歷了痛苦的傳統(tǒng)解決方案的折磨以及大量調(diào)研及對比后,卡思數(shù)據(jù)最終選擇了 TiDB 作為數(shù)據(jù)倉庫及業(yè)務數(shù)據(jù)庫。
TiDB 結合了傳統(tǒng)的 RDBMS 和 NoSQL 的最佳特性,高度兼容 MySQL,具備強一致性和高可用性,100% 支持標準的 ACID 事務。由于是 Cloud Native 數(shù)據(jù)庫,可通過并行計算發(fā)揮機器性能,在大數(shù)量的查詢下性能表現(xiàn)良好,并且支持無限的水平擴展,可以很方便的通過加機器解決性能和容量問題。另外提供了非常完善的運維工具,大大減輕數(shù)據(jù)庫的運維工作。
上線 TiDB卡思數(shù)據(jù)目前配置了兩個 32C64G 的 TiDB、三個 4C16G 的 PD、四個 32C128G 的 TiKV。數(shù)據(jù)量大約 60 億條、4TB 左右,每天新增數(shù)據(jù)量大約 5000 萬,單節(jié)點 QPS 峰值為 3000 左右。
由于數(shù)據(jù)遷移不能影響線上業(yè)務,卡思數(shù)據(jù)在保持繼續(xù)使用原數(shù)據(jù)架構的前提下,使用 Mydumper、Loader 進行數(shù)據(jù)遷移,并在首輪數(shù)據(jù)遷移完成后使用 Syncer 進行增量同步。
卡思數(shù)據(jù)部署了數(shù)據(jù)庫監(jiān)控系統(tǒng)(Prometheus/Grafana)來實時監(jiān)控服務狀態(tài),可以非常清晰的查看服務器問題。
由于 TiDB 對 MySQL 的高度兼容性,在數(shù)據(jù)遷移完成后,幾乎沒有對代碼做任何修改,平滑實現(xiàn)了無侵入升級。
目前卡思數(shù)據(jù)的架構如圖 3:
查詢性能,單表最小 1000 萬,最大 8 億,有比較復雜的連表查詢,整體響應延時非常穩(wěn)定,監(jiān)控展示如圖 4、圖 5。
目前的卡思數(shù)據(jù)已全部遷移至 TiDB,但對 TiDB 的使用還局限在數(shù)據(jù)存儲上,可以說只實現(xiàn)了 OLTP。卡思數(shù)據(jù)準備深入了解 OLAP,將目前一些需要實時返回的復雜查詢、數(shù)據(jù)分析下推至 TiDB。既減少計算服務的復雜性,又可增加數(shù)據(jù)的準確性。
感謝 PingCAP非常感謝 PingCAP 小伙伴們在數(shù)據(jù)庫上線過程中的大力支持,每次遇到困難都能及時、細心的給予指導,非常的專業(yè)和熱心。相信 PingCAP 會越來越好,相信 TiDB 會越來越完善,引領 NewSQL 的發(fā)展。
文章版權歸作者所有,未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/19423.html
摘要:選擇在經(jīng)歷了痛苦的傳統(tǒng)解決方案的折磨以及大量調(diào)研及對比后,卡思數(shù)據(jù)最終選擇了作為數(shù)據(jù)倉庫及業(yè)務數(shù)據(jù)庫。上線卡思數(shù)據(jù)目前配置了兩個的三個的四個的。卡思數(shù)據(jù)部署了數(shù)據(jù)庫監(jiān)控系統(tǒng)來實時監(jiān)控服務狀態(tài),可以非常清晰的查看服務器問題。 作者:劉廣信,火星文化技術經(jīng)理 卡思數(shù)據(jù)是國內(nèi)領先的視頻全網(wǎng)數(shù)據(jù)開放平臺,依托領先的數(shù)據(jù)挖掘與分析能力,為視頻內(nèi)容創(chuàng)作者在節(jié)目創(chuàng)作和用戶運營方面提供數(shù)據(jù)支持,為廣告...
閱讀 3284·2023-04-25 18:03
閱讀 1148·2021-11-15 11:38
閱讀 5550·2021-10-25 09:45
閱讀 846·2021-09-24 09:48
閱讀 2302·2021-09-22 15:34
閱讀 1741·2019-08-30 15:44
閱讀 2682·2019-08-30 13:12
閱讀 608·2019-08-29 16:05