用mongodb存儲日誌

最近一直在考慮架構的事情，有一個問題依然困擾着咱們這些作業務系統的，那就是日誌以及日誌統計。大概的問題以下：

1. 咱們有不少模塊，日誌格式雖然相似但都寫在各自的服務器和目錄中。

2. 日誌中有不少信息是key=>value格式的數據。

3. 一般一個功能上線後，PM或者需求方都會要求一些統計數據以及報表之類，用來跟蹤功能的使用效果。一般PM是不懂寫程序的，所以統計數據的事情多半又提給RD。

4. 這種統計數據和報表，價值隨着時間的流逝而遞減，到了某個時間就再也不有價值，再也不有人關心，而統計程序還在跑，保不齊哪天又要維護，都忘了部署在哪了。

5. 日誌存儲佔用空間，須要按期刪除

6. web服務器鏡像不少，日誌一般也是多份，處理時須要合併

7. web服務器有時要調整，下線了web服務器通常日誌也就丟了

我是個懶人，作好了功能以後，對於這種數據統計的需求一般都很反感，由於數據挖掘這種事情總的來講很考驗靈感，因此需求總變化，今兒要這樣的數，明兒要那樣的數。一個理想狀況是PM都會SQL，而後RD把數據都灌入數據庫，之前咱們組的那幾個NB的PM還在的時候，常常這麼搞的，如今是不行了。還有一個問題就是數據庫不是schema free的，格式不那麼自由，須要事先設計好，這也架不住需求老變。

日誌統計這種事情，一般有如下特色：

1. 大數據量，天天可能有上G的數據（業務數據）

2. 寫頻繁，讀不頻繁（幾乎每一個PV都會產生若干條日誌數據）

3. 統計服務能夠任務化，不須要實時

4. 不準要絕對的數據一致性

按照這個特色，MongoDb算是挺合適的選擇，緣由是：

1. schema free，隨時能夠加須要的字段進去

2. 可擴展性極佳，不用太擔憂存儲空間不夠問題

3. 寫的時候能夠異步，不用太擔憂佔用請求響應的時間

4. 對於collection，能夠規定固定大小（capped collection） ，好比100G，這樣mongodb會按照LRU算法來複用空間，不用惦記着刪日誌

5. 能夠支持通常的查詢條件和彙集，而且提供Javascript Shell，這樣可讓有志於本身分析數據的PM自學編寫統計腳本，最終讓RD擺脫這樣的工做

雖然培養RD的產品意識是好的，但統計產品使用數據這樣的事情，確確實實讓RD提不起興趣，之前部門曾有過一個產品，從各產品線抓取數據而後記錄在數據庫並提供報表展現，但總的來講靈活性很低，一來雙方要定接口，二來統計的事情其實仍是要RD作好，只是省下了作數據展示的工做。

如今的想法是搭建mongodb集羣，用來集中存儲業務日誌的數據，而後在mongodb之上搭建一個平臺用於處理通常的數據統計需求，容許編寫一些任務放在平臺上運行，而這些任務能夠用統一的javascript語言來編寫。對於相對小數據量（咱們的業務系統，相比較檢索端的日誌來講算是小數據量了，一天上G數據都算大的）的需求來講，不失爲一種不錯的方案，主要目的是解決維護和管理的問題。