我的客户没有预算来设置和维护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%的时间内同步可能会很痛苦.