• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Emmanuel & John: Hibernate Search vs Compass

 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I wonder if your book touches on other search integrations, in particular Compass?

Do you have any opinions on one over the other? Or do you see them as much the same beasts?

What opinions do you have about storing indices in the database itself (as Compass can do)?
[ December 09, 2008: Message edited by: Paul Sturrock ]
 
John Griffin
author
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul,

We actually made a conscious decision to stay away from a discussion of other technologies. We have just seen these turn into flame wars when discussed on open forums.

As far as storing indexes in DBs we discuss and discourage this in chapter 11. This is an inefficient way to handle indexes. Every time there is an update or addition there is the possibility of a file segment merge so the index would have to be read and rewritten and there is no way to really predict when this will happen.

That's just a sample of the problems you are faced with.

Hope this helps.

John G
 
Emmanuel Bernard
author
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Emmanuel Bernard
author
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That being said, chapter 1 covers full-text search in general, why it is better than SQL, what problems it addresses, the various *types of* solutions on the market and the gotchas when you try to use full-text libraries in Java application.

We heard good feedback from reviewers on this chapter.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic