I guess Compass is probably the way to go - http://www.opensymphony.com/compass/
From: Prasenjit Mukherjee [mailto:[EMAIL PROTECTED]
Sent: Tue 4/11/2006 2:45 AM
To: java-user@lucene.apache.org
Subject: Re: Distributed Lucene.. - clustering as a requirement
Agreed, an inverted index cannot be efficiently maintained in a
B-tree(hence RDBMS). But I think we can(or should) have the option of
a B-tree based storage for unindexed fields, whereas for indexed fields
we can use the existing lucene's architecture.
prasen
[EMAIL PROTECTED] wrote:
Dmi
Dmitry Goldenberg wrote:
For an enterprise-level application, Lucene appears too file-system and
too byte-sequence-centric a technology. Just my opinion. The Directory
API is just too low-level.
There are good reasons why Lucene is not built on top of a RDBMS. An
inverted index is not effi
ht [mailto:[EMAIL PROTECTED]
Sent: Thu 4/6/2006 3:55 PM
To: java-user@lucene.apache.org
Subject: Re: Distributed Lucene.. - clustering as a requirement
What about using lucene just for searching (i.e., no stored fields
except maybe one "ID" primary key field), and using an RDBMS fo
What about using lucene just for searching (i.e., no stored fields
except maybe one "ID" primary key field), and using an RDBMS for
storing the actual "documents"? This way you're using lucene for what
lucene is best at, and using the database for what it's good at. At
least up to a point -- RDBM
I firmly believe that clustering support should be a part of Lucene. We've
tried implementing it ourselves and so far have been unsuccessful. We tried
storing Lucene indices in a database that is the back-end repository for our
app in a clustered environment and could not overcome the indexing
