问题
问卷中有如下这样的文档,开发者想通过 match query 搜索这些文档来使用分数。
POST sample-index-test/_doc/1
{
"first_name": "James",
"last_name" : "Osaka"
}
以下是对上述文档的示例查询:
GET sample-index-test/_explain/1
{
"query": {
"match": {
"first_name": "James"
}
}
}
上述命令给出来的结果是:
{
"_index": "sample-index-test",
"_id": "1",
"matched": true,
"explanation": {
"value": 0.2876821,
"description": "weight(first_name:james in 0) [PerFieldSimilarity], result of:",
"details": [
{
"value": 0.2876821,
"description": "score(freq=1.0), computed as boost * idf * tf from:",
"details": [
{
"value": 2.2,
"description": "boost",
"details": []
},
{
"value": 0.2876821,
"description": "idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:",
"details": [
{
"value": 1,
"description": "n, number of documents containing term",
"details": []
},
{
"value": 1,
"description": "N, total number of documents with field",
"details": []
}
]
},
{
"value": 0.45454544,
"description": "tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl)) from:",
"details": [
{
"value": 1,
"description": "freq, occurrences of term within document",
"details": []
},
{
"value": 1.2,
"description": "k1, term saturation parameter",
"details": []
},
{
"value": 0.75,
"description": "b, length normalization parameter",
"details": []
},
{
"value": 1,
"description": "dl, length of field",
"details": []
},
{
"value": 1,
"description": "avgdl, average length of field",
"details": []
}
]
}
]
}
]
}
}
如你所知,Elasticsearch 根据相关性对文档进行评分。 在为该文档建立索引后,让我们现在搜索索引。我们目前只有一份关于该索引的文档。
GET sample-index-test/_search
{
"query": {
"match": {
"first_name": "James"
}
}
}
搜索后,你将看到以下结果:
{
"took": 0,
"timed_out": false,
"_shards": {
"total": 1,
"successful": 1,
"skipped": 0,
"failed": 0
},
"hits": {
"total": {
"value": 1,
"relation": "eq"
},
"max_score": 0.2876821,
"hits": [
{
"_index": "sample-index-test",
"_id": "1",
"_score": 0.2876821,
"_source": {
"first_name": "James",
"last_name": "Osaka"
}
}
]
}
}
我想提请你注意结果的 _score 字段。 如你所见,我们文档的 _score 值为 0.2876821 。 例如,当你多次更新文档时,假设我们使用以下请求更新了记录 10 次:
POST sample-index-test/_update/1
{
"script" : "ctx._source.first_name = 'James'; ctx._source.last_name = 'Cena';"
}
或者
POST sample-index-test/_doc/1
{
"first_name": "James",
"last_name" : "Cena"
}
不会有任何添加到索引中。 我们又有了一份文件,没有了。 我们刚刚更新了文档的 last_name 字段。 让我们再次进行精确搜索并尝试查看结果:
GET sample-index-test/_search
{
"query": {
"match": {
"first_name": "James"
}
}
}
上面的命令显示的结果是:
{
"took": 0,
"timed_out": false,
"_shards": {
"total": 1,
"successful": 1,
"skipped": 0,
"failed": 0
},
"hits": {
"total": {
"value": 1,
"relation": "eq"
},
"max_score": 0.046520013,
"hits": [
{
"_index": "sample-index-test",
"_id": "1",
"_score": 0.046520013,
"_source": {
"first_name": "James",
"last_name": "Cena"
}
}
]
}
}
正如你在此处看到的,分数发生了变化。 该文档的分数现在为 0.046520013 。 但根据 TF/IDF 计算,我们需要看到与我们的第一个搜索响应相同的分数。 因为当我们将它与文档的第一个状态进行比较时,没有任何变化。 即使我没有更改 first name 字段,我也只是更改了 last_name 字段并继续搜索 first_name 。 让我们对 _explain 端点进行更多挖掘。
GET sample-index-test/_explain/1
{
"query": {
"match": {
"first_name": "James"
}
}
}
Explain API 端点将为查询和特定文档计算得分解释。 上述请求的结果如下所示:
{
"_index": "sample-index-test",
"_id": "1",
"matched": true,
"explanation": {
"value": 0.046520013,
"description": "weight(first_name:james in 0) [PerFieldSimilarity], result of:",
"details": [
{
"value": 0.046520013,
"description": "score(freq=1.0), computed as boost * idf * tf from:",
"details": [
{
"value": 2.2,
"description": "boost",
"details": []
},
{
"value": 0.046520017,
"description": "idf, computed as log(1 + (N - n + 0.5) / (n + 0.5)) from:",
"details": [
{
"value": 10,
"description": "n, number of documents containing term",
"details": []
},
{
"value": 10,
"description": "N, total number of documents with field",
"details": []
}
]
},
{
"value": 0.45454544,
"description": "tf, computed as freq / (freq + k1 * (1 - b + b * dl / avgdl)) from:",
"details": [
{
"value": 1,
"description": "freq, occurrences of term within document",
"details": []
},
{
"value": 1.2,
"description": "k1, term saturation parameter",
"details": []
},
{
"value": 0.75,
"description": "b, length normalization parameter",
"details": []
},
{
"value": 1,
"description": "dl, length of field",
"details": []
},
{
"value": 1,
"description": "avgdl, average length of field",
"details": []
}
]
}
]
}
]
}
}
去掉一些对我们来说是可选的部分。 现在让我们关注 IDF 计算。 如你所知,反向文档频率(Inverse Document Frequency)查看一个词在语料库中的常见(或不常见)程度。 这意味着我们将使用索引中的文档数来计算 IDF。有关 IDF 的更多知识,请阅读文章 “Elasticsearch:分布式计分”。
idf, computed as log(1 + (N - n + 0.5) / (n + 0.5))
正如你在上面看到的,我们使用的是文档总数,但问题是我们在索引中有一个文档,但它显示的是 10。
{
"value": 10,
"description": "n, number of documents containing term",
"details": []
},
{
"value": 10,
"description": "N, total number of documents with field",
"details": []
}
因此,如果你使用此分数来计算其他服务的内容,这就是问题所在。
为什么会这样?
Elasticsearch 使用 Lucene 并将所有文档存储在段中。 段(segment)是不可变的,文档更新操作有两步过程。 更新文档时,将创建一个新文档,并将旧文档标记为已删除。 所以,当你在 Elasticsearch 索引中创建第一个文档时,Elasticsearch 会将它保存在一个段中,并且只有一个文档。 然后你更新同一个文档 10 次; 在任何更新操作中,Elasticsearch 都会在一个段中创建另一个文档,并将最旧的文档标记为已删除。 但是当你搜索索引时,你会从段中找到最新的文档状态。 暂时删除的文档数量为10。你会再次搜索到文档的最新状态,但 Elasticsearch 会继续在内部统计它们以进行IDF 计算。 因此,每次更新后,“the number of documents with field” 和 “number of documents containing term” 都会发生变化。
解决方案
如你所知,如果你知道什么是段,这个问题会在一段时间后自行解决。 所以,如果你想自己做这件事而不等待,你需要使用 _forcemerge。 我需要在这里放一个来自 Elasticsearch 文档的解释。在我们稍微等一段时间后,我们再去搜索,我们将会看到最终的分数和我们刚开始搜索的结果是一样的。
合并通过将其中的一些合并在一起来减少每个分片中的段数,并且还释放已删除文档所使用的空间。 合并通常会自动发生,但有时手动触发合并很有用。
我们建议只强制合并只读索引(意味着索引不再接收写入)。
为了对我们的索引执行 _forcemerge,我们使用了以下请求:
POST sample-index-test/_forcemerge
根据你的索引大小,此请求可能需要一些时间,你可以通过在 Kibana 上执行以下请求来完成任务:
GET _tasks?actions=*forcemerge*&detailed
另一种方法就是等待。 Elasticsearch 还有一个调度程序和合并策略来自动合并段。 在使用强制合并之前,我建议仔细阅读相关的官方文档。文章来源:https://www.toymoban.com/news/detail-422388.html
最后,还有一个索引生命周期操作,用于使用策略执行强制合并操作。 根据你的逻辑,你可以使用不同的解决方案来获得更好的搜索评分结果。文章来源地址https://www.toymoban.com/news/detail-422388.html
到了这里,关于Elasticsearch:了解和解决文档更新后 Elasticsearch 分数的变化的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!