Re: Distributed search cross cluster

Erick: > ...one for each cluster and just merged the docs when it got them back This would be the logical way. I'm afraid that "just merged the docs" is the crux here, that would make this an expensive task. You'd have to merge docs, facets, highlights etc, handle the different search phases (

Re: Distributed search cross cluster

Hi, I am an ex FAST employee and actually used Unity a lot myself, even hacking the code writing custom mixers etc :) That is all cool, if you want to write a generic federation layer. In our case we only ever need to talk to Solr instances with exactly the same schema and doument types, compat

Re: Distributed search cross cluster

Many years ago, in a different universe, when Federated Search was a buzzword we used Unity from FAST FDS (which is now MS ESP). It worked pretty well across many systems like FAST FDS, Google, Gigablast, ... Very flexible with different mixers, parsers, query transformers. Was written in Python an

Re: Distributed search cross cluster

On 30/01/2018 16:09, Jan Høydahl wrote: Hi, A customer has 10 separate SolrCloud clusters, with same schema across all, but different content. Now they want users in each location to be able to federate a search across all locations. Each location is 100% independent, with separate ZK etc. Ban

Re: Distributed search cross cluster

Jan: Hmmm, must Solr do the work? On some level it seems easier if your middle layer (behind your single IP) has 10 CloudSolrClient thread pools, one for each cluster and just merged the docs when it got them back. That would take care of all of the goodness of internal LBs and all that. Somewher

Re: Distributed Search: Wrong count?

Quick extra clarification – the documents in question we are searching for are child documents we are searching direct (no parent/child in the query) -Frank From: Frank J Kelly mailto:frank.ke...@here.com>> Reply-To: "solr-user@lucene.apache.org" mailto:solr-

Re: Distributed Search (across collections) + partial Filter query

