手动来为es创建index的mapping是非常重要的，需要每个field来进行分析，设置其参数，这样一方面可以节省存储空间，另一方面也可以由于字段设置不合理，导致需要重建索引这类昂贵的操作。
参考官网：把elastic search mapping设置时常用的设置参数进行总结
mapping parameters
官网参考：
https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-params.html#mapping-params
Type
text
用于字段要被全文搜索，如产品描述、新闻内容等，字段内容会被分析，在生成倒排索引之前，字符串会被分词器分成一个一个词项。text类型的字段不用于排序，很少用于聚合（termsAggregation除外）
keyword
用于结构化的数据，如email地址、主机名、状态码、标签等，通常用于过滤、排序、聚合。类型为keyword的字段只能通过精确值搜索到
数字类型
byte, short, integer, long, float, double, half_float, scaled_float
byte -128至127
short -32768至32767
integer -2^31至2^31-1
long -2^63至2^63-1
float 32位单精度IEEE 754浮点类型
double 64位单精度IEEE 754浮点类型
haif_float 16位半精度IEEE 754浮点类型
scaled_float 缩放类型的浮点数
对于年龄字段，使用short
字段的长度越短，索引和搜索的效率越高
处理浮点数时，优先考虑使用scaled_float. scaled_float是通过缩放因子把浮点数变成long类型。price字段取值57.34，设置放大因子100，存储起来就是5734，事实上ES底层存储的是整数类型，因为压缩整数比压缩浮点数更节省空间
date
参考：https://www.elastic.co/guide/en/elasticsearch/reference/current/date.html
JSON中没有日期类型，所以在Elasticsearch中日期可以是以下几种形式
1. 格式化日期的字符串
"2015-01-01" or "2015/01/01 12:10:30"
2. 代表milliseconds-since-the-epoch的长整形数 epoch指的是一个特定的时间1970-01-01 00:00:00 UTC
3. 代表seconds-since-the-epoch的整数型
PUT my_index/_doc/1
{ "date": "2015-01-01" }
PUT my_index/_doc/2
{ "date": "2015-01-01T12:10:30Z" }
PUT my_index/_doc/3
{ "date": 1420070400001 }
boolean
true false
analyzer
分词器，要注意如果修改分词器，那么是要重建索引的，因为分词的内容是放到倒排索引中的，如果不重建索引，是无法修改倒排索引中内容的，所以选择分词器就比较重要，比如中文分词使用ik_smart还是ik_max_word
normalizer
用于解析前的标准化配置，比如把所有的字符转化为小写
boost
用于设置字段的权重，比如，设置关键字出现在title字段的权重是出现在content字段中权重的两倍，其中content字段的默认权重为1
doc_values
doc values是磁盘上的数据结构，在文档索引时构建，它们存储与_source相同的值，但是以面向列的方式存储，这对于排序和聚合来说更有效。几乎所有字段类型都支持Doc值，但analyzed string fields除外。
支持doc values的所有字段都默认启用它们。如果您确定不需要对字段进行排序或聚合，则可以禁用doc值以节省磁盘空间
enabled
Elasticsearch默认会索引所有字段，而有些字段只需要存储，没有查询或者聚合的需求。enabled设置”enabled”: false的字段，Elasticsearch会跳过字段内容，该字段只能从_source字段中获取，但它不可被搜索或以任何其他方式存储
format
format参数用于自定日期格式
fielddata
默认情况下，大多数字段都被编入索引，这使得它们可以搜索。 但是，对脚本中的字段值进行排序，聚合和访问需要使用不同的搜索访问模式。
搜索需要回答“哪些document包含这个term？”这一问题，而排序和聚合需要回答一个不同的问题：“此document的此field的value是多少？”。
对于此数据访问模式，大多数字段可以使用索引时磁盘上doc_values，但文本字段不支持doc_values。
文本字段使用称为fielddata的查询时内存数据结构。 第一次将字段用于聚合，排序或脚本时，此数据结构是根据需要构建的。 它是通过从磁盘读取每个段的整个反向索引，反转term ↔document关系，并将结果存储在内存中的JVM堆中构建。
从这里我们对于倒排索引、doc_values以及fielddata之间的区别就清楚了
index_options
index_options参数控制将哪些信息添加到倒排索引中，以用于搜索和突出显示。 它接受以下设置：
docs
将doc number编入索引。可以回答这个问题”这个term是否在这个field中存在？”
freqs
将doc number和term frequencies编入索引。term frequencies用于对重复的terms进行高于单个terms的评分
position
将doc number和term frequencies以及term positions(or order)编入索引。positions可用于proximity or qhrase query
offsets
将doc number, term frequencies, positions以及开始和结束字符偏移（character offsets，将term映射回原始字符串）都编入索引。offsets被用来快速高亮
数字字段，不推荐使用index_options参数。
Analyzed string fields使用positions作为默认值，所有其他字段使用docs作为默认值
index
index选项控制是否索引字段值。 它接受true或false，默认为true。 未编制索引的字段不可查询。
fields
为不同目的以不同方式索引相同字段通常很有用。例如，字符串字段可以映射为full-text-search的text field，也可以映射为排序或聚合的keyword field
另一个应用需求是以不同方式analyze相同字段以获得更好的相关性，例如，我们可以使用standard analyzer对字段进行索引，该分析器将文本分解为单词，并再次使用english analyzer将单词串入其根形式
norms
norms存储各种normalization factor归一化因子，以便查询时计算文档的分数。尽管对于评分很有用，但norms也需要相当多的磁盘（通常在索引中每个document的每个field大约一个字节的顺序，即使对于没有此特定字段的文档也是如此）。 因此，如果您不需要对特定字段进行评分，则应禁用该字段的规范。 特别是，对于仅用于过滤或聚合的字段就是这种情况。
norms设置必须与同一索引中同名字段的设置相同。 可以使用PUT mapping API在现有字段上禁用norms。
规范可以被禁用（但不能再通过PUT mapping API重新启用）
null_value
无法索引或搜索空值null。 当字段设置为null（或空数组或空值数组）时，它被视为该字段没有值。
null_value参数允许您使用指定的值替换显式空值，以便可以对其进行索引和搜索。
search_analyzer
通常，应在索引时和搜索时应用相同的analyzer，以确保查询中的terms与倒排索引中的terms具有相同的格式。
但有时，在搜索时使用不同的analyzer是有意义的，默认情况下，查询将使用字段映射中定义的analyzer，但可以使用search_analyzer设置override此设置
store
默认情况下，field values会被索引以使其可搜索，但不会存储它们。 这意味着可以查询该字段，但无法检索原始字段值。
通常这没关系。 字段值已经是_source字段的一部分，默认情况下存储该字段。 如果您只想检索单个字段或几个字段的值，而不是整个_source，则可以使用源过滤source filter来实现。
在某些情况下，存储字段是有意义的。 例如，如果您有一个包含标题，日期和非常大的内容字段的文档，您可能只想检索标题和日期，而无需从大型_source字段中提取这些字段
term vectors
term vectors包含有关analysis过程产生的terms的信息，包括：
a list of terms.
the position (or order) of each term.
the start and end character offsets mapping the term to its origin in the original string.
这些term vectors被存储起来，以便可以针对特定文档检索它们。
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_position_offsets：Terms, positions, and character offsets are stored.