缓存与索引

缓存解决方案和索引解决方案之间的真正区别是什么？在我看来,索引解决方案实际上是具有运行搜索查询的能力(如:弹性搜索).是否有任何真正的理由在同一个项目中同时使用缓存解决方案和索引解决方案,或者索引解决方案是否基本上使任何其他缓存变得多余？

示例:假设我将NEST用于ElasticSearch,它将存储和返回POCO; 如果我然后查询ElasticSearch并将POCO返回给我,是不是认为使用从ElasticSearch返回的缓存对象？

目前,我使用ICacheManager接口将数据存储在缓存中......我是这样的:

return CacheManager.Get(cacheKey, () =>
{
    // return something...
});

ElasticSearch会变得多余吗？

编辑

感谢大家的回答.我完全清楚缓存是什么,并且已经理解了文本搜索索引背后的一般思想,所以我只是想知道索引是否已经兼作缓存,因此会使任何其他缓存变得多余.毕竟,当一个人做得很好时,我不想在内存中保留2个缓存(例如:ElasticSearch + Redis).我想我现在有一个更好的主意; 特别是当我意识到并非所有字段都始终存储在索引中时,因此我们需要从缓存中获取对象或者直接从数据库中获取对象 - 至少在某些情况下是这样.谢谢大家!

缓存的全部目的是尽可能快地返回已请求的数据.缓存的一个限制是它们不能太大,因为查找时间会增加,从而无法首先使用缓存.话虽这么说,如果你计划在你的数据库中拥有几百万亿条记录就不足为奇了,将它们全部编入索引并不困难,但是很难将它们全部缓存,尽管RAM已经到了更便宜,更便宜,您可以将所有需要的东西存储在内存中.您还需要问问自己,您的缓存是否需要分布在多个主机上(无论是现在还是将来).

考虑到ES中的查找和查询非常快(+ ES除此之外还带来了更多好处,例如评分),即通常比从数据库中检索相同数据更快,将ES用作缓存是有意义的.我看到的一个问题是常见问题,即只要您开始复制数据(DB - > ES),就需要确保两个商店都不会失去同步.

现在,如果另外你将缓存放入该混合中,它是第三个要维护的数据存储,并确保与主数据存储一致.如果你知道你的数据非常稳定,即写入然后不经常更新,那么这可能没问题,但是在设计数据访问策略时需要始终牢记这一点.

正如@paweloque所说,最终这一切都取决于你的具体用例.每个问题都是不同的,我可以证明,在过去五年左右的几十个围绕ES的项目之后,我从未见过两个项目以相同的方式配置.缓存可能对某些特定情况有意义,但对其他情况则完全没有意义.

您需要认真考虑如何以及在何处存储数据,谁在请求它们(以及以什么速率),谁在创建/更新它们(以及以什么速率),但最终,最佳做法是保持您的堆栈尽可能精简,只需要很少的组件,每个组件都是您必须理解,集成,维护,调整和监控的潜在瓶颈.

最后,我还要补充一点:添加缓存或索引应该被视为软件堆栈的性能优化.你可能知道俗语"过早优化是万恶之源",你应该首先使用你的数据库,测量性能,加载测试,然后见证它可能不支持负载.然后,您可以决定根据需要为其和/或索引抛出缓存.再次,负载测试,测量,然后决定.如果您每天只有十个用户发出一些请求,那么只有一个数据库可能会非常好.您必须了解何时以及为何需要在巴别塔上添加另一层,但最重要的是,您需要一次添加一个层,并查看该层如何改善/降低堆栈的稳定性.

最后但并非最不重要的是,您可以从使用ES作为缓存(主要是键值存储和对象缓存)的人那里找到一些在线文章.

你的问题:

问:缓存解决方案和索引解决方案之间的真正区别是什么？

答:简单的区别在于缓存用于存储经常使用的数据,以便更快地为相同的请求提供服务.从本质上讲,你的缓存比你的主要商店更快但是尺寸更小,因此,它可以存储的数据(考虑到它会更昂贵)

对所有数据进行索引以使其可以更快地搜索.一个简单的Hashtable/HashMap将哈希作为索引,而在一个数组中,0和1是索引.

您可以索引某些列以更快地搜索它们.但是缓存是您希望数据更快地获取它们的地方.通常,Cache是​​RAM,数据库来自HardDisk

缓存通常也是一个键值存储,因此如果您知道密钥然后从缓存中获取它,则无需运行查询.在NHibernate和EntityFrameworks中,查询缓存插入,查询作为键,所有数据都被缓存.现在,您的查询将从缓存中获取,而不是通过数据库运行.