analyzers：
定义使用的分词器。分词不仅发生在数据被索引存入数据时，也发生在查询。所以，查询和索引时最好使用同样的分词器。
Es在索引时寻找分词器的顺序：
- The analyzer defined in the field mapping.
- An analyzer named default in the index settings.
- The standard analyzer.
Es 查询时学找分词器的顺序：
- The analyzer defined in a full-text query.
- The search_analyzer defined in the field mapping.
- The analyzer defined in the field mapping.
- An analyzer named default_search in the index settings.
- An analyzer named default in the index settings.
- The standard analyzer.
search_quote_analyzer： 设置允许您为短语指定分析器，这在处理禁用短语查询的停用词时特别有用。
Normalizer: 是keyword的属性，和分词器类似吗，就是对keywrod的值在进一步做处理。这个是属性在索引keyword和查询keyword都会使用。
官网个的例子就是对单词进行大小写转化和还有词根。
PUT index
{
"settings": {
"analysis": {
"normalizer": {
"my_normalizer": {
"type": "custom",
"char_filter": [],
"filter": ["lowercase", "asciifolding"]
}
}
}
},
"mappings": {
"_doc": {
"properties": {
"foo": {
"type": "keyword",
"normalizer": "my_normalizer"
}
}
}
}
}
PUT index/_doc/1
{
"foo": "BÀR"
}
PUT index/_doc/2
{
"foo": "bar"
}
PUT index/_doc/3
{
"foo": "baz"
}
POST index/_refresh
GET index/_search
{
"query": {
"term": {
"foo": "BAR"
}
}
}
GET index/_search
{
"query": {
"match": {
"foo": "BAR"
}
}
}
返回结果：
"hits" : [
{
"_index" : "index",
"_type" : "_doc",
"_id" : "2",
"_score" : 0.2876821,
"_source" : {
"foo" : "bar"
}
},
{
"_index" : "index",
"_type" : "_doc",
"_id" : "1",
"_score" : 0.2876821,
"_source" : {
"foo" : "BÀR"
}
}
]可以看出 bar 和 BÀR 都被查询出来了。
Boost:
根据boost的值查询时得到的分数也不一样。 默认值是1
PUT my_index
{
"mappings": {
"_doc": {
"properties": {
"title": {
"type": "text",
"boost": 2
},
"content": {
"type": "text"
}
}
}
}
}这个参数值适用于trems 查询， prefix, range and fuzzy queries are not boosted 是不适用的
Coerce：
数据并不总是干净的。 根据它的生成方式，可以在JSON体中将数字呈现为真正的JSON数，例如 5，但它也可以呈现为字符串，例如“5”。 或者，应该是整数的数字可以替代地呈现为浮点，例如， 5.0，甚至“5.0”.
PUT my_index
{
"mappings": {
"_doc": {
"properties": {
"number_one": {
"type": "integer"
},
"number_two": {
"type": "integer",
"coerce": false
}
}
}
}
}
PUT my_index/_doc/1
{
"number_one": "10.2"
}
PUT my_index/_doc/2
{
"number_two": "10"
}
第二跳数据插入失败，因为coerce = false.
copy_to:
允许把多个字段合并成一个字段，然后进行查询。和_all 类型，能进行索引，但是没有被存储。
注意： copy_to 只是复制字段并不会修改_source字段。可以将同样的值赋值到多个字段像这样"copy_to": [ "field_1", "field_2" ] 。不能进行递归赋值。
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"
}
}
}
}
}
PUT my_index/_doc/1
{
"first_name": "John",
"last_name": "Smith"
}
GET my_index/_search
{
"query": {
"match": {
"full_name": {
"query": "John Smith",
"operator": "and"
}
}
}
}
返回结果：
"hits" : [
{
"_index" : "my_index",
"_type" : "_doc",
"_id" : "1",
"_score" : 0.5753642,
"_source" : {
"first_name" : "John",
"last_name" : "Smith"
}
}
]
doc_values: 开启后会以面向列的方式进行存储数据，这样更有利于排序和集合。如果字段不需要排序和集合可以关掉，节省磁盘空间。默认情况下支付doc的值默认都是开启的。
Dynamic：
默认情况下字段可以被动态添加，如果索引没有字段类型，会根据字段值添加创建字段类型。
Dynamic ：
True: 新检测到的字段将添加到映射中
False: 新检测到的字段将被忽略。 这些字段不会被编入索引，因此无法搜索，但仍会出现在返回的匹配的_source字段中。 这些字段不会添加到映射中，必须显式添加新字段。
Strict: 如果检测到新字段，则抛出异常并拒绝该文档。 必须将新字段显式添加到映射中。
PUT my_index
{
"mappings": {
"_doc": {
"dynamic": "false",
"properties": {
"user": {
"properties": {
"name": {
"type": "text"
},
"social_networks": {
"dynamic": true,
"properties": {}
}
}
}
}
}
}
}
PUT my_index/_doc/1
{
"aa": "aa"
}
插入成功。
GET my_index/_search
{
"query": {
"match": {
"aa": "aa"
}
}
}
返回结果：
"hits" : {
"total" : 0,
"max_score" : null,
"hits" : [ ]
}搜索不到。
就算后面显示加字段，因为之前的数据没有被索引，索引之前已经插入的数据也索引不到。
Enabled：
Elasticsearch尝试索引您提供的所有字段，但有时您只想存储字段而不对其进行索引。 例如，假设您使用Elasticsearch作为Web会话存储。 您可能希望索引会话ID和上次更新时间，但不需要在会话数据本身上查询或运行聚合。
启用的设置（仅适用于映射类型和对象字段）会导致Elasticsearch完全跳过对字段内容的解析。 仍然可以从_source字段检索JSON，但它不可搜索或以任何其他方式存储。
就是就把字段值存储到_source里面，但是不会对字段索引解析。
eager_global_ordinals:
全局序数是doc值之上的数据结构，它维护词典顺序中每个唯一术语的增量编号。每个术语都有一个唯一的数字，术语A的数量低于术语B的数量。全局序数仅受关键字和文本字段的支持。在关键字字段中，默认情况下它们可用，但文本字段只能在具有所有相关行李的fielddata启用时使用。
Doc值（和fielddata）也有序数，这是特定段和字段中所有术语的唯一编号。通过提供段序数和全局序数之间的映射，全局序数构建在此之上，后者在整个分片中是唯一的。鉴于特定字段的全局序数与分片的所有分段相关联，只要一个新分段变得可见，就需要完全重建它们。
全局序数用于使用段序数的功能，例如术语聚合，以缩短执行时间。术语聚合完全依赖于全局序数来在分片级别执行聚合，然后仅将最终减少阶段的全局序数转换为实际术语，其结合来自不同分片的结果。
全局序数的加载时间取决于字段中的术语数，但通常它很低，因为它已经加载了源字段数据。全局序数的内存开销很小，因为它被非常有效地压缩。
默认情况下，全局序数在搜索时加载，如果您正在优化索引速度，这是正确的权衡。但是，如果您对搜索速度更感兴趣，那么在您计划在聚合术语中使用的字段上设置eager_global_ordinals：true会很有趣：
这会将成本从搜索时间转移到刷新时间。 Elasticsearch将确保在发布索引内容的更新之前构建全局序数。
Fielddata: 解决text 字段做聚合。文本字段使用名为fielddata的查询时内存数据结构。 第一次将字段用于聚合，排序或脚本时，此数据结构是根据需要构建的。 它是通过从磁盘读取每个段的整个反向索引，反转术语↔︎文档关系，并将结果存储在内存中的JVM堆中构建的。
Fielddata可能会消耗大量的堆空间，尤其是在加载高基数文本字段时。 一旦fielddata已加载到堆中，它将在该段的生命周期内保留。 此外，加载fielddata是一个昂贵的过程，可能会导致用户遇到延迟命中。 这就是默认情况下禁用fielddata的原因。
如果您尝试对文本字段上的脚本进行排序，聚合或访问，您将看到以下异常：
默认情况下，在文本字段上禁用Fielddata。 在[your_field_name]上设置fielddata = true，以便通过反转索引来加载内存中的fielddata。 请注意，这可能会占用大量内存。
PUT my_index
{
"mappings": {
"_doc": {
"properties": {
"my_field": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword"
}
}
}
}
}
}
}
PUT my_index/_mapping/_doc
{
"properties": {
"my_field": {
"type": "text",
"fielddata": true
}
}
}
PUT my_index/_doc/1
{
"my_field": "hello word"
}
PUT my_index/_doc/2
{
"my_field": "hello hi"
}
GET my_index/_search
{
"aggs": {
"group": {
"terms": {
"field": "my_field",
"size": 10
}
}
}
}
返回结果
"aggregations" : {
"group" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "hello",
"doc_count" : 2
},
{
"key" : "hi",
"doc_count" : 1
},
{
"key" : "word",
"doc_count" : 1
}
]
}
}可以看出 对数据的中所有的term 进行了聚合。
fielddata_frequency_filter：
Fielddata过滤可用于减少加载到内存中的术语数量，从而减少内存使用量。 条款可按频率过滤：
频率过滤器允许您仅加载文档频率介于最小值和最大值之间的术语，可以表示为绝对数字（当数字大于1.0时）或百分比（例如0.01为1％，1.0为100）％）。 每段计算频率。 百分比基于具有该字段值的文档数，而不是该段中的所有文档。
通过使用min_segment_size指定段应包含的最小文档数，可以完全排除小段：
PUT my_index
{
"mappings": {
"_doc": {
"properties": {
"tag": {
"type": "text",
"fielddata": true,
"fielddata_frequency_filter": {
"min": 0.001,
"max": 0.1,
"min_segment_size": 500
}
}
}
}
}
}一般情况下 Fielddata 不会被使用。
Format： 用于date类型，根据需要定义自己的时间格式。默认的格式是
"strict_date_optional_time||epoch_millis"。
ignore_above：
长度超过ignore_above设置的字符串将不会被索引或存储。 对于字符串数组，ignore_above将分别应用于每个数组元素，并且不会索引或存储比ignore_above更长的字符串元素。
如果启用了后者，那么所有字符串/数组元素仍将出现在_source字段中，这是Elasticsearch中的默认值。
ignore_malformed：
有时您无法控制所收到的数据。 一个用户可以发送作为日期的登录字段，另一个用户发送作为电子邮件地址的登录字段。
尝试将错误的数据类型索引到字段中默认情况下会抛出异常，并拒绝整个文档。 ignore_malformed参数（如果设置为true）允许忽略该异常。 格式错误的字段未编入索引，但文档中的其他字段正常处理。
Index:
index选项控制是否索引字段值。 它接受true或false，默认为true。 未编制索引的字段不可查询。
index_options :
index_options参数控制将哪些信息添加到反向索引，以用于搜索和突出显示。 它接受以下设置：
docs
仅索引文档编号
freqs
Doc编号和术语频率被编入索引。 术语频率用于对重复术语进行高于单个术语的评分。
Positions
文档编号，术语频率和术语位置（或顺序）被编入索引。 位置可用于邻近或短语查询
Offsets
文档编号，术语频率，位置以及开始和结束字符偏移（将术语映射回原始字符串）都被编入索引。 统一荧光笔使用偏移来加速突出显示。
Fields：
这个通常被用来以不同的方式索引同一个字段。比如一个string字符串 text用来全文检索，keyword 用来聚合。
PUT my_index
{
"mappings": {
"_doc": {
"properties": {
"city": {
"type": "text",
"fields": {
"raw": {
"type": "keyword"
}
}
}
}
}
}
}
Norms：规范存储稍后在查询时使用的各种归一化因子，以便相对于查询计算文档的分数。
尽管对评分很有用，但规范也需要相当多的磁盘（通常在索引中每个字段的每个文档大约一个字节的顺序，即使对于没有此特定字段的文档也是如此）。 因此，如果您不需要对特定字段进行评分，则应禁用该字段上的规范。 特别是，对于仅用于过滤或聚合的字段就是这种情况。
null_value：
无法索引或搜索空值。 当一个字段设置为null（或一个空数组或一个空值数组）时，它被视为该字段没有值。
null_value参数允许您使用指定的值替换显式空值，以便可以对其进行索引和搜索。
null_value需要与字段的数据类型相同。 例如，long字段不能包含字符串null_value。
null_value仅影响数据的索引方式，不会修改_source文档。
position_increment_gap：
分析的文本字段将术语位置考虑在内，以便能够支持邻近或短语查询。 使用多个值索引文本字段时，会在值之间添加“假”间隙，以防止大多数短语查询在值之间进行匹配。 使用position_increment_gap配置此间隙的大小，默认为100。
就是字段是数组时，每个数组之间的间隔是100.
PUT my_index/_doc/1
{
"names": [ "John Abraham", "Lincoln Smith"]
}
GET my_index/_search
{
"query": {
"match_phrase": {
"names": {
"query": "Abraham Lincoln"
}
}
}
}
这个返回的空结果
GET my_index/_search
{
"query": {
"match_phrase": {
"names": {
"query": "Abraham Lincoln",
"slop": 101
}
}
}
}
这个会返回结果 因为 slop > position_increment_gap。
PUT my_index
{
"mappings": {
"_doc": {
"properties": {
"names": {
"type": "text",
"position_increment_gap": 0
}
}
}
}
}
PUT my_index/_doc/1
{
"names": [ "John Abraham", "Lincoln Smith"]
}
GET my_index/_search
{
"query": {
"match_phrase": {
"names": "Abraham Lincoln"
}
}
}
这个会返回结果 因为position_increment_gap 为0。
properties ：设置索引属性。
search_analyzer： 通常，应在索引时和搜索时应用相同的分析器，以确保查询中的术语与反向索引中的术语具有相同的格式。
但有时，在搜索时使用不同的分析器是有意义的，例如在使用edge_ngram标记生成器进行自动完成时。
默认情况下，查询将使用字段映射中定义的分析器，但可以使用search_analyzer设置覆盖此设置：
similarity ：
Elasticsearch允许您为每个字段配置评分算法或相似性。相似性设置提供了一种选择除默认BM25之外的相似性算法的简单方法，例如TF / IDF。
相似性主要用于文本字段，但也可以应用于其他字段类型。
可以通过调整内置相似性的参数来配置自定义相似性。有关此专家选项的更多详细信息，请参阅相似性模块。
开箱即用的唯一相似之处是没有任何进一步配置：
BM25
Okapi BM25算法。默认情况下在Elasticsearch和Lucene中使用的算法。有关详细信息，请参阅可插入相似度算法。
经典
TF / IDF算法曾经是Elasticsearch和Lucene的默认算法。有关更多信息，请参阅Lucene的实用评分函数。
布尔
一个简单的布尔相似性，在不需要全文排名时使用，分数应仅基于查询词是否匹配。布尔相似度为术语提供与其查询提升相等的分数。
PUT my_index
{
"mappings": {
"_doc": {
"properties": {
"default_field": {
"type": "text"
},
"boolean_sim_field": {
"type": "text",
"similarity": "boolean"
}
}
}
}
}store ：
默认情况下，字段值会被索引以使其可搜索，但不会存储它们。 这意味着可以查询该字段，但无法检索原始字段值。
通常这没关系。 字段值已经是_source字段的一部分，默认情况下存储该字段。 如果您只想检索单个字段或几个字段的值，而不是整个_source，则可以使用源过滤来实现。
在某些情况下，存储字段是有意义的。 例如，如果您有一个包含标题，日期和非常大的内容字段的文档，您可能只想检索标题和日期，而无需从大型_source字段中提取这些字段：
存储字段的另一种情况是那些没有出现在_source字段中的字段（例如copy_to字段）。
term_vector ：
设置trems被分词器处理的过程产生的属性。
no | No term vectors are stored. (default) |
yes | Just the terms in the field are stored. |
with_positions | Terms and positions are stored. |
with_offsets | Terms and character offsets are stored. |
with_positions_offsets | Terms, positions, and character offsets are stored. |
The fast vector highlighter requires with_positions_offsets. The term vectors API can retrieve whatever is stored.
设置with_positions_offsets会使字段索引的大小加倍。
