Field Properties by Use Case

Here is a summary of common use cases, and the attributes the fields or field types should have to support the case. An entry of true or false in the table indicates that the option must be set to the given value for the use case to function correctly. If no entry is provided, the setting of that attribute has no impact on the case.

Use CaseindexedstoredmultiValuedomitNormstermVectorstermPositionsdocValues
search within fieldtrue
retrieve contentstrue8true8
use as unique keytruefalse
sort on fieldtrue7false9true 1true7
highlightingtrue4truetrue2true 3
faceting 5true7true7
add multiple values, maintaining ordertrue
field length affects doc scorefalse
MoreLikeThis 5true 6

Notes:

  1. Recommended but not necessary.
  2. Will be used if present, but not necessary.
  3. (if termVectors=true)
  4. A tokenizer must be defined for the field, but it doesn’t need to be indexed.
  5. Described in Understanding Analyzers, Tokenizers, and Filters.
  6. Term vectors are not mandatory here. If not true, then a stored field is analyzed. So term vectors are recommended, but only required if stored=false.
  7. For most field types, either indexed or docValues must be true, but both are not required. DocValues can be more efficient in many cases. For [Int/Long/Float/Double/Date]PointFields, docValues=true is required.
  8. Stored content will be used by default, but docValues can alternatively be used. See DocValues.
  9. Multi-valued sorting may be performed on docValues-enabled fields using the two-argument field() function, e.g., field(myfield,min); see the field() function in Function Queries.