What is the difference between a field and a property in Elasticsearch?

13
votes

I'm currently trying to understand the difference between fields (https://www.elastic.co/guide/en/elasticsearch/reference/current/multi-fields.html) and properties (https://www.elastic.co/guide/en/elasticsearch/reference/current/properties.html).

They are both somehow defined as a "subfield/subproperty" of a type/mapping property, both can have separate types and analyzers (as far as I understood it), both are accessed by the dot notation (mappingProperty.subField or mappingProperty.property).

The docs are using the terms "field" and "property" randomly, I have the feeling, for example:

Type mappings, object fields and nested fields contain sub-fields, called properties.

What is the difference between properties and (sub-)fields? How do I decide if I have a property or a field?

In other words, how do I decide if I use

{
  "mappings": {
    "_doc": { 
      "properties": {
        "myProperty": { 
          "properties": {

          }
        }
      }
    }
  }
}

or

{
  "mappings": {
    "_doc": { 
      "properties": {
        "myProperty": { 
          "fields": {

          }
        }
      }
    }
  }
}
2
elasticsearch
There are no differences, both words are merely synonyms. – Val
@Val But why are there different doc pages then , which implies that there's an actual technical difference? – Foobar
Well, you're right, there are slight differences. properties is a keyword to denote that you'll define fields/properties of an object (whether at root level or within an object type) and fields is a keyword to denote sub-fields of a given field (usually a keyword sub-field of a text field. – Val

2 Answers

10
votes

Subfields are indexed from the parent property source. While sub-properties need to have a "real" value in the document's source.

If your source contains a real object, you need to create properties. Each property will correspond to a different value from your source.

If you only want to index the same value but with different analyzers then use subfields.

It is often useful to index the same field in different ways for different purposes. This is the purpose of multi-fields. For instance, a string field could be mapped as a text field for full-text search, and as a keyword field for sorting or aggregations:

(sorry I find its hard to explain =| )

1
votes

Note: This is an explanation from my current understanding. It may not be 100% accurate.

A property is what we used to call field in a RDBMS (a standard relationship db like MySQL). It stores properties of an object and provides the high-level structure for an index (which we can compare to a table in a relational DB).

A field, which is linked (or included) into the property concept, is a way to index that property using a specific analyzer.

So lets say you have:

  • One analyzer (A) to uppercase
  • One analyzer (B) to lowercase
  • One analyzer (C) to translate to Spanish (this doesn't even exist, just to give you an idea)

What an analyzer does is transform the input (the text on a property) into a series of tokens that will be indexed. When you do a search the same analyzer is used so the text is transformed into those tokens, it gives each one a score and then those tokens are used to grab documents from the index.

(A) Dog = DOG
(B) Dog = dog
(C) Dog = perro

To search using a specific field configuration you call it using a dot:

  • The text field uses the standard analyzer.
  • The text.english field uses the English analyzer.

So the fields basically allow you to perform searches using different token generation models.