缓存策略,何时缓存变得毫无意义？

我对缓存策略和实现都很陌生.我正在开发一个数据库密集型项目,但也会定期更新和更改信息.

我已经找到足够的信息来了解如何开发缓存功能,但我不确定的是一般策略.

如果我缓存所有查询结果并按逻辑事项对它们进行分组,我可以清楚地触发有意义的触发器,我的缓存中可能会有数万个(至少)微小的文件.仅缓存大型查询结果会更有意义吗？

我知道这是一个特定于硬件的问题,但一般来说,缓存变得毫无意义的文件量是多少？这意味着,如果您正在使用所有这些小文件加载文件系统,那么对它们的访问最终会变得足够慢,以至于您可能还没有缓存信息开头？

谢谢大家,我对您提供的任何意见感兴趣

编辑:根据有关这绝对是特定于应用程序的回复,让我以这种方式提出问题应该是普遍的:

假设我的应用程序依赖于一个包含1,000,000个项目的表...

是否可以更快地执行查询以直接从数据库中检索其中一个项目,或者从我的缓存目录中检索其中一个项目,其中包含1,000,000个文件,每个文件都包含其中一个项目的详细信息？

编辑:显然100,000不足以得到一个有效的答案,让它成为1,000,000.有人想要1000,000,000？因为我能做到......

使用MySQL的内置查询缓存,而不是尝试自己维护它.它会在写入时自动清除对表的缓存查询.此外,它在内存中工作,所以它应该是非常有效的...

此外,不要只缓存查询.尝试在渲染周期的不同阶段缓存应用程序的整个段.因此,您可以让MySQL缓存查询,然后缓存每个单独的视图(呈现),每个单独的块和每个页面.然后,您可以根据请求选择是否从缓存中提取.

例如,未登录的用户可以直接从缓存获取整个页面.但是登录用户可能无法(由于用户名等).因此对于他来说,您可以从缓存中在页面上呈现1/2的视图(因为它们不依赖于用户对象).您仍然可以获得缓存的好处,但它将根据需要进行分层.

如果你真的期待很多流量,那绝对值得研究Memcached.让MySQL为您存储查询,然后将所有用户域缓存项存储在memcache中...

编辑:要回答您的修改:

如果单个目录变大,文件系统可能会变慢.只要您按目录"命名"(因此每个目录只有一小部分缓存文件),从这个角度来看应该没问题.至于确切的阈值,它实际上将取决于您的硬件和文件系统.我知道如果单个目录中存在大量文件,EXT3会变得非常慢(我的目录中包含数十万个文件,并且只需要一个文件就可能需要半秒钟stat(),更不用说做任何类型了目录列表)...

但要意识到,如果你添加另一台服务器,你将要么拥有重复的缓存(这不是一件好事),要么必须重写整个缓存层.是否有理由不Memcached从一开始就采用正确的方式？

编辑2:回答您的最新编辑:

打电话仍然太难了.我有一个应用程序,其数据库大约有15亿行(每天增长约50万).我们根本不使用任何缓存,因为我们没有并发问题.即使我们这样做了,我们最好不要再添加MySQL服务器而不是添加缓存,因为任何形式的缓存都会有如此低的命中率,以至于不值得花时间来添加它.

这就是我如此坚持不缓解速度的原因.总会有一个不在缓存中的对象.因此,如果您使用其中一个对象访问某个页面,它仍然需要很快.根据经验,我尝试在接下来的几分钟内缓存将要再次访问的任何内容(无论如何,我在其他应用程序上保留了大约5分钟的生存时间).因此,如果项目在该时间跨度内没有超过几次点击,或者命中率非常低(低于90%),我不打扰缓存该项目....