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 <ian.con...@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 goks...@gmail.com 650-922-8831 (US)
