Hi. I tried 3 methods. But it seems the performance of Hibernate Search is poor.
Did I miss something?

1. Hibernate Search with spatial search
2. Hibernate Search with spatial search with latitude/longitude distance where optimization
3. Hibernate ORM only with NamedStoreProcedure in MySQL with latitude/longitude distance where optimization

< 100000 meters


< 10000 meters


< 1000 meters


< 100 meters


The first number is time in ms. The second number is the result list size. And there're 100000 records in the database.
It seems that it's with poorer performance with Hibernate Search compared with Hibernate ORM only with NamedStoreProcedure.
The gap is even bigger with low result list size.

Hello, that's an interesting question.

Hibernate Search is often faster than running a query in the database, but its focus is on full-text queries. In case of Spatial queries, to tell which technology will "win" depends on many details. For example it might depend on the exact data distribution, such as the data you are querying having many matches rather than being quite sparse. Of course the approaches are very different too, so one might benefit more from having more memory, or more CPU, just to name two options out of thousands of variables: I'd need extensive system metrics to tell why one is winning in your case. For sure Hibernate Search will need to ultimately load all matches from the RDBMS so if you are not using projections you're actually querying both the index and the database, yet typically Hibernate Search would "win" as the queries on the database are much simpler, so they take it easy on the system resources of your DB.

If you're just doing a query on locations and not using any other criteria, it's hard to say which approach will be more effective: RDBMs can also be very competitive as the spatial indexes are similar to traditional RDBMs indexes.

The reason to use the Spatial extensions of Hibernate Search is when you have to combine a Spatial Query with other full-text queries and/or filters. In this case you will have far better performance (and quality of the results) as the full-text capabilities outshine any RDBMs capability, both in performance and tuning options which greatly affect the quality of your results.

Combining full-text queries, filters AND spatial queries can not be done efficiently when these criteria are applied partially in the RBDMs and partially in Lucene, so when the combination is required it should be far better to do it all in Hibernate Search. Not least, this will make the result "more sparse" as Lucene will be able to apply the cheaper filters first, this can provide a dramatic boost in performance.

A different reason to use Hibernate Search for spatial queries is scalability of the architecture: it's much easier (and cheaper) to have multiple app nodes and let them do the hard work of computing all trigonometry functions required for a spatial query, than to scale a database server.

Finally - even though there are some reasonable cases in which a RDBMs might be a better choice - I'll admit that I expect us to generally beat a RDBMs even in the "spatial only" competition: I wouldn't rule out that we can improve our performance. If you feel like sharing some code I'd be happy to verify your measurements and see if there's something which we can improve on.