I've just started using ElasticSearch and so far it's been fairly easy
to get going with. However, I have a couple of questions that came up
during the course of development:
I need to find docs where a string field contains a keyword, but
restricted by an integer field matching a given value. Is it better
to use the "bool" query feature (with sub-queries for string and
integer portions), or do the string query with a filter?
Is it possible to specify multiple fields to search for a given
keyword? So far I've been using _all, but sometimes I need to change
which fields I'm matching in dynamically and _all is predetermined by
the mapping.
I've just started using Elasticsearch and so far it's been fairly easy
to get going with. However, I have a couple of questions that came up
during the course of development:
I need to find docs where a string field contains a keyword, but
restricted by an integer field matching a given value. Is it better
to use the "bool" query feature (with sub-queries for string and
integer portions), or do the string query with a filter?
Filters perform better because they do not perform scoring. So I think in
your case the filtering is way to go.
Is it possible to specify multiple fields to search for a given
keyword? So far I've been using _all, but sometimes I need to change
which fields I'm matching in dynamically and _all is predetermined by
the mapping.
I've just started using Elasticsearch and so far it's been fairly easy
to get going with. However, I have a couple of questions that came up
during the course of development:
I need to find docs where a string field contains a keyword, but
restricted by an integer field matching a given value. Is it better
to use the "bool" query feature (with sub-queries for string and
integer portions), or do the string query with a filter?
Filters perform better because they do not perform scoring. So I think in
your case the filtering is way to go.
Yep, filters are the best way to go here. Much faster, and easily cacheable.
Is it possible to specify multiple fields to search for a given
keyword? So far I've been using _all, but sometimes I need to change
which fields I'm matching in dynamically and _all is predetermined by
the mapping.
It depends on the _all field. For the price of storing more data in the
index, you can get much better results in terms of query performance
(comparing _all to X files query).
It depends on the _all field. For the price of storing more data in the
index, you can get much better results in terms of query performance
(comparing _all to X files query).
Then that might make sense, really depends on the latency of you require
from your searches. _all field causes larger index and slower indexing time,
but usually results in faster queries when trying to match on several
fields. In your case, it sounds like _all field is not needed, but I would
run a simple test to see the difference in expected queries.
It depends on the _all field. For the price of storing more data in the
index, you can get much better results in terms of query performance
(comparing _all to X files query).
Then that might make sense, really depends on the latency of you require
from your searches. _all field causes larger index and slower indexing time,
but usually results in faster queries when trying to match on several
fields. In your case, it sounds like _all field is not needed, but I would
run a simple test to see the difference in expected queries.
Thats pretty much it, though I think you should time it based on how you
plan to actually invoke it in production (from the lang you plan to use, and
so on).
Then that might make sense, really depends on the latency of you require
from your searches. _all field causes larger index and slower indexing
time,
but usually results in faster queries when trying to match on several
fields. In your case, it sounds like _all field is not needed, but I
would
run a simple test to see the difference in expected queries.
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.