I'm considering systems for better search abilities against our database. It's presently an enormous bottleneck (leading to lengthy-lasting queries which are harming our database performance).
My boss wanted me to consider Solr, but on closer inspection, it appears we really want some type of DB integration mechanism with Lucene itself.
Like a background in our current technology stack, we're using straight JSPs on Tomcat, no Hibernate, not one other frameworks on the top from it... just straight Java, JSP, and JDBC against a DB2 database.
Considering that, it appears Hibernate Search may be a little harder to integrate into our bodies, though it may be nice to achieve the use of using Hibernate after this kind of integration.
Does anybody have encounters they are able to tell using one of these simple tools (or any other similar Lucene based solutions) that can help in choosing the right tool?
It must be a FOSS solution, and ideally will manage upgrading Lucene with changes in the database automagicly (though effectively), without extra effort to inform the tool when changes happen to be made (otherwise, it appears moving my very own Lucene solution could be every bit as good). Also, we've multiple application servers with only 1 database (+failover), so it might be nice if you can easily make use of the solution all application servers effortlessly.
I'm ongoing to examine the choices now, but it might be really useful to make use of other individuals encounters.
Whenever you say "search against a DB", exactly what do you mean?
Relational databases and knowledge retrieval systems use completely different approaches permanently reason. What type of data looking? What type of queries would you perform?
Basically would implement an inverted index on the top of the database, as Compass does, I wouldn't use their approach, which would be to implement Lucene's
Directory abstraction with BLOBs. Rather, I'd implement Lucene's
Relational databases are very able to maintaining indexes. The worthiness that Lucene earns this context is its analysis abilities, that are most helpful for unstructured text records. A good idea would leverage the talents of every tool.
As updates are created to the index, Lucene produces more segments (additional files or BLOBs), which degrade performance until a pricey "optimize" procedure can be used. Most databases will amortize this cost over each index update, providing you with more stable performance.
I've had good encounters with Compass. It's great integration with hibernate and may mirror data changes made through hibernate and jdbc straight to the Lucene indexes though its Gps navigation products http://www.compass-project.org/docs/1.2.2/reference/html/gps-jdbc.html.
Maintaining the Lucene indexes on all of your application servers might be an problem. For those who have multiple Application servers upgrading the db, you might hit some difficulties with keeping the index synchronized with the changes. Compass might have another mechanism to handle this now.
The Alfresco Project (Content management systems) also uses Lucene and also have a mechanism for replicating Lucene index changes between servers that might be helpful in handling these problems.
We began using Compass before Hibernate Search really was off the floor and so i cannot offer any comparison by using it.
For any pure performance boost with searching Lucene will definitely help a great deal. Only index that which you worry aboutOrrequire and you ought to be great. You could utilize Hibernate as well as other piece if you want however i don't believe it is needed.
Well, it appears DBSight doesn't meet the FOSS requirement, so unless of course it's an absolutely stellar solution, it's not a choice for me personally at this time...