I attended two very interesting Hibernate sessions at JBoss World yesterday. One was on Hibernate Search, the other was Hibernate Shards.

Hibernate Search

What do you do when your customers add “Google-like search” to the list of requirements for the web application you are delivering? With a straight relational back-end, implementing that requirement might be tougher than you’d think. Just a few challenges are:

• “Keyword” search means you’re probably going to want to use wildcards which perform poorly.
• Your data is scattered across multiple columns. Writing a SQL query to search them all is ugly.
• SQL doesn’t really know how to deal with typical search constructs like proximity, synonyms, or relevance.

Hibernate Search is the answer. It combines the power of the proven Apache Lucene search engine with the ease of configuration of Hibernate. Hooking Hibernate Search into your app is a matter of dropping in a couple of JAR files and adding annotations to your classes to describe what should and shouldn’t be indexed.

Hibernate Shards

What do you do when you can’t (or don’t want to) put all of your data in the same relational database? Google’s word for horizontal partitioning–taking horizontal slices of your database and storing each slice in a separate physical database–is called “sharding”. Give a few Google engineers passionate about the subject a few months and Hibernate Shards is the result (Google donated the project to JBoss).

Shards lets you come up with your own scheme for how rows will be partitioned. Each partition is called a shard. Once you’ve settled on a scheme it’s a matter of configuration through familiar Hibernate configuration constructs. If you don’t use any of the out-of-the-box implementations for how to decide which shard to create and find objects on or for how to generate ID’s, you’ll have to implement those interfaces as well. Once you’ve got everything in place, persisting and querying objects works the same way as straight Hibernate.