用户日志生成策略之我见收藏 此前的博客对用户日志生成提出了一个问题：用户日志生成策略，哪个方案好？

此前的博客对用户日志生成提出了一个问题：用户日志生成策略，哪个方案好？

鉴于有好友很感兴趣，我回答如下：

这个问题是我曾遇到的一个问题，在做处理日志的时候，如果有过这方面的经验的同学应该会有感受，大致有以下三点

从日志处理视角：

（1）日志是每天生成一份的，也有每小时甚至每5分钟日志，但是最后都会拼成一个一天的原始日志（apache日志，或者类似的日志），因此日志处理程序通常每天得到的输入是前一天的一整天的日志

（2）由于各种原因日志处理程序是自动运行的，错误难免，因此常常不可避免的会有redo的操作，但redo的范围通常就是一天，也就是说会存在redo一天日志的可能。

从日志需求视角：

（1）产品经理往往关注的是两类状况，一类是昨天的运营情况，包括类型用户的访问状况，总体访问情况等等，一类是趋势，例如财经类用户的访问趋势，和其他同类产品的比较趋势等等。

从日志本身视角：

(1)web服务器原始日志只能支持顺序访问，需要转化为随机访问的方式，因此需要结合具体的应用场合，在用户日志方面，关键字至少需要包含UserID。

(2)日志应该尽可能少的冗余，节约存储成本，例如我们有这样一个文本a.txt,里面记录了用户的<userid,access datetime><details>，显然datetime包含了日期和时间，这个日期是极大冗余的，如果变换为date.txt，里面记录用户<userid,time><details>则可以大大节约存储成本，如果将datetime转化为从0点开始的秒数，用整数而不是字符串存储能更多的节省，另外details也可以采用一些压缩方式进行压缩，因为大量用户的details的内容可能无法再一台机器存储，压缩后获得的传输上的收益是值得的。

综合以上考虑，每天生成一个可随机访问的日志是比较好的选择，当然会出现如果一个趋势查询，例如30天的查询，不可避免的要访问30个以上的表，如果存储的多台机器，代价也是不小的，当然更多的还有看一周的趋势，这都可以根据具体的情况来进行合并部署来获得更好的访问效果。

当然日志的如何转换为随机访问的方式，可以有很多，可以使用数据库mysql，bdb等，也可以自行开发类似的软件获得更大的优化自由度。