再次学习ES--10--6.4Mapping
1.ES6.4支持的 field type
参考文档：【https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-types.html】
2.字段类型有哪些支持的属性
doc_values和fielddata，重点理解
Most fields are indexed by default, which makes them searchable.
The inverted index allows queries to look up the search term
in unique sorted list of terms,
and from that immediately have access to the list of documents that contain the term.
Sorting, aggregations, and access to field values in scripts
requires a different data access pattern.
Instead of looking up the term and finding documents,
we need to be able to look up the document and find the terms that it has in a field.
Doc values are the on-disk data structure,
built at document index time, which makes this data access pattern possible.
They store the same values as the _source but in a column-oriented fashion
that is way more efficient for sorting and aggregations.
Doc values are supported on almost all field types,
with the notable exception of analyzed string fields.
为了准确理解，粘贴英文原文。
大部分字段都是为了可以搜索，都是默认索引的，倒排索引的结构使得查询包含某些term的文档非常高校，但涉及排序，聚合和脚本等，这个倒排索引效率就不行了，需要另外一种数据结构。
Doc Value是存储在硬盘上的数据结构，在索引期间创建，存贮的数据和_source一样，但是 column-oriented 形式的，这使得排序和聚合更为高效。
- 那么fielddata和doc_value，他们的目的都是一样的，为了排序和聚合时回答这个文档中某个字段是什么，而不是倒序的哪个文档包含这个字段。
- 区别在于fielddata用于text，因为text不支持doc_value
doc_values对于此数据访问模式，大多数字段可以使用磁盘上的索引时间，但text字段不支持doc_values。
相反，text字段使用称为查询时的内存中数据结构 fielddata。第一次将字段用于聚合，排序或脚本时，此数据结构是根据需要构建的。它是通过从磁盘读取每个段的整个反向索引，反转术语↔︎文档关系，并将结果存储在内存中的JVM堆中构建的。
- 为什么对于text需要特殊处理？
首先，不同的字段类型本身就有不同的目的，text的本意就是为了全文搜索，如果要排序，因使用keyword等，可以使用fields字段定义多个类型。非要用text做聚合，效率很低。
text默认情况下，在字段上禁用Fielddata 编辑
Fielddata可能会消耗大量的堆空间，尤其是在加载高基数text字段时。一旦fielddata已加载到堆中，它将在该段的生命周期内保留。此外，加载fielddata是一个昂贵的过程，可能会导致用户遇到延迟命中
Multi-fields
为不同目的以不同方式索引相同字段通常很有用。例如，string可以将字段映射为text用于全文搜索的keyword字段，
以及用于排序或聚合的字段。或者，您可以使用standard分析仪， english分析仪和 french分析仪索引文本字段。
这是多领域的目的。大多数数据类型都通过fields参数支持多字段。
这里只需要注意fields这个的语法即可，得取个名字分别进行使用
3.有哪些注意点
- 1.json对象的Object和nested区别
参考文档[https://elasticsearch.cn/book/elasticsearch_definitive_guide_2.x/nested-objects.html]
对象默认映射为Object，此时ES的文档组织会默认解析为扁平化的结构，此时对象数组的同一个字段会组织在一起。 - Nested格式在查询等操作时，需要使用特定的格式
OBJECT
{
"title": [ eggs, nest ],
"body": [ making, money, work, your ],
"tags": [ cash, shares ],
"comments.name": [ alice, john, smith, white ],
"comments.comment": [ article, great, like, more, please, this ],
"comments.age": [ 28, 31 ],
"comments.stars": [ 4, 5 ],
"comments.date": [ 2014-09-01, 2014-10-22 ]
}
NESTED
{
"comments.name": [ john, smith ],
"comments.comment": [ article, great ],
"comments.age": [ 28 ],
"comments.stars": [ 4 ],
"comments.date": [ 2014-09-01 ]
}
{
"comments.name": [ alice, white ],
"comments.comment": [ like, more, please, this ],
"comments.age": [ 31 ],
"comments.stars": [ 5 ],
"comments.date": [ 2014-10-22 ]
}
-
2、关于数组
ES的所有类型的对象都是支持数组的，开箱即用。
ES拥有这样的特性，可以从lucene进行理解，我们知道Lucene是全文搜索引擎，他为了支持文本搜索使用了倒排索引。因此，所有的字段本身就是经过分析器变成了多个值，所以自然也就自带数组支持了 -
3、关于GEO
地理位置是ES的重要特性，geo有很多的格式，表示方式。区别主要在于内在的存贮格式，和效率有关
最普通常见的就是各种形式的经纬度对，数组，字符串，object等，特别注意的是 geohash和geo-shape，geo-shape用于各种多边形形状搜索 -
4、keyword 与 text
区别只在于，text用于全文搜索，会经过分析器分词等，但keyword定位于精确值，所以不需要经过分析词。因此keyword常用语格式化的字段，而text用于一些非结构性的，不用于排序，聚合等的字段 -
join
父-子关系文档 在实质上类似于 nested model ：允许将一个对象实体和另外一个对象实体关联起来。 而这两种类型的主要区别是：在 nested objects 文档中，所有对象都是在同一个文档中，而在父-子关系文档中，父对象和子对象都是完全独立的文档。
父-子关系的主要作用是允许把一个 type 的文档和另外一个 type 的文档关联起来，构成一对多的关系：一个父文档可以对应多个子文档 。与 nested objects 相比，父-子关系的主要优势有：
更新父文档时，不会重新索引子文档。
*最大优势！ 创建，修改或删除子文档时，不会影响父文档或其他子文档。这一点在这种场景下尤其有用：子文档数量较多，并且子文档创建和修改的频率高时。
子文档可以作为搜索结果独立返回。
连接字段不应像关系数据库中的连接一样使用。
在Elasticsearch中，良好性能的关键是将数据去规范化为文档。每个联接字段has_child或has_parent查询都会为查询性能添加重要税。
连接字段有意义的唯一情况是，如果您的数据包含一对多关系，
其中一个实体明显超过另一个实体。这种情况的一个例子是产品的用例和这些产品的报价。
如果提供的产品数量明显多于产品数量，则将产品建模为父文档并将产品建模为子文档是有意义的。
实际情况下，往往通过增加数据冗余来完成，具体的效率还是需要进行评估的
