Does not it cause substantial inflation in the amount of data to be processed
and stored at indexing time?
As with most logs aggregation systems indexing is many orders of magnitude more
frequent operation than querying and I'm concerned that using multi_fields
instead of all simple string fields may negatively impact indexing performance.
May be there is a way to solve that problem at querying time?
ALSO each field gets "primary" name and other names with the dot and the suffix
for different representations. How to select which representation should be
used as primary?
On Monday, October 6, 2014 8:50:22 PM UTC-7, Doug Nelson wrote:
> I use multi fields to have several different analysis types supported as need
> and also to have the raw version available like in your example.
>
>
>
> On Monday, October 6, 2014 8:34:34 PM UTC-5, Konstantin Erman wrote:
> I have documents in ES with the field "Message", which normally represents
> some multi word text string. Trying to query it with Kibana to see which
> strings are in this property most frequently. What I actually get back is the
> table which shows frequency of the specific words, but not the whole strings!
>
>
> Now that I started to understand something about ES, my guess is that I
> supposed to map that "Message" field as { "type": "string", "index":
> "not_analyzed" }, so it is not split into words. But on the other hand I
> still want to be able to find documents by searching for some words from
> their message fields.
>
>
> Next thought - multi_field "mapping":
> {
> "type" : "string",
> "fields": {
> "raw": { "type": "string", "index":
> "not_analyzed" }
> }
> }
>
>
> So that for normal query analysed Message field would work and when I build
> my Terms panel I use Message.raw instead.
>
>
> I need a confirmation that I'm moving in the right direction and this is
> optimal and intended way to achieve the goal. It does not look so elegant,
> that's why I'm asking. May be I miss some other ways to search string field
> using separate words, but still treat it as a whole for the purpose of
> counting. Please advise!
> Konstantin
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/510ce9e3-fd67-41c3-b969-b25e32eef352%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
