Multi-tenant cloud architecture is a way to partition data such that a single instance of an application can host data from multiple organizations simultaneously. A multi-tenant application allows each organization (tenant) to co-exist without compromising the security of data defined for other.
While the concept is intriguing to many SaaS developers, a full-featured, multi-tenant-aware framework hasn't emerged in the cloud computing world yet. Hibernate -- being a widely used Java ORM tool -- provides some of the features required to implement multi-tenant cloud architecture but not all (more are slated for its forthcoming version). Until then, without specific API support, let's see how you can leverage the limited Hibernate support to implement a multi-tenant cloud architecture.
This article first gives an overview of multi-tenancy in the cloud and then explains how you can use Hibernate to implement that architecture.
Multi-tenant Cloud Architecture and Database Design
The two main considerations for a multi-tenant cloud architecture are the structure of the schema/database and the method for storing the record. There are three approaches for implementing multi-tenant cloud architecture through database design:
- Multiple-tenant, multiple database: In this approach each tenant has their own physical database instance.
- Shared database, multiple schema per tenant: In this approach all tenants share a physical database but have an individual schema or catalog within the database instance.
- Shared database, shared schema: In this approach every tenant shares a single table to hold its data. Each tenant's data is uniquely identified by a discriminator value called tenant-id.
Each of the models above has its own advantages and disadvantages, but models 1 and 2 arguably do not adhere to the concept of multi-tenant cloud architecture at all. In particular, model 2 provides only a portion of multi-tenant cloud architecture features. That leaves model 3 as the best option.
Multi-tenancy with Hibernate
In Hibernate, you can implement model 3 in the following two ways, each with its own benefits and shortcomings.
- Multi-tenant cloud architecture based on separate schema
- The problem of selecting a unique key does not arise.
- Any ID can be unanimously selected as the primary key of the table.
- A custom ConnectionProvider enables you to route calls to the correct JDBC connection.
- This approach is unsafe with second-level cache.
- Applications are not aware of tenant-id.
- Database backup would be easy (for each tenant separately).
- Discriminator-based multi-tenant cloud architecture
- A particular field in a database table called tenant ID is used to uniquely identify a tuple.
- By this ID, you know which row belongs to which tenant.
- Applications have to make sure that only relevant rows of the database are filtered out while manipulating data through query.
- The problem of selecting a unique key arises.
- This approach is safe with second-level cache.
- Database backup would be difficult if not impossible (for each tenant separately).