用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資料都算大的）的需求來說，不失為一種不錯的方案，主要目的是解決維護和管理的問題。