In my last post, I discussed how to handle usage data and the large volume of data it entails. In this post I’ll walk through how and why to split an object if it has grown too large.

Typically when we think about large objects we think about them having too many rows. A less common scenario is having many rows and also many columns. Having a very wide table can make reporting on that object slower than it would be based on the high number of rows alone.

One solution in this scenario is to split the object into two.

When is this necessary?

If an object gets too large, you may see that:

• Rules are timing out and thus failing. (Note that this could be due to an issue with a rule, not the volume of the object)
• Reporting is slow or times out.

What is the goal?
The goal is to break up an object into two separate objects. You can split up an object by rows or by columns.
Why split an object by rows?

• You have a high number of rows, and the rows can be logically divided

OR

• Your object contains a subset of data that will be reported on much more frequently than the rest of the data. For example, the data from the current year versus historical data.

Why split an object by columns?

• You have a high number of columns in the object
• Some of your columns are rich text, storing a lot of data
• Some of the columns are infrequently populated or infrequently referenced

What are the basic steps?
Split by Columns:

1. You can discuss internally to find which columns are least important to your CS Ops. You can also create a report using the Count function to see which columns most often have a value populated.
2. In Data Management, use the Dependencies tab to check where the columns in your object are being used. You’ll want to make note of any updates that will be needed after your changes are made.
3. Create a Rule to populate the new object with the columns that you want to remove from the original object.
4. Remove dependencies from the columns you want to remove. Then delete those columns from the original object.
5. Update any reports or rules that will be affected by this change.

Split by Rows:

1. In Data Management, use the Dependencies tab to check where the data in this object is being used. You’ll want to consider the impacts of splitting your object.
2. Create a Rule to populate the new object with the rows that you want to remove from the original object.
3. Delete those rows from the original object.
4. Update any reports or rules that will be affected by this change.
5. If the object was split into current and historical objects, you will want to repeat this process at regular intervals.

What are some considerations with this approach?

• Minor changes are unlikely to have an impact on performance. In order to see results, you need to make large scale changes.
• Some large updates/deletions may require help or monitoring from the Gainsight engineering team. You can open a support ticket to confirm.
• Low volume objects can only lookup to low volume objects, and high volume objects can only lookup to high volume objects.