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,

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

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.

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.

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 > Reply-To:

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

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 vishal@gmail.com wrote: Thanks a lot

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 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,

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

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 avinash.i...@gmail.com wrote: Hi, I have a use case search all the name=*test* from two tables (product and department) i need distributed result 5

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 jaikit.sa...@yahoo.com wrote: Folks, I have set up 3 cores

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

Re: Distributed Search in Solr with different queries per shard

: 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

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

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

RE: Distributed Search in Solr with different queries per shard

- 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 query

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 different

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

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

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 manuel.lenorm...@gmail.com wrote: In order to accelerate the BinaryResponseWriter.write we extended this writer class to implement the docid to

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 the

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

. Is there a way to improve the 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 Subject: Re: distributed search

Re: distributed search is significantly slower than direct search

: 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 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

Re: distributed search is significantly slower than direct search

[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 surprising such a query takes a long time, I would assume

Re: distributed search is significantly slower than direct search

)? -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 surprising such a query takes

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

@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 query/doc

RE: distributed search is significantly slower than direct search

, 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 surprising

Re: distributed search is significantly slower than direct search

: 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 quite long. 5,000 rows is excessive, and probably where

Re: distributed search is significantly slower than direct search

] 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 quite long. 5,000 rows is excessive

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 quite

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

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?

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) Note that 'core_3' is one

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

Re: Distributed Search and the Stale Check

On Mon, Feb 25, 2013 at 8:26 PM, Mark Miller markrmil...@gmail.com 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

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

Re: Distributed Search and the Stale Check

On Feb 25, 2013, at 8:14 PM, Ryan Zezeski rzeze...@gmail.com 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

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 Mon, Feb 25, 2013 at 8:42 PM, Yonik Seeley yo...@lucidworks.com 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

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

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 ashu.pusp...@gmail.com wrote: Dear Sir/Mam I am a beginner in apache solr. I

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 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

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 dem...@gmail.com wrote: Hi! I'm using Solr 3.5. I have two shards. Now I'm using default

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

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

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 rokrej...@gmail.com wrote: Hi all, I am trying to create a distributed search component in solr which is quite difficult (at

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) by

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

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

Re: Distributed Search doesn't response the result set

, markus.rietz...@rzf.fin-nrw.de wrote: did you send a commit after the last doc posted to solr? -Ursprüngliche Nachricht- Von: Scott Zhang [mailto:macromars...@gmail.com] Gesendet: Dienstag, 8. Juni 2010 08:30 An: solr-user@lucene.apache.org Betreff: Re: Distributed Search doesn't

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

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. fields field name=id type=string indexed=true stored=true required=true / field name=type type=string indexed=true stored=true required=true/ field name=keyword_level1 type=text indexed=true

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

Re: Distributed Search doesn't response the result set

Hi. I tried URL: http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solrindent=trueq=marshiprows=10 Got: response - lst name=responseHeader int name=status0/int int name=QTime16/int - lst name=params str name=shardslocalhost:8983/solr,localhost:7574/solr/str str

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 macromars...@gmail.com wrote: Hi. I tried URL:

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

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

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. That

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 ian.con...@gmail.com wrote: Thanks, I bypassed haproxy

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

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 goks...@gmail.com wrote: This goes through the Apache Commons HTTP client library:

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 ian.con...@gmail.com wrote: I have been using distributed search with haproxy but noticed

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 calderon@gmail.comwrote: hello *, in distributed search when a

Re: distributed search and failed core

On Fri, Jan 29, 2010 at 3:31 PM, Joe Calderon calderon@gmail.com 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

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

Re: Distributed Search nightly delete

On Thu, Aug 27, 2009 at 9:57 PM, GiriGG giri...@gmail.com 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).

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, zehuabradjo...@yahoo.com wrote:

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

RE: Distributed search

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 do performance

Re: Distributed search

On Mon, Mar 9, 2009 at 2:32 PM, Gargate, Siddharth sgarg...@ptc.com 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/core1q=solr I am getting following

Re: Distributed Search in multcore scenario.

On Fri, Mar 6, 2009 at 11:04 AM, Sagar Khetkade sagar.khetk...@hotmail.comwrote: 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

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 where some

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

Re: Distributed Search

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

Re: Distributed Search

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

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

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

Re: Distributed Search

On Wed, Feb 25, 2009 at 11:52 AM, Mark Miller markrmil...@gmail.com 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

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 markrmil...@gmail.com wrote: You

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 comes

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

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

Re: Distributed Search Question

On Thu, Feb 5, 2009 at 2:02 PM, oleg_gnatovskiy oleg_gnatovs...@citysearch.com 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

Re: distributed search doubts

On Mon, Feb 2, 2009 at 1:53 AM, Marc Sturlese marc.sturl...@gmail.comwrote: 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

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:

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 :

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 facet

Re: distributed search mechanism

2008/8/31 Grégoire Neuville [EMAIL PROTECTED] Hi all, I've recently been working with the distributed search capabilities of solr to build a web portal ; all is working fine, but it is now time for me to describe my work on a theoretical point of view. I've been trying to approximately

Re: distributed search mechanism

I thank you for the answer. The http://wiki.apache.org/solr/DistributedSearchDesign page was last edited by Yonik Seeley on the 2008-02-27, which seems a date of major commit (according to JIRA), and he did not amend the current approach part of the page : so the Multi-phased approach, allowing

Re: distributed search mechanism

On Wed, Sep 3, 2008 at 7:35 PM, Grégoire Neuville [EMAIL PROTECTED] wrote: The http://wiki.apache.org/solr/DistributedSearchDesign page was last edited by Yonik Seeley on the 2008-02-27, which seems a date of major commit (according to JIRA), and he did not amend the current approach part of

Re: distributed search mechanism

: This is typically the kind of description I need, but I wonder if the : one cited above is still valid (since it was apparently written quite a : time before final commit). : Assuming it is, what's then the difference between the STEPS mentioned and the STAGES later introduced (STAGE_START,

  1   2   >