我们正在讨论规范化的数据集，其中包含几个不同的实体，这些实体通常必须与相关记录一起访问。我们希望能够搜索所有这些数据。我们还希望使用缓存层来存储视图就绪的非规范化数据。
由于像Elasticsearch和Solr这样的搜索引擎速度很快，而且由于在很多情况下将相同的数据放入搜索引擎和缓存层似乎是合适的，所以我至少读过一些关于组合两个角色。至少在表面层面上这是有意义的，但是我还没有找到关于这种架构的优点和缺点的书面文章。那么：将搜索引擎用作缓存是合适的，还是将一个层用于两个角色，这是一个明智但又愚蠢的情况？
答案 0 :(得分：1)
我听说ES用于什么是真正有用的设置：完整的上下文搜索并与辅助存储并行使用。在这些设置中，数据未存储（但可以是） - "store": "no" - 并且在其索引中使用ES搜索后，实际记录是从第二个存储级别检索的 - 通常是RDBMS - 假设ES持有引用RDBMS中的实际记录（某种ID）。如果您对速度和“搜索”方面的二级存储不满意，我不明白为什么您无法设置ES群集来为您提供缺失的部分。
这里的缺点是构建ES数据结构所花费的时间，因为ES在表示关系时不如RDBMS好。它确实不需要，它的主要工作和目的是不同的。实际上，对于要搜索的非规范化数据集更为快乐。
另一个缺点是保持两个存储系统同步的复杂性，这需要一些思考。但是，一旦初始设置和架构到位，之后应该很容易。
答案 1 :(得分：1)
这些家伙已经做到了......
http://www.artirix.com/elasticsearch-as-a-smart-cache/
我看到的问题不在于读取速度，而在于写入速度。将事物添加到缓存（迫使线程到磁盘和索引合并）会产生相当大的成本。
如果你在AWS上，像memcached或elastic cache这样的东西在插入和读取方面都要高效得多。
“Elasticsearch和Solr很快”是相对的，缓存基础设施通常以一位数毫秒范围来衡量，对于插入来说也是如此。这些搜索引擎至少以10毫秒的读数来衡量，而写入则要高得多。
答案 2 :(得分：0)
使用搜索引擎的唯一推荐方法是创建与最常访问的非规范化数据访问模式匹配的索引。如果需要，可以将其称为缓存。为了搜索它是完美的，因为它足够快。 建议在那里添加缓存 - 统计＆＃34;聚合＆＃34;查询 - ＆＃34;欧洲排名前100位的酒店＆＃34;作为一个很好的例子。
答案 3 :(得分：0)
可能您可以考虑内存中的lucene索引，而不是SOLR或elasticsearch。 Here is an example