【问题标题】:Proper strategy for Redis caching relational dataRedis缓存关系数据的正确策略
【发布时间】:2015-09-04 13:31:53
【问题描述】:

我们有以下用例示例:

我们有用户、商店、朋友(用户之间的关系)和点赞。我们将这些表存储在 MySQL 中并作为键值存储在 Redis 中,以便从 Redis 缓存中读取而不命中数据库。对两个数据存储都进行了写入。 因此,我们的应用程序非常快速且可扩展,因为我们很少访问数据库进行读取。我们将 AWS 用于可扩展的 Redis。 但是,当用户登录时我们遇到了问题,我们必须显示商店列表,以及他的哪些朋友喜欢该商店。这是一个join,Redis不支持直接join。我们想知道存储和显示这些数据的最佳方式是什么。例如:如果这应该存储在一个 Redis 表中,其中键值为“store/user_who likes”并在每次写入时保持不变,或者可能有一个每小时的 cron 来构建它。然后我们可以读取已经存储的数据还是应该按需构建这个连接? 我们注意到,即使是 Facebook 也不会实时更新此信息,而是需要几分钟才能让朋友看到我的哪些朋友喜欢我们共同拥有的页面。 提前感谢您的任何回复。

【问题讨论】:

    标签: caching join redis


    【解决方案1】:

    取决于它对您的重要性。为什么不把每个人的好友按一个集合,把每个店铺的点赞按一个集合,然后当你需要喜欢给定店铺的朋友时,就取两者之间的SINTER(集合交集)。应该很快,并且存储朋友和存储喜欢的集合也会给你带来很多类似的好操作。不确定您目前如何使用 Redis 缓存,但您可以将它们用作可能更便宜的内存替代品,以及获取用户的朋友、商店的喜欢等...

    至于 cron,不知道会有什么帮助。 Redis 的速度足以处理上述类型的写入。内存将首先成为您的瓶颈。

    【讨论】:

    • 感谢 SINTER 的提示。但是,我们使用的是 Sorted Sets,因为它可以让我们在需要为用户获取用户的好友或喜欢的商店时进行分页。您是否建议将数据存储为集合和排序集合,并根据情况使用适当的集合?
    • 没有。只需使用 ZINTERSTORE 并在生成的交叉点上设置一些低 ttl,以便将其用作缓存。
    • 好的,谢谢。我们注意到 ZINTERSTORE 非常昂贵:时间复杂度:O(NK)+O(Mlog(M)),但我想使用它比存储两次数据更有意义。
    猜你喜欢
    • 2017-01-16
    • 2021-05-05
    • 2013-10-13
    • 1970-01-01
    • 2022-08-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-09-12
    相关资源
    最近更新 更多