什么时候在Sitecore 7版本中明确使用SOLR而不是Lucene？

Posted 2021-05-04

我的客户没有预算来设置和维护SOLR服务器以在其生产环境中使用。如果我正确理解Sitecore 7内容搜索API，那么配置使用Lucene的东西并不是什么大问题。在大多数情况下，配置将类似，代码将相同，并且稍后可以交换SOLR服务器。

网站建设有

• 分面搜索页面
• 列出登陆组件以及将利用Content Search API的其他页面上的组件
• 带自定义刻面的铲斗

该网站有大约5,000页和不包括媒体库项目的组件。是否有任何关于简单使用Lucene的担忧？

主要的问题是，在您的架构或设计阶段，您何时知道您应该选择SOLR而不是Lucene？引导您推荐的主要标志是什么？

答案

我认为如果您在有限的预算下与客户打交道，那么Lucene将能够很好地工作并且能够很好地完成您正在进行的工作。您提到的所有内容都得到了Lucene实施的全面支持。

在Sitecore场景中，我会开始考虑Solr：

• 你需要索引大量的项目 - 比如说5万以上 - Lucene很满意这些数字，但Solr改进了查询缓存，并且是为这些大量的项目而设计的。
• 搜索层的弹性具有最大的业务重要性（即站点纯粹由搜索驱动） - Solr使用SolrCloud提供更强大的复制/分片和故障转移系统。
• 在其他应用程序中重新使用搜索层非常重要（非Sitecore） - Solr是一个搜索应用程序，因此可以使用XML / JSON等通过HTTP访问，这使得与外部系统的集成更加容易。
• 你需要一些Lucene没有的Solr特定的附加功能。

..但正如你所说，如果你想在稍后阶段换掉Lucene for Solr，我们一直在努力确保这个过程尽可能简单。值得注意的几点：

• 虽然您的LINQ查询将保持不变，但您的配置将略有不同，需要注意端口。
• 了解Solr如何作为一个应用程序以及架构如何工作是很重要的，但有一些很棒的书籍和丰富的知识。
• Solr有一些略微不同（较新的）分析仪和评分机制，因此您的搜索结果可能略有不同（有时候客户可能会对此感到震惊：P）

..但我认为这些是你可以随着时间的推移积累并与客户一起评估的东西。我相信这里有更多的积分，如果他们想到这些积分，其他人就可以加入。希望这可以帮助 ：）

另一答案

斯蒂芬几乎涵盖了这个问题 - 但我只想添加另一个场景。您需要考虑生产环境中的服务器设置。如果您要在负载均衡器后面使用多个内容传送服务器，我会从一开始就考虑Solr，因为尝试确保每个传送服务器上的Lucene索引在100％的时间内同步可能会很痛苦。

另一答案

我建议您在开始考虑多张CD时就制定一份来自Lucene的逃生计划，原因如下：

A）每个服务器必须维护自己的索引副本：

1. 任何意外重启都可能导致一些文档无法添加到索引中，从而使索引与服务器不同。这将导致同一页面显示不同的CD
2. 每个服务器必须执行索引更新 - 使用CPU和磁盘空间;发布操作结束后响应率下降= /
3. 根据安全指南，CD应该删除Sitecore Shell UI，因此无法从控制面板= 重建索引

B）Lucene不适用于大量内容。每个搜索操作大致如下：

1. 创建一个大小等于索引中文档总数的数组
2. 如果文档与搜索匹配，请在数组中设置标志

虽然这对于低尺寸索引（~10K元素）来说就像一个魅力，但一旦内容量增长，就会产生巨大的性能下降。

分配的数组以Large Object Heap结尾，默认情况下不压缩，从而快速分段。

场景：

1. 执行搜索100K文档 - >在内存中创建的巨大数组
2. 在另一个线程中再执行一次搜索 - >创建一个更大的阵列
3. 更新索引 - >现在100K + 10个文档
4. 第一次行动完成; LOH有100K阵列的空间
5. 再次触发搜索 - >创建> 100K + 10阵列;释放内存“漏洞”不够大，因此需要更多RAM。
6. w3wp.exe进程继续消耗越来越多的RAM

这是Analytics Aggregation的常见情况，因为索引一次由多个线程填充。你会在处理实例上看到一段时间后使用大量的RAM。

C）最后一次Lucene.NET release是在5年前完成的。

而SOLR正在积极开发中。

越早切换到SOLR，就越容易。