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 > 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 <[email protected] <javascript:>> > 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 [email protected] <javascript:>. > 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. > > > -- 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/3bf1946b-86bd-4dbf-b7fd-b07a7f27460a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
