I am building a web application with a backend restful web service.
One of my tables is pretty much standalone, i.e rows only referenced from one other table in a manner where I can happily live without joins and only fetch by primary key when I need to. However this table holds a lot of rows and the searches performed against it all scream “Lucene”. MySQL is unable to handle these queries with a reasonable response time.
So I would like to use Lucene for searching this table. In the past I’ve used Solr extensively so I’m familiar with the concepts and terminology. I was thinking that given my circumstances described above, instead of SQL-to-Lucene index synchronization, I can’t see a reason why I shouldn’t simply use Lucene as the canonical storage for this particular entity. Basically I would like to have a “Lucene DAO” implementation that replaces the current Hibernate DAO implementation for this particular table.
So my questions are:
- Is there any reason why I should avoid that and stick to SQL-to-index sync?
- If a “Lucene DAO” is a viable approach, are there any libraries out there that provide the foundation for something like that? I tried to search but couldn’t find any.
- I have come across Hibernate Search It does only half of what I’m looking for but I can try and use it for searching only. Does anyone have any experience using Hibernate Search?
Edit: I’ve now come across Compass which at a quick glance seems to be what I’m looking for. Does anyone have any experience with it?
Edit #2: Compass has been discontinued and replaced with ElasticSearch which isn’t quite the same (service rather than a component). Hibernate Search didn’t prove to be what I’m looking for either. The bottom line is that this is a valid approach, but for the time being one has to implement such a DAO themselves.
I would ditch SQL for this use case and use Lucene straight, no chaser.
Your queries with Lucene will be a lot richer: n-grams instead of LIKE.