Solr Deployments

Different ways to deploy Solr:

  • Single core with flatten index
  • Multi-cores
  • Multiple deployments

Single core with flatten index:

When I first started out with Solr, I needed to index data from two different tables. One table was in MySQL. One table was PostgreSQL. Information from both of these tables needed to be returned in a single trip to Solr. I had problem with setting up multiple cores. I had other responsibilities, and the responsibility of setting up or configuring Solr to index both of these table was given to another person, but that person failed. I finally came up with a way:

That person already used DataImportHandler (DIH) for importing data from single table. He already configure DIH to pull data from the second table. But somehow thing did not work…

So in the data-config.xml, we defined two data sources.

To avoid unique ID collison, the SQL statements were modified so that the name of the table is concatenated with the primary key for that table.

When Solr is queried, it returns the uniqueField as mysql123 or postgresql123. Based on this information, the front end code would know which table / database to retrieve additional information.

This is an example of 'single core with flatten index'. We can do this because Solr does not impose restriction on the fields (we can have fields that are empty). Fields that were defined to contain information from table A are empty when fields that were defined to store information from table B are populated.

From the database point of view, this is not optimal, but Solr is not a database.

It would be nice if I can recover the old configuration file and post it here.

Multi-core:

Multiple deployments:

We can have multiple single-core instances. Each core can be on a different port, or different URL path.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License