大数据量的Cache Key策略答案

【问题标题】：Cache Key strategie for large amount of data大数据量的Cache Key策略
【发布时间】：2018-01-31 02:21:33
【问题描述】：

我有大约 3MB 难以生成的信息。它结合了对一些非常大的表的连接查询和查询完成后的繁重处理。最重要的是，结果信息会被频繁读取（每个客户端每分钟 4-10 次，所有客户端都会读取 3000 次）。

我应该将该信息存储在单个键下的缓存中，还是应该在每次需要时将其分解并检索 N 个片段？

详情：
- 我不认为这是一个“基于意见的问题”，因为可以用代码证明存在更好/更坏的情况
- 我无法先发制人地知道哪个“碎片”将包含我需要的信息......将其视为银行对账单，银行经理可以在其中查找“转账”和“$ 1400.00”......因此我必须检索整个事物以进行进一步过滤/排序
- 数据不是扁平的，但不是那个嵌套的。大部分物品（大约 70% 只有 2 lvl，其余为 3 lvl）
- 我使用 Redis 作为缓存服务器和 c# - Asp.Net MVC 4
- 过滤是单一来源的，并应用于 4 个字段（尝试匹配 4 个字段上的值的单个搜索框）。
- 总是按日期排序

【问题讨论】：

这听起来像是典型的分析过程/数据仓库情况。生成的数据是否可以存储回一个或多个非规范化数据库表中，还是绝对需要缓存在内存中？
@KarlWenzel 我想说，由于数据访问的频率，缓存在内存中的性能比任何数据库解决方案都要高...原始估计指向每分钟超过 3000 次访问
如果没有数据库查询引擎来处理所有过滤/排序的优化和缓存，那么也许您可以构建自己的索引？也许您的代码中有一个支持虚拟数据表的代码库？您的数据是什么样的；是字段很多的平表，还是嵌套很多？
@KarlWenzel 它不是扁平的，但它不是 that 嵌套的......它最多向下 3 层，但嵌套的项目并不多......
好的，几分钟后我有一个会议，但我会回到这个。与此同时，也许有人会看到这些 cmets 并提出一些建议。您可以考虑将这些额外的详细信息连同您期望的过滤器/排序参数以及您使用的语言/网络平台一起放入您的原始问题中。

标签： performance caching scalability

【解决方案1】：

我应该将该信息存储在单个键下的缓存中，还是应该在每次需要时将其分解并检索 N 个片段？

您需要考虑：

您可以缓存的最大对象大小是多少（例如，1MB 默认 max_item_size 用于 memcached，但 512MB 用于 redis 字符串类型）
什么对您的工作负载真正有意义（例如，分成 N 个部分；您会使用单独的部分吗？）

最重要的是，结果信息会被频繁读取（每个客户端每分钟 4-10 次，因此所有客户端都会读取 3000 次）。

仅基于此声明，我的解释是 same 信息被返回 3000 次。因此，对于单个键，这将是 3000 个缓存请求，对于 N 个片段，这将是 N * 3000 个请求。很容易看出哪个更贵。加上组合 N 个片段所需的计算时间。

你可以同时做这两个：

让客户的请求使用单一密钥。
让您的服务器端使用 N 个缓存键，并在可能的情况下重用现有的中间结果，将它们组合并使用单个键存储结果。

【讨论】：