留存率,数据表分表问题

本帖最后由 minoc 于 2013-5-22 15:00 编辑

现在有一个1千多万的数据表,是记录的用户的产品使用记录,

有如下几用查询留存要用到的字段,
id    userid   软件使用时间戳timestamp    应用包名packname    版本号version    发布渠道channel   用户注册时间register   数据入库时间datetime

数据600M多,索引600M多,一共1400万条左右,

此表涉及到留存率这个功能,比如3月注册的用户在4月的留存情况, 还有可能要看3月注册的用户在5月的留存情况,更具体的是,3月在4月中每一天的留存率,
如:3月在4月的留存率,即是(register=3月内 and timestamp=4月内),这个条件内的用户数占3月用户注册总数的比例

产品越来用户越多,数据增加越来越大,如果要分表,当前这个表就要保留最少3 4 5月这3个月的数据,查询了一下,这3个月占了900W多, 如果现在查询一次留存率,把3月在4月的留存缓存了,只需要保留4 5月的数据.也有700W多,数据表还是挺大的,但这不是办法,以后数据更多的时候,一个月有可能就会出现1千万,所以这样分表只是把表缩小了体积,没有多大意义

其实说这么多,我想知道的是,留存率,怎么统计比较好,可以占用空间少,效率又高,注意里面有版本和包名的字段,用处是查询一个包名或者版本3月在4月的留存情况.

分去吧 现在都是这样 空间换时间  或者是加个缓存

不是说一定要在现在的表基础上分,
而是找到更好的数据存储方式,
刚在又百度了老半天,又找到一个更理想的留存存储方式,不过还不太完善,正在研究中

难道你想改变原来的数据存储方式？

把原来的数据分离出来,
文档已经总结好了, 明天就试验,
这样的话表结构会缩小N多,以后数据量大了也更容易分表,100万用户1天也只有100万条数据,但不可能100万用户会同时在这一天使用

其实吧,我现在的想法是,不要把功能全做在一个表里去,可以把每个功能或多个类似的功能做在单独一个表,相同数据可以在多表中重复浪费磁盘空间(当然有限),但可以提高性能及减少问题复杂性,后期更好维护及分表

试下mysql merge吧，每月一个表，如果单独查询某个月可以用子表查询，如果查询三个月可查询主表，这样效率就高了很多，另外可以根据需求来修改主表包含的子表如三个月就包含，3，4，5，如两个月就包含3，4