Hi all, thanks to Andrea Gazzarini suggestion I solved it using local params ( which is different from macro expansion even if conceptually similar). Local params were available in Solr 4.10.x I appended this filter query in the request handler of interest: {!lucene df=filterField v=$allow

Re: distributed search limitations via SolrCloud

5.x will still build a war file that you an deploy on Tomcat. But support for that is going away eventually, certainly by 6.0. But you do have to make the decision sometime before 6.0 at least. Best, Erick On Wed, May 27, 2015 at 1:24 PM, Vishal Swaroop wrote: > Thanks a lot Erick... great input

Re: distributed search limitations via SolrCloud

Thanks a lot Erick... great inputs... Currently our deployment is on Tomcat 7 and I think SOLR 5.x does not support Tomcat but runs on its own Jetty server, right ? I will discuss this with the team. Thanks again. Regards Vishal On Wed, May 27, 2015 at 4:16 PM, Erick Erickson wrote: > I'd mov

Re: distributed search limitations via SolrCloud

I'd move to Solr 4.10.3 at least, but preferably Solr 5.x. Solr 5.2 is being readied for release as we speak, it'll probably be available in a week or so barring unforeseen problems and that's the one I'd go with by preference. Do be aware, though, that the 5.x Solr world deprecates using a war fi

Re: distributed search limitations via SolrCloud

Thanks a lot Erick... You are right we should not delay moving to sharding/SolrCloud process. As you all are expert... currently we are using SOLR 4.7.. Do you suggest we should move to latest SOLR release 5.1.0 ? or we can manage the above issue using SOLR 4.7 Regards Vishal On Wed, May 27, 201

Re: distributed search limitations via SolrCloud

Hard to say. I've seen 20M doc be the place you need to consider sharding/SolrCloud. I've seen 300M docs be the place you need to start sharding. That said I'm quite sure you'll need to shard before you get to 2B. There's no good reason to delay that process. You'll have to do something about the

Re: distributed search on tables

thanks Erick -- View this message in context: http://lucene.472066.n3.nabble.com/distributed-search-on-tables-tp4197456p4198285.html Sent from the Solr - User mailing list archive at Nabble.com.

Re: distributed search on tables

You can do what you want either by using two queries or using grouping/field collapsing. Best, Erick On Fri, Apr 3, 2015 at 8:03 AM, avinash09 wrote: > Hi, > > I have a use case search all the name="*test*" from two tables (product and > department) > i need distributed result 5 result from prod

Re: Distributed search across Solr cores in a collection - NPE

It was because I did not have unique id's in my index. I added that and it worked. Also it is mentioned as one of the requirement for Distributed Search. Thanks,Jaikit On Wednesday, January 14, 2015 1:53 AM, Jaikit Savla wrote: Folks, I have set up 3 cores in a single collection a

Re: Distributed search across Solr cores in a collection - NPE

Jaikit, uniq key is mandatory for distributed search. if most of your docs have ids assigned, you can drop remaining ones by adding something like ..&fq=id:[* TO *] On Wed, Jan 14, 2015 at 12:53 PM, Jaikit Savla < jaikit.sa...@yahoo.com.invalid> wrote: > Folks, > I have set up 3 cores in a single

Re: Distributed Search in Solr with different queries per shard

I agree with Eric that this is premature unless you can show that it makes a difference. Firstly why are you splitting the data into multiple time tiers (one recent, and one all) and then waiting to merge results from all of them? Time tiering is useful when you can do the search separately on bot

Re: Distributed Search in Solr with different queries per shard

x queries for each so unifying all 4 may cause a significant > overhead on the system, especially if there are tens of such queries per > second. > Thanks, > Avner > > -Original Message- > From: Erick Erickson [mailto:erickerick...@gmail.com] > Sent: Wednesday, May 21, 2

RE: Distributed Search in Solr with different queries per shard

[mailto:erickerick...@gmail.com] Sent: Wednesday, May 21, 2014 6:13 PM To: solr-user@lucene.apache.org Subject: Re: Distributed Search in Solr with different queries per shard I suppose you could, but I _really_ question whether it's a wise investment in time. Personally I'd treat them as two

RE: Distributed Search in Solr with different queries per shard

ssage- From: Jack Krupansky [mailto:j...@basetechnology.com] Sent: Wednesday, May 21, 2014 6:52 PM To: solr-user@lucene.apache.org Subject: Re: Distributed Search in Solr with different queries per shard Unfortunately the same query will be sent to all cores if you use the shards parameter to

Re: Distributed Search in Solr with different queries per shard

Unfortunately the same query will be sent to all cores if you use the shards parameter to query multiple cores. Is there some characteristic of the first core that is distinct from the second core so that you could OR the differences between the two? -- Jack Krupansky -Original Message--

Re: Distributed Search in Solr with different queries per shard

I suppose you could, but I _really_ question whether it's a wise investment in time. Personally I'd treat them as two different collections and have the app layer fire off two queries and do the aggregation (this is a variant of "federated search" I think). This removes your issue with having the c

Re: Distributed search with Terms Component and Solr Cloud.

Hi Ryan, just take a look on the thread "TermsComponent/SolrCloud". Setting your parameters as default in solrconfig.xml should help. Uwe Am 13.01.2014 20:24, schrieb Ryan Fox: Hello, I am running Solr 4.6.0. I am experiencing some difficulties using the terms component across multiple shar

Re: distributed search is significantly slower than direct search

https://issues.apache.org/jira/browse/SOLR-5478 There it goes On Mon, Nov 18, 2013 at 5:44 PM, Manuel Le Normand < manuel.lenorm...@gmail.com> wrote: > Sure, I am out of office till end of week. I reply after i upload the patch >

Re: distributed search is significantly slower than direct search

Sure, I am out of office till end of week. I reply after i upload the patch

Re: distributed search is significantly slower than direct search

Hi Thanks very much for your answers :) Manuel, if you have a patch I will be glad to test it's performance Yuval On Mon, Nov 18, 2013 at 10:49 AM, Shalin Shekhar Mangar < shalinman...@gmail.com> wrote: > Manuel, that sounds very interesting. Would you be willing to > contribute this back to th

Re: distributed search is significantly slower than direct search

Manuel, that sounds very interesting. Would you be willing to contribute this back to the community? On Mon, Nov 18, 2013 at 9:53 AM, Manuel Le Normand wrote: > In order to accelerate the BinaryResponseWriter.write we extended this > writer class to implement the docid to id tranformation by docV

Re: distributed search is significantly slower than direct search

In order to accelerate the BinaryResponseWriter.write we extended this writer class to implement the docid to id tranformation by docValues (on memory) with no need to access stored field for id reading nor lazy loading of fields that also has a cost. That should improve read rate as docValues are

