I am trying to understand if we can partially customize elasticsearch's dynamic mapping i.e for some of the fields we will set the data type explicitely and all the remaining fields (which are not mentioned explicitely) will be taken care by elasitcsearch through its dynamic mappaing. The advantage in this is, we dont have to set datayype for each and every field and elaticsearch will set data type for new fields.
Is it possible?
If not, is there other way to achieve this, wherein we will save time on not setting data type for each and every filed and use the advantage of dynamic mapping.
I am currently using dynamic mapping and planning to change 'text' to 'match_only_text' (as scoring is not important for server, aplication logs) so want to know how can i achieve this best way without impacting much.
I will try this, meantime can you confirm, if we miss to add a field (which is a part of document) in dynamic template will elasticsearch index it or ignore it?
Also how it will handle any new field (which will come on future) in case its not part of document when its indexing.
This is the default behaviour of Elasticsearch, if you do not explicitly set a mapping in your index or using a template, it will be dynamically mapped.
The issue with dynamic mapping is that sometimes it will not the fields in the way you expect and it makes you wast a lot of disk space as every string field will be index twice, both as keyword and text.
With the Dynamic templates you have a little more control on how the fields that aren't explicitly mapped will be mapped, for example you can tell elasticsearch that every new string field that is not explicitly mapped, will be mapped as just a keyword field and not as keyword and text.
It says, If a dynamic template doesn’t define match_mapping_type, match, or path_match, it won’t match any field.
Q. Can someone say, what will happen with that field?
Q. Will it not indexed or stored.
What will happen if same field matches at two places. i.e If we first map all integer fields to some data type but in the same template if we add integer field explicitly to some other data type, which one will take preference?
Disabled_norms
Q. It it talking about scoring which we can see in below screenshot?
If the field does not match any definition of the dynamic template, elasticsearch will try to guess how to map it, it will be indexed and stored.
Doesn't see why anyone would do that other than by mistake, but If I'm not wrong the explicit mapping will take precedence over any dynamic template, needs to test to see what will happen.
Not sure what is your question here, but if you do not need scores when searching your documents you can disable norms to save space, if you need scores or not depends on your use case.
If you set index to false on a field you won't be able to filter on the value of the field, but will be able to run aggregations on them and they will also show up on Kibana.
For example, you may have a field named bytesSent with the amount of bytes sent by something that you do not want to filter by some specific value but still want to be able to run some aggregations like get the sum of the field for a specific case.
For norms, just trying to understand whether it is referring to the same _score field which we can see in attached screenshot.
I think it is fine to disable it as i dont see use case where we want to see score value when searching.
Saving as much as possible disk space is the aim.
For time series,
I think i am still not clear by what exactly mean by filter on.
I got the point, even if we didnt index numeric fileds we still be able to see them in kibana as other fields and run aggregation (min, max) on them but not the filter one.
Yes, this is the only score you have in elasticsearch, if you disable norms you won't haver any score for your searchs.
I'm not sure what is really the question, if you set index: false you won't be able to filter on the values of those fields, it means that you won't be able to make a query and use this field as a filter for the query to get more specific results.
If you have for example a field named bytesSent with the value of 100, you won't be able to filter on this field to find all the documents that have the value of 100, but you will be able to run an aggregation on this field and get the sum of this field in multiple documents.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
