Unanalyzed string vs long on es 5.0


(ddorian43) #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!


(ddorian43) #2

bump (after 2 days is enough I think)


(Nik Everett) #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.


(ddorian43) #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).


(Nik Everett) #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.


(ddorian43) #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


(system) #7

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