2、相反,如果在查询时指定boost值,每一个查询都可以使用不同的boost值,灵活。
3、在索引中指定boost值,boost存储在记录中,从而会降低分数计算的质量。
- coerce
是否进行类型“隐式转换”。es最终存储文档的格式是字符串。
例如存在如下字段类型:
“number_one”: {
“type”: “integer”
}
声明number_one字段的类型为数字类型,那是否允许接收“6”字符串形式的数据呢?因为在JSON中,“6”用来赋给int类型的字段,也是能接受的,默认coerce为true,表示允许这种赋值,但如果coerce设置为false,此时es只能接受不带双引号的数字,如果在coerce=false时,将“6”赋值给number_one时会抛出类型不匹配异常。
可以在创建索引时指定默认的coerce值,示例如下:
PUT my_index
{
“settings”: {
“index.mapping.coerce”: false
},
“mappings”: {
// 省略字段映射定义
}
}
- copy_to
copy_to参数允许您创建自定义的_all字段。换句话说,多个字段的值可以复制到一个字段中例如,first_name和last_name字段可以复制到full_name字段如下:
PUT my_index
{
“mappings”: {
“_doc”: {
“properties”: {
“first_name”: {
“type”: “text”,
“copy_to”: “full_name”
},
“last_name”: {
“type”: “text”,
“copy_to”: “full_name”
},
“full_name”: {
“type”: “text”
}
}
}
}
}
表示字段full_name的值来自 first_name + last_name。
关于copy_to重点说明:
1、字段的复制是原始值,而不是分词后的词根。
2、复制字段不会包含在_souce字段中,但可以使用复制字段进行查询。
3、同一个字段可以复制到多个字段,写法如下:“copy_to”: [ “field_1”, “field_2” ]
- doc_values
当需要对一个字段进行排序时,es需要提取匹配结果集中的排序字段值集合,然后进行排序。倒排索引的数据结构对检索来说相当高效,但对排序就不那么擅长了。
业界对排序、聚合非常高效的数据存储格式首推列式存储,在elasticsearch中,doc_values就是一种列式存储结构,默认情况下绝大多数数据类型都是开启的,即在索引时会将字段的值(或分词后的词根序列)加入到倒排索引中,同时也会该字段的值加入doc_values中,所有该类型的索引下该字段的值用一列存储。
doc_values的使用示例:
PUT my_index
{
“mappings”: {
“_doc”: {
“properties”: {
“status_code”: {
“type”: “keyword” // 默认情况下,“doc_values”:true
},
“session_id”: {
“type”: “keyword”,
“doc_values”: false
}
}
}
}
}
- dynamic
是否允许动态的隐式增加字段。在执行index api或更新文档API时,对于_source字段中包含一些原先未定义的字段采取的措施,根据dynamic的取值,会进行不同的操作:
-
true,默认值,表示新的字段会加入到类型映射中。
-
false,新的字段会被忽略,即不会存入_souce字段中,即不会存储新字段,也无法通过新字段进行查询。
-
strict,会显示抛出异常,需要新使用put mapping api先显示增加字段映射。
dynamic设置为false,也是可以通过put mapping api进行字段的新增,同样put mapping api可以对dynamic值进行更新。
举例说明:
PUT my_index/_doc/1
{
“username”: “johnsmith”,
“name”: {
“first”: “John”,
“last”: “Smith”
}
}
PUT my_index/_doc/2 // @1
{
“username”: “marywhite”,
“email”: “mary@white.com”,
“name”: {
“first”: “Mary”,
“middle”: “Alice”,
“last”: “White”
}
}
GET my_index/_mapping // @2
代码@1在原有的映射下,增加了username,name.middle两个字段,通过代码@2获取映射API可以得知,es已经为原本不存在的字段自动添加了类型映射定义。
注意:dynamic只对当前层级具有约束力,例如:
PUT my_index
{
“mappings”: {
“_doc”: {
“dynamic”: false, // @1
“properties”: {
“user”: { // @2
“properties”: {
“name”: {
“type”: “text”
},
“social_networks”: { // @3
“dynamic”: true,
“properties”: {}
}
}
}
}
}
}
}
代码@1:_doc类型的顶层不能不支持动态隐式添加字段映射。
代码@2:但_doc的嵌套对象user对象,是支持动态隐式添加字段映射。
代码@3:同样对于嵌套对象social_networks,也支持动态隐式添加字段映射。
- enabled
是否建立索引,默认情况下es会尝试为你索引所有的字段,但有时候某些类型的字段,无需建立索引,只是用来存储数据即可。只有映射类型(type)和object类型的字段可以设置enabled属性。示例如下:
PUT my_index
{
“mappings”: {
“_doc”: {
“properties”: {
“user_id”: {
“type”: “keyword”
},
“last_updated”: {
“type”: “date”
},
“session_data”: {
“enabled”: false
}
}
}
}
}
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”
}
上述示例,es会存储session_data对象的数据,但无法通过查询API根据session_data中的属性进行查询。
同样,可以通过put mapping api更新enabled属性。
- eager_global_ordinals
全局序列号,它以字典顺序为每个惟一的术语保持递增的编号。全局序号只支持字符串类型(关键字和文本字段)。在关键字字段中,它们在默认情况下是可用的,但文本字段只能fielddata=true时可用。doc_values(和fielddata)也有序号,是特定段(segment)和字段中所有词根(term)的唯一编号。全局序号只是在此之上构建的,它提供了段序号(segment ordinals)和全局序号(global ordinals)之间的映射,全局序号在整个分片中是唯一的。由于每个字段的全局序号与一个分片(shard)的所有段(segment)相关联,因此当一个新的segment(段)变为可见时,需要完全重新构建它们。术语聚合依懒全局序号,首先在分片级别(shard)执行聚合,然后汇聚所有分片的结果(reduce)并将全局序号转换为真正的词根(字符串),合并后返回聚合后的结果。默认情况下,全局序号是在搜索时加载的,这对提高索引API的速度会非常有利。但是,如果您更加重视搜索性能,,那么在您计划使用的聚合的字段上设置eager_global_ordinals,会对提高查询效率更有帮助。
eager_global_ordinals的意思是预先加载全局序号。
其示例如下:
PUT my_index/_mapping/_doc
{
“properties”: {
“tags”: {
“type”: “keyword”,
“eager_global_ordinals”: true
}
}
}
- fielddata
为了解决排序与聚合,elasticsearch提供了doc_values属性来支持列式存储,但doc_values不支持text字段类型。因为text字段是需要先分析(分词),会影响doc_values列式存储的性能。es为了支持text字段高效排序与聚合,引入了一种新的数据结构(fielddata),使用内存进行存储。默认构建时机为第一次聚合查询、排序操作时构建,主要存储倒排索引中的词根与文档的映射关系,聚合,排序操作在内存中执行。因此fielddata需要消耗大量的JVM堆内存。一旦fielddata加载到内存后,它将永久存在。通常情况下,加载fielddata是一个昂贵的操作,故默认情况下,text字段的字段默认是不开启fielddata机制。在使用fielddata之前请慎重考虑为什么要开启fielddata。通常text字段用来进行全文搜索,对于聚合、排序字段,建议使用doc_values机制。
为了节省内存的使用,es提供了另一项机制(fielddata_frequency_filter),允许只加载那些词根频率在指定范围(最大,小值)直接的词根与文档的映射关系,最大最小值可以指定为绝对值,例如数字,也可以基于百分比(百分比的计算是基于整个分段(segment),其频率分母不是分段(segment)中所有的文档,而是segment中该字段有值的文档)。可以通过min_segment_size参数来指定分段中必须包含的最小文档数量来排除小段,也就是说可以控制fielddata_frequency_filter的作用范围是包含大于min_segment_size的文档数量的段。fielddata_frequency_filter的使用示例如下:
- format
在JSON文档中,日期表示为字符串。Elasticsearch使用一组预先配置的格式来识别和解析这些字符串,并将其解析为long类型的数值(毫秒)。
日期格式主要包括如下3种方式:
1)自定义格式
2)date mesh(已在DSL查询API中详解)
3)内置格式
1、自定义格式
首先可以使用java定义时间的格式,例如:
PUT my_index
{
“mappings”: {
“_doc”: {
“properties”: {
“date”: {
“type”: “date”,
“format”: “yyyy-MM-dd HH:mm:ss”
}
}
}
}
}
2、date mesh
某些API支持,已在DSL查询API中详细介绍过,这里不再重复。
3、内置格式
elasticsearch为我们内置了大量的格式,如下:
- epoch_millis
时间戳,单位,毫秒。
- epoch_second
时间戳,单位,秒。
- date_optional_time
日期必填,时间可选,其支持的格式如下:
- basic_date
其格式表达式为 :yyyyMMdd
- basic_date_time
其格式表达式为:yyyyMMdd’T’HHmmss.SSSZ
- basic_date_time_no_millis
其格式表达式为:yyyyMMdd’T’HHmmssZ
- basic_ordinal_date
4位数的年 + 3位(day of year),其格式字符串为yyyyDDD
- basic_ordinal_date_time
其格式字符串为yyyyDDD’T’HHmmss.SSSZ
- basic_ordinal_date_time_no_millis
其格式字符串为yyyyDDD’T’HHmmssZ
- basic_time
其格式字符串为HHmmss.SSSZ
- basic_time_no_millis
其格式字符串为HHmmssZ
- basic_t_time
其格式字符串为’T’HHmmss.SSSZ
- basic_t_time_no_millis
其格式字符串为’T’HHmmssZ
- basic_week_date
其格式字符串为xxxx’W’wwe,4为年 ,然后用’W’, 2位week of year(所在年里周序号) 1位 day of week。
- basic_week_date_time
其格式字符串为xxxx’W’wwe’T’HH:mm:ss.SSSZ.
- basic_week_date_time_no_millis
其格式字符串为xxxx’W’wwe’T’HH:mm:ssZ.
- date
其格式字符串为yyyy-MM-dd
- date_hour
其格式字符串为yyyy-MM-dd’T’HH
- date_hour_minute
其格式字符串为yyyy-MM-dd’T’HH:mm
- date_hour_minute_second
其格式字符串为yyyy-MM-dd’T’HH:mm:ss
- date_hour_minute_second_fraction
其格式字符串为yyyy-MM-dd’T’HH:mm:ss.SSS
- date_hour_minute_second_millis
其格式字符串为yyyy-MM-dd’T’HH:mm:ss.SSS
- date_time
其格式字符串为yyyy-MM-dd’T’HH:mm:ss.SSS
- date_time_no_millis
其格式字符串为yyyy-MM-dd’T’HH:mm:ss
- hour
其格式字符串为HH
- hour_minute
其格式字符串为HH:mm
- hour_minute_second
其格式字符串为HH:mm:ss
- hour_minute_second_fraction
其格式字符串为HH:mm:ss.SSS
- hour_minute_second_millis
其格式字符串为HH:mm:ss.SSS
- ordinal_date
其格式字符串为yyyy-DDD,其中DDD为 day of year。
- ordinal_date_time
其格式字符串为yyyy-DDD‘T’HH:mm:ss.SSSZZ,其中DDD为 day of year。
- ordinal_date_time_no_millis
其格式字符串为yyyy-DDD‘T’HH:mm:ssZZ
- time
其格式字符串为HH:mm:ss.SSSZZ
- time_no_millis
其格式字符串为HH:mm:ssZZ
- t_time
其格式字符串为’T’HH:mm:ss.SSSZZ
- t_time_no_millis
其格式字符串为’T’HH:mm:ssZZ
- week_date
其格式字符串为xxxx-'W’ww-e,4位年份,ww表示week of year,e表示day of week。
- week_date_time
其格式字符串为xxxx-'W’ww-e’T’HH:mm:ss.SSSZZ
- week_date_time_no_millis
其格式字符串为xxxx-'W’ww-e’T’HH:mm:ssZZ
- weekyear
其格式字符串为xxxx
- weekyear_week
其格式字符串为xxxx-'W’ww,其中ww为week of year。
- weekyear_week_day
其格式字符串为xxxx-'W’ww-e,其中ww为week of year,e为day of week。
- year
其格式字符串为yyyy
- year_month
其格式字符串为yyyy-MM
- year_month_day
其格式字符串为yyyy-MM-dd
温馨提示,日期格式时,es建议在上述格式之前加上strict_前缀。
- ignore_above
超过ignore_above设置的字符串不会被索引或存储。对于字符串数组,将分别对每个数组元素应ignore_above,超过ignore_above的字符串元素将不会被索引或存储。目前测试的结果为:对于字符串字符长度超过ignore_above会存储,但不索引(也就是无法根据该值去查询)。其测试效果如下:
public static void create_mapping_ignore_above() { // 创建映射
RestHighLevelClient client = EsClient.getClient();
try {
CreateIndexRequest request = new CreateIndexRequest(“mapping_test_ignore_above2”);
XContentBuilder mapping = XContentFactory.jsonBuilder()
.startObject()
.startObject(“properties”)
.startObject(“lies”)
.field(“type”, “keyword”) // 创建关键字段
.field(“ignore_above”, 10) // 设置长度不能超过10
.endObject()
.endObject()
.endObject();
// request.mapping(“user”, mapping_user);
request.mapping(“_doc”, mapping);
System.out.println(client.indices().create(request, RequestOptions.DEFAULT));
} catch (Throwable e) {
e.printStackTrace();
} finally {
EsClient.close(client);
}
}
public static void index_mapping_ignore_above() { // 索引数据
RestHighLevelClient client = EsClient.getClient();
try {
IndexRequest request = new IndexRequest(“mapping_test_ignore_above2”, “_doc”);
Map<String, Object> data = new HashMap<>();
data.put(“lies”, new String[] {“dingabcdwei”,“huangsw”,“wuyanfengamdule”});
request.source(data);
System.out.println(client.index(request, RequestOptions.DEFAULT));
} catch (Throwable e) {
e.printStackTrace();
} finally {
EsClient.close(client);
}
}
public static void search_ignore_above() { // 查询数据
RestHighLevelClient client = EsClient.getClient();
try {
SearchRequest searchRequest = new SearchRequest();
searchRequest.indices(“mapping_test_ignore_above2”);
SearchSourceBuilder sourceBuilder = new SearchSourceBuilder();
sourceBuilder.query(
// QueryBuilders.matchAllQuery() // @1