点击上方“方才编程”,即可关注我!
本文导读
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"]
}
}
}
}
完整版《Mapping参数详解》,公号后台回复【ES】即可获取。
待续
留言区
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/34782.html