ElasticSearch系列18：Mapping 设计指南
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 为 whitespace2）上述步骤没有，再读取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"]
}
}
}
}腾讯云开发者
