@TOC
参考ES 7版本官网文档
官网7.17文档
挑了一些我感觉重要的点总结
如有舛误，欢送斧正
mapping是什么
在ES里创立一个索引
PUT demo_index{ "mappings": { "dynamic": false "properties": { "demo_id": { "type": "text" } } }}下面的properties里定义了字段demo_id，它的类型是text。dynamic抉择了false阐明mapping不须要动静规定来匹配，这种状况下进行搜寻时和一般的关系型数据库搜寻十分相似。
mapping相似于数据库中的表构造定义，定义以下这些内容
- 定义字段名称
- 定义字段数据类型
- 字段、倒排索引的相干配置
然而和比方mysql这样的数据相比还是有很多不同之处，搜寻的字段类型能够提前定义好，也能够不定义让ES来揣测，也可在搜寻的时候动静退出新字段。
GET /demo_index/_mapping查看mapping动静mapping
如果你想应用动静mapping就将下面提到的dynamic字段设置为true或者runtime
默认动静mapping
ES容许直接插入文档，不须要提前定义类型、字段 ，当你查问的时候会主动揣测匹配显示进去。
curl -X PUT "localhost:9200/data/_doc/1?pretty" -H 'Content-Type: application/json' -d'{ "count": 5 }应用kibana的话间接PUT data/_doc/1 ... 就行
自动检测类型和增加字段就是动静mapping，ES有默认的检测规定，咱们本人也能够定义本人的规定。
设计本人的mapping检测模板
这一块比较复杂
match_mapping_type
这个能够了解为依据字段默认检测进去的类型进行匹配
用的官网文档的案例：
能够看到当默认检测进去的字段类型为integer时，将替换为long类型；如果检测进去的类型为text或者keyword类型，将会替换为string类型。
PUT demo_index{ "mappings": { "dynamic_templates": [ { "integers": { "match_mapping_type": "long", "mapping": { "type": "integer" } } }, { "strings": { "match_mapping_type": "string", "mapping": { "type": "text", "fields": { "raw": { "type": "keyword", "ignore_above": 256 } } } } } ] }}这张图是在默认检测下，从Json解析进去的数据类型和ES里的数据的对应关系。须要留神的是dynamic字段设置为true和runtime的对应关系是略有不同的。
math/unmatch
依据字段名称去匹配字段类型
如下，如果JSON解析进去的字段匹配long_*并且不匹配*_text，并且默认检测进去的类型是long，那么将其匹配为string类型。
PUT demo-index{ "mappings": { "dynamic_templates": [ { "longs_as_strings": { "match_mapping_type": "string", "match": "long_*", "unmatch": "*_text", "mapping": { "type": "long" } } } ] }}除了应用简略的通配符来进行匹配之外，还能够应用正则表达式：
"match_pattern": "regex","match": "^profit_\d+$"path_match/path_unmatch
这个是依据字段门路匹配，我了解是用于匹配多层级的对象。
这里产生的成果就是name对象去掉middle字段。
PUT demo-index{ "mappings": { "dynamic_templates": [ { "full_name": { "path_match": "name.*", "path_unmatch": "*.middle", "mapping": { "type": "text", "copy_to": "full_name" } } } ] }}PUT demo-index/_doc/1{ "name": { "first": "John", "middle": "Winston", "last": "Lennon" }}官网文档里的这个案例，还应用了copy_to，copy_to能够将值复制到另一个字段里，是一个很实用的性能。
运行时字段
能够在mapping下设置runtime局部，应用script脚本来管制动静字段。
脚本能够拜访整个文档，包含原始_source和mapping字段，脚本会查问所有所需字段的值。
PUT demo-index/{ "mappings": { "runtime": { "day_of_week": { "type": "keyword", "script": { "source": "emit(doc['@timestamp'].value.dayOfWeekEnum.getDisplayName(TextStyle.FULL, Locale.ROOT))" } } }, "properties": { "@timestamp": {"type": "date"} } }}运行时字段在搜寻时不会呈现在_source里，然而会有这个field，搜寻时能够指定这个字段将其值搜寻进去
>GET demo-index/_search{ "fields" : ["day_of_week"], "query": { "match": { ... } }}动静值就会显示在查问后果的hits里的每个hit的fields里
在某些状况下这个性能能够省去reindex, 比方发现mapping里某字段心愿批改它的数据类型，或者心愿某些字段能够有另外的一种模式，在mapping中不太不便批改，计划能够有进行reindex，然而也能够通过这种动静模式拿到想获取的值（读时建模）。
当设置dynamic字段为runtime时,
PUT demo-index{ "mappings": { "dynamic": "runtime", "properties": { "@timestamp": { "type": "date" } } }}检测到的新字段会主动退出到mapping的fields作为运行时字段。
也能够随时更新或删除运行时字段。要替换现有的运行时字段，在具备雷同名称的映射中增加一个新的运行时字段。设置null就能够删除。
PUT demo-index/_mapping{ "runtime": { "day_of_week": null }}dynamic
dynamic用于管制是否动静增加新字段，可选项有：
- true：新字段增加到mapping中（默认）。
- runtime：新字段作为运行时字段增加到mapping中，这些字段不可索引，是_source在查问时加载的。
- false：疏忽新字段，这些字段不会被索引或搜寻，但仍会呈现在_source返回的命令和字段中。这些字段不会增加到mapping中，必须显式增加新字段。
- strict：如果检测到新字段，则会抛出异样。必须将新字段显式增加到mapping中。
动静模式 （true）艰深来说就是往index里写入doc，doc里的字段类型对应es里的什么数据类型，将会由默认揣测规定来进行主动揣测匹配（当然也能够自义定揣测规定）。
不须要动静模式（false）的时候，能够依照本人的理论需要去设置mapping，插入doc的时候，字段与mapping里的保持一致，如果doc增加了一个mapping里不存在的字段，新字段不会被主动增加到mapping中，并且指定该字段进行查问时，也无奈匹配到后果，能够存储、然而不能索引。
当dynamic设置为false时，显式设置mapping，相似于关系型数据库