when is using JDBC with lucene indexes a good idea?

Question

I'm implementing a lucene (Compass) based search engine for our application and we will be deploying to a vmware environment. The client tells me that the I/O performance is so bad on the the vmware host that JDBC storage for lucene would be preferred over shared storage of the index files. I'm surprised by this.

So I'm wondereing if you have a choice, what are some pros and cons of using a database or shared storage for lucene indexes in a clustered environment? Does it depend on the expected number of index writes?

Answer 1

I would ask for some data to back up that assertion. Don't databases use I/O as well? Or would your JDBC solution connect to a non-virtualized database instance?

How often do you re-index with Lucene? I don't see how this could be a problem if you only do it once a day using a separate batch job.

I'd prefer Lucene to JDBC because the solution demanded search capability. Try doing free-form searches with SQL and LIKE clauses sometime. That would seem far more inefficient.

If it's a big concern, try a small benchmark.