- index.mapping.depth.limit
字段级联的最大深度,默认为20。
- index.mapping.nested_fields.limit
一个索引最多包含字段类型为nested的个数,默认为50。
1.4 动态映射机制
与关系型数据库不同的是,一个type(对应关系型数据库的表)中的字段可以在使用过程中动态添加。具体的动态映射机制,将在后续文章中单独结束。
1.5 更新已有映射定义
es不支持直接修改已索引的已存在的字段映射,因为修改字段映射,意味着已索引的数据生效,可以使用别名机制来修改字段的名称,如果需要修改已存在字段的映射,建议重新创建一个索引,再使用reindex API迁移数据。
1.6 索引、type组织方式
索引在创建时,Elasticsearch6.x版本只支持一个映射类型,而7.x版本后将完成删除映射类型。es5.x中一个索引包含多个type的情况再6.x版本将继续支持查询,7.0版本后,API将完成移除与多类型相关的API。
Elasticsearch6.x版本后为什么不继续对单一索引库提供多类型支持呢?
当初,为了方便理解es,通常与关系型数据库进行类比,例如es中的index(索引)相当于关系型数据库的database,而类型(type)相当于关系型数据库中的table。其实这是一个错误的比喻。在关系型数据库中,表是相互独立的,一个表中的列名与另外一个表中的列名相同是没有关系的,但对于es的类型映射定义,情况并非如此。
在es单一索引中,不同映射类型(type)具有相同名称的字段在内部都是由同一个Lucence字段来存储,这也就意味着同一个索引内不同的类型,如果出现名字相同的字段,其数据类型也必须相同。更重要的是,存储在同一索引中具有很少或没有共同字段的不同类型(实体)会导致数据稀疏,大大降低Lucece高效压缩文档的能力,影响其检索性能。
基于上述各种原因,故es将在后续版本中不支持一个索引中定义多个类型。
2、meta-field(元字段)
每个文档都有与之关联的元数据,例如_index、mapping _type和_id元字段。在创建映射类型时,可以定制其中一些元字段的行为。
- identity meta-fields(表明文档身份的元字段)
- _index
文档所在的索引,类似于关系型数据库的database。
- _uid
_type与_id的组合,文档的唯一标识。
- _type
文档映射类型。
- _id
文档的_id值。
- document source meta-fields
- _source
文档的原始json数据。
- _size
文档_souce字段的字节长度,需要插件:mapper-size plugin。
- indexing meta-fields
- _all
将所有字段映射成一个_all字段,在6.0.0版本后废弃,可以使用copy_to来定义需要聚合的字段。
_field_names
_field_names字段,用于索引文档中包含除null之外的任何值的每个字段的名称。exist查询使用这个字段来查找对于特定字段具有或不具有任何非空值的文档,也就是该字段记录的是字段值不为null的所有字段名称。当前版本,_field_names字段不包含启用了doc_values、norm的字段,对于启用doc_values或norm的字段,exist查询仍然可用,但不会使用_field_names字段。
注:禁用_field_names通常是不必要的,因为它不再承载以前的索引开销。如果你有很多禁用doc_value和norm的字段,并且你不需要使用这些字段执行exist查询,你可能想禁用_field_names,你可以通过如下方式禁用_field_names字段:
PUT tweets
{
“mappings”: {
“_doc”: {
"_
【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开:qq.cn.hn/FTf 免费领取
field_names": {
“enabled”: false
}
}
}
}
- _ignored
设置为ignore_malformed=true的所有字段。
- routing meta-field
- _routing
分片路由字段。
- other meta-field
1._meta
用于用户自定义的元数据,例如:
PUT my_index
{
“mappings”: {
“_doc”: {
“_meta”: {
“class”: “MyApp::User”,
“version”: {
“min”: “1.0”,
“max”: “1.3”
}
}
}
}