标签：
最近一直在考虑架构的事情，有一个问题依然困扰着我们这些做业务系统的，那就是日志以及日志统计。大概的问题如下：
我们有很多模块，日志格式虽然类似但都写在各自的服务器和目录中。
日志中有很多信息是key=>value格式的数据。
通常一个功能上线后，PM或者需求方都会要求一些统计数据以及报表之类，用来跟踪功能的使用效果。通常PM是不懂写程序的，因此统计数据的事情多半又提给RD。
这种统计数据和报表，价值随着时间的流逝而递减，到了某个时间就不再有价值，不再有人关心，而统计程序还在跑，保不齐哪天又要维护，都忘了部署在哪了。
日志存储占用空间，需要定期删除
web服务器镜像很多，日志通常也是多份，处理时需要合并
web服务器有时要调整，下线了web服务器一般日志也就丢了
我是个懒人，做好了功能之后，对于这种数据统计的需求通常都很反感，因为数据挖掘这种事情总的来说很考验灵感，所以需求总变化，今儿要这样的数，明儿要那样的数。一个理想情况是PM都会SQL，然后RD把数据都灌入数据库，以前我们组的那几个NB的PM还在的时候，经常这么搞的，现在是不行了。还有一个问题就是数据库不是schema free的，格式不那么自由，需要事先设计好，这也架不住需求老变。
日志统计这种事情，通常有以下特点：
大数据量，每天可能有上G的数据（业务数据）
写频繁，读不频繁（几乎每个PV都会产生若干条日志数据）
统计服务可以任务化，不需要实时
不许要绝对的数据一致性
按照这个特点，MongoDb算是挺合适的选择，原因是：
schema free，随时可以加需要的字段进去
可扩展性极佳，不用太担心存储空间不够问题
写的时候可以异步，不用太担心占用请求响应的时间
对于collection，可以规定固定大小（capped collection） ，比如100G，这样mongodb会按照LRU算法来复用空间，不用惦记着删日志
可以支持一般的查询条件和聚集，并且提供Javascript Shell，这样可以让有志于自己分析数据的PM自学编写统计脚本，最终让RD摆脱这样的工作
虽然培养RD的产品意识是好的，但统计产品使用数据这样的事情，确确实实让RD提不起兴趣，以前部门曾有过一个产品，从各产品线抓取数据然后记录在数据库并提供报表展示，但总的来说灵活性很低，一来双方要定接口，二来统计的事情其实还是要RD做好，只是省下了做数据展现的工作。
现在的想法是搭建mongodb集群，用来集中存储业务日志的数据，然后在mongodb之上搭建一个平台用于处理一般的数据统计需求，允许编写一些任务放在平台上运行，而这些任务可以用统一的javascript语言来编写。对于相对小数据量（我们的业务系统，相比较检索端的日志来说算是小数据量了，一天上G数据都算大的）的需求来说，不失为一种不错的方案，主要目的是解决维护和管理的问题。
标签：
原文地址：http://my.oschina.net/u/1024573/blog/475839
