Split Database for Better Performance

Gladinet Cloud Enterprise (GCE) is an Enterprise File Sync, Share, and Collaboration solution.  During POC (Proof of Concept) stage and early production stage, it probably doesn’t matter how the configuration information and runtime data is stored. However, as more and more users are getting onto the system. We need to start thinking about split the database for better performance and adding worker nodes for load balance.

Two Types of Traffic

GCE database is one of the most critical components of the GCE platform as it contains two distinct type of data. The first type is static which includes for example username, email, and the user’s published shared files and folders. This type of data is relatively small and can be estimated at 5000 bytes per user. Therefore, for a 2000 user implementation, the database size for this static data can be estimated at 10 MB.


The second type of data is volatile for example; file change log, audit trace, and the file list. The database size for this type of information which includes for example 100 file changes per user in a single day and each file change can be estimated at 1000 bytes for database storage is much larger. For example for a 15 day period (the default change log history) it can be estimated at 100x1000x15 = 1.5 MB per user for an upper limit estimation. For HIPPA compliancy the default change log history can be much longer. Therefore, the database size for the volatile data is much larger than the static information.

 

To use an analogy, it is like highway with lanes in two different directions, it is better to keep them separated. For performance and regulatory reasons, it is recommended splitting the database into two separate databases, one for static data and the other one for volatile data.
The secondary database for volatile data can either be MySQL or SQL database.  Before the only option to split the database was to add the connection strings in ‘web.config’ file which is typically located under C:\Program Files (x86)\Gladinet Cloud Enterprise\root.

New Setting

Now, a new setting ‘Logging DB Connection String:’ has been added under Cluster Settings\Settings which can be used to configure the secondary database which will hold volatile data.

image

MySQL Connection String Format

Use the following string format for MySQL connection string:

Server=localhost;Database=gladinet;Uid=root;Pwd=password;

Where,

‘localhost’ = MySQL Server name

‘gladinet’ = GCE database name

SQL Connection String Format

Data Source=server_name;Initial Catalog=logging_db_name;User Id=user_id;Password=user_password;

Where,

Server_name = SQL Server name

Logging_db_name = logging db name

image

 

For more information, contact support@gladinet.com or visit http://www.gladinet.com for the enterprise section.

Comments

Popular posts from this blog

7 Biggest Limitations of SharePoint Online And How to Fix Them

5 Reasons CentreStack's File Server Mobilization Beats File Server Migration

Access and Backup to HP Cloud Storage