我配置了Solr 4.4.0核心,其中包含大约630k文档,原始大小约为10 GB.为了查询和突出显示,每个字段都被复制到文本字段.当我执行没有突出显示的搜索时,结果会在大约100毫秒内返回,但是当启用突出显示时,相同的查询需要10-11秒.我还注意到,对相同术语的后续查询持续大约需要10-11秒.
我对该领域的初始配置如下
<field name="text" type="text_general" indexed="true" stored="true"
multiValued="true"
omitNorms="true"
termPositions="true"
termVectors="true"
termOffsets="true" />
Run Code Online (Sandbox Code Playgroud)
发送的查询类似于以下内容
http://solrtest:8983/solr/Incidents/select?q=error+code&fl=id&wt=json&indent=true&hl=true&hl.useFastVectorHighlighter=true
Run Code Online (Sandbox Code Playgroud)
我的所有研究似乎都没有提供为什么突出表现如此糟糕的线索.一时兴起,我决定看看omitNorms = true属性是否有效,我修改了文本字段,清除了数据,并从头开始重新加载.
<field name="text" type="text_general" indexed="true" stored="true"
multiValued="true"
termPositions="true"
termVectors="true"
termOffsets="true" />
Run Code Online (Sandbox Code Playgroud)
奇怪的是,这似乎解决了问题.突出显示的初始查询花费2-3秒,后续查询花费不到100毫秒.
但是,因为我们想要omitNorms = true,我的永久解决方案是拥有两个 "text"字段的副本,一个具有属性,另一个没有.这个想法是针对一个字段执行查询并突出显示另一个字段.所以现在架构看起来像
<field name="text" type="text_general" indexed="true" stored="true"
multiValued="true"
omitNorms="true"
termPositions="true"
termVectors="true"
termOffsets="true" />
<field name="text2" type="text_general" indexed="true" stored="true"
multiValued="true"
termPositions="true"
termVectors="true"
termOffsets="true" />
Run Code Online (Sandbox Code Playgroud)
查询如下
http://solrtest:8983/solr/Incidents/select?q=error+code&fl=id&wt=json&indent=true&hl=true&hl.fl=text2&hl.useFastVectorHighlighter=true
Run Code Online (Sandbox Code Playgroud)
同样,数据被清除并重新加载相同的630k文档,但这次索引大小约为17 GB.(正如预期的那样,因为"text"字段中的内容是重复的.)
问题是性能数字恢复到每次运行的最初10-11秒.无论是第一次删除omitNorms都是侥幸还是还有其他事情正在发生.我不知道是什么......
使用jVisualVM捕获CPU示例显示使用大多数CPU的以下两种方法
org.apache.lucene.search.vectorhighlight.FieldPhraseList.<init>() 8202 ms (72.6%)
org.eclipse.jetty.util.BlockingArrayQueue.poll() 1902 ms (16.8%)
Run Code Online (Sandbox Code Playgroud)
我看到init方法低至54%,民意测验数高达30%.
有任何想法吗?我可以寻找任何其他地方来追踪瓶颈?
谢谢
更新
我用相同的数据集但不同的配置做了一堆测试,这是我发现的......虽然我不明白我的发现.
这是我测试的方式 - >
我找到了什么 - >
我很困惑....
我知道这有点过时了,但我遇到了同样的问题,并想加入我们的方法。
我们正在从一堆二进制文档中索引文本,并且需要 Solr 维护一些有关文档和文本的元数据。用户需要根据内容中的元数据和全文搜索来搜索文档,并查看相关内容的突出显示和片段。如果突出显示/片段的内容位于每个文档中的较远位置(例如第 50 页而不是第 2 页),性能问题会变得更糟
由于突出显示性能不佳,我们不得不将每个文档分解为多个 solr 记录。根据内容字段的长度,我们将其分成更小的块,将元数据属性复制到每个记录,并为每个记录分配每个文档的唯一 ID。然后在查询时,我们将搜索所有这些记录的内容字段,并按我们分配的唯一字段进行分组。由于内容字段较小,Solr 不必深入每个内容字段,而且从最终用户的角度来看,这是完全透明的;尽管它确实为我们增加了一些索引开销。
此外,如果您选择这种方法,您可能需要考虑在每个“子文档”之间稍微重叠秒数,以确保如果在两秒边界处存在短语匹配,它将正确返回。
希望能帮助到你。