什么时候在 Sitecore 7 构建中绝对使用 SOLR 而不是 Lucene？

Question

我的客户没有预算来设置和维护 SOLR 服务器以在其生产环境中使用。如果我正确理解了 Sitecore 7 内容搜索 API，那么配置使用 Lucene 并不是什么大问题。大部分配置类似，代码相同，以后可以换一个SOLR服务器。

网站建设有

• 分面搜索页面
• 在着陆页和其他将利用 Content Search API 的页面上列出组件
• 具有自定义构面的存储桶

该网站有大约 5,000 个页面和组件，不包括媒体库项目。单纯使用 Lucene 有什么顾虑吗？

主要问题是，在您的架构或设计阶段，您何时知道绝对应该选择 SOLR 而不是 Lucene？导致您建议这样做的主要迹象是什么？

Answer 1

我认为，如果您正在与预算有限的客户打交道，那么 Lucene 将工作得非常好，并且在您正在做的事情的规模上表现出色。 Lucene 的实现完全支持您提到的所有内容。

在 Sitecore 场景中，如果满足以下条件，我会开始考虑 Solr：

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

.. 但正如您所说，如果您想在稍后阶段将 Lucene 换成 Solr，我们已经努力确保该过程尽可能简单。这里值得注意的几点：

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

.. 但我认为这些是您可以随着时间的推移积累起来并与客户一起评估的东西。我相信这里还有更多要点，如果他们想到它们，其他人可以加入。希望这会有所帮助:)

Answer 2

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

Answer 3

我建议您在开始考虑多张 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，就越容易。