Indeed. If you want to run terms agg on a analyzed field, it might have no sense. In that case you should use multi field to analyze you field for search and don’t analyze it for aggs.
See http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-core-types.html#_multi_fields_3 <http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-core-types.html#_multi_fields_3> -- David Pilato | Technical Advocate | Elasticsearch.com @dadoonet <https://twitter.com/dadoonet> | @elasticsearchfr <https://twitter.com/elasticsearchfr> | @scrutmydocs <https://twitter.com/scrutmydocs> > Le 28 nov. 2014 à 11:50, horst knete <[email protected]> a écrit : > > Thx for response, > > Actually the need to search with wildcards is given because our mapping. In > our events are indexed a whole lot of urls which are indexed to many terms by > the default analyzer, this will lead to an pretty akward output if you are > doing the "top 10" search in Kibana in the table panel. Thx to an post of an > other guy in here in the forum we adjusted the mapping so everything get > indexed into 1 token per field, allowing urls to be displayed in correct way > but having the disadvantage of having to need to use wildcards because " > apache " wont return any events. > > We are actually using 1 big server with 256 RAM + 64 CPU, divided into 3 > elasticsearch instances. > > Given to your post it seems to make sense to adjusted the mapping back to the > way that everything get tokenized back to the default way, eliminating the > need of using wildcards and use not_analyzed fields for urls. > > Maybe some kind of stupid question: if you dont specify any field in kibana > search, it will be redirected by default to the _all field right? is there a > way of changing that behaviour so that " apache " get not directed to _all > but rather to "message"-field? that would eliminate the need of _all field > which would reduce disk space and cpu/ram load for indexing > > Am Freitag, 28. November 2014 10:56:09 UTC+1 schrieb David Pilato: > Some comments: > > Searching for `program:apache` actually search in field `program`. > > Searching with wildcards is something you really should not do! Actually when > you do full text search on Google, I guess you don’t use wildcards, right? > It’s not really user friendly. > So wildcards are extremely slow and even slower when you start with *! Look > here for reference: > http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-wildcard-query.html#query-dsl-wildcard-query > > <http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-wildcard-query.html#query-dsl-wildcard-query> > Searching in _all field is also something you should not do but it depends on > your use case. I’d prefer using copy_to feature in mapping instead of using > _all field. > > Now, I think it depends on your infra. How many nodes, RAM, … you have. > > > > > -- > David Pilato | Technical Advocate | Elasticsearch.com > <http://elasticsearch.com/> > @dadoonet <https://twitter.com/dadoonet> | @elasticsearchfr > <https://twitter.com/elasticsearchfr> | @scrutmydocs > <https://twitter.com/scrutmydocs> > > > >> Le 28 nov. 2014 à 10:44, horst knete <badun...@ <>hotmail.de >> <http://hotmail.de/>> a écrit : >> >> Hey guys, >> >> we are experience poor performance if we do some "full text" ( searches >> without specifying an field name). >> >> If we search in an 200 GB index which lays on SSDs for something like ' >> program:apache ' the search takes about 10-15 seconds, if we search for ' >> *apache* ' the whole search goes for 1,5-2 minutes. >> >> What can cause this? Our mapping? the high heap of the SSD ES node ( 80gb + >> ~90 GB available Lucene system memory)? Is it normal? >> >> If you need any information, please let me know. >> >> thanks for any respond >> >> >> >> -- >> 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 elasticsearc...@ <>googlegroups.com <http://googlegroups.com/>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elasticsearch/a3a41710-93b4-4e81-93a7-6cde43e5c387%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elasticsearch/a3a41710-93b4-4e81-93a7-6cde43e5c387%40googlegroups.com?utm_medium=email&utm_source=footer>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > 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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/3bf1946b-86bd-4dbf-b7fd-b07a7f27460a%40googlegroups.com > > <https://groups.google.com/d/msgid/elasticsearch/3bf1946b-86bd-4dbf-b7fd-b07a7f27460a%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/DEE3804A-9449-46BE-A0D1-7A0610A23ED7%40pilato.fr. For more options, visit https://groups.google.com/d/optout.
