(56) ElasticSearch's dynamic mapping strategy

  This article is divided into 3 parts to talk about ElasticSearch's dynamic mapping strategy.

  1. Dynamic unfamiliar field processing configuration

  What happens when I add a document and encounter fields that are not defined in the mapping? This depends on the dynamic configuration when creating the mapping. There are three configuration values ​​for this attribute parameter:

  1) true: automatic mapping when encountering unfamiliar fields, the default value of ElasticSearch

  2) false: Ignore when encountering unfamiliar fields

  3) Strict: report errors when encountering unfamiliar fields

  The following is a demonstration:

PUT /lib
{
    "settings":{
        "number_of_shards":3,
        "number_of_replicas":0
      },
        "mappings":{
            "user":{
                "dynamic":"strict",
                "properties":{
                    "name":{"type":"text"},
                    "address":{
                      "type":"object",
                      "dynamic":true
                    }
                }
            }
        }
}

  The type user defines dynamic, and its value is strict, which means that if a field other than name and address appears in the added document, an error will be reported. Dynamic is also defined in the address, and the value is true, which means that if other fields appear in the address, es will automatically map it (because the address is of type object and can contain other fields). The position of dynamic writing does not move, the scope of the tube is different.

  Add example, no error

put /lib/user/1
{
    "name":"lisi",
    "address":{
      "province":"beijing",
      "city":"beijing"
    }
}

  Add results

{
  "_index": "lib",
  "_type": "user",
  "_id": "1",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 1,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 0,
  "_primary_term": 1
}

  Add example, report error

put /lib/user/2
{
    "name":"lisi",
    "age":23,
    "address":{
      "province":"beijing",
      "city":"beijing"
    }
}

  Add results:

{
  "error": {
    "root_cause": [
      {
        "type": "strict_dynamic_mapping_exception",
        "reason": "mapping set to strict, dynamic introduction of [age] within [user] is not allowed"
      }
    ],
    "type": "strict_dynamic_mapping_exception",
    "reason": "mapping set to strict, dynamic introduction of [age] within [user] is not allowed"
  },
  "status": 400
}

  2. The identification of the default date format of date_detection is configured for the date type

  The default value of date_detection is true, the default will recognize the date according to a certain format, such as yyyy-MM-dd will be recognized as a date type by default

  If the following 1990-12-12 does not indicate the field type, it will default to the date type according to the format

hput /lib/user/1
{
    "name":"1990-12-12",
    "address":{
      "province":"beijing",
      "city":"beijing"
    }
}

  If you want to write the date format, it will not be recognized as the date type, it should be set to false, as follows:

PUT /lib
{
    "settings":{
        "number_of_shards":3,
        "number_of_replicas":0
      },
      "mappings":{
          "user":{
              "date_detection":false
          }
      }
}

  3. Dymamic mapping template (type) custom dynamic mapping template configuration

  Please see the following example, which defines the index my_index, type my_type, the type and tokenizer are specified in the mapping, but the field is not specified. However, match and match_mapping_type are defined, meaning that if the field name ends with _en, the following template is used; if there is no match, the template is not used. The configuration of _en is the default english tokenizer, and the stardand standard tokenizer is not matched.

PUT /my_index
{
  "mappings": {
    "my_type":{
      "dynamic_templates":[
          {
            "en":{
              "match":"*_en",
              "match_mapping_type":"string",
              "mapping":{
                "type":"text",
                "analyzer":"english"
              }
            }
          }
        ]
    }
  }
}
PUT /my_index/my_type/1
{
  "title_en":"this is my dog"
}
PUT /my_index/my_type/2
{
  "title":"this is my cat"
}

  Test: The document with id 1 matches the template, using the English tokenizer. The tokenizer ignores words such as is a an, and the documents will not be queried based on is, as follows:

GET /my_index/my_type/_search
{
  "query":{
    "match": {
      "title_en": "is"
    }
  }
}

  search result:

{
  "took": 3,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 0,
    "max_score": null,
    "hits": []
  }
}

  Test: The document with id 2 does not match the template, and the standard word breaker is used. The word breaker does not ignore words such as is a an. The documents can be queried based on is as follows:

GET /my_index/my_type/_search
{
  "query":{
    "match": {
      "title": "is"
    }
  }
}

  search result:

{
  "took": 4,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 0.2876821,
    "hits": [
      {
        "_index": "my_index",
        "_type": "my_type",
        "_id": "2",
        "_score": 0.2876821,
        "_source": {
          "title": "this is my cat"
        }
      }
    ]
  }
}

 

Guess you like

Origin www.cnblogs.com/javasl/p/12685840.html