我有一个包含多个字段的~50K文档的索引。其中一个字段是“内容”，其中包含一个文本（可能只是几个单词或非常大的文章）。 在文档中，关于“内容”字段有许多重复。 我想添加一个group_id字段，该字段将指示它所属的“内容”重复文档组。
我尝试使用“匹配”和“more_like_this”，但它们似乎没有返回完全相同的副本，而是返回几乎重复的副本。
实施例： 给出以下索引：
{
"author": "name1",
"content": "text1"
},
{
"author": "name2",
"content": "text2"
}
{
"author": "name3",
"content": "text1"
}
{
"author": "name4",
"content": "text2"
}
{
"author": "name5",
"content": "text3"
}
我想得到：
{
"author": "name1",
"content": "text1",
"group_id: 0
},
{
"author": "name2",
"content": "text2",
"group_id: 1
}
{
"author": "name3",
"content": "text1",
"group_id: 0
}
{
"author": "name4",
"content": "text2",
"group_id: 1
}
{
"author": "name5",
"content": "text3",
"group_id: 2
}
谢谢！
答案 0 :(得分：0)
我猜你的案例中的内容是一个经过分析的字段 - 这是默认的，你也需要能够进行全文搜索查询。但这意味着它实际上并没有以完整的原始形式编入索引，因此您的Elasticsearch无法找到该字段的精确字符串匹配。您只能使用以下类型映射找到未分析字段的精确字符串匹配：
{
"content": {
"type": "string",
"index": "not_analyzed"
}
}
然而！在您的情况下，这实际上是一个非常糟糕的主意，原因有二：首先，您将无法再对此字段进行全文搜索，因此无论是否进行分析，您都必须对其进行两次索引。其次，因为它可能具有相当大的值，这对于作为整体的索引和搜索来说是低效的。
您的实际要求是不要与Elasticsearch进行大型字符串匹配，而是按内容值对文档进行分组。更好的方法是在文档中添加一个字段，该字段包含内容字段的摘要（哈希），然后按该字段分组。摘要不需要字符串字段，将数字保持为数字实际上是有意义的。查看为独特性和速度设计的一些散列算法，如MurmurHash3，它可以产生32位或128位哈希值。然后迭代所有文档并更新它们。