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 < lat...@mdpi.com.invalid> 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 > >
