数据统计系统设计思路遇挫,求救.? 400 报错
按照惯例,先描述场景.
首先此系统是用来统计的,对用户数据进行统计.要求可以按小时,日,周,月来查询.
每日有200w+的用户量,按照每个用户有20个操作来算.要处理4000w+的请求.
一 最早的想法,是把所有请求放入队列,然后对相同用户,相同事件进行合并,然后入库.
所有统计放入数据库进行统计.结果被无情的pass掉了.原因,数据库占用过大..
二 写日志,所有请求过来后记录日志,拆分成多个小文件,按日进行存放.
定时对日志文件进行分析,然后将结果入库.
也快要被pass掉,原因每天大概2g以上的日志文件,要保存一个月.
入库,出库,穷折腾mysql了.同时老大很不看好存日志的方式..
三 所有请求尽管放马过来,memcached中存储用户id,订单id等关键信息.
同时memcached中建立对应字段,分别存储时,日,周,月的信息.
对用户id 订单id 进行判断是否重复用户和订单,然后对memcached中的时 日 周 月字段进行对应操作.
也被pass掉了,只能按照自然周 自然月进行统计..不符合需求
--------------------------------
要求尽可能的不要在现网db上进行操作.压力已经很大,如果再进行统计操作,估计会挂掉.
要求低成本....
大家踊跃点啊.....
你这个需求类似OLAP了,可以参考下相关资料。
如果自己实现,思路就是用类似于你们的方法2保存原始数据,在此基础上,将每日的数据统计出一个中间结果存起来形成“日统计”,最终的统计结果基于此“日统计”进一步统计完成。
如果再复杂点,可以把“日统计”看成第一层的统计结果缓存,还可以形成“周统计”、“旬统计”、“月统计”、“季统计”的多级统计结果缓存。
这个方法将计算量分散到了每天,所以最终形成统计结果时对数据库的压力不大。
######日志不是挺好吗,
每天晚上分析完日志结果入库,
可以将日志导入别的数据库上,再删掉文件就行了
######你这个需求类似OLAP了,可以参考下相关资料。
如果自己实现,思路就是用类似于你们的方法2保存原始数据,在此基础上,将每日的数据统计出一个中间结果存起来形成“日统计”,最终的统计结果基于此“日统计”进一步统计完成。
如果再复杂点,可以把“日统计”看成第一层的统计结果缓存,还可以形成“周统计”、“旬统计”、“月统计”、“季统计”的多级统计结果缓存。
这个方法将计算量分散到了每天,所以最终形成统计结果时对数据库的压力不大。
存日志最大的问题是每日的统计结果不能复用.需要存一个月的日志..
例如我要查询一周的活跃用户.如果这个用户连续登录一周,从日统计的结果进行累加,,,结果会是7次..
######日志不是挺好吗,
每天晚上分析完日志结果入库,
可以将日志导入别的数据库上,再删掉文件就行了
目前统计中遇到的难题就是日统计结果不能复用.需要存大量的原始用户日志.
一个月的日志存下来会有4*30=120g.放数据库也不合适.数据太多.
想象下对120g的日志进行分析.需要多久..
如果只是查询自然月的,那当然可以放到晚上,定时进行分析.
现在需求是要求查询任意30天内的数据.
######早上测试了下infobright 这个东东.
下边是统计耗时情况.
mysql> select uid u,event e,sum(event2),count(uid) from test group by e;
+--------+---------+-------------+------------+
| u | e | sum(event2) | count(uid) |
+--------+---------+-------------+------------+
| 123456 | pay | 190000270 | 38000037 |
| 123456 | login | 30 | 10 |
| 123456 | insert | 0 | 3 |
| 123456 | newtask | NULL | 3 |
+--------+---------+-------------+------------+
4 rows in set (17.58 sec)
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。