Solr 查询为 Solr Cloud 和主从设置上的相同内容提供不同的分数

Question

我们在 Solr 上查询时遇到了奇怪的问题。 Solr cloud 给出不同的分数，然后 Solr master 设置相同的内容。另一个问题是 Solr Cloud 正在为不同请求中的相同内容和相同查询更改此分数，这导致多次调用中的文档顺序不同。在 Master salve 分数是固定的，在不同的呼叫中不会改变。

这里是主从上相同记录的分数计算

63372217#83#-2128821991: " 8.439063 = boost(((title:narendra | 关键字:narendra) (title:mod | 关键字:mod))~1,1.0/(3.16E-11*float(ms( const(1524117881692),date(effectivetriedate)))+1.0))，乘积：9.141734 = 总和：9.141734 = 最大值：9.141734 = 权重（标题：mod in 10186378）[SchemaSimilarity]，结果：9.141734 = score（ 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(keywords:mod in 10186378) [SchemaSimilarity]，结果：8.783037 = score(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(有效试用日期)=2018-03-19T18:09:00Z))+1.0)", 60930380#83#-2128833038: " 8.3860035 = boost(((title:narendra | 关键字:narendra) (title:mod | 关键字: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 = score（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 = max of: 8.783037 = weight(keywords:mod in 3310267) [SchemaSimilarity]，结果：8.783037 = score(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),日期（有效试用日期）=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 中的默认行为是在每个分片上单独计算分数，然后再合并到层次结构的更高层。这假设您有相当数量的文档，并且无论其内容如何，​​这些文档都随机（且均匀地）分布在您的分片中。如果是这种情况，分数应该足够相似，以避免引起更大的问题。

在您的情况下，这就是创建不同分数的原因 - 在您的“单个节点回答查询”情况下（即您的主/从设置），计数与您有集群（SolrCloud）设置时的计数不同 - 在集群中设置文档分布在多个服务器上，默认情况下，只有本地计数用于每个节点的评分。比较查询之间的分数（尤其是随着时间的推移会发生变化的新近度提升）也很困难。我的猜测是，对于那些文档，您的分数非常接近，以至于其中一个被评为最相关的文档确实悬而未决，并且分数根据每个分片中存在的文档数量而变化（即添加另一个document 到其中一个分片会在本地更改该分片的分数）。

一种可能的解决方案是使用分布式 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"/>