用户向系统申请,系统会随机给用户生成一个不重复的短网址 xx.xx.xx/abced1用于编辑内容(其中abcde1就是短网址标识,称coding)
现在要统计所有coding的访问记录。
目前有一张access_log表,每当某个coding的短网址被访问时,先是根据UA信息、ip地址、有效时间经过算法得到一个uvmark(访客标识),如果表里已经有相同的uvmark,表示是同一个人访问了多次,此时不做insert记录,而是update该条数据的number字段+1。不过没有uvmark,就添加insert一条记录(记录包括coding.访问的设备.系统环境.浏览器环境.访问城市.访问时间等等)
但是随着访问量的增大,表里的数据已经非常多了。将近9000万条数据,每天增量大概200万。统计一些扫描量大的码,比如按时间的sql是这样的: select number from access_log where coding = XXXX and time between time_start and time_end
取出来的数据 uv就是条数的数量 pv就是每条的number相加(按地域.环境等等同理) 效率比较低。如果一个短网址每天平均有2W的访问量,那么我要统计他最近一个月的访问量,需要的时间达到50S以上
随便找了个coding的访问统计。如下
我这么做有问题吗? 有可以优化的地方吗?像百度统计这种的数据库设计是怎样的,为什么感觉他们的非常快。
每天总结一下,过去的访问量直接取总结的结果,而不是从头统计
每天总结一下,过去的访问量直接取总结的结果,而不是从头统计
30天之前的某一天 还是实时吗?
显然就不是了!
除了今天的数据会发生变化以外,过去的任何一天的数据多不会发生变化(过去了就过去了)
所以你只要按统计方案记录下统计结果就可以了
30天之前的某一天 还是实时吗?
显然就不是了!
除了今天的数据会发生变化以外,过去的任何一天的数据多不会发生变化(过去了就过去了)
所以你只要按统计方案记录下统计结果就可以了
那没关系,你按每小时一统计,一天的才24条记录
你也可以按每分钟,甚至每秒钟一统计,都会比你重新从原始数据中汇总起来要快
那没关系,你按每小时一统计,一天的才24条记录
你也可以按每分钟,甚至每秒钟一统计,都会比你重新从原始数据中汇总起来要快
你这些数据是怎么计算得来的?
1+1 会算,10+10 就不会算啦?
你这些数据是怎么计算得来的?
1+1 会算,10+10 就不会算啦?
以 #6 下图的苏州为例:访问量519 表示的是迄今为止的访问量,而明天的访问量是 519 + n
这个不会有疑问吧?
那么到了明天,今天的这个 519 还会变吗?显然是不会变的