25,980
社区成员
发帖
与我相关
我的任务
分享请教一个需求的高性能实现
大家好，有这样的一个需求，使用我的手机客户端软件的人很多，我在后台记录下了很多人的浏览日志，并维护在一张表中，表的记录数大约有1000万，现在某个手机客户端用户有N个好友(例如300个)，我需要查询这N个好友的浏览日志，并进行分页。如何才能高效实现，多谢！
...全文
请发表友善的回复…
发表回复
MiceRice 2014-01-16
- 打赏
- 举报
如果你根本都不没有任何渠道去知道他好友是谁，那么你还提出来要查看他好友的访问记录？这个命题本身不科学吧？
BuleRiver 2014-01-15
- 打赏
- 举报
多谢您的回复，但是这也是无法实现的。因为获取这些好友信息，需要用户授权，例如QQ好友，用户不输入QQ号，我是不知道TA的好友列表的。
MiceRice 2014-01-10
- 打赏
- 举报
想办法把这个好友关系的信息，逐步拉到你的服务器这边来咯。
你这边所服务的用户A，必然可以取得他的好友信息B。那么反过来考虑，B如果有记录，不管他的好友是否还有XYZ，你也只需要在A的盒子放一条消息即可，因为反正XYZ不是你系统所服务的用户。
等X某天成为了你系统所服务的用户，那么注册完成后初始化一次盒子信息就是了。
BuleRiver 2014-01-10
- 打赏
- 举报
您的意见非常好，对我们帮助非常大，但是有一点不同：由于一些好友关系是存在于别人的服务器上的，例如QQ好友，因此我们的后台是无法确切的知道某个人有哪些好友，因此服务器是不能给用户设置"消息盒子"的。
MiceRice 2014-01-10
- 打赏
- 举报
我能想到的预处理有两类：
1、利用内存：将近期的浏览日志按用户Hash放入内存，那么检索时直接可以取出300个用户的近期记录，然后做一次快排。
2、利用磁盘：给每个用户设置一个固定容量的“消息盒子”，每当有某个被关注用户新出现浏览记录（或者说发推），则向所有关注该用户的“消息盒子”以异步准实时的方式投递一条简短信息。
在脑子里判断是方案2速度更高，但是需要评价下磁盘开销。
BuleRiver 2014-01-08
- 打赏
- 举报
多谢您的回复，不知道您说的更多的预处理是什么？多谢。
MiceRice 2014-01-08
- 打赏
- 举报
这个命题难度其实不小，相当于微博（所关注对象的转发信息）的需求了。
我不清楚微博的数据模型是怎么设计的，所以只能提点我自己的想法了：
1、无限时间范围的查询是不合理的，而且支持难度很高；
2、预处理是必需的，否则每次检索和排序的开销比较高，尤其是排序要设法避免，因为如果要进行排序（按时间）就意味着所有数据都必须检索出来后才能开始排序；
大致设计如下：
◎ 设计一张当期浏览日志表，字段：浏览时间、浏览者ID、浏览ID、其它浏览信息；
主键：浏览时间、浏览者ID、浏览ID，簇集索引。
◎ 该表信息应该以特定时间周期（比如一个月）来保持一定规模，不能无限制扩大；
超过该时间范围的浏览信息，可以移入另一张表：“近期浏览日志表”
◎ 检索时先把朋友Select出来，然后再使用In来进行检索；因为簇集索引第一字段是时间，所以不需要再使用OrderBy关键字；注意限制返回记录数，不要一次性返回所有。
以上是初步想法，如果是类似微博的要求，这个肯定是不够的，还需要更多的空间（内存、磁盘）和预处理来换取时间。
BuleRiver 2014-01-07
- 打赏
- 举报
不知道大家遇到过类似的问题没有，多谢。
