Liferay Database Architecture

In this article, I will share the database architecture of liferay portal along with various deployment strategies of database server with liferay portal.

Liferay is open source portal and provides high degree of flexibility in terms of development and implementation based on our requirements. Liferay portal can connect to single database or multiple databases in a clustered environment.

Liferay portal can connect / run on different types of databases like db2, derby, hypersonic, ingres, mysql, oracle, postgresql, sqlserver, Sybase and provides the OOTB properties to be defined in the portal-ext.properties file.

Liferay stores all of its data related to OOTB features in the database and provides a flexibility to connect with the different tables for our custom plugin. In the next article I will explain how to connect / store custom plugin data in the different database.

Let’s go through the 2 database deployment strategies (Sharding, RW) for liferay portal as mentioned below:-

1)    Database Sharding – The concept of Database Sharding has been gaining popularity over the past several years, due to the enormous growth in transaction volume and size of business application databases.

In simple terms the database sharding can be defined as “Shared Nothing” for large database to improve performance & scalability of the applications. The basic concept of Database Sharding is very simple i.e. take a large database, and break it into a number of smaller databases across servers. The concept is illustrated in the following diagram:

 Database Sharding

Liferay Portal can be used to host multiple portals within the same portal server using Portal Instances (Companies). By default, Liferay Portal stores data of all the instances in the same database. After some time it will have impact on performance as liferay will store all data from multiple instance in same database and table will grow rapidly. For example: If any request comes then portal will scan the data of all the instances. In order to improve the performance then we can configure multiple database shards and can define the algorithm for selecting the shards.

Each portal instance will be mapped to a specific shard database. By implementing this mechanism, data from multiple instances will be distributed in multiple databases. Liferay by default supports only 3 shards but if your requirements ask for more shards then provide shard-data-source-spring.xml and do the configuration in the portal-ext.properties.

 

 

 

Now let’s go through the steps to configure the database shardings:-


1. Append the following property in portal-ext.properties to enable database sharding:

spring.configs = < Existing config files >, META-INF/ shard-data-source-spring.xml

2. Configure database shards by adding the following properties in portal-ext.properties:

#Shard 1

jdbc.default.driverClassName =< Database Driver Class Name for shard 1 >

jdbc.default.url = < Database JDBC URL for shard 1 >

jdbc.default.username =< Database User Name for shard 1 >

jdbc.default.password =< Database Password for shard 1 >

#Shard 2

jdbc.one.driverClassName =< Database Driver Class Name for shard 2 >

jdbc.one.url = < Database JDBC URL for shard 2 >

jdbc.one.username = < Database User Name for shard 2 >

jdbc.one.password = < Database Password for shard 2 >

#shard 3

jdbc.two.driverClassName =< Database Driver Class Name for shard 3 >

jdbc.two.url = < Database JDBC URL for shard 3 >

jdbc.two.username = < Database User Name for shard 3 >

jdbc.two.password = < Database Password for shard 3 >

By default, shards will be assigned to each portal instance based on the round ribbon algorithm. Liferay also supports the manual selection algorithm.

To enable the manual shard selection algorithm, we need to add the following property in portal-ext.properties:

shard.selector = com.liferay.portal.dao.shard.ManualShardSelector

 

2)    Read / Write Database – This approach is very important in order to improve the performance of the applications which has many transactions with large number of concurrent users. It is the right architecture approach to separate the Read & Write database and in this situation all the Write operations will be performed on write database and read operations on read only database.

Liferay has built in database replication mechanism so that all the data from write database will be replicated to read database in order to improve performance.

Liferay Portal supports configuring read and write databases through portal-ext.properties:

1. Add the below entry:-

spring.configs = < Existing config files >, META-INF/ dynamic-data-source-spring.xml

2. Add the following properties to portal-ext.properties to configure the read database:

jdbc.read.driverClassName =< Read Database Driver Class Name >

jdbc.read.url = < Read Database JDBC URL >

jdbc.read.username = < Read Database User Name >

jdbc.read.password = < Read Database Password >

 3. Add the following properties to portal-ext.properties to configure the write database:

jdbc.write.driverClassName =< Read Database Driver Class Name >

jdbc.write.url = < Read Database JDBC URL >

jdbc.write.username = < Read Database User Name >

jdbc.write.password = < Read Database Password >

Note:- If the datasource are configured through JNDI then update the portal-ext accordingly like jdbc.read.jndi & jdbc.write.jndi.