Hibernate has emerged as one of the primary Java object-relational data access layers. While a single Hibernate application could access data from multiple databases since the framework's initial release, developers had to create their own frameworks to distribute single logical data sets across several databases. The recently released Hibernate Shards project, contributed by Google, promises to solve that, and offer:

A horizontal partitioning solution built on top of Hibernate Core. When you need to distribute (shard) your data across multiple databases, Hibernate Shards is for you (too much data for a single database instance, regional deployment requirements, etc.) Like all Hibernate projects, Hibernate Shards is released under the LGPL license.

A cursory look at the project's architecture overview document reveals that:

The primary goal of Hibernate Shards is to enable application developers to query and transact against sharded datasets using the standard Hibernate Core API. This allows existing applications that use Hibernate but do not yet need sharding to adopt our solution without major refactoring if and when they do reach this stage.

This also allows application developers who are familiar with Hibernate, need sharding, and are starting from scratch to become productive in a short amount of time because there will be no need to ramp-up on a new toolset. With this goal in mind, it should come as no surprise that Hibernate Shards primarily consists of shard-aware implementations of many of the Hibernate Core interfaces you already know and love.

The Hibernate Session, SessionFactory, Criteria, and Query interfaces are implemented as ShardedSession, ShardedSessionFactory, ShardedCriteria, and ShardedQuery. These implementations,

Serve as a sharding engine that knows how to apply your application-specific sharding logic across your various data stores. We don't expect application developers to need to write much code that knowingly interacts with these interfaces, so if you do find yourself declaring or passing around Sharded instances take a step back and see if you can make do with the parent interface instead.

What techniques do you use to scale up the database layer of your enterprise application?