text和keyword這兩個類型，是在5以后的版本中出現的。官網中，對這兩個數據類型，這樣描述
-
Text datatype：
-
A field to index full-text values, such as the body of an email or the description of a product. These fields are analyzed, that is they are passed through an analyzer to convert the string into a list of individual terms before being indexed. The analysis process allows Elasticsearch to search for individual words within each full text field. Text fields are not used for sorting and seldom used for aggregations (although the significant text aggregation is a notable exception).
-
If you need to index structured content such as email addresses, hostnames, status codes, or tags, it is likely that you should rather use a keyword field.
-
Keyword datatype
-
A field to index structured content such as email addresses, hostnames, status codes, zip codes or tags.
-
They are typically used for filtering (Find me all blog posts where status is published), for sorting, and for aggregations. Keyword fields are only searchable by their exact value.
-
If you need to index full text content such as email bodies or product descriptions, it is likely that you should rather use a text field.
原來，es從2.X版本一下子跳到了5.X版本，將string類型變為了過期類型，取而代之的是text和keyword數據類型，一直到現在最新的6以上版本。接下來就看看這兩個字段的區別。
按照官方文檔的闡述，text類型的數據被用來索引長文本，例如電子郵件主體部分或者一款產品的介紹，這些文本會被分析，在建立索引文檔之前會被分詞器進行分詞，轉化為詞組。經過分詞機制之后es允許檢索到該文本切分而成的詞語，但是text類型的數據不能用來過濾、排序和聚合等操作。
keyword類型的數據可以滿足電子郵箱地址、主機名、狀態碼、郵政編碼和標簽等數據的要求，不進行分詞，常常被用來過濾、排序和聚合。
綜上，可以發現text類型在存儲數據的時候會默認進行分詞，並生成索引。而keyword存儲數據的時候，不會分詞建立索引，顯然，這樣划分數據更加節省內存。
這樣，我們映射了某一個字段為keyword類型之后，就不用設置任何有關分詞器的事情了，該類型就是默認不分詞的文本數據類型。而對於text類型，我們還可以設置它的分詞類型，如下：
-
PUT /zk_test/info/_mapping
-
{
-
"info":{
-
"properties":{
-
"address":{"type":"text","analyzer":"standard"}
-
}
-
}
-
}
analyzer 還有中文分詞 chinese，英文分詞 english 等參數。
另外，我們在像之前2.X版本中一樣設置分詞使用"index":"not_analyzed"配置時，會有提醒，提示"index"參數只有false和true兩個值。
在5以上的版本中，“index”參數用來配置該字段是否可以被用來搜索，true可以通過搜索該字段檢索到文檔，false為否，配置分詞器，用analyzer參數。