Elastic Search的RestFul API入门：初识mapping
本节课旨在探讨Elasticsearch中Mapping的使用。在Elasticsearch中，Mapping是定义索引中字段（Field）的数据类型和属性的过程。它为Elasticsearch提供了一种途径，以解析和处理文档中的各个字段，以便在搜索、排序和聚合等操作中，能够准确地处理数据。从本质上说，Mapping可被视为Java的基本数据类型和Mysql的字段类型。本教程将用三节课的时间，探讨Mapping相关的RestFul API的使用。
这节课程的主题将围绕ES的映射相关的动态字段、动态模板、指定字段类型以及运行时字段展开，以下为本节课程的大纲：
初识mapping
- 初识mapping之前的准备
-
- 获取索引全部字段信息
- 获取索引指定字段信息
- 获取索引数据
- mapping/动态字段
-
- mapping添加时间格式
- 关闭日期检测
- 添加时间格式-关闭自动转换
- 添加时间格式-自定义时间格式
- 添加时间格式-自定义时间格式
- 开启数字检测
- 添加时间格式-数字检测
- mapping/动态模板
-
- 动态模板long变int
- 验证动态模板long变int
- 匹配和不匹配
- 验证匹配和不匹配
- mapping/指定字段类型
-
- 固定字段类型
- 后期添加字段类型
- mapping/运行时字段
-
- 添加运行时字段-造数据
-
- 第一种添加方法：直接用json类型的body
- 第二种添加方法：接口调用工具在请求头的参数里面添加如下参数
- 添加运行时字段-添加
- 添加运行时字段-验证
- 检索运行时字段-构建索引结构
- 检索运行时字段-添加数据
- 检索运行时字段-验证
初识mapping之前的准备
在详细介绍这些内容之前，首先我们需要掌握如何验证和查看ES的映射相关接口。这里，mapping_test是索引的名称，可以根据需求进行自定义，而其中的_开头的则代表ES官方的API，不可以进行自定义。
获取索引全部字段信息
GET /mapping_test/_mapping
这个请求通常用于查看索引中存储的数据的结构，以便了解字段的定义和数据类型。
获取索引指定字段信息
GET /mapping_test/_mapping/field/create_date
这个请求通常用于查看特定字段的映射信息，以便了解字段的定义和如何对待特定类型的数据。
获取索引数据
GET /mapping_test/_search
这个请求将返回索引里面全部的文档。
mapping/动态字段
什么是动态字段？
动态字段允许您更好地控制 Elasticsearch 如何映射您的数据
——官网
我们讲几个api接口也许你就明白了。
mapping添加时间格式
PUT /mapping_test/_doc/1
{
"create_date": "2015/09/02"
}
这个请求是用于将一个文档（document）索引到Elasticsearch中。就是在es里面插入了一条数据。
我们查看一下该索引的字段信息：
可以看到我们create_date的类型（type）为date，format为yyyy/MM/dd HH:mm:ss||yyyy/MM/dd||epoch_millis 也就是说如果你传入的格式为yyyy/MM/dd 的情况下，ES就会将该字段自动定义为date属性。
关闭日期检测
PUT /mapping_test2
{
"mappings": {
"date_detection": false
}
}
我们新建一个索引mapping_test2，并且在新建的时候date_detection可以通过设置禁用动态日期检测false。
注意，只能在新索引中关闭日期检测，已经存在的索引不支持更改自动检测的类型，需要在索引里面添加时间格式的数据之前更改此配置。
添加时间格式-关闭自动转换
PUT /mapping_test2/_doc/1
{
"create_date": "2015/09/02"
}
这个时候我们再添加一样的数据
就会发现这个字段就不是date类型的字段了：
添加时间格式-自定义时间格式
PUT /mapping_test4
{
"mappings": {
"dynamic_date_formats": [
"MM/dd/yyyy"
]
}
}
添加了一个格式：MM/dd/yyyy这意味着在该索引中，日期字段将使用指定的日期格式进行解析和索引。
添加时间格式-自定义时间格式
PUT /mapping_test4/_doc/2
{
"create_date": "09/25/2015"
}
如果我们传的格式是MM/dd/yyyy这样的，那么这个字段将会被解析为date类型。
这个时候我们看这个字段就是根据自定义格式的format生成的type为date类型的字段了。
开启数字检测
PUT /mapping_test6
{
"mappings": {
"numeric_detection": true
}
}
numeric_detection在ES中默认是关闭的，也就是说如果我们添加"1.0"的数据会被ES识别为字符串，如果需求是不能为字符串，那么我们需要开启这个配置。
添加时间格式-数字检测
PUT /mapping_test6/_doc/1
{
"my_float": "1.0",
"my_integer": "1"
}
这样就会自动检测传入的是否满足numeric类型的格式，满足则会转换，numeric我们后面会进行更深刻的讲解。
通过以上的几个api示例，大家应该明白了什么是mapping的动态字段：可以动态的关闭或者开启或改变字段的默认属性，此称为动态。
mapping/动态模板
什么是动态模板？
动态模板允许您更好地控制 Elasticsearch 如何映射您的数据，超越默认的动态字段映射规则。
——官网
我们同样来几个api示例来验证mapping的动态模板。
动态模板long变int
PUT/mapping_test8
{
"mappings": {
"dynamic_templates": [
{
"integers": {
"match_mapping_type": "long",
"mapping": {
"type": "integer"
}
}
}
]
}
}
这个请求将创建一个名为 “mapping_test8” 的索引，并定义了一个动态模板，用于将长整数类型的字段映射为整数类型。这允许 Elasticsearch 在索引文档时自动应用这个映射规则，从而影响字段的数据类型。这种映射定义对于索引中的数据处理非常有用，因为它允许自动化的映射规则应用。
验证动态模板long变int
PUT/mapping_test8/_doc/1
{
"my_integer": 5
}
这个时候我们去查看该索引的字段信息就会发现my_integer字段变为了int类型，默认所有的数字都是long类型。
ES不仅仅支持固定的模板，例如上面这样固定的类型，而且还支持通配符，下面我们来看一下通配符的情况。
匹配和不匹配
PUT/mapping_test9
{
"mappings": {
"dynamic_templates": [
{
"longs_as_strings": {
"match_mapping_type": "string",
"match": "long_*",
"unmatch": "*_text",
"mapping": {
"type": "long"
}
}
}
]
}
}
longs_as_strings 这个是我们可以自定义的模板名称。
match_mapping_type: 设置为 “string”，表示匹配文本字段。match: 设置为 “long_*”，匹配字段名以 “long_” 开头的字段。unmatch: 设置为 “*_text”，不匹配以 “_text” 结尾的字段名。mapping: 设置为将匹配到的字段类型更改为 “long”。
根据这个动态模板，意图是将字段名以 "long_" 开头且不以 "_text" 结尾的文本字段映射为 “long” 类型的字段。
验证匹配和不匹配
PUT/mapping_test9/_doc/1
{
"long_num": "5",
"long_text": "foo"
}
这个时候我们可以看见如果字段名称为long开头的并且不是以text结尾的，例如：long_num就被ES的模板规范为了long类型的字段了，虽然它传入的是字符串。而long_text还是以原样输出为字符串类型。
通过上面的几个api示例相信大家已经理解了mapping的动态模板是什么意思了：创建模板的时候设置一个模板，如果传入的字段信息符合这个模板的话就根据模板里面的规则进行字段的定义。
接下来带大家再认识一个mapping的属性：指定字段类型。
mapping/指定字段类型
固定字段类型
PUT/mapping_test12
{
"mappings": {
"properties": {
"age": {
"type": "integer"
},
"email": {
"type": "keyword"
},
"name": {
"type": "text"
}
}
}
}
定义了三个字段：一个整数类型的 “age” 字段，一个关键字类型的 “email” 字段，以及一个文本类型的 “name” 字段。这些映射定义了索引中存储的是固定的数据结构。
通过properties属性，我们直接把对应的字段设置成对应的类型。之后我们查看该索引的字段信息则是固定的类型了。
后期添加字段类型
PUT/mapping_test13/_mapping
{
"properties": {
"age": {
"type": "keyword",
"index": false
}
}
}
如果你在创建索引之初没有给字段固定类型，则可以通过这个接口去后期添加字段类型。
拓展：索引选项（Index）：设置为 “false”，表示 “age” 字段不会被索引，也就是不能被用于搜索。此选项适用于那些不需要搜索的字段，比如用于存储标识符或者其他不需要搜索的数据。将 “index” 设置为 “false” 可以让该字段在索引时不生成倒排索引，从而节省存储空间和提高索引速度。
通过上面的几个api示例相信大家已经明白了mapping的指定字段类型：在创建索引的时候不仅仅可以指定字段的类型，而且可以在后期动态地往指定的索引添加新的字段和对应的字段类型。
不知不觉这篇文章就要结束了，最后给大家介绍一下mapping的运行时字段。
mapping/运行时字段
什么是运行时字段？
其实就是相当于一个临时的字段，我们可以在定义特定用途的字段而不修改底层架构的前提下进行一些字段的操作。
添加运行时字段-造数据
PUT/mapping_test15/_bulk
{"index":{}}
{"@timestamp":1516729294000,"model_number":"QVKC92Q","measures":{"voltage":"5.2","start": "300","end":"8675309"}}
{"index":{}}
{"@timestamp":1516642894000,"model_number":"QVKC92Q","measures":{"voltage":"5.8","start": "300","end":"8675309"}}
{"index":{}}
{"@timestamp":1516556494000,"model_number":"QVKC92Q","measures":{"voltage":"5.1","start": "300","end":"8675309"}}
{"index":{}}
{"@timestamp":1516470094000,"model_number":"QVKC92Q","measures":{"voltage":"5.6","start": "300","end":"8675309"}}
{"index":{}}
{"@timestamp":1516383694000,"model_number":"HG537PU","measures":{"voltage":"4.2","start": "400","end":"8625309"}}
{"index":{}}
{"@timestamp":1516297294000,"model_number":"HG537PU","measures":{"voltage":"4.0","start": "400","end":"8625309"}}
这里给大家解释一下：
这个请求使用了Bulk API来执行批量索引操作。Bulk API可以一次处理多个文档的索引、更新或删除操作，以提高索引效率。
每个请求由两部分组成：
- {“index”:{}}：这是操作行，指示将要进行索引操作，并且没有指定ID，Elasticsearch会自动生成文档的ID。
- 文档数据：这是实际要索引的文档数据。每个文档都是一个JSON对象，包含 “@timestamp” 字段、“model_number” 字段和 “measures” 字段。其中 “@timestamp” 字段是时间戳，“model_number” 字段是型号编号，“measures” 字段是包含测量数据的嵌套对象。
如何使用这个api：
第一种添加方法：直接用json类型的body
注意这里最后一行必须要以换行结束，仔细看图中的信息是以换行结束的。但是这样的方式，在某些调用软件里面会标红（因为它不是一个常规的json）。但是不影响api的执行效果，如果大家在意这个报错的话可以用第二种添加方法。
第二种添加方法：接口调用工具在请求头的参数里面添加如下参数
Content-Type : application/x-ndjson
这样我们使用raw类型的body就不会报错标红了。
添加运行时字段-添加
PUT/mapping_test15/_mapping
{
"runtime": {
"measures.start": {
"type": "long"
},
"measures.end": {
"type": "long"
}
}
}
在不改变原数据类型的情况下，我们通过添加两个运行时字段，即measures.start和measures.end，来扩展查询的能力。在查询过程中，这些新增的运行时字段将优先于其他数据字段进行查询。
measures.start 、 measures.end 运行时字段， 类型：long，表示字段的数据类型为长整型。
这里看到我们的元数据类型并没有改变：
只是添加了两个运行时字段而已：
添加运行时字段-验证
GET/mapping_test15/_search
{
"aggs": {
"avg_start": {
"avg": {
"field": "measures.start"
}
},
"avg_end": {
"avg": {
"field": "measures.end"
}
}
}
}
与通常的查询一样，我们可以使用上述的查询语句来验证新增的运行时字段是否正常工作。
可以看到，通过新增的运行时字段，我们成功地计算出了平均值。如果原数据的类型为text，则无法使用相关的函数进行计算。
如果你觉得这个还是不够，那么接下来我们将展示一个更高级的功能：
检索运行时字段-构建索引结构
PUT/mapping_test16/
{
"mappings": {
"dynamic": "runtime",
"runtime": {
"day_of_week": {
"type": "keyword",
"script": {
"source": "emit(doc['@timestamp'].value.dayOfWeekEnum.getDisplayName(TextStyle.FULL, Locale.ROOT))"
}
}
},
"properties": {
"@timestamp": {"type": "date"}
}
}
}
在source字段中，我们采用了Elasticsearch内置的脚本功能，在此，我们暂且不做进一步解释。至于dayOfWeekEnum，这是我们在Java编程语言中使用的枚举类型。我们都知道，Elasticsearch的核心代码是用Java编写的。总的来说，此语句旨在获取日期字段的星期几，并以全文本形式呈现。生成的结果将作为运行时字段的值。
检索运行时字段-添加数据
PUT/mapping_test16/_bulk
{ "index": {}}
{ "@timestamp": "2020-06-21T15:00:01-05:00", "message" : "211.11.9.0 - - [2020-06-21T15:00:01-05:00] \"GET /english/index.html HTTP/1.0\" 304 0"}
{ "index": {}}
{ "@timestamp": "2020-06-21T15:00:01-05:00", "message" : "211.11.9.0 - - [2020-06-21T15:00:01-05:00] \"GET /english/index.html HTTP/1.0\" 304 0"}
{ "index": {}}
{ "@timestamp": "2020-04-30T14:30:17-05:00", "message" : "40.135.0.0 - - [2020-04-30T14:30:17-05:00] \"GET /images/hm_bg.jpg HTTP/1.0\" 200 24736"}
{ "index": {}}
{ "@timestamp": "2020-04-30T14:30:53-05:00", "message" : "232.0.0.0 - - [2020-04-30T14:30:53-05:00] \"GET /images/hm_bg.jpg HTTP/1.0\" 200 24736"}
{ "index": {}}
{ "@timestamp": "2020-04-30T14:31:12-05:00", "message" : "26.1.0.0 - - [2020-04-30T14:31:12-05:00] \"GET /images/hm_bg.jpg HTTP/1.0\" 200 24736"}
{ "index": {}}
{ "@timestamp": "2020-04-30T14:31:19-05:00", "message" : "247.37.0.0 - - [2020-04-30T14:31:19-05:00] \"GET /french/splash_inet.html HTTP/1.0\" 200 3781"}
{ "index": {}}
{ "@timestamp": "2020-04-30T14:31:27-05:00", "message" : "252.0.0.0 - - [2020-04-30T14:31:27-05:00] \"GET /images/hm_bg.jpg HTTP/1.0\" 200 24736"}
{ "index": {}}
{ "@timestamp": "2020-04-30T14:31:29-05:00", "message" : "247.37.0.0 - - [2020-04-30T14:31:29-05:00] \"GET /images/hm_brdl.gif HTTP/1.0\" 304 0"}
{ "index": {}}
{ "@timestamp": "2020-04-30T14:31:29-05:00", "message" : "247.37.0.0 - - [2020-04-30T14:31:29-05:00] \"GET /images/hm_arw.gif HTTP/1.0\" 304 0"}
{ "index": {}}
{ "@timestamp": "2020-04-30T14:31:32-05:00", "message" : "247.37.0.0 - - [2020-04-30T14:31:32-05:00] \"GET /images/nav_bg_top.gif HTTP/1.0\" 200 929"}
{ "index": {}}
{ "@timestamp": "2020-04-30T14:31:43-05:00", "message" : "247.37.0.0 - - [2020-04-30T14:31:43-05:00] \"GET /french/images/nav_venue_off.gif HTTP/1.0\" 304 0"}
我们同样再次添加一些数据，假设这是一个日志文件内容的信息，数据示例来自官网。
检索运行时字段-验证
GET/mapping_test16/_search
{
"fields": [
"@timestamp",
"day_of_week"
],
"_source": false
}
这个时候我们再搜索这个字段的时候，ES就会自动计算了day_of_week对应的值。
通过这篇文章我们也初识了ES的mapping，在本文中，我们介绍了如何使用Elastic Search的RestFul API来实现索引信息的获取和管理。讲解了动态字段、动态模板、指定字段类型以及运行时字段的相关概念，后面两篇还会讲mapping中常见和不常见的字段类型。期待和大家再次见面。
感谢语
感谢您的阅读，在我们的前两篇试读文章中，我们已经对es的基础知识和Restful API有了初步的了解。至此，本专栏试读部分告一段落。然而，es的世界远不止于此。在即将发布的付费文章中，我们将深入探讨更多高级主题，包括但不限于复杂查询的构建、性能优化、数据分析和可视化等。这些内容将帮助您更好地理解和利用Elasticsearch，一定要跟着课程中列好的api一遍一遍地敲，光看不练假把戏！这是一个值得投资的机会，一个提升自我，掌握未来的机会。期待我们在未来的文章中再次相遇！购买本专栏将获得一份精心整理的API文档或可选择直接加入该团队中（可直接查看本篇专栏中的所有api）。
最后文中使用到的工具是apifox，感谢apifox（支持国产，不是广告）