lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: Lucene as a primary datastore
Date Wed, 20 Jan 2010 13:59:27 GMT
My preference is to put the effort into preserving the original
source on the theory that I'm sure no information is lost that
way. So the suitability of Lucene to store it varies depending
upon the source IMO.

If it's raw text, then storing all the raw text in an un-indexed
field in Lucene might suit you well. But if it's a database,
there may be lots of meta-data codified in the design
(e.g. foreign keys, required fields, etc) that's hard to
preserve outside a DB, and that you may need someday....

So that's the first question I'd explore....


On Tue, Jan 19, 2010 at 10:58 PM, Guido Bartolucci <> wrote:

> I know that the primary use case for Lucene is as an index of data
> that can be reconstructed (e.g., from a relational database or from
> spidering your corporate intranet).
> But, I'm curious if anyone uses Lucene as their primary datastore for
> their gold data. Is it good enough?
> Would anyone consider (or do people already) store data in Lucene
> that, if it was lost, would destroy their business? And no, I'm not
> suggesting that you don't back up this data, I'm just curious if there
> are problems with using Lucene in this way. Are there subtle
> corruptions that might show up in Lucene that wouldn't show up in
> Oracle or MySQL?
> I'm considering using Lucene in this way but I haven't been able to
> find any documentation describing this use case. Are there any studies
> of Lucene vs MySQL running for N years comparing the corruptions and
> recovery times?
> Am I just ignorant and scared of Lucene and too trusting of Oracle and
> MySQL?
> Thanks.
> -guido.
> (BTW, I did find a similar question asked back in 2007 in the archives
> but it doesn't really answer my question)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message