【redis存储结构设计】存储坐标点及其多维度点击数
我现在有个需求
需要记录页面点击数据，上游吐到redis中，
上游怎么吐到redis中对我们来说是透明的，
我们只用关心redis中如何存储就好。
查询需求：
查询某天某页面下所有点击数，即
有效点击总数+无效点击总数查询某天某页面某分辨率下
所有有效点击总数和无效点击总数查询某天某页面某分辨率下
所有的坐标点及点击数框选查询（相当于范围查询） 查询某天某页面某分辨率下 某个范围（比如
100<x<1000,30<y<600）坐标点的有效点击总数和无效点击总数。
同时还有各种维度的有效点击数和无效点击数
需求解释：
关于有效点击和无效点击：我们进行存储时可以用0和1区分，至于前端如何定义有效或者无效，对我们透明。
关于分辨率：按宽度区分共有三种：比如1380 1190 1000; 根据现有实现：有了分辨率可以将zset切割的小一些，比如没有分辨率可能有共10w个key 的zset,有了分辨率我一次最多查询某个分辨率下 可能只有3w个key 的zset。
关于框选： 就是用鼠标在页面上从左上到右下划出一个框， 我们会查询这个选择框范围（如100<x<1000,30<y<600）内所有的点相关的数据。
关于维度: 就是点击这个点的用户 所在地区， 所使用浏览器
当前实现
上游吐过来的点经过处理存入redis,
x,y都经过
Math.ceil(realx / 4.0) * 4;
Math.ceil(realy / 4.0) * 4;
处理，即相当于4个点为一个点存储到redis.
使用4个zset来实现需求。
一个 zset 记录某天某页面某分辨率的数据
key为 date_pageid_分辨率 member为： 有效OR无效_ 浏览器_ 地区score为点击数
举例：key: 20140908_0001_1000member: 0_1_10对应无效点击，1对应浏览器表中的QQ浏览器，1对应地区表中的上海score:10
每个坐标点相关数据都用一个对应的
zset记录key为 date_pageid_分辨率_ 横坐标_ 纵坐标member为： 有效OR无效浏览器地区score为点击数
举例：key: 20140908_0001_1000_23_478member: 0_1_20对应无效点击，1对应浏览器表中的QQ浏览器，2对应地区表中的北京score:12
这样可以理解为，坐标为（23，478）这个点，在20140908这一天，pageid为0001的页面上，分辨率为1000的时候，来自北京地区的，使用QQ浏览器，进行的无效点击数为12
两个zset 做辅助范围查询
通过zrangebyscore 分别获得x,y范围(如
100<x<1000,30<y<600)对应的key集然后取交集获得需要查询的真正key集
y的辅助查询zetkey为： date_pageid_分辨率yeg.20140908_0001_1000_ymember： 为 date_pageid分辨率_ 横坐标 _纵坐标eg.20140908_0001_1000_23_478score为：横坐标y的值eg.478x的辅助查询zet
key为： date_pageid_分辨率xeg.20140908_0001_1000_xmember： 为 date_pageid分辨率_ 横坐标 _纵坐标eg.20140908_0001_1000_23_478score为：横坐标X的值eg.23
当前实现存在的问题
查询速度太慢
举例 ：比如我想一次取出某天某页面某分辨率下所有的点，
可能需要一次查询几万个keyeg. keys("20140908_0001_1000_*");
获得查询的key集之后 ，还需要使用zrange(key)得到每个key下的member集，然后再使用zscore(key,member)获得对应的key和 member下的score值
可以看到这个操作：
串行化执行，不容易改成并行化。
暂时的解决方案：可以利用异步任务执行 ，进行缓存以优化查询速度，
但是有可能引起redis慢查询问题。
框选行为
举例：查询范围(如100<x<1000,30<y<600)
使用
zrangeByScore(key, 100, 1000)``zrangeByScore(key, 30, 600)
查出x,y在各自范围分别对应的key集，然后
取交集获得最终需要查询的key集
获得查询的key集之后 ，还需要使用
zrange(key)得到每个key下的member集，
然后再使用
zscore(key,member)获得对应的key和 member下的score值
缺点：因为查询范围不定，所以无法进行缓存，当查询范围很大时，即key很多的时候，查询速度很慢。和上面查询坐标点一样
串行化执行，不容易改成并行化。有可能引起redis慢查询问题。
不知道大家针对我
现在的实现方案有什么更好的优化策略或者针对查询需求有没有什么更好的设计方案，
新人第一次发帖，感谢@暗雨西喧对排版的提醒。
请大家多指教。