Re: distributed search is significantly slower than direct search

k check - inner server metrics as cpu user / iowait, >>>>> packets >>>>>transferred over the network, page faults etc. are excellent in >>> order >>>>> to >>>>>understand if the disk/network/cpu is slowing you down. Then

Re: distributed search is significantly slower than direct search

seconds). > > >> > > >> We tried increasing cache sizes and got hits, but it only improved the > > >> query time by a second (~6), so no major effect. > > >> We are not indexing during our tests. The performance is similar. > > >> (How do w

Re: distributed search is significantly slower than direct search

or effect. > >> We are not indexing during our tests. The performance is similar. > >> (How do we measure doc size? Is it important due to the fact that the > >> performance is the same when returning only id field?) > >> > >> We still don't complet

Re: distributed search is significantly slower than direct search

he performance (code, configuration, query)? >> >> -Original Message- >> From: idokis...@gmail.com [mailto:idokis...@gmail.com] On Behalf Of >> Manuel Le Normand >> Sent: Thursday, November 14, 2013 1:30 AM >> To: solr-user@lucene.apache.org >> Subjec

Re: distributed search is significantly slower than direct search

-user@lucene.apache.org Subject: Re: distributed search is significantly slower than direct search It's surprising such a query takes a long time, I would assume that after trying consistently q=*:* you should be getting cache hits and times should be faster. Try see in the adminUI how do your

RE: distributed search is significantly slower than direct search

(code, configuration, query)? -Original Message- From: idokis...@gmail.com [mailto:idokis...@gmail.com] On Behalf Of Manuel Le Normand Sent: Thursday, November 14, 2013 1:30 AM To: solr-user@lucene.apache.org Subject: Re: distributed search is significantly slower than direct search It's surpris

Re: distributed search is significantly slower than direct search

groups them. > > > > Is there a way to refactor code in order to improve distributed documents > > fetching? > > > > Thanks. > > > > -Original Message- > > From: Erick Erickson [mailto:erickerick...@gmail.com] > > Sent: Wednesday, October

Re: distributed search is significantly slower than direct search

-- > From: Erick Erickson [mailto:erickerick...@gmail.com] > Sent: Wednesday, October 30, 2013 3:17 AM > To: solr-user@lucene.apache.org > Subject: Re: distributed search is significantly slower than direct search > > You can't. There will inevitably be some overhead in the dist

RE: distributed search is significantly slower than direct search

: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Wednesday, October 30, 2013 3:17 AM To: solr-user@lucene.apache.org Subject: Re: distributed search is significantly slower than direct search You can't. There will inevitably be some overhead in the distributed case. That said, 7 seconds is

Re: distributed search is significantly slower than direct search

You can't. There will inevitably be some overhead in the distributed case. That said, 7 seconds is quite long. 5,000 rows is excessive, and probably where your issue is. You're having to go out and fetch the docs across the wire. Perhaps there is some batching that could be done there, I don't kno

RE: Distributed search results in "SocketException: Connection reset"

: Distributed search results in "SocketException: Connection reset" This usually means the end server timed out. On 06/30/2013 06:31 AM, Shahar Davidson wrote: > Hi all, > > We're getting the below exception sporadically when using distributed > search. (using Solr 4.2.1

Re: Distributed search results in "SocketException: Connection reset"

This usually means the end server timed out. On 06/30/2013 06:31 AM, Shahar Davidson wrote: Hi all, We're getting the below exception sporadically when using distributed search. (using Solr 4.2.1) Note that 'core_3' is one of the cores mentioned in the 'shards' parameter. Any ideas anyone? T

Re: Distributed Search Question

Firstly, you could combine your two schemas into one, and have id, title, body, filename and url. I'd also add 'source' too. Then all questions of different schemas go away :-) But, to answer your original question - so long as the fields that are queried on exist on both sides, you should be okay

Re: Distributed Search and the Stale Check

On Mon, Feb 25, 2013 at 8:26 PM, Mark Miller wrote: > Please file a JIRA issue and attach your patch. Great write up! (Saw it > pop up on twitter, so I read it a little earlier). > > Done. https://issues.apache.org/jira/browse/SOLR-4509

Re: Distributed Search and the Stale Check

On Mon, Feb 25, 2013 at 8:42 PM, Yonik Seeley wrote: > > > That's insane! > It is insane. Keep in mind this was a 5-node cluster on the same physical machine sharing the same resources. It consist of 5 smartos zones on the same global zone. On my MacBook Pro I saw ~1.5ms per stale check bu

Re: Distributed Search and the Stale Check

> On my particular benchmark rig, each stale check call accounted for an > additional ~10ms. That's insane! It's still not even clear to me how the stale check works (reliably). Couldn't the server still close the connection between the stale check and the send of data by the client? -Yonik

Re: Distributed Search and the Stale Check

On Feb 25, 2013, at 8:14 PM, Ryan Zezeski wrote: > I would like to see a > similar fix made upstream and that is why I am posting here. Please file a JIRA issue and attach your patch. Great write up! (Saw it pop up on twitter, so I read it a little earlier). - Mark

RE: Distributed Search and the Stale Check

I don't have anything to add besides saying "this is awesome". Great analysis. -Michael

Re: distributed search

Ashutosh, Do you want to import data to solr?please explain the use case. How you are performing a search in current scenario? And what is expected from solr? Rgds AJ On 22-Jun-2012, at 15:09, "Ashutosh Puspwan" wrote: > Dear Sir/Mam > > I am a beginner in apache solr. I want to search data

Re: distributed search

This is possible, but you have to create a schema that somehow rationalizes the differences of the two, either by having the sum of all the fields, by sharing the fields but using a type field to signify the sense in which they're being used, by using dynamic fields to relax the schema, or some com

Re: Distributed search between solrclouds?

Yeah, you can still override the shards param and search anywhere AFAIK. I have not tried it recently, but it should work. On May 18, 2012, at 7:57 AM, Darren Govoni wrote: > The thought here is to distribute a search between two different > solrcloud clusters and get ordered ranked results betw

Re: Distributed search between solrclouds?

The thought here is to distribute a search between two different solrcloud clusters and get ordered ranked results between them. It's possible? On Tue, 2012-05-15 at 18:47 -0400, Darren Govoni wrote: > Hi, > Would distributed search (the old way where you provide the solr host > IP's etc.) still

