Multi-tenancy
The
term multi-tenancy in general is applied to software development to indicate an
architecture in which a single running instance of an application
simultaneously serves multiple clients (tenants). This is highly common in SaaS
solutions.
Data
Multi-tenancy
Isolating information (data,
customizations, etc) pertaining to the various tenants is a particular
challenge in these systems. This includes the data owned by each tenant stored
in the database. It is this last piece, sometimes called multi-tenant data, on
which we will focus.
Multi-tenant
data approaches
There are 3 main approaches to
isolating information in these multi-tenant systems which goes hand-in-hand
with different database schema definitions and JDBC setups. Each approach has
pros and cons as well as specific techniques and considerations. Multi-TenantData Architecture does a great job of covering these topics.
Separate
database
Each tenant's data is kept in a
physically separate database instance. JDBC Connections would point
specifically to each database, so any pooling would be per-tenant. A general
application approach here would be to define a JDBC Connection pool per-tenant and
to select the pool to use based on the“tenant identifier” associated with the currently logged in user.
Separate
schema
Each tenant's data is kept in a
distinct database schema on a single database instance. There are 2 different
ways to define JDBC Connections here:
- Connections could point specifically to each
schema, as we saw with the Separate
databaseapproach. This is an option provided that the
driver supports naming the default schema in the connection URL or if the
pooling mechanism supports naming a schema to use for its Connections.
Using this approach, we would have a distinct JDBC Connection pool
per-tenant where the pool to use would be selected based on the “tenant identifier” associated with the currently logged in user.
- Connections could point to the database itself
(using some default schema) but the Connections would be altered using the
SQL SET
SCHEMA (or similar) command. Using this approach, we would have a single
JDBC Connection pool for use to service all tenants, but before using the
Connection it would be altered to reference the schema named by the “tenant identifier” associated with the currently logged in user.
Partitioned
(discriminator) data
All data is kept in a single database
schema. The data for each tenant is partitioned by the use of partition value
or discriminator. The complexity of this discriminator might range from a
simple column value to a complex SQL formula. Again, this approach would use a
single Connection pool to service all tenants. However, in this approach the
application needs to alter each and every SQL statement sent to the database to
reference the “tenant
identifier” discriminator.
Data
Multi-tenancy in Hibernate
Using Hibernate with multi-tenant
data comes down to both an API and then integration piece(s). As usual
Hibernate strives to keep the API simple and isolated from any underlying
integration complexities. The API is really just defined by passing the tenant
identifier as part of opening any session.
Example 16.1. Specifying tenant identifier
from SessionFactory
Session session = sessionFactory.withOptions()
.tenantIdentifier( yourTenantIdentifier )
...
.openSession();
Additionally, when specifying
configuration, a org.hibernate.MultiTenancyStrategy should
be named using the hibernate.multiTenancy setting.
Hibernate will perform validations based on the type of strategy you specify.
The strategy here correlates to the isolation approach discussed above.
NONE
(the default) No multi-tenancy is expected. In
fact, it is considered an error if a tenant identifier is specified when
opening a session using this strategy
SCHEMA
Correlates to the separate schema approach. It is
an error to attempt to open a session without a tenant identifier using this
strategy. Additionally, aorg.hibernate.service.jdbc.connections.spi.MultiTenantConnectionProvider must
be specified.
DATABASE
Correlates to the separate database approach. It is
an error to attempt to open a session without a tenant identifier using this
strategy. Additionally, aorg.hibernate.service.jdbc.connections.spi.MultiTenantConnectionProvider must
be specified.
DISCRIMINATOR
Correlates to the partitioned (discriminator)
approach. It is an error to attempt to open a session without a tenant
identifier using this strategy. This strategy is not yet implemented in
Hibernate as of 4.0 and 4.1. Its support is planned for 5.0.
No comments:
Post a Comment