>From the example:
client.prepareSearch(indexName).setRouting(routingStr).setQuery(
QueryBuilders.termQuery("_routing", routingStr)).execute().actionGet();
For clarification, can someone verify that the routing needs to be
specified via setRouting(routingStr) as well as
TermQuery(QueryBuilders.termQuery("_routing", routingStr)...? I am
having a difficult time finding documentation on the java client api as it
pertains to routing. Thanks for the help.
On Friday, September 23, 2011 7:15:43 PM UTC-4, kimchy wrote:
>
> Replace setFilter with setQuery(QueryBuilders.termQuery("_routing",
> routingStr), as the filter is mainly used to filter results fo the query
> you execute (mainly used with faceting).
>
> On Fri, Sep 23, 2011 at 11:18 PM, Per Steffensen <[email protected]
> <javascript:>> wrote:
>
>> Shay Banon skrev:
>>
>> Get is as fast as you can go to retrieve a single document, search
>> against a single field (term query) that uses routing to direct the search
>> request to a single shard will be almost as fast, but not the same. I don't
>> have actual numbers to say how slower it will be.
>>
>> Regarding a combined index, there is no option to do that in
>> elasticsearch. You can do a boolean query, with several must clauses
>> including term query against a, b, and c. This will be slower (since now
>> you are not searching on a single field, but 3).
>>
>> On the other hand, the _routing field is automatically indexed (not
>> analyzed). So, based on the same below, you can simply do a term query
>> against _routing field with the routing value.
>>
>> Thanks. Will the following code do the trick?
>>
>> client.prepareSearch(indexName).setRouting(routingStr).setFilter(new
>> TermFilterBuilder("_routing", routingStr)).execute().actionGet();
>>
>>
>> Of course, you might get several documents with the search request, but
>> I think you factored that in (a_b_c_1, and a_b_c_2).
>>
>> On Thu, Sep 15, 2011 at 10:06 PM, Per Steffensen <[email protected]
>> <javascript:>> wrote:
>>
>>> curl -X PUT "localhost:9200/mytest/abc/_mapping" -d '{
>>> "abc" : {
>>> "_routing" : {
>>> "required" : true
>>> }
>>> "properties" : {
>>> "idx" : {"type" : "string", "index" : "not_analyzed"},
>>> "a" : {"type" : "string"},
>>> "b" : {"type" : "string"},
>>> "c" : {"type" : "integer"},
>>> "txt" : {"type" : "string", "null_value" : "na"}
>>> }
>>> }
>>> }
>>>
>>> Lots of abc documents indexed into mytest index - a.o. this
>>> curl -XPUT
>>> "localhost:9200/mytest/abc/1234_5678_90123?routing=1234_5678_90123" -d '{
>>> "sms" :
>>> {
>>> "a" : "1234",
>>> "b" : "5678",
>>> "c" : 90123,
>>> "txt" : "Hello World"
>>> }
>>> }
>>>
>>> Expect this "get" will be very efficient:
>>> curl -XGET "
>>> http://localhost:9200/mytest/abc/1234_5678_90123?routing=1234_5678_90123
>>> "
>>>
>>> I have cheated a little in the code above, when I indicate that I can
>>> make an id consisting of the values of a, b and c. It is only almost true -
>>> sometimes (but very very seldom) there will be documents with the same
>>> values for a, b and c. Therefore I cannot make id's like this (will have to
>>> make a_b_c_X id's og just GUID id's instead), and therefore I cannot "find"
>>> the document(s) using the "get" above.
>>>
>>> Question: If I know that there will never be more than a few documents
>>> with concrete values for a, b and c, can I create a "search" finding those
>>> documents, a search that is just (or almost) as efficient (with respect to
>>> searchtime and resources used) as the "get" above? Note that I am using
>>> routing so I should at least be able to hit the right shard in such a
>>> search.
>>>
>>> In a RDMS I would make an combined index of a, b and c and use the query
>>> "select * from abc where a="1234" and b="5678" and c=90123" (the "search")
>>> instead of "select * from abc where id="1234_5678_90123"" (the "get"), and
>>> that would be just as efficient (if the RDMS uses the combined index, or
>>> else I will force it by hinting).
>>>
>>> Thanks!
>>>
>>> Regards, Per Steffensen
>>>
>>>
>>
>>
>
--
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/7012fe03-4b32-4a86-8ca2-0cfdeb635760%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
