开发者社区> 问答> 正文

Redis两个有序集合(大量数据)按条件筛选

在Redis中有两个有序集合,第一个的score为文章的点赞数,值为文章id,第二个有序集合score为文章的阅读量,值还是文章id。这两个有序集合里面的文章id都是一样。文章id有一百亿左右。我现在想知道阅读量大于1000但是点赞数小于10的文章有哪些。于是我分别对他们zrangebyscore,把结果拿到本地再取交集。这个过程网络io消耗了太多的时间。如果是Redis 的普通集合,我可以直接取交集,但是我发现有序集合没有直接在Redis取交集的功能,大家有什么好的优化建议吗 我现在遇到的问题是,可能点赞单独满足条件的文章有一亿条,单独满足阅读量的文章也有一亿条,拿回这两亿条信息耗时12秒,最后交集下来可能只有2篇文章。大量时间白白浪费在网络io上,我希望能让Redis先交集完成,然后我直接取结果。降低网络io,我现在时间就是浪费在这个取回本地的过程上,真正交集的时间不到1秒 10和1000是可变的,老板随时会修改组合,1-1000000都可以,每个数字都可以,呈现方式是做了一个网页,老板输入这两个数字来搜索文章,现在搜索一次要12秒以上(我这个实际场景相当于是老板想知道哪些文章可能被刷了阅读量。所以有一个页面,他输入点赞数,阅读数,动态给他筛选文章出来)

展开
收起
景凌凯 2020-04-22 17:56:38 2069 0
1 条回答
写回答
取消 提交回答
  • 有点尴尬唉 你要寻找的东西已经被吃掉啦!
    • 如果我设计的话,我会设计一个权重字段。把多个入参因子转换成一个数据模型。那么,这样一个字段就可以解决问题。那么,两个入参,获得一个出参,再去过滤和排序。
    • 我们之前更复杂,需要点赞数,收藏数,阅读量,评论数去排行榜。点赞/收藏/浏览这些计数数据,数据库冗余一份计数器表,redis存一份。然后,权重信息单独存一份在数据库,非实时更新,而是定时更新。
    • 其实,如果没有redis,最好冗余一张计数器表提供查询性能。如果有redis,其实持久化就够了,mysql那个表不一定需要,最多可能做个数据修复和订正。
    • 那我的理解,其实这个是内部的运营数据,对数据的实时性要求不高,所以可以做T+1,如果对数据的实时性要求不高,其实技术上反而好办的多;你这种别考虑实时性了,一方面实时性对运营分析数据带来的价值不大反而带来了技术架构的复杂性,另一方面搞不好回头因为这样的查询把你们核心链路搞挂了;可以考虑做T+1离线数据。复杂一些的架构设计,就是存量(历史) + 增量(定时增量binlog同步)。简单一些,可以考虑数据量分片/分桶(1000+,2000+,3000+),这样可以散列掉很多数据。
    2020-04-22 17:56:58
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
ApsaraDB for Redis——与创客同行 立即下载
微博的Redis定制之路 立即下载
云数据库Redis版的开源之路 立即下载