【问题标题】:RDBMS result caching vs Application level caching?RDBMS 结果缓存与应用程序级缓存?
【发布时间】:2017-03-25 12:26:30
【问题描述】:

在我 10 年的经验中,我们默认使用 Oracle 或 SQL Server 配置的 RDBMS。从未调整默认禁用的结果缓存(至少在 oracle 中)。我一直看到使用应用程序级别的缓存选项,如 ehcache/memcache/redis 等作为缓存解决方案。

问题 - 如果我在数据库服务器上有可用的内存带宽,无论我是否面临任何性能问题,主动使用结果缓存(即数据库级别)不是一个很好的选择吗? 有了这个查询结果,select * from employee where department = 'Finance' 将始终与财务部门相对应地被缓存。

我的问题是,如果硬件可以通过 LRU 或根据特定要求的适当算法来支持它,为什么不使用 DB 级缓存呢? 在我需要创建密钥的应用程序级缓存中,将其部署(如 memcached)作为单独的服务器?

【问题讨论】:

  • 我的一般规则:不要缓存缓存。数据库将进行各种缓存;很少需要添加另一层缓存。

标签: java web-applications memcached ehcache rdbms


【解决方案1】:

例如,ehcache 为您提供的应用程序级缓存允许您的应用程序无需支付通过网络获取数据的代价。 (假设您的应用程序没有托管在与您的 RDBMS 相同的机器上)

当您想到 looking at the common latency in IT systems 时,它可能已经为您的应用带来了巨大的收益。

【讨论】:

  • 同意。这里的要点是同时使用EHcache(for objects which I already will be needing frequently and costly to fetch fromDB ) DB cache(for db objects which may or may not be costly or usage will depend on work flow)。我想在这里说明为什么不使用 LRU 将 DB 缓存配置为某个较大的值,以便可以从内存而不是 IO 调用中获取一些查询结果(无论它们是否昂贵)。至少它肯定会有所作为,如果不是很大
  • 是的,我想您所描述的内容是有道理的。但听起来你最终需要配置和记住 2 个缓存...
猜你喜欢
  • 1970-01-01
  • 2018-06-07
  • 2012-03-26
  • 2014-07-05
  • 2012-10-04
  • 2014-05-22
  • 1970-01-01
  • 1970-01-01
  • 2017-08-17
相关资源
最近更新 更多