03.elasticsearch-mapping-param解析
文章目錄
- 1. mapping param
- 1. 概覽
- 2. mapping param詳述
- 1.1 analyzer
- 1.2.search_quote_analyzer
- 2. normalizer
- 3. boost
- 4. coerce
- 5. copy_to
- 6. doc_values
- 7. dynamic
- 8. enabled
- 9. fielddata
- 1. fielddata 功能
- 2.fielddata_frequency_filter
- 10. eager_global_ordinals
- 1. 什么是全局序數
- 2. global ordinals的load時機
- 3. global ordinals使用建議
- 11. format
- 1. 內建format的樣例
- 2. built-in format
- 12. ignore_above
- 13. ignore_malformed
- 14. index_options
- 15. index_phrases
- 16. index_prefixes
- 17. index
- 18. fields
- 19. norms
- 20. null_value
- 21. position_increment_gap
- 22. properties
- 23. search_analyzer
- 24. similarity
- 25. store
- 26. term_vector
1. mapping param
mapping param 是在定義es中index存儲的doc的某個字段的一些特征的，他決定了該字段的存儲方式以及在存儲之前的analysis部分如何進行。
不同的數據類型的field可以設置的mapping param是下面概覽的中的一個子集。在前文中不同的type的field能夠設置的mapping param也是有記錄的。
1. 概覽
2. mapping param詳述
1.1 analyzer
這個主要設置的是index的時候首先選擇的analyzer,也是search中中等優先使用的analyzer.
可以參考analyzer相關文章來回顧。
樣例
1.2.search_quote_analyzer
不太明白官方在這一個頁面擠進來兩個analyzer，不知道怎么想的，但是為了更好的和官方對應，我也擠一擠好了
這個analyzer是專門為精準的phrase查詢服務的，也就是針對那些可能有停用詞的phrase查詢。
如果想要實現精確的phrase查詢，需要在mapping中有這樣的配置
2. normalizer
注意，這里不要和后面的norms搞混了，這個也是analysis的一部分。
只不過他是char_filter 和 token_filter的組合。
還有就是他可以在keyword類型的字段中使用，會改變dov_values中存儲的值。
使用agg查詢的時候是這樣
GET index/_search {"size": 0,"aggs": {"foo_terms": {"terms": {"field": "foo"}}} }返回 ..."aggregations": {"foo_terms": {"doc_count_error_upper_bound": 0,"sum_other_doc_count": 0,"buckets": [{"key": "bar","doc_count": 2},{"key": "baz","doc_count": 1}]}}這里是因為doc_values中的存儲和_source中對應的字段的值是不一樣的導致的。
3. boost
首先說一下，在index的時候指定boost的方式在5.0的時候就已經過期了
在mapping中定義的boost只是在search的時候使用。
也就是
的查詢效果和
POST _search {"query": {"match" : {"title": {"query": "quick brown fox","boost": 2}}} }是一致的,主要是用來干預打分。
4. coerce
這個屬性是為了處理一些相對來說沒有那么臟的數據，
非常臟的數據，比如type為integer，index的時候給了一個字符串 “abc” ,那么就只能是拋異常，或者是通過設置 ignore_malformed 來忽略對應的字段的dov_values等設置，只是在_source字段中進行存儲。
沒有那么臟的數據，比如
注意這個設置只是針對number類型和geometry 類型的數據進行處理
定義type為keyword, indexing為 數字可以成功，這個功勞不是coerce的，后面會看到這個是dynamic mapping的功勞
實際上在dynamic mapping中也沒有看到，應該是其他類型的往string轉都是直接根據mapping中的顯式定義轉了
樣例
PUT my_index {"aliases" : { },"mappings" : {"properties" : {"requests" : {"type" : "text"},"number":{"type": "integer","coerce":true}}} }PUT my_index/_doc/1 {"requests":"hahaha","number":"5" }PUT my_index/_doc/2 {"requests":"hahaha","number":6.1 }PUT my_index/_doc/3 {"requests":"hahaha","number":7 }GET my_index/_search {"query": {"match_all": {}},"sort": [{"number": {"order": "asc"}}] }返回
{"took" : 1,"timed_out" : false,"_shards" : {"successful" : 1,"skipped" : 0,"failed" : 0},"hits" : {"total" : {"value" : 3,"relation" : "eq"},"max_score" : null,"hits" : [{"_index" : "my_index","_type" : "_doc","_id" : "1","_score" : null,"_source" : { "requests" : "hahaha", "number" : "5" },"sort" : [ 5 ]},{"_index" : "my_index","_type" : "_doc","_id" : "2","_score" : null,"_source" : { "requests" : "hahaha", "number" : 6.1 },"sort" : [ 6 ]},{"_index" : "my_index","_type" : "_doc","_id" : "3","_score" : null,"_source" : { "requests" : "hahaha", "number" : 7 },"sort" : [ 7 ]}]} }從sort字段中可以看出來存儲的對應的doc_values都已經發生了變化了，因為被corces 處理了。
假如mapping中將corece定義為false,則put操作中的6.1，“5” 都會直接拋異常。
同時這個設置可以直接在mapping級別進行設置
PUT my_index {"settings": {"index.mapping.coerce": false},"mappings": {"properties": {"number_one": {"type": "integer","coerce": true},"number_two": {"type": "integer"}}} }5. copy_to
這個是可以設置將多個filed拷貝到一個或者多個其他的field當中。
PUT my_index {"mappings": {"properties": {"first_name": {"type": "text","copy_to": "last_name" },"last_name": {"type": "text","copy_to": "full_name" },"full_name": {"type": "text"}}} }PUT my_index/_doc/1 {"first_name": "John good boy ","last_name": "Smith bad girl " }GET my_index/_search {"query": {"match": {"full_name": { "query": "smith"}}} }上面的文檔會命中put進去的文檔，但是query換成john，good ，boy 中的任意組合都是不能搜索出來的，也就是拷貝會不進行循環,first_name 拷貝到last_name的值不會再拷貝到full_name,只有直接indexing進last_name的值會進入索引。
假如使用下面的查詢
GET my_index/_search {"query": {"match": {"last_name": "good"}} }也是可以命中該文檔的。
總的來說，copy_to 有以下特性：
6. doc_values
大部分field都進行了indexed操作生成了倒排詞典來查詢，但是進行agg,sort，script_field操作的時候，我們需要快速根據文檔的編號獲取某個field的值。
doc_values存儲在磁盤上，在indexing的時候生成，采用列式存儲，獲取對應的field更加快速。除了 analyzed 的字段，doc_values支持其他的大部分常見字段。
如果這個字段不用來agg,sort,script_field操作，你也可以禁用doc_values來節約磁盤。
7. dynamic
默認的情況下doc mapping中的field是可以根據文檔內容動態增加的，對于object類型的field其子field也是可以動態增加的。
其背后就是這個dynamic mapping param在起作用，該字段可以有三個值
在2，3情況下想要正價filed只有修改mapping
這個字段可以直接在整個mapping級別設置或者為某一個字段設置,采用最近父親生效原則，比如下面的social_networks可以動態增加field
PUT my_index {"mappings": {"dynamic": false, "properties": {"user": { "properties": {"name": {"type": "text"},"social_networks": { "dynamic": true,"properties": {}}}}}} }8. enabled
如果對某個field設置了enabled:false該字段不會被index,所以也不能被搜索,也可以對整個mapping設置，這樣的話index的所有字段都是沒有indexed的。
樣例
PUT my_index {"mappings": {"properties": {"user_id": {"type": "keyword"},"last_updated": {"type": "date"},"session_data": { "type": "object","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" }PUT my_index/_doc/session_2 {"user_id": "jpountz","session_data": "none", "last_updated": "2015-12-06T18:22:13" }GET my_index 返回 {"my_index" : {"aliases" : { },"mappings" : {"properties" : {"last_updated" : {"type" : "date"},"session_data" : {"type" : "object","enabled" : false},"user_id" : {"type" : "keyword"}}} }首先，這個地方的put session_1 的session_data的內容會被忽略，只會存在_source當中，不能被搜索，對應的mapping文件也不會有dynamic field加入。
對整個mapping設置的樣例
PUT my_index {"mappings": {"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" }GET my_index?flat_settings=true 返回 {"my_index" : {"aliases" : { },"mappings" : {"enabled" : false},"settings" : {"index.creation_date" : "1605509510151","index.number_of_replicas" : "1","index.number_of_shards" : "1","index.provided_name" : "my_index","index.uuid" : "UFZynHQuQl29jg4bFf8mtQ","index.version.created" : "7020099"}} }9. fielddata
1. fielddata 功能
text field沒有doc_values結構，所以針對text field 的agg,sort ，script操作維護了一個 query-time in-memory 的數據結構，這個數據結構就叫 fielddata ,
他會在第一次使用一個text field進行agg,sort,script操作的時候構建的。這個操作耗時耗內存，他是通過加載所有的倒排詞典，構建doc->term的正向信息，在jvm中保存這些信息。
對于text field這個字段默認也是 disabled 的。
如果非要使用text field進行聚合的話應該使用fields特性新定一個filed 存儲為keyword 使用doc_values特性進行agg, sort,script 操作。
2.fielddata_frequency_filter
為了優化fielddata對內存的使用，增加了一個2.fielddata_frequency_filter 來選擇性的只加載一些
PUT my_index {"mappings": {"properties": {"tag": {"type": "text","fielddata": true,"fielddata_frequency_filter": {"min": 0.001,"max": 0.1,"min_segment_size": 500}}}} }含有該term的doc的數量要大于總量的千分之一但是要小于十分之一，segment的doc的數量大于500才會被加載。
10. eager_global_ordinals
1. 什么是全局序數
全局序數主要是為了dov_values類型的數據的agg查詢做優化的。
在每個segment當中，對于dov_vlues類型的數據存儲做了優化，并不是直接存儲doc_id—> field的映射，而是維護了一個segment ordinals mapping，這個mapping的key是一個數字，這個數字是怎么來的呢，比如把所有的filed值做字典排序后的序數，或者直接就是賦予一個遞增的integer(去重后)，mapping的val是一個keyword(對應的field的value)。這樣的話在doc_values中就只需要存儲doc_id—>(maping中的key)就行了。這樣可以實現數據的壓縮，對于重復的字段，在doc_values中就只會存儲一份。
整個結構類似這樣
doc_values:
doc_id—>segment-ordianl
segment-ordinal—>field-value
注意，上面講的只是segment ordianals,并不是glabal ordinals。
global ordinals 就是把當前shard中的所有的segment ordinals 構建為一個全局的 ordinals。
主要的作用在于使用agg等操作的時候不需要再訪問field的真實值即可進行訪問。對于sort操作不起作用，因為global-ordinal的大小不代表field-value的大小，只能取得field value之后再進行比較。
所以sort操作只需要segment-ordinals就足夠了，不需要glabal-ordinals
gobal-ordinals的使用場景
global ordinals的存儲：
global-ordinals的存儲是在內存中構建的，如果內存緊張的話也會被 fielddata circuit breaker 給阻斷，而且global-ordinals的內存占用可以通過node_stats api獲取，在fielddata項下面。
2. global ordinals的load時機
默認的情況下是在第一次需要的query 查詢發生的時候。如果想保持比較高的index速度，這個方式是很正確的，但是如果對search performance 更在意，應該使用建議開啟eager_global_ordinals 選項，
當eager_global_ordinals 開啟之后，每當shard 產生了refresh(就是產生了doc的增刪改之后產生新的segment以便于這些內容能夠被search),都會重建global ordinals,這會增加indexing的代價但是優化查詢單速度。同時開啟這個設置之后再增加副本或者是遷移副本的時候也會eagerly創建global ordianals 。
在開啟了相關設置之后還可以通過update mapping進行關閉
PUT my_index/_mapping {"properties": {"tags": {"type": "keyword","eager_global_ordinals": true}} }PUT my_index/_mapping {"properties": {"tags": {"type": "keyword","eager_global_ordinals": false}} }對于frozen的index ，global ordianls會在每次查詢的時候創建，在查詢結束后再丟棄，所以eager_global_ordinals 不應該在frozen的index中開啟，同時對于frozen盡量先進行段合并，合并為一個segment最好，這樣就不用創建global ordinals了,因為segment ordinal 和 global ordinal是等價的了。
3. global ordinals使用建議
一般情況下，global ordinals 不會暫用太多的內存,但是對于有比較大shard的索引或者索引當中有很多term都是uniqued ,load global ordinals 會是一個昂貴的操作。
還有一些可選的配置來改善global ordinals 的使用
11. format
這個主要使用在es對日期類型的數據識別上。因為json對日期沒有特殊的支持，只是一個string,所以需要進行特殊識別才行。
這個format分為兩種，一種是es內建的format,支持用戶通過名稱進行快速的選配，還有一種是自定義的format,只要符合java中java.time.format.DateTimeFormatter 中定義的規范的string格式都可以
1. 內建format的樣例
PUT my_index {"mappings": {"properties": {"date": {"type": "date","format": "yyyy-MM-dd"}}} }2. built-in format
epoch_millis: Java Long.MIN_VALUE and Long.MAX_VALUE.
epoch_second: Java Long.MIN_VALUE and Long.MAX_VALUE.除以1000，標識的范圍和上一個保持一致
date_optional_time or strict_date_optional_time: iso標準時間定義
basic_date: yyyyMMdd
basic_date_time: yyyyMMdd’T’HHmmss.SSSZ
basic_date_time_no_millis: yyyyMMdd’T’HHmmssZ
basic_ordinal_date: 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 or strict_basic_week_date: xxxx’W’wwe
basic_week_date_time or strict_basic_week_date_time: xxxx’W’wwe’T’HHmmss.SSSZ
basic_week_date_time_no_millis or strict_basic_week_date_time_no_millis: xxxx’W’wwe’T’HHmmssZ
date or strict_date: yyyy-MM-dd
date_hour or strict_date_hour: yyyy-MM-dd’T’HH
date_hour_minute or strict_date_hour_minute: yyyy-MM-dd’T’HH:mm
date_hour_minute_second or strict_date_hour_minute_second: yyyy-MM-dd’T’HH:mm:ss
date_hour_minute_second_fraction or strict_date_hour_minute_second_fraction: yyyy-MM-dd’T’HH:mm:ss.SSS
date_hour_minute_second_millis or strict_date_hour_minute_second_millis: yyyy-MM-dd’T’HH:mm:ss.SSS
date_time or strict_date_time: yyyy-MM-dd’T’HH:mm:ss.SSSZZ
date_time_no_millis or strict_date_time_no_millis: yyyy-MM-dd’T’HH:mm:ssZZ
hour or strict_hour: HH
hour_minute or strict_hour_minute: HH:mm.
hour_minute_second or strict_hour_minute_second: HH:mm:ss
hour_minute_second_fraction or strict_hour_minute_second_fraction: HH:mm:ss.SSS
hour_minute_second_millis or strict_hour_minute_second_millis: HH:mm:ss.SSS
ordinal_date or strict_ordinal_date: yyyy-DDD
ordinal_date_time or strict_ordinal_date_time: yyyy-DDD’T’HH:mm:ss.SSSZZ
ordinal_date_time_no_millis or strict_ordinal_date_time_no_millis: yyyy-DDD’T’HH:mm:ssZZ
time or strict_time: HH:mm:ss.SSSZZ
time_no_millis or strict_time_no_millis: HH:mm:ssZZ
t_time or strict_t_time: 'T’HH:mm:ss.SSSZZ
t_time_no_millis or strict_t_time_no_millis: 'T’HH:mm:ssZZ
week_date or strict_week_date: xxxx-'W’ww-e
week_date_time or strict_week_date_time: xxxx-'W’ww-e’T’HH:mm:ss.SSSZZ
week_date_time_no_millis or strict_week_date_time_no_millis: xxxx-'W’ww-e’T’HH:mm:ssZZ
weekyear or strict_weekyear: xxxx
weekyear_week or strict_weekyear_week: xxxx-'W’ww
weekyear_week_day or strict_weekyear_week_day: xxxx-'W’ww-e
year or strict_year: yyyy
year_month or strict_year_month: yyyy-MM
year_month_day or strict_year_month_day: yyyy-MM-dd
es真是太寶媽了，但是估計大部分人都沒有耐心看完這些吧😭
12. ignore_above
對string類型的數據起作用，是一個int值，長度超過這個值的string不會被 indexed或者stored(field store),對于string arr ,限制會應用到其中的每一個元素。但是對于那些超過長度的字段仍然會在_source字段中進行存儲。
這個測試是對keyword類型的起作用，text類型的不允許設置這個參數。
在查詢中會返回所有的文檔，但是agg的結果沒有第二個文檔
13. ignore_malformed
這個設置對很多字段都生效，會忽略格式上不合法的字段，但是整個doc依然能夠成功indexed,不合法的字段在_source字段依然會有存儲，但是沒有doc_value等信息的存儲了。
如果這個指端設置為false（默認值），出現不合法的寫入之后會拋異常，整個文檔也沒有辦法正常寫入。
樣例
PUT my_index {"mappings": {"properties": {"number_one": {"type": "integer","ignore_malformed": true},"number_two": {"type": "integer"}}} }會成功 PUT my_index/_doc/1 {"text": "Some text value","number_one": "foo" }拋異常 PUT my_index/_doc/2 {"text": "Some text value","number_two": "foo" }還可以在index級別設置這個值
PUT my_index {"settings": {"index.mapping.ignore_malformed": true },"mappings": {"properties": {"number_one": { "type": "byte"},"number_two": {"type": "integer","ignore_malformed": false }}} }同樣的，對于malformed的字段會有所記錄，在doc中增加一個 _ignored字段進行標識。
對于object,nested,range 類型的字段沒有辦法設置這個屬性
14. index_options
這個屬性主要是針對string.text的字段進行設置的。
主要設置了哪些信息會被加入到倒排索引當中。
可以是下面的幾個值
對于string.text positions 是默認的設置
對于其他可以設置的字段 docs是默認的設置
對于numeric 類型的數據不支持這個屬性
PUT my_index {"mappings": {"properties": {"text": {"type": "text","index_options": "offsets"}}} }PUT my_index/_doc/1 {"text": "Quick brown fox" }GET my_index/_search {"query": {"match": {"text": "brown fox"}},"highlight": {"fields": {"text": {} }} }15. index_phrases
這個是為了優化phrase查詢而做的設置，設置了true，會假如一個2gram的shingles filter的功能，會把兩個term結合到一起產生新的field.
這會讓phrase queries 運行的更加高效，但是index的存儲占用也會變大，而且在沒有stop-word的工作的更好，因為有stop-word的查詢會退化為一個普通的phrase query
默認值為false
16. index_prefixes
這個允許index term的前綴來加快前綴查詢匹配的速度。
有兩個參數
這個不知道怎么進行驗證，后面看看吧
17. index
這個就是設置字段是否indexed, 對應值為false的字段不能被搜索，默認為true
18. fields
這個屬性主要是為了支撐一個field多種存儲類型的需求
PUT my_index {"mappings": {"properties": {"city": {"type": "text","fields": {"raw": { "type": "keyword"}}}}} }兩個字段可以有不同個type，不同的analyzer等
19. norms
這個是存儲各種各樣的normalization factors 歸一化系數，這些系數是為了能夠在query的時候計算出相似度score使用
盡管norms對計算相似度打分很有用，但是也會占據不少存儲空間，正常情況下，index的每個文檔中的每個field都會占用一個byte,即使某個doc中沒有這個field也會占用（這是lucene的存儲原理決定的）,所以如果你不需要對一個field進行score計算時可以針對這個field關閉這個選項。
這個mapping param 從able變成 disable 可以通過PUT mapping api進行修改,但是無法再從disable變成able
update 成false之后不會立即移除norms存儲，會在old segment合并生成新的segment的時候去除norms信息
20. null_value
正常情況下，null值被認為該字段沒有值，所以該doc的該字段不會被indexed，也不可searchable
null_value 的設置可以在該field indexing的值為null的時候放入一個特殊值，這個值可以進行indexed和searchable,需要注意的是該字段必須被設置為null，如果index的時候不傳該字段的話則也不會被替換成null_value的值
當然，該字段同樣不會修改_source字段
樣例
PUT my_index {"mappings": {"properties": {"status_code": {"type": "keyword","null_value": "NULL" }}} }PUT my_index/_doc/1 {"status_code": null }PUT my_index/_doc/2 {"status_code": [] }PUT my_index/_doc/3 {“message”:"this is message" }GET my_index/_search {"query": {"term": {"status_code": "NULL" }} }對于查詢而要，doc 1 會被召回，doc2 ,doc3不會被召回，doc3是因為沒有顯式的指定該字段的值為null。
21. position_increment_gap
這個mapping param主要用在string.text字段，而且是當該field 的value是一個數組的時候才會起作用。
正常情況下一個text輸入field之前會進行analysis,一般會有ananlzyer分詞，并且記錄每個詞的position,當一個filed的輸入有多個values的時候，在這些values之間實際上是不應該有position信息的，所以一旦這樣的輸入出現，會填充虛假的gap，讓不同的field之間的position加大。
觀察下面的analyze
POST my_index/_analyze {"analyzer": "standard","text": ["want some","like bread"] }{"tokens" : [{"token" : "want","start_offset" : 0,"end_offset" : 4,"type" : "<ALPHANUM>","position" : 0},{"token" : "some","start_offset" : 5,"end_offset" : 9,"type" : "<ALPHANUM>","position" : 1},{"token" : "like","start_offset" : 10,"end_offset" : 14,"type" : "<ALPHANUM>","position" : 102},{"token" : "bread","start_offset" : 15,"end_offset" : 20,"type" : "<ALPHANUM>","position" : 103}] }可以看到 like bread的position 一個是102，一個是103，這就說明中間加入了虛假的gap，因為中間的position實際上是沒有詞的。
gap 的值 就是由position_increment_gap 設置的，默認是100
這種操作主要是為了在進行phrase查詢的時候出錯。
比如查詢some like命中了該文檔是不合理的。
比如下面的案例
PUT my_index {"mappings": {"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" }} }該查詢會將doc1召回,顯然是不合理的。
22. properties
mapping中的 object fields 和 nested fields 包含properties屬性，這個屬性可以是任何數據類型，包括object和nested類型
properties可以通過三種方式設置
這些子屬性可以通過點號.來再query或者agg中引用。
GET my_index/_search {"query": {"match": {"manager.name": "Alice White"}},"aggs": {"Employees": {"nested": {"path": "employees"},"aggs": {"Employee Ages": {"histogram": {"field": "employees.age","interval": 5}}}}} }23. search_analyzer
一般情況下，會在indexing和query的時候使用相同的analyzer 來保持分詞使用的一致性。
但是有些時候我們也可以在index和query的時候使用不同的analyzer來達到更好的搜索效果，比如，對于著名的中文分詞器 ik-analyzer 插件，
在index的時候我們一般使用 ik_max_wordanalyzer 來產生盡可能多的詞匯以便于在搜索的時候使用
在query的時候我們一般使用 ik_smart產生最佳分詞（不是最多的，可能是按照最有意義的分詞方式）這樣的命中效果會更好一些，防止召回的太多。
又或者使用edge_ngram進行indexing分詞,在query的時候使用standard，可以實現前綴匹配
24. similarity
這個主要用來設置es的string.text查詢的相似度計算模型
這個計算模型可以自定義，也可以使用es內置的開箱即用，一般情況下內建的開箱即用就可以滿足大部分需求，如果采用自定義的方式需要對相似度計算的模型比較熟悉才好操作。在后面介紹相似度模型的時候會重點再介紹es中有哪些相似度計算模型，這里只是著重說一下使用es內置的如果和配置。
es內置的相似度打分模型有3個
關于BM25的discount_overlaps 的一個比較好的解釋
https://stackoverflow.com/questions/44115497/elasticsearch-similarity-discount-overlaps
25. store
正常情況下field會被indexed,可以被search,整個doc的內容都會被存儲到_source字段，
但是這個字段的原始值不會被單獨存儲，如果只想獲取這個字段的原始值的話需要通過source filtering
返回
"hits" : [{"_index" : "my_index","_type" : "_doc","_id" : "1","_score" : 1.0,"fields" : {"date" : ["2015-01-01T00:00:00.000Z"],"title" : ["Some short title"]}}]同樣的，我們也可以這樣使用
GET my_index/_search {"_source": ["title","date"] }返回 hits" : [{"_index" : "my_index","_type" : "_doc","_id" : "1","_score" : 1.0,"_source" : {"date" : "2015-01-01","title" : "Some short title"}}]一般情況下沒有必要的話不要開啟這個屬性，只有在doc中有某些field的內容非常大，而有些查詢不需要的那些大內容的field的時候才建議對小內容的field使用store屬性。
26. term_vector
term向量是string.text類型的數據進行了analysis處理后的產生的term的組合。
他包含了下面的內容
term_vector 的設置可以有
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.
with_positions_payloads: Terms, positions, and payloads are stored.
with_positions_offsets_payloads: Terms, positions, offsets and payloads are stored.
當我們使用term vectors API的時候可以查看一個文檔中field的vector
樣例
PUT my_index {"mappings": {"properties": {"text": {"type": "text","term_vector": "with_positions_offsets"},"number":{"type": "text"}}} }PUT my_index/_doc/1?refresh {"text": "Quick brown fox","number":"want app and want banana" }使用terms vectors api查看field包含的terms
GET my_index/_termvectors/1?fields=number,text返回{"_index" : "my_index","_type" : "_doc","_id" : "1","_version" : 1,"found" : true,"took" : 0,"term_vectors" : {"text" : {"field_statistics" : {"sum_doc_freq" : 3,"doc_count" : 1,"sum_ttf" : 3},"terms" : {"brown" : {"term_freq" : 1,"tokens" : [ { "position" : 1, "start_offset" : 6, "end_offset" : 11}]},"fox" : {"term_freq" : 1,"tokens" : [ { "position" : 2, "start_offset" : 12, "end_offset" : 15}]},"quick" : {"term_freq" : 1,"tokens" : [ { "position" : 0, "start_offset" : 0, "end_offset" : 5}]}}},"number" : {"field_statistics" : {"sum_doc_freq" : 4,"doc_count" : 1,"sum_ttf" : 5},"terms" : {"and" : {"term_freq" : 1,"tokens" : [ { "position" : 2, "start_offset" : 9, "end_offset" : 12}]},"app" : {"term_freq" : 1,"tokens" : [ { "position" : 1, "start_offset" : 5, "end_offset" : 8}]},"banana" : {"term_freq" : 1,"tokens" : [ { "position" : 4, "start_offset" : 18, "end_offset" : 24}]},"want" : {"term_freq" : 2,"tokens" : [ { "position" : 0, "start_offset" : 0, "end_offset" : 4}, { "position" : 3, "start_offset" : 13, "end_offset" : 17}]}}}} }以上，可以看到文檔的term vector信息，為什么number字段沒有設置保存term_vector 在使用api的時候依然能夠查到呢，這是因為terms vector api的原理導致的，如果沒有的話他會自己從index中進行計算得到數據
假如直接使用
GET my_index/_termvectors/1這個只會獲取默認已經存儲的term vectors，那么就不會返回number的term vectors了。
使用
GET my_index/_termvectors/1?fields=number,text會觸發強制計算term vectors。
這個一般情況下沒有什么用，只是在快速高亮顯示上又一些用處。
而且term_vector設置到with_positions_offsets 就會使這個字段在索引中的存儲翻倍，因為需要一個額外的list terms去維護。
總結
以上是生活随笔為你收集整理的03.elasticsearch-mapping-param解析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 02.elasticsearch-met
- 下一篇： 04.elasticsearch-dyn