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.

為了準確理解，粘貼英文原文。
大部分字段都是為了可以搜索，都是默認索引的，倒排索引的結(jié)構(gòu)使得查詢包含某些term的文檔非常高校，但涉及排序，聚合和腳本等，這個倒排索引效率就不行了，需要另外一種數(shù)據(jù)結(jié)構(gòu)。
Doc Value是存儲在硬盤上的數(shù)據(jù)結(jié)構(gòu)，在索引期間創(chuàng)建，存貯的數(shù)據(jù)和_source一樣，但是 column-oriented 形式的，這使得排序和聚合更為高效。

• 那么fielddata和doc_value，他們的目的都是一樣的，為了排序和聚合時回答這個文檔中某個字段是什么，而不是倒序的哪個文檔包含這個字段。
• 區(qū)別在于fielddata用于text，因為text不支持doc_value
  doc_values對于此數(shù)據(jù)訪問模式，大多數(shù)字段可以使用磁盤上的索引時間，但text字段不支持doc_values。

相反，text字段使用稱為查詢時的內(nèi)存中數(shù)據(jù)結(jié)構(gòu) fielddata。第一次將字段用于聚合，排序或腳本時，此數(shù)據(jù)結(jié)構(gòu)是根據(jù)需要構(gòu)建的。它是通過從磁盤讀取每個段的整個反向索引，反轉(zhuǎn)術(shù)語??文檔關(guān)系，并將結(jié)果存儲在內(nèi)存中的JVM堆中構(gòu)建的。

• 為什么對于text需要特殊處理？
  首先，不同的字段類型本身就有不同的目的，text的本意就是為了全文搜索，如果要排序，因使用keyword等，可以使用fields字段定義多個類型。非要用text做聚合，效率很低。

text默認情況下，在字段上禁用Fielddata 編輯
Fielddata可能會消耗大量的堆空間，尤其是在加載高基數(shù)text字段時。一旦fielddata已加載到堆中，它將在該段的生命周期內(nèi)保留。此外，加載fielddata是一個昂貴的過程，可能會導致用戶遇到延遲命中

Multi-fields

為不同目的以不同方式索引相同字段通常很有用。例如，string可以將字段映射為text用于全文搜索的keyword字段，
以及用于排序或聚合的字段?；蛘撸梢允褂胹tandard分析儀， english分析儀和 french分析儀索引文本字段。
這是多領(lǐng)域的目的。大多數(shù)數(shù)據(jù)類型都通過fields參數(shù)支持多字段。

這里只需要注意fields這個的語法即可，得取個名字分別進行使用

3.有哪些注意點

• 1.json對象的Object和nested區(qū)別
  參考文檔[https://elasticsearch.cn/book/elasticsearch_definitive_guide_2.x/nested-objects.html]
  對象默認映射為Object，此時ES的文檔組織會默認解析為扁平化的結(jié)構(gòu)，此時對象數(shù)組的同一個字段會組織在一起。
• 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、關(guān)于數(shù)組
  ES的所有類型的對象都是支持數(shù)組的，開箱即用。
  ES擁有這樣的特性，可以從lucene進行理解，我們知道Lucene是全文搜索引擎，他為了支持文本搜索使用了倒排索引。因此，所有的字段本身就是經(jīng)過分析器變成了多個值，所以自然也就自帶數(shù)組支持了

• 3、關(guān)于GEO
  地理位置是ES的重要特性，geo有很多的格式，表示方式。區(qū)別主要在于內(nèi)在的存貯格式，和效率有關(guān)
  最普通常見的就是各種形式的經(jīng)緯度對，數(shù)組，字符串，object等，特別注意的是 geohash和geo-shape，geo-shape用于各種多邊形形狀搜索

• 4、keyword 與 text
  區(qū)別只在于，text用于全文搜索，會經(jīng)過分析器分詞等，但keyword定位于精確值，所以不需要經(jīng)過分析詞。因此keyword常用語格式化的字段，而text用于一些非結(jié)構(gòu)性的，不用于排序，聚合等的字段

• join
  父-子關(guān)系文檔 在實質(zhì)上類似于 nested model ：允許將一個對象實體和另外一個對象實體關(guān)聯(lián)起來。 而這兩種類型的主要區(qū)別是：在 nested objects 文檔中，所有對象都是在同一個文檔中，而在父-子關(guān)系文檔中，父對象和子對象都是完全獨立的文檔。
  父-子關(guān)系的主要作用是允許把一個 type 的文檔和另外一個 type 的文檔關(guān)聯(lián)起來，構(gòu)成一對多的關(guān)系：一個父文檔可以對應多個子文檔 。與 nested objects 相比，父-子關(guān)系的主要優(yōu)勢有：
  更新父文檔時，不會重新索引子文檔。
  *最大優(yōu)勢！ 創(chuàng)建，修改或刪除子文檔時，不會影響父文檔或其他子文檔。這一點在這種場景下尤其有用：子文檔數(shù)量較多，并且子文檔創(chuàng)建和修改的頻率高時。
  子文檔可以作為搜索結(jié)果獨立返回。

連接字段不應像關(guān)系數(shù)據(jù)庫中的連接一樣使用。
在Elasticsearch中，良好性能的關(guān)鍵是將數(shù)據(jù)去規(guī)范化為文檔。每個聯(lián)接字段has_child或has_parent查詢都會為查詢性能添加重要稅。

連接字段有意義的唯一情況是，如果您的數(shù)據(jù)包含一對多關(guān)系，
其中一個實體明顯超過另一個實體。這種情況的一個例子是產(chǎn)品的用例和這些產(chǎn)品的報價。
如果提供的產(chǎn)品數(shù)量明顯多于產(chǎn)品數(shù)量，則將產(chǎn)品建模為父文檔并將產(chǎn)品建模為子文檔是有意義的。

實際情況下，往往通過增加數(shù)據(jù)冗余來完成，具體的效率還是需要進行評估的