我的客户没有预算来设置和维护SOLR服务器以在其生产环境中使用。如果我正确理解Sitecore 7内容搜索API,那么配置使用Lucene的东西并不是什么大问题。在大多数情况下,配置将类似,代码将相同,并且稍后可以交换SOLR服务器。
网站建设有
该网站有大约5,000页和不包括媒体库项目的组件。是否有任何关于简单使用Lucene的担忧?
主要的问题是,在您的架构或设计阶段,您何时知道您应该选择SOLR而不是Lucene?引导您推荐的主要标志是什么?
我认为如果您在有限的预算下与客户打交道,那么Lucene将能够很好地工作并且能够很好地完成您正在进行的工作。您提到的所有内容都得到了Lucene实施的全面支持。
在Sitecore场景中,我会开始考虑Solr:
..但正如你所说,如果你想在稍后阶段换掉Lucene for Solr,我们一直在努力确保这个过程尽可能简单。值得注意的几点:
..但我认为这些是你可以随着时间的推移积累并与客户一起评估的东西。我相信这里有更多的积分,如果他们想到这些积分,其他人就可以加入。希望这可以帮助 :)
斯蒂芬几乎涵盖了这个问题 - 但我只想添加另一个场景。您需要考虑生产环境中的服务器设置。如果您要在负载均衡器后面使用多个内容传送服务器,我会从一开始就考虑Solr,因为尝试确保每个传送服务器上的Lucene索引在100%的时间内同步可能会很痛苦。
我建议您在开始考虑多张CD时就制定一份来自Lucene的逃生计划,原因如下:
A)每个服务器必须维护自己的索引副本:
B)Lucene不适用于大量内容。每个搜索操作大致如下:
虽然这对于低尺寸索引(~10K元素)来说就像一个魅力,但一旦内容量增长,就会产生巨大的性能下降。
分配的数组以Large Object Heap结尾,默认情况下不压缩,从而快速分段。
场景:
这是Analytics Aggregation的常见情况,因为索引一次由多个线程填充。你会在处理实例上看到一段时间后使用大量的RAM。
C)最后一次Lucene.NET release是在5年前完成的。
而SOLR正在积极开发中。
越早切换到SOLR,就越容易。