ElasticSearch系列18：Mapping 设计指南

方才编程_公众号同名

发布于 2020-11-13 10:39:57

1K0

发布于 2020-11-13 10:39:57

文章被收录于专栏：方才编程方才编程

本文导读

ElasticSearch 的 mapping 该如何设计，才能保证检索的高效？想要回答这个问题，就需要全面系统地掌握 mapping 各种参数的含义以及其适用的场景。（ps：本文基于ElasticSearch 7.7.1）

本文通过分类讲解各个参数的含义，结合使用示例，让你从此不再迷路。

最后，还有方才兄精心设计的 mapping 实例，让你全面掌握 mapping 设计。

本文导航

什么是 Mapping？

Mapping 类似于数据库中的表结构定义 schema，它有以下几个作用：

1、定义索引中字段的名称；
2、定义字段的数据类型，比如 text、keyword、date；
3、倒排索引的相关配置，比如设置某个字段为不被索引；

下面我们就一起来学习下mapping配置各个参数的含义，以及如何结合实际场景进行合理的配置。

基础配置

1、properties

mappings、object字段和nested字段包含的子字段就叫做 properties，示例：

PUT my_index
{
  "mappings": {
    "properties": { 
      "manager": {
        "properties": { 
          "age":  { "type": "integer" },
          "name": { "type": "text"  }
        }
      },
      "employees": {
        "type": "nested",
        "properties": { 
          "age":  { "type": "integer" },
          "name": { "type": "text"  }
        }
      }
    }
  }
}

分词相关的配置

1、fields

对同一个字段建立不同的索引方式，即multi-field。示例：

PUT my_index
{
  "mappings": {
    "properties": {
      "name": { 
       # 针对 name 字段，使用 standard 分词器建立索引
        "type": "text",
        "fields": {
       # 针对 name.sub_name 字段，使用 english 分词器建立索引
          "sub_name": { 
            "type":     "text",
            "analyzer": "english"
          }
        }
      }
    }
  }
}

2、analyzer

设置text类型字段index时的分词器。如上例中的【"analyzer": "english"】，就表示对 name.sub_name 字段，使用 english 分词器建立索引。

关于analyzer，方才兄在这里补充一个知识点，ElasticSearch如何确定 index 的 analyzer：

1）读取字段的“analyzer”配置

PUT my_index
{
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "analyzer": "whitespace"
      }
    }
  }
}
# 指定字段 title 建立倒排索引时的 analyzer 为 whitespace

2）上述步骤没有，再读取index的setting：analysis.analyzer.default

PUT my_index
{
  "settings": {
    "analysis": {
      "analyzer": {
        "default": {
          "type": "english"
        }
      }
    }
  }
}

3）都没有，使用默认的 standard 标准分词器

3、search_analyzer

设置 search 时使用的分词器。ElasticSearch 如何确定 search 时的 analyzer：

1）search API 指定 analyzer

GET my_index/_search
{
  "query": {
    "match": {
      "message": {
        "query": "Quick foxes",
        "analyzer": "stop"
      }
    }
  }
}

2）读取 index 的 mapping 字段配置 search_analyzer

PUT my_index
{
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "analyzer": "whitespace",
        "search_analyzer": "simple"
      }
    }
  }
}

3）读取 index 的 setting 的 analysis.analyzer.default_search

PUT my_index
{
  "settings": {
    "analysis": {
      "analyzer": {
        "default": {
          "type": "simple"
        },
        "default_search": {
          "type": "whitespace"
        }
      }
    }
  }
}

4）field 的 analyzer

5）都没有，使用默认的 standard analyzer

4、normalizer

针对 keyword 字段的normalizer属性，与analyzer类似，不同之处在于它保证 analyzer 生成单个 token。

与 analyzer相比，缺少了 tokenizer【关于分词的原理与流程，推荐阅读：ElasticSearch实战系列02：中文+拼音混合检索，并高亮显示】，示例：

PUT index
{
  "settings": {
    "analysis": {
      "normalizer": {
        "my_normalizer": {
          "type": "custom",
          "char_filter": [],
          "filter": ["lowercase", "asciifolding"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "foo": {
        "type": "keyword",
        "normalizer": "my_normalizer"
      }
    }
  }
}
# 存入文本【BÀR a】，该配置得到的倒排索引是【bar a】
PUT index/_doc/1
{
  "foo": "BÀR a"
}
# 可以检索到结果
GET index/_search
{
  "query": {
    "term": {
      "foo": "BAR"
    }
  }
}

与相关性算分相关的配置

1、boost

增强字段的权重，示例【关于es的相关度，推荐阅读：ES系列13：彻底掌握相关度：从TF-IDF、BM25到对相关度的控制】：

PUT my_index
{
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "boost": 2 
      },
      "content": {
        "type": "text"
      }
    }
  }
}

与数据处理相关的配置

1、dynamic

控制是否可以动态添加新字段。可选参数：

