Unanalyzed string vs long on es 5.0

Elastic Stack Elasticsearch
1

All my rows in my table have a unique integer + unique slug (unchangable).

Is it a lot better to index a numeric field compared to string (based on changes on es 5)?

String is more readable when debugging, but if it's a big difference in size/ then I'll go for integers.

I will only index, not _store / _source.

Thank You!

2

bump (after 2 days is enough I think)

3

I'd use the slug as the _id of the document so long as it is reasonably short. We already index _uid (type + id) as a string so you may as well use it.

4

@nik9000

Note that I'm asking what to store as a field in the mapping, not "_id". But something like "field_id" that I will later filter on (only on equality, no ranges).

5

And I'm telling you that you can get away with adding neither to your mapping and using the slug as the id.

I don't know off hand whether it'd be better to add a string or a number to the mapping. It is worth testing, I think. So long as you won't be aggregating or sorting on the field I'd turn off doc_values for it to save space.

6

... I'm saying that will have other documents on es that will have a field called "field_id" that I will use to filter on. That "thing_id" can be either string/long.

I wasn't asking about storing the original "thing" document on es.

Thanks

7

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