SSDB在大數(shù)據(jù)量日志分析中的應(yīng)用案例

在一個(gè)網(wǎng)站廣告系統(tǒng)中, 需要針對(duì)每一個(gè)用戶所接受的彈窗次數(shù)和點(diǎn)擊次數(shù)這兩個(gè)重要指標(biāo)進(jìn)行統(tǒng)計(jì), 從而進(jìn)行效果分析和精準(zhǔn)投放的改進(jìn). 這兩個(gè)指標(biāo)的統(tǒng)計(jì)算法其實(shí)非常簡單, 主要的難點(diǎn)在于大數(shù)據(jù)量. 廣告系統(tǒng)的涉及的用戶量達(dá)到數(shù)千萬人, 每天的日志數(shù)據(jù)量是幾

在一個(gè)網(wǎng)站廣告系統(tǒng)中, 需要針對(duì)每一個(gè)用戶所接受的彈窗次數(shù)和點(diǎn)擊次數(shù)這兩個(gè)重要指標(biāo)進(jìn)行統(tǒng)計(jì), 從而進(jìn)行效果分析和精準(zhǔn)投放的改進(jìn). 這兩個(gè)指標(biāo)的統(tǒng)計(jì)算法其實(shí)非常簡單, 主要的難點(diǎn)在于大數(shù)據(jù)量. 廣告系統(tǒng)的涉及的用戶量達(dá)到數(shù)千萬人, 每天的日志數(shù)據(jù)量是幾億條.

最開始的想法是使用 MySQL 數(shù)據(jù)庫, 不過這個(gè)方案馬上就被否, 因?yàn)槿绱舜罅繑?shù)據(jù)已經(jīng)遠(yuǎn)遠(yuǎn)超過 MySQL 的存儲(chǔ)能力, 必定帶來許多無謂的問題.

第二個(gè)方案是使用 Redis. Redis 是內(nèi)存存儲(chǔ)方案, 速度快, 而且 zset 數(shù)據(jù)結(jié)果存儲(chǔ)列表數(shù)據(jù)非常方便, 能直接地統(tǒng)計(jì)用戶的彈窗次數(shù)和點(diǎn)擊次數(shù). 不過, Redis 本身的局限就是它最多能存儲(chǔ)不超過內(nèi)存容量的數(shù)據(jù), 對(duì)于一臺(tái) 100G 內(nèi)存的服務(wù)器, Redis 最好是存儲(chǔ)不超過 30G 的數(shù)據(jù)量. 因此, Redis 的方案在運(yùn)行了短時(shí)間之后也被否定了.

第三個(gè)方案是使用 SSDB. SSDB 可以存儲(chǔ) TB(1000GB) 級(jí)別的數(shù)據(jù), 并且支持列表等集合數(shù)據(jù)結(jié)構(gòu), 有著和 Redis 高度兼容的 API, 所以, 當(dāng)從 Redis 遷移到 SSDB 時(shí), 改動(dòng)非常小.

每一個(gè)用戶的彈窗歷史用一個(gè) zset 來存儲(chǔ), key 是時(shí)間戳, 對(duì)應(yīng)的 score 也是時(shí)間戳, 因?yàn)槲覀冎魂P(guān)心用戶的彈窗歷史, 具體的彈窗信息會(huì)用 map 來存儲(chǔ)(時(shí)間戳作為 key, 對(duì)應(yīng)彈窗信息 value). SSDB 的 zset 支持根據(jù) score 范圍來查詢, 所以只需要一條命令就能算出用戶在任意時(shí)間段內(nèi)的彈窗次數(shù).

用戶的點(diǎn)擊統(tǒng)計(jì)也是類似.

Related posts:

1. 用PHP遍歷SSDB中的zset集合
2. 如何使用SSDB的zscan命令
3. 單實(shí)例支撐每天上億個(gè)請(qǐng)求的SSDB
4. LevelDB 服務(wù)器 SSDB 支持主從(master-slave)同步了!
5. Redis 導(dǎo)數(shù)據(jù)的 PHP 腳本

你現(xiàn)在看的文章是: SSDB在大數(shù)據(jù)量日志分析中的應(yīng)用案例

Linode VPS - 美國虛擬主機(jī) | IT牛人博客聚合網(wǎng)站

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com