缓存与索引
缓存解决方案和索引解决方案之间的真正区别是什么？在我看来，索引解决方案实际上是具有运行搜索查询功能（例如：Elastic
Search）的缓存。是否有任何真正的理由在同一项目中同时使用缓存解决方案和索引解决方案，或者索引解决方案基本上会使其他任何缓存变得多余？
示例：假设我对ElasticSearch使用NEST，它将存储并返回POCO；如果我随后查询ElasticSearch并已将POCO返回给我，那是否不认为使用的是从ElasticSearch返回的缓存对象？
目前，我使用ICacheManager接口将数据存储在缓存中。
return CacheManager.Get(cacheKey, () =>{
// return something...
});
使用ElasticSearch会变得多余吗？
感谢大家的答案。我完全了解高速缓存是什么，并且已经理解了用于文本搜索的索引背后的一般思想，所以我只是真正想知道索引是否已兼用作高速缓存，因此是否会使其他任何高速缓存冗余。毕竟，当一个性能很好时，我不想在内存中保留2个缓存（例如：ElasticSearch
+
Redis）。我想我现在有一个更好的主意。尤其是当我意识到并非所有字段都始终存储在索引中时，因此至少在某些情况下，我们无论如何都需要从缓存中获取对象或直接从db中获取对象。谢谢大家！
回答：
缓存的全部目的是
地返回已经请求的数据。高速缓存的一个限制是，它们也不能太大，因为查找时间会增加，因此会破坏首先拥有高速缓存的目的。话虽这么说，如果您计划在数据库中拥有几百万条记录，也就不足为奇了，尽管由于RAM越来越多，对它们全部进行索引还是很困难的，这并不奇怪。越来越便宜，您也许可以将所需的全部存储在内存中。您还需要问自己是否需要在多个主机之间分配缓存（无论是现在还是将来）。
考虑到ES中的查找和查询非常快（+
ES不仅为您带来了很多好处，例如计分），即通常比从数据库中检索相同数据要快，因此将ES用作缓存是有意义的。我看到的一个问题是一个常见的问题，即，一旦开始复制数据（DB->
ES），就需要确保两个存储都不会不同步。
现在，如果您另外将高速缓存放入该混合中，那么它将是第三个要维护的数据存储，并确保与主数据存储一致。如果您知道自己的数据非常稳定，即编写然后不经常更新，那可能没问题，但是在设计数据访问策略时，始终需要牢记这一点。
就像@paweloque所说的，最终一切都取决于您的确切用例。每个问题都不尽相同，我可以证明，过去五年左右围绕ES开展了数十个项目之后，我从未见过两个项目以相同的方式进行配置。在某些特定情况下，缓存可能有意义，而在其他情况下则根本没有意义。
您需要认真考虑如何以及在何处存储数据，谁在要求它们（以什么速率），谁在创建/更新它们（以什么速率），但是最后，最佳实践是保持您的堆栈尽可能精简，只需要很少的组件，每个组件都是您必须了解，集成，维护，调整和监视的潜在瓶颈。
最后，我还要添加一件事：添加缓存或索引应被视为对软件堆栈的性能优化。众所周知，“过早的优化是万恶之源”，您应该首先只使用数据库，测量性能，对其进行负载测试，然后见证它可能不支持负载。只有这样，您才可以根据需要决定将高速缓存和/或索引扔给它。再次，进行负载测试，测量然后决定。如果您每天只有十个用户发出几个请求，那么仅拥有一个数据库可能就可以了。您必须了解何时以及为什么需要在Babel塔上添加另一层，但是最重要的是，您一次需要添加一层，并查看该层如何提高/降低堆栈的稳定性。
最后但并非最不重要的一点是，您可以从使用ES作为缓存（主要是键值存储和对象缓存）的人们那里找到一些在线文章。
以上是 缓存与索引 的全部内容， 来源链接： utcz.com/qa/397382.html