Re: Distributed search: RequestHandler

Hmmm, *how* does this not work? What are you seeing when you try this and what to do you expect to see? Also, what does attaching &debugQuery=on show you? Best Erick On Sat, Feb 11, 2012 at 1:34 PM, ku3ia wrote: > Hi! > > I'm using Solr 3.5. I have two shards. Now I'm using default and my own >

Re: Distributed search has problems with some field names

Hi, On 09/29/2011 03:10 PM, Erick Erickson wrote: I know I've seen other anomalies with odd characters in field names. In general, it's much safer to use only letters, numbers, and underscores. In fact, I even prefer lowercase letters. Since you're pretty sure those work, why not just use them?

Re: Distributed search has problems with some field names

I know I've seen other anomalies with odd characters in field names. In general, it's much safer to use only letters, numbers, and underscores. In fact, I even prefer lowercase letters. Since you're pretty sure those work, why not just use them? Best Erick On Wed, Sep 28, 2011 at 6:59 AM, Luis Ne

Re: Distributed search component.

I am still fighting (after a month of doing other things) with the first part of the problem. Any ideas? Many thanks, Rok On Mon, Apr 4, 2011 at 9:06 AM, Rok Rejc wrote: > Hi all, > > I am trying to create a distributed search component in solr which is quite > difficult (at least for me, becau

Re: Distributed search

Can you please provide more information about your setup and what requests you are making? On Apr 19, 2011, at 10:40 AM, Laurent Fleifel wrote: > Hello, > > I want to do distributed search with Solr for embedded "servers" via Solrj. > > For now, I use MultiCore features (as in the tutorial) b

Re: Distributed Search doesn't response the result set

> search > > works. > > > > Is there a way to let "ID" not be "indexed" in solr? > > > > > =========== > > > > > > > > > > On Tue,

Re: Distributed Search doesn't response the result set

== > > > > > On Tue, Jun 8, 2010 at 7:38 PM, wrote: > > > did you send a commit after the last doc posted to solr? > > > > > -Ursprüngliche Nachricht- > > > Von: Scott Zhang [mailto:macromars...@gmail.com] > > > Ges

Re: Distributed Search doesn't response the result set

On Tue, Jun 8, 2010 at 7:38 PM, wrote: > did you send a commit after the last doc posted to solr? > > > -Ursprüngliche Nachricht- > > Von: Scott Zhang [mailto:macromars...@gmail.com] > >

Re: Distributed Search doesn't response the result set

Hi. All. I am still testing. I think I am approaching the truth. Now confirmed: the doc in my existing lucene indexes, when search with distributed search, none of them are returned. But the docs inserted from solr post.jar are returned successfully. Don't know why. looks the lucene docs ha

Re: Distributed Search doesn't response the result set

Hi. All. I tried with the default solr example plus my own config/schema file. I post test document into solr manually. Then test the distributed search and it works. Then I switch to my existing l*ucene index, and it d*oesn't work. So I am wondering is that the reason, when solr use lucene index

Re: Distributed Search doesn't response the result set

Is there a possibility caused by I am using my own lucene indexes. Not the one created by solr itself? Regards Scott On Mon, Jun 7, 2010 at 4:24 PM, Scott Zhang wrote: > Hi. > I tried URL: > http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=marship&

Re: Distributed Search doesn't response the result set

Hi. I tried URL: http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=marship&rows=10 Got: - 0 16 - localhost:8983/solr,localhost:7574/solr true marship 10 Nothing Happens. On Mon, Jun 7, 2010 at 4:16 PM, Marco Martinez < mmarti...@paradigmatecnolo

Re: Distributed Search doesn't response the result set

Try to put the rows parameter in your request, i guess that in your solrconfig you have configured the default rows to 0 in your default request handler. Marco Martínez Bautista http://www.paradigmatecnologico.com Avenida de Europa, 26. Ática 5. 3ª Planta 28224 Pozuelo de Alarcón Tel.: 91 352 59 4

Re: Distributed Search doesn't response the result set

Thanks for replying. Here is the part of my schema.xml: I only have 4 fields in my document. id I am running 2 instances as tutorial shows: one on 8983. Another one is on 7574. When I search

Re: Distributed Search doesn't response the result set

Hi Scott, We need more information about your request, can you put the query that you are doing to the servers. Marco Martínez Bautista http://www.paradigmatecnologico.com Avenida de Europa, 26. Ática 5. 3ª Planta 28224 Pozuelo de Alarcón Tel.: 91 352 59 42 2010/6/7 Scott Zhang > Hi. All. >

Re: Distributed search fault tolerance

My response to this was mangled by my email client - sorry - hopefully this one comes through a little easier to read ;) On 03/09/2010 04:28 PM, Shawn Heisey wrote: I attended the Webinar on March 4th. Many thanks to Yonik for putting that on. That has led to some questions about the best way

