【问题标题】:PHP: How to cache a big table in redis?PHP:如何在redis中缓存一个大表?
【发布时间】:2013-08-16 01:57:58
【问题描述】:

假设我有一个带有 id -> 字符串的大(MySQL-)表(>10k 行)。我可以将它们全部放在一个数组中并缓存这个数组。但问题来了:如何高效缓存?

a) 将其缓存为一个大项目。所以我会执行

$redis->set("array", $array);

相当简短和容易。但是对于我需要的每个条目,我都必须获取整个内容。绝对低效。

b) 缓存每个条目本身:

foreach( $array as $id => $str )
  $redis->set( "array:$id", $str );

使用这种方式,我将在 Redis 中拥有 >10k 条目。那感觉不太好。如果我有 10 个这样的表,我将有 100k 个条目....

那么你的建议是什么?如何缓存一个大数组?

【问题讨论】:

  • 用例:我一次只需要一个条目。
  • 为什么需要在Redis中缓存一整张数据库表,为什么不直接使用原始数据库表中的数据?
  • 1) id 和 string 只是其中的两列。 2)数据库流量大,我想减少负载。 3)这不是缓存的意义吗 - 如果经常使用,可以缓冲 DB-Data 吗? 4) Redis 是纯内存的,位于 webserver 的机器上,DB 在集群中自己的机器上。
  • Well 数据库对经常访问的记录有自己的缓存;但是如果数据库流量很大,那么确保它被正确索引 - 外部缓存对于存储需要很长时间运行的常规、相对静态的查询的结果是有益的,但如果数据库访问不慢(取决于你的查询),但是在没有聚合/等的情况下检索单个记录的简单索引查询不应该比 redis 访问慢...
  • ... 即使您的 redis 在物理上位于同一台服务器上,它仍然像通过网络请求一样被请求,所以您唯一要节省的是网络延迟;但增加了缓存验证、未命中后备等的开销

标签: php mysql caching redis


【解决方案1】:

缓存大数组只有在您计划将其作为一个整体进行检索时才会有所帮助。然而,缓存失效将是一个非常“繁重”的操作,因为当您更改某些内容时,您必须使整个数组失效并从数据库中重新读取它。

redis 中的 10k 根本不算多。您可以毫无问题地拥有数百万个条目。

我会选择 b) 版本。单独缓存每个条目。更易于维护、更简单的应用程序代码和更小的应用程序端内存占用,这在您想要扩展应用程序时变得越来越重要。

【讨论】:

  • 我喜欢你的回答 - 我会试一试!非常感谢!
【解决方案2】:

第一个问题是:为什么需要缓存那个数组。

如果你总是需要整个数组,那么:

$redis->set("array", $array);

如果您只需要一些特定的索引(第二个解决方案),那么您为什么要尝试缓存整个事物而不是每次都查询数据库以获得所需的 id。 只获取需要的数据总是更有效。

请记住,缓存有用性是使用读取(从缓存中有效读取的项目)和未命中(从数据源读取然后添加到缓存中的项目)之间的比率来估计的。

如果您正在缓存整个表(10k 未命中),但仅通过 id 查询少数元素(2de 解决方案),那么您的比率接近于零。 如果您每次都需要整个表,则使用第一个解决方案 (1miss) 将其缓存,因此您的比率更有可能 > 1。

另外,请记住,redis 是一个单独的服务器。对于对 redis 的每个请求,都会向该服务器发出一个请求(在本地主机上或不在本地主机上)。 所以基本上 redis 和 mysql 的规则是一样的:一个大请求比许多小请求执行得更快。

【讨论】:

  • 我不需要整个数组。我一次只需要一个条目。
  • 然后,选择第二种解决方案。当你需要一个条目时,从缓存中获取它。如果不在缓存中,则从数据库中获取并将其存储在缓存中。但是不要一启动就将整个表加载到缓存中,让它只在需要时才延迟加载到缓存中。
  • 但是 10k 次“从 id = 的表中选择字段?”比一次“从表中选择 id、字段”并缓存这些负载要重得多……不是吗?
  • 延迟加载的目的是在给定时间只加载您需要的内容。因此,如果 10k Select 较重,它们会按时间分布(几分钟甚至几小时,具体取决于您的应用程序使用情况)有关急切加载与延迟加载的更多信息:codingatilivedigitally.wordpress.com/2012/06/01/…
猜你喜欢
  • 1970-01-01
  • 2016-03-29
  • 2011-02-21
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-07-16
  • 2012-04-25
  • 2016-08-28
相关资源
最近更新 更多