突出显示时,Solr性能非常慢

Jas*_*son 15 lucene solr

我配置了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%.

有任何想法吗?我可以寻找任何其他地方来追踪瓶颈?

谢谢

更新

我用相同的数据集但不同的配置做了一堆测试,这是我发现的......虽然我不明白我的发现.

  • 快速突出显示性能要求omitNorms不设置为true.(不知道omitNorms和突出显示有什么关系.)
  • 但是,如果对同一字段执行查询和突出显示(即df = hl.fl),这似乎只是真的.(再次,不知道为什么......)
  • 然而,另一个是,仅针对模式中存在的默认文本字段完成.

这是我测试的方式 - >

  • 测试反对约525,000份文件
  • 几乎所有字段都被复制到多值文本字段
  • 在某些测试中,几乎所有字段都复制到发送多值text2字段(此字段与文本相同,但它具有相反的omitNorms设置
  • 每次更改配置时,Solr实例都会停止,数据文件夹已删除,实例已重新启动

我找到了什么 - >

  • 当仅仅是文本中使用字段和omitNorms =真,性能是坏的(10秒的响应时间)
  • 当仅仅是文本中使用字段和omitNorms =真不存在,表现得大(亚秒响应时间)
  • 文字不会omitNorms =真文本2一样,机智突出对查询文本子第二次返回,其他所有的组合导致10-30秒的响应时间.
  • 文字确实有omitNorms =真文本2没有没有,在7-10秒高亮返回查询的组合.

我很困惑....

use*_*270 1

我知道这有点过时了,但我遇到了同样的问题,并想加入我们的方法。

我们正在从一堆二进制文档中索引文本,并且需要 Solr 维护一些有关文档和文本的元数据。用户需要根据内容中的元数据和全文搜索来搜索文档,并查看相关内容的突出显示和片段。如果突出显示/片段的内容位于每个文档中的较远位置(例如第 50 页而不是第 2 页),性能问题会变得更糟

由于突出显示性能不佳,我们不得不将每个文档分解为多个 solr 记录。根据内容字段的长度,我们将其分成更小的块,将元数据属性复制到每个记录,并为每个记录分配每个文档的唯一 ID。然后在查询时,我们将搜索所有这些记录的内容字段,并按我们分配的唯一字段进行分组。由于内容字段较小,Solr 不必深入每个内容字段,而且从最终用户的角度来看,这是完全透明的;尽管它确实为我们增加了一些索引开销。

此外,如果您选择这种方法,您可能需要考虑在每个“子文档”之间稍微重叠秒数,以确保如果在两秒边界处存在短语匹配,它将正确返回。

希望能帮助到你。