Most of the time, the best approach is to denormalize everything into one big 
virtual table. Think about a making a view, where each row is one document in 
Solr. That row needs everything that will be searched and everything that will 
be displayed, but nothing else.

I’ve heard of installations with tens of thousands of fields. A thousand fields 
might be cumbersome, but it won’t break Solr.

If the tables contain different kinds of things, you might have different 
collections (one per document), or one collection with a “type” field for each 
kind of document. 

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Oct 26, 2015, at 4:08 PM, Daniel Valdivia <h...@danielvaldivia.com> wrote:
> 
> Hi, I’m new to the solr world, I’m in need of some experienced advice as I 
> see I can do a lot of cool stuff with Solr, but I’m not sure which path to 
> take so I don’t shoot myself in the foot with all this power :P
> 
> I have several tables (225) in my application, which I’d like to add into a 
> single index (multiple type of documents in the same index with unique id) 
> however, each table has a different number of columns, from 5 to 30 columns, 
> do you recomend indexing each column separately or joining all columns into a 
> single “big document”?
> 
> I’m trying to provide my users with a simple experience where they type their 
> search query in a simple search box and I list all the possible documents 
> across different tables that match their query, not sure if that strategy is 
> the best, or perhaps a core per table?
> 
> So far these are my considered strategies:
> 
> unique_id , table , megafield: All of the columns in the record get mixed 
> into a single megafield and indexes (cons: no faceting?)
> a core per table: Each table gets a core, all the fields get indexed (except 
> numbers and foreign keys), I’m not sure if having 200 cores will play nice 
> with Solr
> Single core, all fields get indexed ( possible 1,000’s of columns), this 
> sounds expensive and not so efficient to me
> 
> My application has around 2M records
> 
> Thanks in advance for any advise.
> 
> Cheers

Reply via email to