Query vs. fetch times


(Pierce Wetter) #1

Noob Question:

So my query times in Elastic HQ are about 7x the fetch times.

Is that expected or is it possible we're not giving the shard hint
correctly so it has to ask all the shards?

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Zachary Tong) #2

That is expected behavior.

The Search phase has to A) traverse all the shards, B) traverse all
documents which match your (potentially complex) query and C) calculate a
score for each matching document. Depending on your query, that is
potentially a lot of documents to evaluate.

In contrast, the Fetch phase is given a list of document addresses (shard
and docID). The list is usually small, say ten results. It then goes
straight to the appropriate shard, loads the document and serializes the
source back to the coordinating node. This is much faster than the Search
phase.

As an aside, by default elasticsearch will search all shards of an index.
You can use custom routing to direct the search to a particular shard, but
this is generally more advanced behavior and may not be needed.

-Zach

On Friday, September 20, 2013 4:22:52 PM UTC-4, Pierce Wetter wrote:

Noob Question:

So my query times in Elastic HQ are about 7x the fetch times.

Is that expected or is it possible we're not giving the shard hint
correctly so it has to ask all the shards?

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Pierce Wetter) #3

Yeah, I was pretty sure that we were using custom routing, but the
resulting subset would still be a fair number of documents, so 7x isn't so
bad from that point of view.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Zachary Tong) #4

Ah, I see. Yeah, I'll stand by the original "expected behavior", the
Search phase will probably be considerably slower than Fetch even if you
direct it to a single shard, dependent on size of the shard.

Now, if the search is taking too long in general, that's something to be
concerned about. But I wouldn't worry about search:fetch ratio =)

-Zach

On Fri, Sep 20, 2013 at 5:49 PM, Pierce Wetter obastard@gmail.com wrote:

Yeah, I was pretty sure that we were using custom routing, but the
resulting subset would still be a fair number of documents, so 7x isn't so
bad from that point of view.

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/0tx_nVTSIxA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(system) #5