Re: solr as the data store

[Lance Norskog <go...@gmail.com>]

Problems:

1) If you get the schema wrong it is painful to live with. You may need to
extract all data and reindex with your new schema. To ease this I wrote an
XSL script that massaged the default Solr XML output into the Solr XML input
format. Extracting is really slow and this process took days.

2) If you get a corrupted Lucene index, restoring from an old one will throw
away all of your intervening updates.

I really don't recommend this course. If you can archive your input data on
tape, you may be very happy you did so. If you must use a DB, MySQL has a
table format that archives into ZIP format files. (It does not make indexes;
all searches are table scans.)

Lance

On Wed, Jan 28, 2009 at 12:37 PM, Ian Connor <ia...@gmail.com> wrote:

> Hi All,
>
> Is anyone using Solr (and thus the lucene index) as there database store.
>
> Up to now, we have been using a database to build Solr from. However, given
> that lucene already keeps the stored data intact, and that rebuilding from
> solr to solr can be very fast, the need for the separate database does not
> seem so necessary.
>
> It seems totally possible to maintain just the solr shards and treat them
> as
> the database (backups, redundancy, etc are already built right in). The
> idea
> that we would need to rebuild from scratch seems unlikely and the speed
> boost by using solr shards for data massaging and reindexing seems very
> appealing.
>
> Has anyone else thought about this or done this and ran into problems that
> caused them to go back to a seperate database model? Is there a critical
> need you can think is missing?
>
> --
> Regards,
>
> Ian Connor
>



-- 
Lance Norskog
goksron@gmail.com
650-922-8831 (US)