1）true 动态添加新的字段--缺省；
2）false 忽略新的字段,【不会被索引】不会添加字段映射，但是会存在于_source中；
3）strict 如果遇到新字段抛出异常【推荐配置参数】。

PUT /my_index{  "mappings": {    "my_type": {      "dynamic": "strict",      "properties": {        "title": {          "type": "string"        },        "stash": {          "type": "object",          "dynamic": "strict"        }      }    }  }}

2、format

为 date 类型的字段指定格式，示例：

ES的date类型允许我们规定格式，可以使用的格式有3种：
yyyy-MM-dd HH:mm:ss
yyyy-MM-dd
epoch_millis（毫秒值）

# 规定格式如下：|| 表示或者

PUT my_index
{
  "mappings": {
    "_doc": {
      "properties": {
        "date": {
          "type":   "date",
          "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
        }
      }
    }
  }
}
注意：一旦我们规定了格式，如果新增数据不符合这个格式，ES将会报错mapper_parsing_exception。

可参考阅读：ElasticSearch系列03：ES的数据类型

与性能相关配置

1、enabled

设置成 false，仅做存储，不⽀持搜索和聚合分析（数据保存在 _source 中）。

该enabled设置仅可应用于顶级映射定义和object字段，示例：

PUT my_index
{
  "mappings": {
    "properties": {
      "user_id": {
        "type":  "keyword"
      },
      "last_updated": {
        "type": "date"
      },
      "session_data": { 
        "type": "object",
        "enabled": false
      }
    }
  }
}
# 任何任意数据都可以传递到该session_data字段，因为它将被完全忽略。
PUT my_index/_doc/session_1
{
  "user_id": "kimchy",
  "session_data": { 
    "arbitrary_object": {
      "some_array": [ "foo", "bar", { "baz": 2 } ]
    }
  },
  "last_updated": "2015-12-06T18:20:22"
}

PUT my_index/_doc/session_2
{
  "user_id": "jpountz",
  "session_data": "none", 
  "last_updated": "2015-12-06T18:22:13"
}

2、doc_values

Doc Values 默认对所有字段启用，除了 text。禁用 Doc Values，可以节省磁盘空间，但不能被用于聚合、排序以及脚本操作，仍然可以查询。示例：

PUT my_index
{
  "mappings": {
    "properties": {
      "status_code": {
        "type": "keyword"
      },
      "session_id": {
        "type": "keyword",
        "doc_values": false
      }
    }
  }
}
PUT /my_index/_doc/1
{
  "session_id":"关注我"
}
# 可以检索到
GET /my_index/_search
{
  "query": {
    "term": {
      "session_id": {
        "value": "关注我"
      }
    }
  }
}
# 直接报错 illegal_argument_exception
GET /my_index/_search
{
 "aggs": {
   "test_agg": {
     "terms": {
       "field": "session_id",
       "size": 10
     }
   }
 }
}

如果你确定永远也不会对某些字段进行聚合、排序或是使用脚本操作，就可以通过禁用特定字段的 Doc Values，这样可以节省磁盘空间。

3、index

设置为 false，不构建倒排索引，不能被查询，但还是⽀持 aggregation，排序，脚本，并出现在 _source 【与doc_values 的效果相反】。示例：

PUT my_index
{
  "mappings": {
    "properties": {
      "test_field": {
        "type": "keyword",
         "index": false
      }
    }
  }
}
PUT /my_index/_doc/1
{
  "test_field":"关注我"
}
# 直接报错
GET /my_index/_search
{
  "query": {
    "term": {
      "test_field": {
        "value": "关注我"
      }
    }
  }
}
# 可以聚合
GET /my_index/_search
{
 "aggs": {
   "test_agg": {
     "terms": {
       "field": "test_field",
       "size": 10
     }
   }
 }
}

因为倒排索引在index时会序列化到磁盘，所以该配置设置为false，也节约磁盘【ps：关于此配置是否节约内存，有待深入研究，欢迎有了解的小伙伴在留言区分享】。

4、fielddata

对 text 字段，该参数默认是禁止的，所以直接对 text 字段进行聚合、排序或在脚本中使用时，ElasticSearch 会报错。此时，你可以开启该配置，以完成聚合需求：

PUT my_index
{
  "mappings": {
    "properties": {
      "test_field": {
        "type": "text",
        "fielddata": true
      },
      "test_field2":{
        "type": "text"
      }
    }
  }
}
PUT /my_index/_doc/1
{
  "test_field":"点个在看",
  "test_field2":"可好"
}

# 可以聚合
GET /my_index/_search
{
  "size": 0, 
 "aggs": {
   "test_agg": {
     "terms": {
       "field": "test_field",
       "size": 10
     }
   }
 }
}
# 聚合报错
GET /my_index/_search
{
  "size": 0, 
 "aggs": {
   "test_agg": {
     "terms": {
       "field": "test_field2",
       "size": 10
     }
   }
 }
}

