lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jack Krupansky <>
Subject Re: Solr best practices for many to many relations...
Date Thu, 14 Apr 2016 14:23:33 GMT
Solr is a search engine, not a database.

JOINs? Although Solr does have some limited JOIN capabilities, they are
more for special situations, not the front-line go-to technique for data
modeling for search.

Rather, denormalization is the front-line go-to technique for data modeling
in Solr.

In any case, the first step in data modeling is always to focus on your
queries - what information will be coming into your apps and what
information will the apps want to access based on those inputs.

But wait... you say you are upgrading, which suggests that you have an
existing Solr data model, and probably queries as well. So...

1. Share at least a summary of your existing Solr data model as well as at
least a summary of the kinds of queries you perform today.
2. Tell us what exacting is driving your inquiry - are queries too slow,
too cumbersome, not sufficiently powerful, or... what exactly is the
problem you need to solve.

-- Jack Krupansky

On Thu, Apr 14, 2016 at 10:12 AM, Bastien Latard - MDPI AG <> wrote:

> Hi Guys,
> *I am upgrading from solr 4.2 to 6.0.*
> *I successfully (after some time) migrated the config files and other
> parameters...*
> Now I'm just wondering if my indexes are following the best
> practices...(and they are probably not :-) )
> What would be the best if we have this kind of sql data to write in Solr:
> I have several different services which need (more or less), different
> data based on these JOINs...
> e.g.:
> Service A needs lots of data (but bot all),
> Service B needs a few data (some fields already included in A),
> Service C needs a bit more data than B(some fields already included in
> A/B)...
> *1. Would it be better to create one single index?*
> *-> i.e.: this will duplicate journal info for every single article*
> *2. Would it be better to create several specific indexes for each similar
> services?*
> *-> i.e.: this will use more space on the disks (and there are ~70millions
> of documents to join) 3. Would it be better to create an index per table
> and make a join? -> if yes, how?? *
> Kind regards,
> Bastien

  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message