問題描述

項(xiàng)目需要做一個(gè)dashboard圖表網(wǎng)站，展示日志的相關(guān)統(tǒng)計(jì)信息。這個(gè)頁面圖表很多，一次性會加載出很多數(shù)據(jù)。

日志表有很多種，都是一些入侵攻擊日志、惡意站點(diǎn)訪問日志等等，需要統(tǒng)計(jì)出當(dāng)前時(shí)間、過去24小時(shí)、過去一周被攻擊主機(jī)個(gè)數(shù)、惡意站點(diǎn)數(shù)（這是其中兩個(gè)需求）等等數(shù)據(jù)。

比如被攻擊主機(jī)個(gè)數(shù)，需要查多張數(shù)據(jù)表，然后統(tǒng)計(jì)出這個(gè)數(shù)據(jù)。

日志存儲在PostgreSQL里面，已經(jīng)基于時(shí)間做了分表，但是每天的的日志量都在100W以上。

寫入數(shù)據(jù)庫的模式是隨時(shí)從其他的系統(tǒng)中寫入。

根據(jù)這個(gè)應(yīng)用場景，如果設(shè)計(jì)這個(gè)后端統(tǒng)計(jì)呢？還請大神提供一點(diǎn)思路，謝謝。

問題解答

雖然是一個(gè)PostgreSQL的問題，但是打了各種數(shù)據(jù)庫標(biāo)簽。那么我就從MongoDB和NoSQL的角度說說這個(gè)問題。因?yàn)橐恍┣闆r不是特別清楚，基于自己的假設(shè)來回答，如果有和你情況不符的地方再提出來。數(shù)據(jù)庫的日常應(yīng)用無非OLAP和OLTP兩大類，你的應(yīng)用是一個(gè)比較典型的OLAP應(yīng)用。通常OLAP的特點(diǎn)是對時(shí)效性的要求不是非常高，對系統(tǒng)資源占用比較重。你沒有提對時(shí)效性要求到底有多高，還有你們數(shù)據(jù)的寫入模式是怎樣的。每天某個(gè)時(shí)間批量導(dǎo)入？或是隨時(shí)從其他系統(tǒng)寫入？不管怎樣，還是有一些通用的辦法來應(yīng)對的。以下是無論使用哪種數(shù)據(jù)庫都可以做的一些事情：

從你的描述來看這是個(gè)比較典型的時(shí)序數(shù)據(jù)，過去的數(shù)據(jù)是不會變的。所以可以在每天結(jié)束時(shí)把這一天的數(shù)據(jù)先聚合好，某年某月某日有多少次攻擊多少次惡意訪問之類。如果要查一段時(shí)間的，則可以把已經(jīng)按天統(tǒng)計(jì)好的數(shù)據(jù)再聚合一次。比如一個(gè)月的就是30條數(shù)據(jù)再次聚合，這比30x100w=3000w條數(shù)據(jù)的聚合要輕松很多。如果你的統(tǒng)計(jì)粒度需要比天還小，那就要看具體小到什么程度。如果是精確到時(shí)，那我可能還是會考慮按小時(shí)預(yù)聚合，這樣統(tǒng)計(jì)比如過去30天的數(shù)據(jù)，就會有30x24=720條數(shù)據(jù)，也在接受范圍內(nèi)。但是如果統(tǒng)計(jì)范圍允許到年，則有365x24=8760，情況就不是很樂觀了。當(dāng)然如果需要精確到分鐘，那又是更麻煩的事情。但即使這樣，預(yù)聚合仍然能有效減少數(shù)據(jù)量從而降低運(yùn)算所需的時(shí)間和資源。為了解決小粒度聚合的問題，實(shí)際應(yīng)用中可能需要進(jìn)行多個(gè)層次的預(yù)聚合。比如按月，按天，按時(shí)，按分分別聚合好，這樣在需要某分鐘到某分鐘的數(shù)據(jù)時(shí)，可以把大粒度的范圍通過月、天、時(shí)先消化掉，剩下的兩頭零碎部分再用時(shí)、分鐘處理，這樣最大程度上減小需要聚合的數(shù)據(jù)量。

無論使用哪種數(shù)據(jù)庫，索引優(yōu)化都是很重要的步驟。按上述方法預(yù)聚合后，各種時(shí)間因素肯定都是需要在索引中的。如果在時(shí)間基礎(chǔ)上還需要對某個(gè)主機(jī)或域名等篩選，則最好是有這些字段的聯(lián)合索引。具體問題具體分析，這個(gè)還需要你根據(jù)自己的表結(jié)構(gòu)和查詢?nèi)?yōu)化。

無論怎么優(yōu)化，OLAP對資源的占用都是不能忽略的。如果你的數(shù)據(jù)是實(shí)時(shí)寫入，聚合期間很容易受到I/O瓶頸的影響。所以最好是把接受數(shù)據(jù)和分析數(shù)據(jù)的結(jié)點(diǎn)分開。

說說如果使用MongoDB還有哪些事情可以做。

分片。水平擴(kuò)展是NoSQL的特色之一，理論上所需時(shí)間和結(jié)點(diǎn)數(shù)量成反比。而數(shù)據(jù)量的增長在分布式環(huán)境中也不是一個(gè)問題。

Tag Aware Sharding。MongoDB分片的特色，可以把舊數(shù)據(jù)自動(dòng)歸集到容量大，但是性能相對差的硬件上，這樣讓熱數(shù)據(jù)始終保持在性能較好的機(jī)器上達(dá)到更好的效果。

天然的讀寫分離和高可用。復(fù)制集本身就可以實(shí)現(xiàn)讀寫分離和高可用。相信這兩個(gè)特性對任何應(yīng)用都是很有意義的。

最后還是要提醒一點(diǎn)，理論歸理論，沒有一個(gè)方案是完美的，實(shí)際應(yīng)用時(shí)肯定還會遇到各種各樣奇怪的問題。編程是一項(xiàng)創(chuàng)造性的工作，需要你自己在實(shí)踐中不斷尋找最優(yōu)的解決方案，在實(shí)踐中成長。

1、個(gè)人感覺按天分區(qū)比較好，為了提升性能，統(tǒng)計(jì)SQL不要直接查詢父表，而是將子表進(jìn)行 union 統(tǒng)計(jì)。2、另一點(diǎn)是合理設(shè)計(jì)索引；

沒做過，覺得可以用定時(shí)器然放到redis里，現(xiàn)查的話確實(shí)太慢。多個(gè)查詢條件都加上索引會好些吧

這個(gè)日志數(shù)據(jù)處理是主業(yè)還是副業(yè)？

如果是主業(yè)，那就要學(xué)習(xí)下 @Mongoing中文社區(qū) 的方案，尤其是時(shí)序數(shù)據(jù)進(jìn)行預(yù)處理的概念。

如果是副業(yè)，那直接上 ELK 套件就好了，投入低見效快。