Here are some nice features specific to Hibernate Search:
- objects returned by Hibernate Search are actual object instance an HQL query would have returned ie from the same persistence context
- Hibernate Search treats indexing as an auxiliary function hat would not make a main transaction fail which I think it the right approach. nobody wants the order to be cancelled because indexing went wrong
- Hibernate Search has a very deep integration int he Hibernate programmatic model and APIs, particularly, full-text queries are implementations of org.hibernate.Query or javax.persistence.Query. Access to the full-text library is one step away from the Session or EntityManager (ie a subinterface named FullTextSession or FullTextEntityManager)
- minimal configuration and configuration files is one of our core values
- the asynchronous indexing in a cluster out of the box is something specific to Hibernate Search
So in a
word, Hibernate Search makes it look like you are using Hibernate.
On the subject of storing the index in the database it suffers two problems IMO:
- you still suffer from the global pessimistic lock when an index is updated (no other node can update the same lucene index)
- implementations I have seen use blobs which are... problematic in most databases and quite slow. Particularly MySQL. Also it will increase your network traffic compared to a local Lucene directory (ie on the local file system).
More on the subject here
http://forum.hibernate.org/viewtopic.php?t=980778&highlight=database+lucene+directory