CODEWITHSUNDEEP
hibernatehibernate-search
Code Junkie
Code Junkie

Reputation: 7788

hibernate-search with criteria projection queries

I'm using hibernate search for all my free text / facet searching. I'm trying to increase performance and I'm noticing my query has a lot of unneeded selects and joins. My goal is to create a projection query, now I know I can do this directly with hibernate-search by storing items in the index, but I'd like to try and refrain from doing that do to memory consumption. My thought was to return a list of pks from hibernate-search and then pass them into my criteria query. My question, is this the correct approach?

Upvotes: 0

Views: 883

Answers (1)

Hardy
Hardy

Reputation: 19109

Before answering your question, let me try to clarify a few things, even though I think you already understood them.

Hibernate Search is an extension of Hibernate ORM which uses Apache Lucene. Based on its configuration it will index parts of your managed entities in a Lucene index. You can then build a so called "free-text search" query, which searches the Lucene index. This is independent from any JPA or Hibernate ORM specific query capability which targets the relational database which stores the entities.

Back to "free-text" searches. The default behavior of Hibernate Search is indeed to run the specified Lucene query against the Lucene index to retrieve a list of entity ids. These ids are then used to do a bulk loading from the database using Hibernate ORM capabilities.

Now to your question.

I'm trying to increase performance and I'm noticing my query has a lot of unneeded selects and joins.

One really has to differentiate here. There are two queries happening. The Lucene query against the free text index and the Hibernate ORM query to lead the matching entities from the database. Since you are talking about select and joins, I take it that you talk about the latter. If the SQL queries are the performance bottleneck and there are too many joins etc, performance tuning should look at the complexity of the domain model and its tuning in relation to Hibernate ORM (lazy associations etc).

My goal is to create a projection query, now I know I can do this directly with hibernate-search by storing items in the index

Right, if you don't need managed entities and are only interested in parts of the data, projection queries are the way to go. Again, there are two types. Hibernate Search projection queries and Hibernate ORM projection queries. The former, as you already mentioned, store additional data in the Lucene index and execute the projection against this data. The benefit is in this case that there is no database access at all. The latter projection type, are projection against the relational database. Instead of loading the full entity only selected properties will be loaded (via SQL).

My thought was to return a list of pks from hibernate-search and then pass them into my criteria query.

One could do that, but I don't think this is the best approach. To do this, you would need to projection queries. First a Hibernate Search projection query to get the list of entity ids and then a ORM projection query to load the properties from the database. You can skip the second projection completely if you store the relevant properties in the Lucene index.

So, if performance is your ultimate goal, that's the way to go. You seem to be worried about memory consumption though. IMO Lucene and Hibernate Search do a good job in trying to be as efficient as possible. I would not out of premature optimizations considerations discard the pure Hibernate Search projection approach.

Upvotes: 1

Related Questions