I am in the process of adding routing to my documents to decrease CPU
usage. I think routing is a great solution. If I understand correctly, I
can provide the routes that I want to search. If I do not provide the
routes then it will search across ALL shards. So far that's what my tests
show.
However, now I want to search by id which is auto generated by ES and I use
prepareGet. My tests fail when I don't provide the routing. I don't have
enough data to know the routing when fetching by ID. I was hoping the
behavior would be the same as search - i.e. if I don't provide the routes
then it will get across all shards.
Interestingly, prepareMultiGet does this exactly. If I don't provide
routing then it will return the document to me. Is this "work as designed"?
Should I use multiGet?
Some code.
// Simple get
GetResponse response = client().prepareGet(indexName(), documentType(), id).
execute().get(); // doesn't work
// Multi get
MultiGetResponse response = client().prepareMultiGet().add(indexName(),documentType
(), id).execute().get(); // this does work
Nope I was wrong. MultiGet also doesn't behave this way.
So am I left with doing search even for a simple id?
On Wednesday, August 14, 2013 11:49:17 AM UTC-7, Amir Raminfar wrote:
I am in the process of adding routing to my documents to decrease CPU
usage. I think routing is a great solution. If I understand correctly, I
can provide the routes that I want to search. If I do not provide the
routes then it will search across ALL shards. So far that's what my tests
show.
However, now I want to search by id which is auto generated by ES and I
use prepareGet. My tests fail when I don't provide the routing. I don't
have enough data to know the routing when fetching by ID. I was hoping the
behavior would be the same as search - i.e. if I don't provide the routes
then it will get across all shards.
Interestingly, prepareMultiGet does this exactly. If I don't provide
routing then it will return the document to me. Is this "work as designed"?
Should I use multiGet?
Some code.
// Simple get
GetResponse response = client().prepareGet(indexName(), documentType(), id
).execute().get(); // doesn't work
// Multi get
MultiGetResponse response = client().prepareMultiGet().add(indexName(),documentType
(), id).execute().get(); // this does work
If you don't have the routing information, then yes, you would need to do a
search. Why even use routing if you don't know the routing information
when doing a search/get? If you don't use routing elasticsearch will be
able to go directly to the correct shard when doing the Get.
Thanks,
Matt Weber
On Wed, Aug 14, 2013 at 11:51 AM, Amir Raminfar findamir@gmail.com wrote:
Nope I was wrong. MultiGet also doesn't behave this way.
So am I left with doing search even for a simple id?
On Wednesday, August 14, 2013 11:49:17 AM UTC-7, Amir Raminfar wrote:
I am in the process of adding routing to my documents to decrease CPU
usage. I think routing is a great solution. If I understand correctly, I
can provide the routes that I want to search. If I do not provide the
routes then it will search across ALL shards. So far that's what my tests
show.
However, now I want to search by id which is auto generated by ES and I
use prepareGet. My tests fail when I don't provide the routing. I don't
have enough data to know the routing when fetching by ID. I was hoping the
behavior would be the same as search - i.e. if I don't provide the routes
then it will get across all shards.
Interestingly, prepareMultiGet does this exactly. If I don't provide
routing then it will return the document to me. Is this "work as designed"?
Should I use multiGet?
Some code.
// Simple get
GetResponse response = client().prepareGet(indexName(**), documentType(),id
).execute().get(); // doesn't work
// Multi get
MultiGetResponse response = client().prepareMultiGet().add**(indexName(),documentType
(), id).execute().get(); // this does work
Thanks for responding. My primary use case to search by URI which is probably 90% of my requests. The _id is auto generated and I don't need it at all. I guess I should optimize for the more popular use case which is fetching by one field than _id.
--
Amir Raminfar
On Wednesday, August 14, 2013 at 12:16 PM, Matt Weber wrote:
If you don't have the routing information, then yes, you would need to do a search. Why even use routing if you don't know the routing information when doing a search/get? If you don't use routing elasticsearch will be able to go directly to the correct shard when doing the Get.
Nope I was wrong. MultiGet also doesn't behave this way.
So am I left with doing search even for a simple id?
On Wednesday, August 14, 2013 11:49:17 AM UTC-7, Amir Raminfar wrote:
I am in the process of adding routing to my documents to decrease CPU usage. I think routing is a great solution. If I understand correctly, I can provide the routes that I want to search. If I do not provide the routes then it will search across ALL shards. So far that's what my tests show.
However, now I want to search by id which is auto generated by ES and I use prepareGet. My tests fail when I don't provide the routing. I don't have enough data to know the routing when fetching by ID. I was hoping the behavior would be the same as search - i.e. if I don't provide the routes then it will get across all shards.
Interestingly, prepareMultiGet does this exactly. If I don't provide routing then it will return the document to me. Is this "work as designed"? Should I use multiGet?
Some code.
// Simple get
GetResponse response = client().prepareGet(indexName(), documentType(), id).execute().get(); // doesn't work
// Multi get
MultiGetResponse response = client().prepareMultiGet().add(indexName(), documentType(), id).execute().get(); // this does work
Any help would be appreciated. Thanks!
--
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 (mailto:elasticsearch%2Bunsubscribe@googlegroups.com).
For more options, visit https://groups.google.com/groups/opt_out.
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.