caching - 对象缓存 vs 缓存数据库查询结果

Question

该问题主要与数据库端的缓存有关。比如说，我们进行了各种性能优化，包括查询调优、数据库分片、数据库反规范化等。我们仍然看到需要在数据库端有一个内存缓存。我们有 2 个缓存选项 - 缓存数据库查询结果与缓存数据库 (OR) 业务对象。

缓存对象(如(用户、产品、地址)与缓存查询返回的结果集)的优缺点是什么？

Answer 1

根据我的经验，缓存应用程序对象 与缓存原始查询结果相比有很多好处。

如果您的应用程序已经使用将业务逻辑与数据库访问分开的 DAO 层进行结构化，那么使用缓存代理模式(即提供实现相同接口(interface)的实体)很容易在 DAO 之上添加一个微小的缓存层您的 DAO，处理缓存中的存储/检索，并在需要时将数据库访问委托(delegate)给实际的目标实体)。

这种方法导致了应用程序设计中的一系列关键考虑因素:

数据库访问逻辑、缓存层和业务逻辑之间有明确的职责分离

缓存逻辑的所有细节( key 生成、存储策略和过期管理)都封装在一个单独的实体中

您可以选择有选择地启用缓存设施，例如仅适用于某些方法/DAO

DAO 和缓存代理共享相同的接口(interface)，例如在运行时也很容易打开/关闭缓存

您可以分别测试 DAO 和缓存代理

更实用的是，缓存应用程序对象意味着:

在存储或检索对象时，您需要支付单个序列化/反序列化开销，而在检索查询结果时，您仍然需要构建对象

对象的复杂性(几乎)无关紧要(例如，缓存代理忽略了 DAO 在 2 个不同的数据源上使用 3 个单独的查询创建了对象)

在某些情况下，生成缓存键可能很棘手，而散列查询字符串(您在缓存代理中不知道)要容易得多

缓存中的序列化对象(例如 json 字符串)也可以从其他应用程序中读取和使用(不受欢迎，但有时需要)

很可能您的数据库已经实现了一个复杂而快速的缓存查询机制，您可能希望根据自己的需要对其进行调整，而不是在它之上构建另一个层

你可以自己为你的 DAO 构建一个缓存层。如果您的应用程序已经基于 Spring 等框架，缓存支持可能已经内置，您只需要设置正确的配置(尽管并不总是像您想要的那样灵活)。

最后，我不能说使用查询缓存比经过深思熟虑的对象缓存有特别的缺点。尽管如此，它应该让我想知道一个流行的框架，如 Hibernate默认情况下禁用查询缓存，并且需要在单个查询上选择性地启用它。