fined.
If the nodes are locally run proxies exposed as a Solr shard, the
connection details will be de-coupled from ZooKeeper. That would also
allow for mapping of field names & values and similar site-specific
adjustments of requests & queries.
> In my experience, there is a clear distinc
There may be more.
Also have a look at tribe nodes in Elasticsearch, although these don't
fully address all issues I listed above.
In my experience, there is a clear distinction between "technical"
federated search (possibly something like the tribe nodes) and
"semantic"
Hi all,
We've been discussing a way of implementing a federated search by
leveraging the distributed query parts of SolrCloud. I've written this up
at
http://www.flax.co.uk/blog/2015/01/20/solr-superclusters-for-improved-federated-search/
and would welcome any comments or feedback. S
Yes, either term can be used to confuse people equally well!
-- Jack Krupansky
-Original Message-
From: Alejandro Calbazana
Sent: Thursday, October 2, 2014 3:28 PM
To: solr-user@lucene.apache.org ; Ahmet Arslan
Subject: Re: Solr + Federated Search Question
Thanks Ahmet. Yay! New
hape/schema of the content would differ significantly).
>
> Thanks,
>
> Alejandro
>
>
>
>
> On Wed, Oct 1, 2014 at 9:47 AM, Jack Krupansky
> wrote:
>
> > Alejandro, you'll have to clarify how you are using the term "federated
> > search&quo
Alejandro
On Wed, Oct 1, 2014 at 9:47 AM, Jack Krupansky
wrote:
> Alejandro, you'll have to clarify how you are using the term "federated
> search". I mean, technically Ahmet is correct in that Solr queries can be
> fanned out to shards and the results from each
> > I have a general question about Solr in a federated search context. I
> > understand that Solr does not do federated search and that different
> tools
> > are often used to incorporate Solr indexes into a federated/enterprise
> > search solution. Does anyone have recom
ld like to
"plug-in". The content in each repository would be of different types (the
shape/schema of the content would differ significantly).
Thanks,
Alejandro
On Wed, Oct 1, 2014 at 9:47 AM, Jack Krupansky
wrote:
> Alejandro, you'll have to clarify how you are using the
: https://www.linkedin.com/groups?gid=6713853
On 1 October 2014 09:29, Alejandro Calbazana wrote:
> Hello,
>
> I have a general question about Solr in a federated search context. I
> understand that Solr does not do federated search and that different tools
> are often used to i
Alejandro, you'll have to clarify how you are using the term "federated
search". I mean, technically Ahmet is correct in that Solr queries can be
fanned out to shards and the results from each shard aggregated
("federated") into a single result list, but... more t
Hi,
Federation is possible. Solr has distributed search support with shards
parameter.
Ahmet
On Wednesday, October 1, 2014 4:29 PM, Alejandro Calbazana
wrote:
Hello,
I have a general question about Solr in a federated search context. I
understand that Solr does not do federated search
Hello,
I have a general question about Solr in a federated search context. I
understand that Solr does not do federated search and that different tools
are often used to incorporate Solr indexes into a federated/enterprise
search solution. Does anyone have recommendations on any products (open
of .75 on another. So "federated search"
is hard, you usually have to figure out a way to
group the results in a way that's meaningful to
a user.
Don't quite know how carrot handles that one...
FWIW,
Erick
On Mon, Nov 4, 2013 at 11:09 PM, Susheel Kumar <
susheel.ku...@the
On Tue, Nov 5, 2013 at 6:09 AM, Susheel Kumar <
susheel.ku...@thedigitalgroup.net> wrote:
> Hello,
>
> We have a scenario where we present results to users one from solr and
> other from real time web site search. The solr data we have locally
> available that we are able to index but other websit
Hello,
We have a scenario where we present results to users one from solr and other
from real time web site search. The solr data we have locally available that we
are able to index but other website search, we don't host data and it is real
time.
We are wondering if we can use some fede
Hi,
I have a general design question about federated search that I'd like to
get some thoughts on.
I have several line of business applications that manage their own data.
There is a need to search across these LOB apps, but each of them have
different authorization schemes in terms of all
Hi Dan,
You might want to take a look at pazpar2 [1], an open-source, federated
search engine with first-class support for SOLR (with addition to standard
information retrieval protocols like Z39.50/SRU).
[1] http://www.indexdata.com/pazpar2
On Thu, Sep 5, 2013 at 9:55 PM, Paul Libbrecht
ns to avoid the cost of
> purchasing an expensive enterprise search platform. We are big; we
> already have a closed-source enterprise search engine (and our own home
> grown Entrez search used for PubMed).Since we can already do Federated
> Search with the above, I am evaluating the
a closed-source enterprise search engine (and our own home
grown Entrez search used for PubMed). Since we can already do Federated
Search with the above, I am evaluating the effort of adding such to Apache
Solr. Because NLM data is used in the open relevancy project, we actually
have the releva
On Tue, Aug 27, 2013 at 3:33 AM, Bernd Fehling <
bernd.fehl...@uni-bielefeld.de> wrote:
> Years ago when "Federated Search" was a buzzword we did some development
> and
> testing with Lucene, FAST Search, Google and several other Search Engines
> according Federat
On Tue, Aug 27, 2013 at 2:03 AM, Paul Libbrecht wrote:
> Dan,
>
> if you're bound to federated search then I would say that you need to work
> on the service guarantees of each of the nodes and, maybe, create
> strategies to cope with bad nodes.
>
> paul
>
+1
I'll think on that.
Years ago when "Federated Search" was a buzzword we did some development and
testing with Lucene, FAST Search, Google and several other Search Engines
according Federated Search in Library context.
The results can be found here
http://pub.uni-bielefeld.de/download/2516631/2516644
Some m
Dan,
if you're bound to federated search then I would say that you need to work on
the service guarantees of each of the nodes and, maybe, create strategies to
cope with bad nodes.
paul
Le 26 août 2013 à 22:57, Dan Davis a écrit :
> First answer:
>
> My employer is a libr
>>
>>
>>
>> On Sun, Aug 18, 2013 at 3:14 PM, Erick Erickson
>> wrote:
>>
>>> The lack of global TF/IDF has been answered in the past,
>>> in the sharded case, by "usually you have similar enough
>>> stats that it doesn
hat
> other alternatives I might consider.
>
>
>
> On Sun, Aug 18, 2013 at 3:14 PM, Erick Erickson
> wrote:
>
>> The lack of global TF/IDF has been answered in the past,
>> in the sharded case, by "usually you have similar enough
>> stats that it doesn'
late robot rules?Is it even possible
to do this from an API perspective? Wouldn't google notice?
Third answer:
On Gartner's 2013 Enterprise Search Magic Quadrant, LucidWorks and the
other Enterprise Search firm based on Apache Solr were dinged on the lack
of Federated Search. I do
Why not simply create a meta search engine that indexes everything of each of
the nodes.?
(I think one calls this harvesting)
I believe that this the way to avoid all sorts of performance bottleneck.
As far as I could analyze, the performance of a federated search is the
performance of the
pre-supposes a fairly
> evenly distributed set of documents.
>
> But if you're talking about federated search across different
> types of documents, then what would you "rescore" with?
> How would you even consider scoring docs that are somewhat/
> totally diffe
Since LucidWorks was dinged in the 2013 Magic Quadrant on Enterprise Search
due to a lack of "Federated Search", the for-profit Enterprise Search
companies must be doing it some way.Maybe relevance suffers (a lot),
but you can do it if you want to.
I have read very little of th
The lack of global TF/IDF has been answered in the past,
in the sharded case, by "usually you have similar enough
stats that it doesn't matter". This pre-supposes a fairly
evenly distributed set of documents.
But if you're talking about federated search across different
type
I've thought about it, and I have no time to really do a meta-search during
evaluation. What I need to do is to create a single core that contains
both of my data sets, and then describe the architecture that would be
required to do blended results, with liberal estimates.
>From the perspective o
Carrot, which integrates with Solr among other things. You can test
their federated search at: http://www.etools.ch
Regards,
Alex.
Personal blog: http://blog.outerthoughts.com/
LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
- Time is the quality of nature that keeps events from
> > Ok , thank you for the answer.
> > May be you can pointing me on documentation or any other source where can
> > I
> > get the Idea how to develop such extension.
> >
> > Thanks
> > Oleg.
> >
> >
> > On Fri, Jan 4, 2013 at 2:47 PM, Up
ion or any other source where can
> I
> get the Idea how to develop such extension.
>
> Thanks
> Oleg.
>
>
> On Fri, Jan 4, 2013 at 2:47 PM, Upayavira wrote:
>
> > Solr does not support federated search in the form you describe - that
> > is, to make a q
Ok , thank you for the answer.
May be you can pointing me on documentation or any other source where can I
get the Idea how to develop such extension.
Thanks
Oleg.
On Fri, Jan 4, 2013 at 2:47 PM, Upayavira wrote:
> Solr does not support federated search in the form you describe - that
&
Solr does not support federated search in the form you describe - that
is, to make a query to Solr which solr defers to another search system.
There may be ways you could achieve it (Solr is pretty extensible) and
such a feature would be a very useful one, but it would take some,
likely
Hi,
I've recently posted a message on this list about the ways of
implementing a 'federated search' (a search on multiple indices) whith
Solr. Starting from the answers I got plus informations from the
mailing list archives and the Solr Wiki, I've planned to test three
con
e.
>
> Otis
>
> --
> Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
>
>
> - Original Message
> > From: Grégoire Neuville <[EMAIL PROTECTED]>
> > To: solr-user@lucene.apache.org
> > Sent: Friday, February 29, 2008 6:38:50 AM
>
2008 6:38:50 AM
> Subject: Federated Search
>
> Hello,
>
> I've recently developped a cocoon application that search and retrieve
> catalogue entries by passing requests to a solr, and then managing its
> responses. Quite classical so far. The next step of the project is t
- browsing through the web came I accross an application called the Lucene
Web Service : what do you think of it ? (its goal seems precisely to query
multiple indices, it thus would be the thing I'm searching for ; but
considering the scale of this project, I think I'd prefer to base my work on
rs of the
type of the former describe. This is where my questions arise :
- is Solr able to interrogate several Lucene indices ?
- searching through the wiki or mailing lists for 'federated search'
inevitably take me to the Distributed Search issue : as far as I've
understood,
Hi Jed,
Thanks for sharing your thoughts and the link.
Venkatesh
On 3/11/07, Jed Reynolds <[EMAIL PROTECTED]> wrote:
Venkatesh Seetharam wrote:
>
>> The hash idea sounds really interesting and if I had a fixed number of
> indexes it would be perfect.
> I'm infact looking around for a reve
I have several indexes now (4 at the moment, 20gb each, and I want to be
able to drop in a new machine easily). I'm using SQL server as a DB and
it scales well. The DB doesn't get hit too hard, mostly doing location
lookups, and the app does some checking to make sure a document has
really c
Venkatesh Seetharam wrote:
The hash idea sounds really interesting and if I had a fixed number of
indexes it would be perfect.
I'm infact looking around for a reverse-hash algorithm where in given a
docId, I should be able to find which partition contains the document
so I
can save cycles
Hi Jack,
Howdy. Comments are inline.
is there any reason you don't want to use HTTP?
I've seen that Hadoop RPC is faster then HTTP. Also, Since Solr returns XML
response, you incur overhead in parsing that and then merging. I havent sone
scale testing with HTTP and XML response.
Do the searc
Hi Tim,
Thanks for your response. Interesting idea. Does the DB scale? Do you have
one single index which you plan to use Solr for or you have multiple
indexes?
But I don't know how big the index will grow and I wanted to be able to
add servers at any point.
I'm thinking of having N partition
Jack L wrote:
This is very interesting discussion. I have a few question while
reading Tim and Venkatesh's email:
To Tim:
1. is there any reason you don't want to use HTTP? Since solr has
an HTTP interface already, I suppose using HTTP is the simplest
way to communicate the solr servers
This is very interesting discussion. I have a few question while
reading Tim and Venkatesh's email:
To Tim:
1. is there any reason you don't want to use HTTP? Since solr has
an HTTP interface already, I suppose using HTTP is the simplest
way to communicate the solr servers from the merger/se
Venkatesh Seetharam wrote:
Hi Tim,
Howdy. I saw your post on Solr newsgroup and caught my attention. I'm
working on a similar problem for searching a vault of over 100 million
XML documents. I already have the encoding part done using Hadoop and
Lucene. It works like a charm. I create N in
On 2/27/07, Ken Krugler <[EMAIL PROTECTED]> wrote:
I'm also interested in this. For me, I don't need sorted output,
faceted browsing, or alternative output formats - so something along
the lines of the "Merge XML responses w/o Schema" proposal would be
just fine.
Open issues:
3. Highlighting
I just downloaded Solr to try out, it seems like it will replace a
ton of code I've written. I saw a few posts about the
FederatedSearch and skimmed the ideas at
http://wiki.apache.org/solr/FederatedSearch. The project I am
working on has several Lucene indexes 20-40GB in size spread among a
I just downloaded Solr to try out, it seems like it will replace a ton
of code I've written. I saw a few posts about the FederatedSearch and
skimmed the ideas at http://wiki.apache.org/solr/FederatedSearch. The
project I am working on has several Lucene indexes 20-40GB in size
spread among a
52 matches
Mail list logo
