Supported field types

You can specify data types for your fields when creating a mapping. The following table lists all data field types that OpenSearch supports.

CategoryField types and descriptions
Aliasalias: An additional name for an existing field.
Binarybinary: A binary value in Base64 encoding.
NumericA numeric value (byte, double, float, half_float, integer, long, unsigned_long, scaled_float, short).
Booleanboolean: A Boolean value.
Datedate: A date stored in milliseconds.
date_nanos: A date stored in nanoseconds.
IPip: An IP address in IPv4 or IPv6 format.
RangeA range of values (integer_range, long_range, double_range, float_range, date_range, ip_range).
Objectobject: A JSON object.
nested: Used when objects in an array need to be indexed independently as separate documents.
flat_object: A JSON object treated as a string.
join: Establishes a parent/child relationship between documents in the same index.
Stringkeyword: Contains a string that is not analyzed.
text: Contains a string that is analyzed.
match_only_text: A space-optimized version of a text field.
token_count: Stores the number of analyzed tokens in a string.
wildcard: A variation of keyword with efficient substring and regular expression matching.
Autocompletecompletion: Provides autocomplete functionality through a completion suggester.
search_as_you_type: Provides search-as-you-type functionality using both prefix and infix completion.
Geographicgeo_point: A geographic point.
geo_shape: A geographic shape.
RankBoosts or decreases the relevance score of documents (rank_feature, rank_features).
k-NN vectorknn_vector: Allows indexing a k-NN vector into OpenSearch and performing different kinds of k-NN search.
Percolatorpercolator: Specifies to treat this field as a query.
Derivedderived: Creates new fields dynamically by executing scripts on existing fields.
Star-treestar_tree: Precomputes aggregations and stores them in a star-tree index, accelerating the performance of aggregation queries.

Arrays

There is no dedicated array field type in OpenSearch. Instead, you can pass an array of values into any field. All values in the array must have the same field type.

  1. PUT testindex1/_doc/1
  2. {
  3.   "number": 1 
  4. }
  6. PUT testindex1/_doc/2
  7. {
  8.   "number": [1, 2, 3] 
  9. }

Multifields

Multifields are used to index the same field differently. Strings are often mapped as text for full-text queries and keyword for exact-value queries.

Multifields can be created using the fields parameter. For example, you can map a book title to be of type text and keep a title.raw subfield of type keyword.

  1. PUT books
  2. {
  3.   "mappings" : {
  4.     "properties" : {
  5.       "title" : {
  6.         "type" : "text",
  7.         "fields" : {
  8.           "raw" : {
  9.             "type" : "keyword"
  10.           }
  11.         }
  12.       }
  13.     }
  14.   }
  15. }

Null value

Setting a field’s value to null, an empty array, or an array of null values makes this field equivalent to an empty field. Therefore, you cannot search for documents that have null in this field.

To make a field searchable for null values, you can specify its null_value parameter in the index’s mappings. Then, all null values passed to this field will be replaced with the specified null_value.

The null_value parameter must be of the same type as the field. For example, if your field is a string, the null_value for this field must also be a string.

Example

Create a mapping to replace null values in the emergency_phone field with the string “NONE”:

  1. PUT testindex
  2. {
  3.   "mappings": {
  4.     "properties": {
  5.       "name": {
  6.         "type": "keyword"
  7.       },
  8.       "emergency_phone": {
  9.         "type": "keyword",
  10.         "null_value": "NONE" 
  11.       }
  12.     }
  13.   }
  14. }

Index three documents into testindex. The emergency_phone fields of documents 1 and 3 contain null, while the emergency_phone field of document 2 has an empty array:

  1. PUT testindex/_doc/1
  2. {
  3.   "name": "Akua Mansa",
  4.   "emergency_phone": null
  5. }
  1. PUT testindex/_doc/2
  2. {
  3.   "name": "Diego Ramirez",
  4.   "emergency_phone" : []
  5. }
  1. PUT testindex/_doc/3 
  2. {
  3.   "name": "Jane Doe",
  4.   "emergency_phone": [null, null]
  5. }

Search for people who do not have an emergency phone:

  1. GET testindex/_search
  2. {
  3.   "query": {
  4.     "term": {
  5.       "emergency_phone": "NONE"
  6.     }
  7.   }
  8. }

The response contains documents 1 and 3 but not document 2 because only explicit null values are replaced with the string “NONE”:

  1. {
  2.   "took" : 1,
  3.   "timed_out" : false,
  4.   "_shards" : {
  5.     "total" : 1,
  6.     "successful" : 1,
  7.     "skipped" : 0,
  8.     "failed" : 0
  9.   },
  10.   "hits" : {
  11.     "total" : {
  12.       "value" : 2,
  13.       "relation" : "eq"
  14.     },
  15.     "max_score" : 0.18232156,
  16.     "hits" : [
  17.       {
  18.         "_index" : "testindex",
  19.         "_type" : "_doc",
  20.         "_id" : "1",
  21.         "_score" : 0.18232156,
  22.         "_source" : {
  23.           "name" : "Akua Mansa",
  24.           "emergency_phone" : null
  25.         }
  26.       },
  27.       {
  28.         "_index" : "testindex",
  29.         "_type" : "_doc",
  30.         "_id" : "3",
  31.         "_score" : 0.18232156,
  32.         "_source" : {
  33.           "name" : "Jane Doe",
  34.           "emergency_phone" : [
  35.             null,
  36.             null
  37.           ]
  38.         }
  39.       }
  40.     ]
  41.   }
  42. }

The _source field still contains explicit null values because it is not affected by the null_value.