使用搜索引擎作为缓存层是否合适？
Is it appropriate to use a search engine as a caching layer?
我们谈论的是规范化数据集，其中包含几个必须经常与相关记录一起访问的不同实体。我们希望能够搜索所有这些数据。我们还想使用缓存层来存储可查看的非规范化数据。
由于像 Elasticsearch 和 Solr 这样的搜索引擎速度很快，而且在很多情况下将相同的数据同时放入搜索引擎和缓存层似乎是合适的，所以我至少读过人们将两个角色。这至少在表面上是有意义的，但我还没有找到很多关于这种架构的优缺点的文章。那么：使用搜索引擎作为缓存是否合适，或者使用一层作为两个角色是否明智？
我听说过将 ES 用于真正有用的设置：完整上下文搜索并与辅助存储并行使用。在这些设置中，数据未存储（但可以存储）- "store": "no" - 在使用 ES 在其索引中进行搜索后，实际记录是从第二个存储级别（通常是 RDBMS）检索到的，因为 ES 持有一个对 RDBMS 中实际记录的引用（某种 ID）。如果您对二级存储在速度和 "search" 方面给您带来的任何好处不满意，我不明白为什么您不能设置 ES 集群来弥补缺失的部分。
这里的缺点是花费时间来构建 ES 数据结构，因为 ES 在表示关系方面不如 RDBMS。而且它确实不需要，它的主要工作和目的是不同的。而且，实际上，更喜欢搜索一组非规范化的数据。
另一个缺点是保持两个存储系统同步的复杂性，这需要提前考虑。但是，一旦初始设置和架构到位，之后应该很容易。
这些人做到了...
http://www.artirix.com/elasticsearch-as-a-smart-cache/
我看到的问题不是读取速度，而是写入速度。将内容添加到缓存（强制假脱机到磁盘和索引合并）会产生相当高的成本。
memcached 或 elastic cache 之类的东西（如果您在 AWS 上）在插入和读取方面效率更高。
"Elasticsearch and Solr are fast" 是相对的，缓存基础设施通常在个位数毫秒范围内测量，插入也是如此。这些搜索引擎的读取时间至少为 10 毫秒，而写入时间要高得多。
唯一推荐的使用搜索引擎的方法是创建与您最常访问的非规范化数据访问模式相匹配的索引。如果需要，您可以将其称为缓存。对于搜索来说，它是完美的，因为它足够快。
建议为其添加缓存 - "aggregated" 查询的统计信息 - "Top 100 hotels in Europe"，作为一个很好的例子。
也许你可以考虑使用内存中的 lucene 索引，而不是 SOLR 或 elasticsearch。 Here is an example
我们谈论的是规范化数据集，其中包含几个必须经常与相关记录一起访问的不同实体。我们希望能够搜索所有这些数据。我们还想使用缓存层来存储可查看的非规范化数据。
由于像 Elasticsearch 和 Solr 这样的搜索引擎速度很快，而且在很多情况下将相同的数据同时放入搜索引擎和缓存层似乎是合适的，所以我至少读过人们将两个角色。这至少在表面上是有意义的，但我还没有找到很多关于这种架构的优缺点的文章。那么：使用搜索引擎作为缓存是否合适，或者使用一层作为两个角色是否明智？
我听说过将 ES 用于真正有用的设置：完整上下文搜索并与辅助存储并行使用。在这些设置中，数据未存储（但可以存储）- "store": "no" - 在使用 ES 在其索引中进行搜索后，实际记录是从第二个存储级别（通常是 RDBMS）检索到的，因为 ES 持有一个对 RDBMS 中实际记录的引用（某种 ID）。如果您对二级存储在速度和 "search" 方面给您带来的任何好处不满意，我不明白为什么您不能设置 ES 集群来弥补缺失的部分。
这里的缺点是花费时间来构建 ES 数据结构，因为 ES 在表示关系方面不如 RDBMS。而且它确实不需要，它的主要工作和目的是不同的。而且，实际上，更喜欢搜索一组非规范化的数据。
另一个缺点是保持两个存储系统同步的复杂性，这需要提前考虑。但是，一旦初始设置和架构到位，之后应该很容易。
这些人做到了...
http://www.artirix.com/elasticsearch-as-a-smart-cache/
我看到的问题不是读取速度，而是写入速度。将内容添加到缓存（强制假脱机到磁盘和索引合并）会产生相当高的成本。
memcached 或 elastic cache 之类的东西（如果您在 AWS 上）在插入和读取方面效率更高。
"Elasticsearch and Solr are fast" 是相对的，缓存基础设施通常在个位数毫秒范围内测量，插入也是如此。这些搜索引擎的读取时间至少为 10 毫秒，而写入时间要高得多。
唯一推荐的使用搜索引擎的方法是创建与您最常访问的非规范化数据访问模式相匹配的索引。如果需要，您可以将其称为缓存。对于搜索来说，它是完美的，因为它足够快。 建议为其添加缓存 - "aggregated" 查询的统计信息 - "Top 100 hotels in Europe"，作为一个很好的例子。
也许你可以考虑使用内存中的 lucene 索引，而不是 SOLR 或 elasticsearch。 Here is an example