Re: Distributed search fault tolerance

On 03/09/2010 04:28 PM, Shawn Heisey wrote: I attended the Webinar on March 4th. Many thanks to Yonik for putting that on. That has led to some questions about the best way to bring fault tolerance to our distributed search. High level question: Should I go with SolrCloud, or stick with 1.

Re: Distributed search fault tolerance

I guess I must be including too much information in my questions, running into "tl;dr" with them. Later today when I have more time I'll try to make it more bite-size. On 3/9/2010 2:28 PM, Shawn Heisey wrote: I attended the Webinar on March 4th. Many thanks to Yonik for putting that on. Tha

Re: Distributed search and haproxy and connection build up

Not yet - but thanks for the link. I think that the OS also has a timeout that keeps it around even after this event and with heavy traffic I have seen this build up. Having said all this, the performance impact after testing was negligible for us but I thought I would post that haproxy can cause

Re: Distributed search and haproxy and connection build up

Have you played around with the "option httpclose" or the "option forceclose" configuration options in HAProxy (both documented here: http://haproxy.1wt.eu/download/1.3/doc/configuration.txt)? -Tim On Wed, Feb 10, 2010 at 10:05 AM, Ian Connor wrote: > Thanks, > > I bypassed haproxy as a test and

Re: Distributed search and haproxy and connection build up

Thanks, I bypassed haproxy as a test and it did reduce the number of connections - but it did not seem as those these connections were hurting anything. Ian. On Tue, Feb 9, 2010 at 11:01 PM, Lance Norskog wrote: > This goes through the Apache Commons HTTP client library: > http://hc.apache.org

Re: Distributed search and haproxy and connection build up

This goes through the Apache Commons HTTP client library: http://hc.apache.org/httpclient-3.x/ We used 'balance' at another project and did not have any problems. On Tue, Feb 9, 2010 at 5:54 AM, Ian Connor wrote: > I have been using distributed search with haproxy but noticed that I am > sufferi

Re: distributed search and failed core

thx guys, i ended up using a mix of code from the solr-1143 and solr-1537 patches, now whenever there is an exception theres is a section in the results indicating the result is partial and also lists the failed core(s), weve added some monitoring to check for that output as well to alert us when a

Re: distributed search and failed core

On Fri, Jan 29, 2010 at 3:31 PM, Joe Calderon wrote: > hello *, in distributed search when a shard goes down, an error is > returned and the search fails, is there a way to avoid the error and > return the results from the shards that are still up? The SolrCloud branch has load-balancing capabili

Re: distributed search and failed core

My only suggestion is to put haproxy in front of two replicas and then have haproxy do the failover. If a shard fails, the whole search will fail unless you do something like this. On Fri, Jan 29, 2010 at 3:31 PM, Joe Calderon wrote: > hello *, in distributed search when a shard goes down, an err

Re: Distributed Search & nightly delete

On Thu, Aug 27, 2009 at 9:57 PM, GiriGG wrote: > > Hi All, > > I need to build a Search system using Solr. I need to keep data of 30 days > which will be around 400GB. > I will be using Distributed Search with Master/Slaves (Data will be > published to each shard on round robin basis). My challen

Re: Distributed search has problem for facet

Thanks for the bug report... this looks like an escaping bug. But, it looks like it stems from a really weird field name? facet.field=authorname: Shouldn't that be facet.field=authorname -Yonik http://www.lucidimagination.com On Thu, Jul 16, 2009 at 8:14 PM, zehua wrote: > > I use two shards i

Re: Distributed Search in Solr

Hi Grant, What i have got from your comments is: 1. We will have to add a support for BoostingTermQuery which extends SpanTermQuery like in lucene payload support. In current world we anyway have other class which is extending SpanTermQuery . Where should i put this class or newly built BoostingTe

Re: Distributed Search in Solr

On Jul 9, 2009, at 11:58 PM, Sumit Aggarwal wrote: Hi, 1. Calls made to multiple shards are made in some concurrent fashion or serially? Concurrent 2. Any idea of algorithm followed for merging data? I mean how efficient it is? Not sure, but given that Yonik implemented it, I suspect

Re: Distributed search

On Mon, Mar 9, 2009 at 2:32 PM, Gargate, Siddharth wrote: > Hi, >I am trying distributed search and multicore but not able to fire a > query. I tried > > http://localhost:8080/solr/select/?shards=localhost:8080/solr/core0,localhost:8080/solr/core1&q=solr > I am getting following error: "M

RE: Distributed search

icular core to fire distributed search? -Original Message- From: Otis Gospodnetic [mailto:otis_gospodne...@yahoo.com] Sent: Tuesday, February 17, 2009 9:08 AM To: solr-user@lucene.apache.org Subject: Re: Distributed search Hi, That should work, yes, though it may not be a wise thing to d

Re: Distributed Search in multcore scenario.

On Fri, Mar 6, 2009 at 11:04 AM, Sagar Khetkade wrote: > > I have multi-core scenario where the schemas are different and I have to > search for these cores as per the use case. I am using distributed search > approach here for getting the search results for the query from these cores. Distribut

Re: Distributed Search

> : > > Ok, so it wouldn't be possible to have a smaller, faster authoritative > : > > shard for near-real-time updates while keeping the entire dataset in a > : > > second shard which is updates less frequently? > > I believe Otis's point is that many people use distributed search across > shards

Re: Distributed Search

: > Yes, that's the standard trick. :) : > > Ok, so it wouldn't be possible to have a smaller, faster authoritative : > > shard for near-real-time updates while keeping the entire dataset in a : > > second shard which is updates less frequently? : Ok, now I'm confused, if the shard the document

Re: Distributed Search

Fair enough. We should update the Wiki then? I think it currently does read as if its a supported feature rather than something you should avoid. -- - Mark http://www.lucidimagination.com Yonik Seeley wrote: On Wed, Feb 25, 2009 at 11:52 AM, Mark Miller wrote: You are not supposed to h

Re: Distributed Search

On Wed, Feb 25, 2009 at 11:52 AM, Mark Miller wrote: > You are not supposed to have duplicates is a bit strong - I was over reading > into something Yonik had mentioned in the past. It looks like its supposed > to become more useful: Well, perhaps slightly more deterministic so that two queries r

Re: Distributed Search

You are not supposed to have duplicates is a bit strong - I was over reading into something Yonik had mentioned in the past. It looks like its supposed to become more useful: I think Yonik might have to clear this up, but it looks like the current implementation is not deterministic, and he ha

Re: Distributed Search

I don't think your supposed to have duplicate keys? I think its supposed to work more as a graceful failure than a feature you should count on. Id's should be unique across the collection. Ok, now I'm confused, if the shard the document comes from is non-deterministic, how can you use this '

Re: Distributed Search

Otis Gospodnetic wrote: Yes, that's the standard trick. :) Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: gwk To: solr-user@lucene.apache.org Sent: Wednesday, February 25, 2009 5:18:47 AM Subject: Re: Distributed Search

Re: Distributed Search

Yes, that's the standard trick. :) Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: gwk > To: solr-user@lucene.apache.org > Sent: Wednesday, February 25, 2009 5:18:47 AM > Subject: Re: Distributed Search > > Koji S

Re: Distributed Search

Koji Sekiguchi wrote: gwk wrote: Hello, The wiki states 'When duplicate doc IDs are received, Solr chooses the first doc and discards subsequent ones', I was wondering whether "the first doc" is the doc of the shard which responds first or the doc in the first shard in the shards GET paramet

Re: Distributed Search

gwk wrote: Hello, The wiki states 'When duplicate doc IDs are received, Solr chooses the first doc and discards subsequent ones', I was wondering whether "the first doc" is the doc of the shard which responds first or the doc in the first shard in the shards GET parameter? Regards, gwk

Re: Distributed search

: for exampe if we have 3 cores -core0 ,core1 and core2 for 3 different : languages and to search across all the 3 indexes : use the shard parameter as : shard=localhost:8080/solr/core0,localhost:8080/solr/core1,localhost:8080/solr/core2 Distributed search requires that all of the shards have "c

Re: Distributed search

Hi, That should work, yes, though it may not be a wise thing to do performance-wise, if the number of CPU cores that solr server has is lower than the number of Solr cores. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch From: revathy arun

Re: Distributed Search Question

On Thu, Feb 5, 2009 at 2:02 PM, oleg_gnatovskiy wrote: > Hello all. I am using distributed search over three servers, and found that a > shard query to one of the boxes sometimes results in two hits to each of the > other boxes. What is the purpose for having 2 hits? Do we need both? The first hi

Re: distributed search doubts

On Mon, Feb 2, 2009 at 1:53 AM, Marc Sturlese wrote: > > Hey there, > I have asked before about this two questions but got no response... I am > really interested in moving to distributed search so... hopefuly someone > can > give me a hand. > > 1.-In distributed search, Solr do a search per shard

RE: Distributed Search ...

Thanks Otis for clarification. Sourav -Original Message- From: Otis Gospodnetic [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2008 8:18 PM To: solr-user@lucene.apache.org Subject: Re: Distributed Search ... Sourav, Whichever Solr instance you send the request to will dispatch

Re: Distributed Search ...

Sourav, Whichever Solr instance you send the request to will dispatch requests to other Solr instances you specified and will merge the results. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: souravm <[EMAIL PROTECTED]> > To: "solr-user@

Re: Distributed search, standard request handler and more like this

: I'm doing some expirements with the morelikethis functionality using the : standard request handler to see if it also works with distributed search (I : saw that it will not yet work with the MoreLikeThis handler, : https://issues.apache.org/jira/browse/SOLR-788). As far as I can see, this : also

Re: Distributed search and facet counts using facet.limit=-1

Thanks Jaco, I confirmed this problem (not sure why it's still a problem - I thought for sure I had fixed this in the past). -Yonik On Fri, Sep 5, 2008 at 10:50 AM, Jaco <[EMAIL PROTECTED]> wrote: > Hello, > > I'm testing the distributed search using the shards= parameter, looking into > the face

  1   2   >