Hibernate framework-based database fragmentation for SaaS applications

Hibernate Framework-based database fragmentation for SaaS applications

SaaS is changing the way you design, build, deploy, and manipulate your applications. The key difference between developing a SaaS application and developing a generic enterprise application is that SaaS applications must be multi-tenant. Other key SaaS requirements, such as security, customization, service-oriented architecture (SOA), and integration, also affect the SaaS application architecture.

Multi-Tenant refers to the ability of an application to host multiple tenants and share databases within a single code base. There are a variety of design options to enable a multi-tenant data schema-a private database for each tenant, a shared database-independent mode for each tenant, and a fragmented database sharing pattern for all tenants. A cost-effective strategy is to adopt a shared database and shared-mode strategy for all tenants. This approach poses a major challenge to database scaling because the database is shared among all the tenants supported by the SaaS application. A simple method is to extend the shared database horizontally based on the tenant ID and through the database fragmentation.

Database fragmentation refers to the horizontal partitioning of a database, where each partition is called a fragment. There are some open source and proprietary software, such as Hibernate shards, Apache Slice, SQLAlchemy ORM and dbshards, to provide fragmentation capabilities. In this paper, Hibernate is used as the most common ORM framework in Java EE space. We will use the Hibernate shards (an extension of Hibernate) to solve the database extension problem for SaaS applications and to provide fragmented functionality to Hibernate users.

Database fragmentation for SaaS applications

The SaaS application employs a shared database, shared pattern, and is designed to be scalable when it no longer meets basic performance metrics-for example, when too many users try to access the database at the same time, or the size of the database causes the query and update to execute too long. One way to extend a shared database horizontally is to fragment the database. This is the most efficient way to extend a database horizontally, because the rows in a shared pattern are different for different tenants depending on the tenant ID. You can easily partition a database horizontally based on the tenant ID. This facilitates the movement of data belonging to each tenant to a single partition.

In data partitioning for multi-tenant SaaS applications, we need to consider factors such as performance degradation due to the increased number of concurrent users, or increased database size due to the configuration of multiple tenants, affecting the performance characteristics of existing databases. This will help you choose the right partitioning technology based on the individual tenant's database size requirements or the number of users who simultaneously access the database's individual tenant. Database fragmentation offers many advantages, such as faster read and write to the database, improved search responses, smaller table sizes, and on-demand for tables.

Hibernate database fragmentation can be used to build SaaS applications that adopt other multi-tenant data schema options, such as a dedicated database for each tenant, or a shared database-independent mode for each tenant. Hibernate database fragmentation can be extracted from the application code that is connected to multiple databases based on the tenant environment by providing metadata configuration and an API partition that handles the operation of inserting data and reading data from multiple databases based on the tenant environment.

Implementing partitions using Hibernate shards

Hibernate Shards is a framework designed to encapsulate and minimize this complexity by adding horizontal partitioning support to the Hibernate Core. It minimizes the implementation complexity of processing fragmented data. The main goal of Hibernate shards is to have applications query and process shared data sets using standard Hibernate Core APIs. This approach has the following advantages:

Provides non-intrusive solutions to support database fragmentation while building existing SaaS applications using Hibernate.

Allow SaaS applications that use Hibernate, but do not need to be fragmented, to adopt solutions without significant refactoring, provided they do reach this stage.

Hibernate Shards offers:

Hibernate Core provides fragmentation-aware interface extensions, so the code does not need to know that it is interacting with a fragmented dataset. The fragmentation-aware extensions that act as fragmentation engines are as follows:

Org.hibernate.shards.ShardedSessionFactory

Org.hibernate.shards.criteria.ShardedCriteria

Org.hibernate.shards.session.ShardedSession

Org.hibernate.shards.query.ShardedQuery

An interface that implements application-specific fragmentation policies. The fragment engine described above uses the partitioning strategy provided by the application.

Org.hibernate.shards.strategy.access.shardaccessstrategy-through this policy, hibernate determines how database operations can be applied across multiple fragments. The policy is referenced every time the query is executed. Two default implementations Sequentialshardaccessstrategy and Parallelshardaccessstrategy have been provided.

org.hibernate.shards.strategy.resolution.shardresolutionstrategy-This policy is used to determine the set of fragments that the object of the given ID is located in. Fragmentation resolution is associated with ID generation, and Hibernate provides multiple strategies for ID generation, such as local, application-level UUID generation, and distributed Hilo generation.

org.hibernate.shards.strategy.selection.shardselectionstrategy-This policy allows us to determine the fragment where the new object is created. Based on the requirements of the application, we decide the implementation of the interface. Although Hibernate initially provides an out-of-the-box loop implementation, we need to provide an implementation based on the tenant ID for SaaS based applications.