Well, all I can say is "if you find yourself trying to do lots of joins in Solr, go back to the drawing board" ;).
Solr is a great search engine, but its ability to be used like a RDBMS is...er...limited. RDBMSs are great at what they do, but make pretty rotten search engines. Rather than think of this as porting your tables over to Solr, you probably want to consider making analyzing what you need the end Solr-powered app to _do_ and designing your Solr architecture from there. If I were going to offer the single most important (IMO) piece of advice, it'd be "define the use cases, then extract data from your DB to support them". And really push back on silly use-cases ;) Best, Erick On Mon, Oct 26, 2015 at 7:35 PM, Walter Underwood <wun...@wunderwood.org> wrote: > 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 >
