Database growth estimation

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Automation Server requirements > Performance and optimization >

Database growth estimation

Overview

Automation Server executes your processes and delivers them to the desktops and mobiles of every business user.

For introductory information about Automation Server, refer to Automation Server.

 

The information presented here provides a quick reference, regarding database growth estimation according to a Bizagi project's specifics.

The following case study presents results based on a specific scenario; such exercise applies for on-premises Bizagi projects.

 

System characteristics

The specifications of the system used for this reference are:

Bizagi version: 11.1.X or higher.

SQL Server 2008 SP3 (10.0.5500.0).

 

Scenario specification

The process used the test is the Purchase Process as available and downloadable from Bizagi's Process Xchange.

 

Process and case scenario

The diagram of this process is shown in the following image.

 

se_01

 

As it can be evidenced in the image, the Purchase Request process contains two sub-processes: Quotations and Purchase Order.

For a complete picture of the process from start to end, it is necessary to take a look at the following sub-processes diagrams.

 

The Quotations sub-process:

 

se_02

 

The Purchase Order sub-process:

 

se_03

 

The path taken as sample for this process, goes from the Start event to the End event without passing through loops or alternative sequence flows.

The same path is executed over and over by each of the multiple cases.

Such path consists of the execution of the following 8 tasks in this particular order:

Create Purchase Request.

Authorize Request.

Notify approval.

Quotations > Request Quotations.

Quotations > Select Supplier.

Purchase Orders > Create Purchase Order.

Purchase Orders > Send Purchase Order to Supplier.

Purchase Orders > Generate Order and sent to ERP.

 

The following image illustrates the path taken for this example, as viewed from the process level (Purchase Request):

 

se_05

 

The execution flow of the Purchase Order sub-process can be evidenced in the following image:

 

se_06

 

Data model specification

The data model of Purchase Request is depicted in the image below.

Information is written into attributes of Master entities only (those 4 shown in a blue color in its header).

 

se_04

 

As mentioned above, not all attributes shown are assigned with new values (either through an insert or an update). Those marked with a red dot are used in this case scenario.

The following table indicates the list of attributes that are considered by the cases' path, and to which entity they belong:

 

Entity (Master type)

Attribute

Attribute type

Products Requested for Purchase

Description

String

Quantity

Integer

Units

Integer

Unit Price

Currency

Total Price

Currency

Purchase Request

Reference to another entity (Integer)

Purchase Approval

Approval date

Date

Approved

Boolean

Approval user

Reference to another entity (Integer)

Purchase Request

Reference to another entity (Integer)

Purchase Order

Order date

Date

Order number

Integer

Payment term

Reference to another entity (Integer)

Payment option

Reference to another entity (Integer)

ERP Purchase Order Number

Integer

Purchase Request

Requested by

Reference to another entity (Integer)

Request date

Date

Purchase Justification

String

Requires approval for Products/Services

Boolean

Delivery Address

String

Required delivery date

String

Request state

Reference to another entity (Integer)

Request state observation

String

Purchase Observations

String

City

Reference to another entity (Integer)

Cost center

Reference to another entity (Integer)

Quotation

Quotation Cost

Currency

Delivery date

Date

Discount

Currency

Unit Price

Currency

Total Price

Currency

Use only selected quotations

Boolean

Quality Score

Integer

Selected

Boolean

Supplier

Reference to another entity (Integer)

Purchase Request

Reference to another entity (Integer)

 

For all business attributes above, information was recorded only once, except for those in the Quotation entity.

For the Quotation entity, given that it was designed as a collection for this data model, two records were added.

This means that the total number of writes into business attributes can be calculated as:

6 attributes from Products Requested for Purchase + 4 attributes from Purchase Approval + 5 attributes from Purchase Order  + 11 attributes from Purchase Request + 10 attributes from Quotation twice (one per row of the table).

These adds up to a total of 41 writes into business attributes.

 

File attachments are not considered by the exercise presented here.

By default, Bizagi stores file attachments in a file server of yours.

 

 

Results

The following table displays database growth results after executing the case certain amount of times.

 

Number of executed cases

Data .mdf file size (KB)

Log .ldf file size (KB)

Total database storage size (KB)

0

32000

22144

54144

10000

474368

164672

639040

100000

4193536

199296

4392832

 

For additional reference, note that a completely blank Bizagi project, has:

Total database storage size: 19648 KB.

Data file size: 9472 KB.

Log file size: 10176 KB.

In other words, an empty project (with no data model, no processes and no information on its database) occupies 19648 KB or 19.2 MB.

Consider that you may choose to partition the Bizagi database in a way that different tables are stored in different files (.mdf, .ldf). This choice is left up to the DBA's consideration and it will not affect this analysis, given that what is suggested in these cases, is to simply separate parameter entities from master entities.

 

The following chart represents the data .mdf file size according to the amount of cases:

 

DBGrowth_mdf

 

The following chart represents the data .ldf file size according to the amount of cases:

 

DBGrowth_log

 

The following chart represents the total database storage size according to the amount of cases:

 

DBGrowth_total

 

Average file size per case

Based on the results presented above, in average, each case having the characteristics of this particular exercise, occupies:

Total database storage size: 52.3 KB.

Data file size: 42.92 KB.

Log file size: 8.01 KB.

 

Calculations were made by: first gathering the size occupied for each amount of cases, while first subtracting that initial size of the process model (when there were zero cases); and then dividing that resulting size between the amount of cases.