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.
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.
MySQL Connection String Format
Use the following string format for MySQL connection string:
‘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;
Server_name = SQL Server name
Logging_db_name = logging db name