Question

我们在查询Solr时面临着奇怪的问题。 Solr云给出不同的分数然后Solr master为相同的内容设置。另外一个问题是Solr Cloud正在为不同请求中的相同内容和相同查询更改此分数，这导致多个呼叫中的文档顺序不同。在主要药膏得分是固定的，并且在不同的通话中没有变化。

以下是主奴隶上相同记录的分数计算

63372217＃83＃-2128821991：“8.439063 = boost（（（标题：narendra | keywords：narendra）（标题：mod | keywords：mod））~1,1.0 /（3.16E-11 * float（ms（ms const（1524117881692），date（effectivetriedate）））+ 1.0）），乘积：9.141734 =总和：9.141734 =最大值：9.141734 =体重（标题：mod in 10186378）[SchemaSimilarity]，结果：9.141734 =得分（ doc = 10186378，freq = 1.0 = termFreq = 1.0），乘积：9.458362 = idf（docFreq = 805，docCount = 10322376）0.96652406 = tfNorm，计算自：1.0 = termFreq = 1.0 1.2 =参数k1 0.75 =参数b 6.5560484 = avgFieldLength 7.111111 = fieldLength 8.783037 = weight（关键字：mod in 10186378）[SchemaSimilarity]，结果：8.783037 =得分（doc = 10186378，freq = 1.0 = termFreq = 1.0），乘积：8.783037 = idf（docFreq = 886，docCount = 5782333）1.0 = tfNorm，计算自：1.0 = termFreq = 1.0 1.2 =参数k1 0.0 =参数b（字段省略的标准）0.92313594 = 1.0 /（3.16E-11 * float（ms（const（1524117881692），date（ effectivetriedate）= 2018-03-19T18：09：00Z））+ 1.0）“， 60930380＃83＃-2128833038：“8.3860035 = boost（（（title：narendra | keywords：narendra）（title：mod | keywords：mod））~1,1.0 /（3.16E-11 * float（ms（const）（1524117881692）），date（effectivetriedate）））+ 1.0）），产品：12.907965 =总和：4.1249275 =最大值：4.1249275 =重量（关键词：narendra in 3310267）[SchemaSimilarity]，结果：4.1249275 =得分（doc = 3310267），freq = 1.0 = termFreq = 1.0），乘积：4.1249275 = idf（docFreq = 93469，docCount = 5782333）1.0 = tfNorm，计算自：1.0 = termFreq = 1.0 1.2 =参数k1 0.0 =参数b（字段省略的范数））8.783037 =最大值：8.783037 =重量（关键词：mod在3310267中）[SchemaSimilarity]，结果：8.783037 =得分（doc = 3310267，freq = 1.0 = termFreq = 1.0），乘积：8.783037 = idf（docFreq = 886），docCount = 5782333）1.0 = tfNorm，计算自：1.0 = termFreq = 1.0 1.2 =参数k1 0.0 =参数b（字段省略的范数）0.6496767 = 1.0 /（3.16E-11 * float（ms（const（1524117881692）， date（effectivetriedate）= 2017-10-03T18：02：13Z））+ 1.0）“

云设置

,63372217#83#-2128821991=
8.45718 = boost(((title:narendra | keywords:narendra) (title:mod |   keywords:mod))~1,1.0/(3.16E- 11*float(ms(const(1524118417608),date(effectivetriedate)))+1.0)), product of:
  9.161503 = sum of:
9.161503 = max of:
  9.161503 = weight(title:mod in 49446) [SchemaSimilarity], result of:
    9.161503 = score(doc=49446,freq=1.0 = termFreq=1.0
), product of:
      9.522509 = idf(docFreq=298, docCount=4078658)
      0.96208924 = tfNorm, computed from:
        1.0 = termFreq=1.0
        1.2 = parameter k1
        0.75 = parameter b
        6.4863324 = avgFieldLength
        7.111111 = fieldLength
  8.878012 = weight(keywords:mod in 49446) [SchemaSimilarity], result of:
    8.878012 = score(doc=49446,freq=1.0 = termFreq=1.0
), product of:
      8.878012 = idf(docFreq=319, docCount=2291617)
      1.0 = tfNorm, computed from:
        1.0 = termFreq=1.0
        1.2 = parameter k1
        0.0 = parameter b (norms omitted for field)
0.9231215 = 1.0/(3.16E-11*float(ms(const(1524118417608),date(effectivetriedate)=2018-03-19T18:09:00Z))+1.0)  


63372217#83#-2128821991=
8.499447 = boost(((title:narendra | keywords:narendra) (title:mod | keywords:mod))~1,1.0/(3.16E- 11*float(ms(const(1524118478192),date(effectivetriedate)))+1.0)), product of:
  9.207306 = sum of:
9.207306 = max of:
  9.207306 = weight(title:mod in 90314) [SchemaSimilarity], result of:
    9.207306 = score(doc=90314,freq=1.0 = termFreq=1.0
), product of:
      9.534913 = idf(docFreq=306, docCount=4240239)
      0.96564126 = tfNorm, computed from:
        1.0 = termFreq=1.0
        1.2 = parameter k1
        0.75 = parameter b
        6.5421023 = avgFieldLength
        7.111111 = fieldLength
  8.90691 = weight(keywords:mod in 90314) [SchemaSimilarity], result of:
    8.90691 = score(doc=90314,freq=1.0 = termFreq=1.0
), product of:
      8.90691 = idf(docFreq=320, docCount=2366191)
      1.0 = tfNorm, computed from:
        1.0 = termFreq=1.0
        1.2 = parameter k1
        0.0 = parameter b (norms omitted for field)

请在这里建议。

Answer 1

Solr中的默认行为是，在层次结构中向上合并之前，会在每个分片上自行计算分数。这假定您拥有相当数量的文档，并且无论文档的内容如何，文档都会在您的分片中随机（均匀地）传播。如果是这种情况，那么得分应该足够相似，以避免它导致任何更大的问题。

在您的情况下，这就是创建不同分数的原因 - 在您的＆＃34;单个节点中回答查询＆＃34; case（即主/从设置），计数与集群（SolrCloud）设置时不同 - 在集群设置中，文档分布在多个服务器上，默认情况下，只有本地计数用于每个节点的评分。比较不同查询的分数（尤其是随着时间的推移会随着时间的推移而变化的新近度提升）也很难。我的猜测是，你所拥有的分数彼此如此接近，以至于那些文件中的其中一个是最相关的，并且分数根据每个分片中存在的文档数量而变化（即添加另一个其中一个分片的文档会更改该分片的本地分数。）

一种可能的解决方案是使用分布式IDF - 即在整个集合中使用频率而不仅仅是本地分片的评分方法。完成by configuring the stats cache以使用ExactStatsCache，ExactSharedStatsCache或LRUStatsCache代替默认LocalStatsCache。 LocalStatsCache被描述为：

LocalStatsCache：这仅使用本地术语和文档统计信息来计算相关性。如果在分片中具有统一的术语分布，则可以很好地工作。如果没有配置<statsCache>，则此选项是默认选项。

虽然ExactStatsCache的说明解释了它使用了集合范围的值：

ExactStatsCache：此实现使用全局值（跨集合）来处理文档频率。

另外两个是ExactStatsCache的不同缓存实现。

您可以更改solrconfig.xml中使用的statscache：

<statsCache class="org.apache.solr.search.stats.ExactStatsCache"/>

Solr查询为Solr Cloud和Master Slave设置的相同内容提供不同的分数

1 个答案: