views:

304

answers:

2

Whilst testing a Solr install for a future MySQL -> Solr migration, it's immediately apparent that the "rules" for what constitutes a good data stucture, and by extension an efficient search, are very different in Solr when compared to an RDBMS like MySQL. The most obvious thing being that data isn't (or doesn't seem to be) normalised to the same degree.

Does anyone have any advice regarding the best way to go about making the transition from MySQL to Solr? Are there any established patterns for structuring data in a non-RDBMS (Solr specifically) that I should be learning about? Any common pitfalls to avoid? Is it simply a case of de-normalising related tables into objects?

+1  A: 

The Solr Enterprise Search Server? If it were me doing it, I would migrate only your documents over, not the entire database. Is that feasible?

Robert Harvey
Absolutely. When you mention documents, you mean only those things that need to be indexed / searchable? In my case that would relate to products on an ecommerce site.
MatW
If you have a single Products table, the differences should be minimal.
Robert Harvey
There are many tables that relate to a product, but the relationships are simple and easily de-normalised.
MatW
Do you really have to denormalize? All you need to retrieve the document is a foreign key in your Products table to reference the document in the Solr server. If by denormalization you mean providing views as such, then fine. If you mean to restructure your database, I don't think you have to.
Robert Harvey
+3  A: 

First of all, you have to ask yourself if you want to:

  1. migrate the whole thing to Solr or
  2. just use Solr as a complement used for searching.

For anything other than non-trivial relational schemas, I'd recommend #2. The more heterogeneous data you have in one index, the less useful it is.

Mauricio Scheffer