但是，一旦将 fielddata 加载到 JVM 的 Heap 中，在该 segment 的生命周期内会一直保留在堆中，所以使用 fielddata 会占用大量的堆内存，影响性能。而对于非 text 类型字段的聚合，大多数使用的都是 doc_value，根据ElasticSearch官网对其的描述：

Doc Values 是在索引时与倒排索引同时生成。也就是说 Doc Values 和倒排索引一样，基于 Segement 生成并且是不可变的。同时 Doc Values 和倒排索引一样序列化到磁盘，这样对性能和扩展性有很大帮助。Doc Values 通过序列化把数据结构持久化到磁盘，我们可以充分利用操作系统的内存，而不是 JVM 的 Heap 。 当 working set 远小于系统的可用内存，系统会自动将 Doc Values 驻留在内存中，使得其读写十分快速；不过，当其远大于可用内存时，系统会根据需要从磁盘读取 Doc Values，然后选择性放到分页缓存中。很显然，这样性能会比在内存中差很多，但是它的大小就不再局限于服务器的内存了。

综上，个人建议，如有对 text 类型字段进行聚合、排序等需求，建议通过 fields 配置多字段：新增 keyword类型，同时将 index 参数设置为false，示例如下：

PUT my_index
{
  "mappings": {
    "properties": {
      "my_field": { 
        "type": "text",
        "fields": {
         # 该字段只用于聚合、排序等，所以关闭了index
          "keyword": { 
            "type": "keyword",
            "index":false
          }
        }
      }
    }
  }
}
PUT /my_index/_doc/1
{
  "my_field":"点个在看,可好"
}

# 可以聚合
GET /my_index/_search
{
  "size": 0, 
 "aggs": {
   "test_agg": {
     "terms": {
       "field": "my_field.keyword",
       "size": 10
     }
   }
 }
}

5、store 与 _source 对比

对比分析：

从每一个 stored field 中获取值都需要一次磁盘 io，如果想获取多个 field 的值，就需要多次磁盘 io ，但是，如果从 _source 中获取多个 field 的值，则只需要一次磁盘 io ，因为 _source 只是一个字段，而且_source是被压缩过的。所以在大多数情况下，从 _source 中获取是快速而高效的。

哪些情形下需要显式的指定 store 属性呢？

如果你的文档长度很长，存储 _source 或者从 _source 中获取 field 的代价很大，你可以显式的将某些 field 的 store 属性设置为 yes。此时只查询这一个字段的值的，效率高。

总结

ps：之前有读者反馈说，有的知识点缺少总结，今天，它来了。

一图胜千言

结合示例，更明白

PUT /blogs_index/
{
  "settings": {
    "index": {
      "number_of_shards": 1,
      "number_of_replicas": 1
    },
    "analysis": {
      "analyzer": {
        "pinyin_analyzer": {
          "tokenizer": "standard",
          "filter": [
            "my_pinyin"
          ]
        }
      },
      "filter": {
        "my_pinyin": {
          "type": "pinyin",
          "keep_first_letter": true,
          "keep_separate_first_letter": true,
          "keep_full_pinyin": true,
          "keep_original": true,
          "limit_first_letter_length": 16,
          "lowercase": true
        }
      }
    }
  },
  "mappings": {
    # 禁止新增字段
    "dynamic": "strict",
    "properties": {
      "id": {
        "type": "integer"
      },
      "author": {
        "type": "text",
        # 对作者使用拼音分词
        "analyzer": "pinyin_analyzer",
        "fields": {
          # 建立多字段，用于聚合
          "keyword": {
            "type": "keyword",
            "index":false
          }
        }
      },
      # 博客的分类，支持 term 查询
      "blog_sort": {
        "type": "keyword",
        # 需要聚合，且数据量较大，但唯一值较少
        "eager_global_ordinals": true,
        # 提升该字段的权重
        "boost": 3
      },
      "title": {
        "type": "text",
        "analyzer": "ik_max_word",
        # 检索的分词没必要细粒度，提升效率
        "search_analyzer": "ik_smart",
        # 对 标题 不需要聚合、排序
        "doc_values": false,
        # 提升该字段的权重
        "boost": 5
      },
      "content": {
        "type": "text",
        "analyzer": "ik_max_word",
        "search_analyzer": "ik_smart",
        # 博客内容为大字段，单独存储，用于查询返回
        "store": true,
        # 不需要聚合、排序
        "doc_values": false
      },
      "update_time":{
        "type": "date",
        # 规定格式，提高可读性
        "format": ["yyyy-MM-dd HH:mm:ss"],
        # 该字段仅用于显示，不用检索、聚合、排序【非object类型，不能使用 enabled 参数】
        "index":false,
        "doc_values": false
      },
      "create_time":{
        "type": "date",
        "format": ["yyyy-MM-dd HH:mm:ss"]
      }
    }
  }
}

本文参与腾讯云自媒体分享计划，分享自微信公众号。

原始发表：2020-10-29，如有侵权请联系 cloudcommunity@tencent.com 删除

analyzer