What's the difference between "store" and "doc_values" in field properties?


(Jianhang Cao) #1

inverted index is used for terms to find the doc_ids,
doc_values are used for doc_ids to find values of a field, and will be serialized into the disk.
However what about the property "store"? I just don't understand.

btw: can you show me why I can't sort by a field if I set "doc_values" : false and "store" : true?


Atomic insert/delete/update on multiple indices
Issue storing binary fields in 6.2.2
(Mark Walkom) #2

If it's not stored then you can't return the field value, see https://www.elastic.co/guide/en/elasticsearch/reference/5.1/mapping-store.html


(Jianhang Cao) #3

yes, the doc said so.
But, when you set doc_values: true, the field value is already serialized into the disk, right?
Why can't ElasticSearch return the value in the doc_value files?


(Martijn Van Groningen) #4

Elasticsearch can return doc values fields:
https://www.elastic.co/guide/en/elasticsearch/reference/5.1/search-request-docvalue-fields.html

Stored fields are designed for optimal storage whereas doc values are
designed the access field values quickly. During the execution of query
many of doc values fields are accessed for candidate hits, so the access
must be fast. This the reason why you should use doc values in sorting,
aggregations and scrips. Today many features in ES use doc values
automatically.

On the other hand stored fields should be used for return field values for
the top matching documents. In ES by default it is used just for that. Just
fetching stored fields for a couple of documents is fine (stored values are
decompressed and send back to the client). They shouldn't be used during
execution of a query as it would make the entire search request
significantly slower. (you can use stored fields in scripts, but really you
shouldn't do that)


(Jianhang Cao) #5

so when I set my property below:
"prop_1":{ "type":"string", "index":"not_analyzed","store":true,"doc_values":true}
there would be 4 separate files stored in the disk: one for store, one for index, another for doc_values, the other of course is for _source. Am I right?


(Martijn Van Groningen) #6

Yes, so prop_1 would be stored on its own as an indexed, doc values and stored field. On top of that the prop_1 is stored to into the _source field together with your other fields.

Unless you have a very specific reason, I think you should set store to false as it doesn't get you anything extra and you would use more disk space.


(Jianhang Cao) #7

definitly yes:)
great answer, thx for that!


(system) #8

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.