如何避免ElasticSearch中的索引爆炸

如何解决如何避免ElasticSearch中的索引爆炸

我有两个来自同一索引的文档，它们最初看起来像这样（此处仅显示_source值）

{
    "id" : "3","name": "Foo","property":{
        "schemaId":"guid_of_the_RGB_schema_defined_extenally","value":{
            "R":255,"G":100,"B":20
        }
    }
}

{
    "id" : "2","name": "Bar","property":{
        "schemaId":"guid_of_the_HSL_schema_defined_extenally","value":{
            "H":255,"S":100,"L":20
        }
    }
}

该架构（用于value的验证）存储在ES外部，因为它与索引无关。 如果我没有定义映射，则将value字段视为Object映射。一旦有新的子字段，它的子字段就会增长。

当前，ElasticSearch支持扁平化映射https://www.elastic.co/guide/en/elasticsearch/reference/current/flattened.html，以防止索引中的这种爆炸式增长。但是，由于受到以下限制，它对搜索内场的支持有限：As with queries,there is no special support for numerics — all values in the JSON object are treated as keywords. When sorting,this implies that values are compared lexicographically.

我需要能够查询索引以找到与给定文档匹配的文档（例如，B在[10,30]范围内）

到目前为止，我想出了一个解决方案，可以像这样构建文档

{
    "id":4,"name":"Boo","property":
    {
        "guid_of_the_normalized_RGB_schema_defined_extenally":
        {
           "R":0.1,"G":0.2,"B":0.5
        }
}

尽管它不能解决我在制图方面的爆炸性问题，但可以缓解其他一些问题。 对于字段property

，我的映射现在看起来像这样

"property": {
        "properties": {
          "guid_of_the_RGB_schema_defined_extenally": {
            "properties": {
              "B": {
                "type": "long"
              },"G": {
                "type": "long"
              },"R": {
                "type": "long"
              }
            }
          },"guid_of_the_normalized_RGB_schema_defined_extenally": {
            "properties": {
              "B": {
                "type": "float"
              },"G": {
                "type": "float"
              },"R": {
                "type": "float"
              }
            },"guid_of_the_HSL_schema_defined_extenally": {
            "properties": {
              "B": {
                "type": "float"
              },"R": {
                "type": "float"
              }
            }
          }
        }
      }

这可以解决字段名称相同但数据类型不同的情况。

有人可以建议我一个解决方案的方法，而不必担心Flattened的搜索限制吗？

解决方法

为避免映射爆炸，最好的解决方案是更好地规范化数据。 您可以在映射中设置“ dynamic”：“ strict”，如果文档中包含尚未在映射中的字段，则该文档将被拒绝。 之后，您仍然可以添加新字段，但必须先在映射中显式添加它们。

您可以添加pipeline以便在提取之前清理和规范化数据。

如果您不想或无法重新编制索引：

即使您不知道键的“中间”部分，也可以使查询变得容易，您可以将多个匹配项与星号配合使用。

GET myindex/_search
{
  "query": {
    "multi_match": {
      "query": 0.5,"fields": ["property.*.B"]
    }
  }
}

但是您仍然无法根据需要对其进行排序。 要在不触摸数据的情况下对多个“未知”字段名称进行排序，可以使用脚本：https://www.elastic.co/guide/en/elasticsearch/painless/current/painless-sort-context.html

但是也许您可以通过向索引添加动态模板来简化整个过程。

PUT test/_mapping
{
  "dynamic_templates": [
    {
      "unified_red": {
        "path_match": "property.*.R","mapping": {
          "type": "float","copy_to": "unified_color.R"
        }
      }
    },{
      "unified_green": {
        "path_match": "property.*.G","copy_to": "unified_color.G"
        }
      }
    },{
      "unified_blue": {
        "path_match": "property.*.B","copy_to": "unified_color.B"
        }
      }
    }
  ],"properties": {
    "unified_color": {
      "properties": {
        "R": {
          "type": "float"
        },"G": {
          "type": "float"
        },"B": {
          "type": "float"
        }
      }
    }
  }
}

然后，您将可以使用相同的查询来查询任何值：

GET test/_search
{
  "query": {
    "range": {
      "unified_color.B": {
        "gte": 0.1,"lte": 0.6
      }
    }
  }
}

对于已经存在的字段，您必须在映射上自己添加copy_to，然后运行_update_by_query来填充它们。