How to calculate Anaplan model size?

karank_*4578

Hi Guys

I am using below calculation to find model size

1000000000 cells = 9.3 GB

1 cell = 9.3/1000000000

Total cells exported from module export =

6206436639

which gives me

57.71986074 GB's

problem is Anaplan shows model size as 39.29 Gb's ?. I have used this calculation on 8 models and all of these comes close to model size shown in Anaplan , just this one doesn't work .

Ps:- i also tried doing the calc by line item type and cell count by data type but still its way out like above 10 GB's out .

I have attached an excel sheet as well with actual cells extract

any idea ?

Model_Size_52666.xls

Accepted answers

DavidSmith

@karank

You can't really use ratio metrics for cells to GB, it's too variable

The sizing is as follows for any line item or list property. The "cell count" for properties will be the number of members in the list (including subsets)

Boolean = 1b

List, Time, Date formatted = 4b

Number and Text = 8b

As @usman.zia said each list item = 500b (including the name and code properties)

You also need to account for subsets = these also count as list members too, so 1m items and 2 subsets of 500k each = 2m

Finally you need to throw switchover into the mix. This can reduce model cell count too as the "actual" periods are not counted

I hope that helps

David

All comments

usman.zia

Hi @karank

To quote Michael Gould:

Each list item carries a memory allocation of 500 bytes per item. This is an estimate to allow for the item name, item code, parent and other built-in properties, along with internal indexing that is needed to give efficient look-ups. Custom properties are additional to this - the size for custom properties is calculated as if they were a 1-dimensional line item.

Source:

https://community.anaplan.com/t5/Anaplan-Platform-Discussions/Model-sizing/m-p/1177#M1985

So it could be that your model is extremely slim on list item properties?

Also I have seen someone else quote a lower number of 0.0000000074126 as @Alessio_Pagliano mentioned on the link above also.

I hope this helps,

Usman

DavidSmith

@karank

You can't really use ratio metrics for cells to GB, it's too variable

The sizing is as follows for any line item or list property. The "cell count" for properties will be the number of members in the list (including subsets)

Boolean = 1b

List, Time, Date formatted = 4b

Number and Text = 8b

As @usman.zia said each list item = 500b (including the name and code properties)

You also need to account for subsets = these also count as list members too, so 1m items and 2 subsets of 500k each = 2m

Finally you need to throw switchover into the mix. This can reduce model cell count too as the "actual" periods are not counted

I hope that helps

David

Alessio_Pagliano

Spot on @usman.zia ,

Generally speaking model size could be estimated with cell size only but if you want to be precise or have massive lists/properties you then need to consider them accordingly. This is probably why you might come across some exceptions

PS Do you need properties as opposed to system modules ? (re: best practices)

Thanks,

Alessio

karank_*4578

Thanks guys

I tried same calc on 8 different models including this and it works on 7 . Close enough considering its estimate .

Out of these 7 one model is actually a dev copy of the same model on which it doesnt work ???? . i am using Alm and models are syncd . how can i get such huge cell count difference but model sizes are same ?

Misbah

@karank

One of the reasons can be the number of list items as they don't add to the cell count but do occupy space (500 bytes per item). Same holds good for the number of items within each subset that you have across all lists-these also don't give you the cell count but eats up your space.

Thanks,

Misbah

DavidSmith

@Misbah

Just to clarify, List Properties DO add to the cell count, it is just that the cells are not visible in the grid page of the list

List Properties = Line items for size and performance. Think of them as interchangeable

David

Misbah

@DavidSmith

Absolutely, I meant to say that cells are not visible in the grid and size of the model can't be estimated based on the number of cells that an Anaplanner sees. As you rightly mentioned earlier, that size and cell count doesn't go hand in hand.

Thanks,

Misbah

@DavidSmith

Also List Properties DO add to the cell count and ARE visible in the grid. Its about List items and number of items within the subsets of each list that doesn't go to the Visible Cell Grid.

Thanks,

Misbah

Damian_Broj_oldaccount

As all other mentioned- analyzing only the cell count on module list would never give you exact answer on the model size. There are some other elements that increase it's size- mostly list related ones. To calculate everything accurately you would need to analyze your modules one by one taking into consideration the data types plus calculating the same for all lists etc. The question is what is the reason behind your calculation? Are you trying to optimize your model or just confirm that the calculation of size is valid?

karank_*4578

@Damian_Broj_oldaccount My client has a requirement to track model size and some other KPI's on daily bases. I have an Anaplan model which keeps track of all other model cell counts on daily bases . I have tried it couple of ways on 8 models across multiple workspaces

1 - Using the suggested method i.e get each line item cell count and data type and get the bytes and convert to GBs

Result :- 7 out of 8 models are way off with GB's displayed on Anaplan . Only 1 model comes very close .

2- Using the approximation method . I.e 1000000000 cells = 9.3 GB

Result :- 7 out of 8 models are very close only one 1 model is way off . Interestingly 1 that is off is the one which works with approach 1

May be i need to convince my client to analyse model size on cell counts rather than Gb's since there is no way to find the gap cell/space which comes from line items within Anaplan

DavidSmith

As we’ve said previously, you can’t use cells to Gb. That does not account for the Gb that lists and their subsets take up.
I’ve been sizing a few models recently and when I use 500b per list item I’m only slightly off. I found that if I used 93% of the 500b for the lists, I was spot on. That worked for a 52gb model just as for a 2gb model
David

karank_*4578

@DavidSmith i get that but cells ->bytes -> GB's does not give me what Anaplan shows as model size . For it to work i have to do some approximation as you highlighted above . So if both methods are approximation i am getting better results with second one with much easier calculations.

Perhaps we can have a way to show exact results size by items in Anaplan to take the guess work out of it altogether one day . This might be handy especially considering clients pay by space for Anaplan .

DavidSmith

@karank

I'm not sure if this will help, but I've attached the sizing spreadsheet I use. As I mentioned, this is pretty accurate.

I tend to use the "error" % to get the totals correct to what is shown in the model, and then use the increase row tot flex the sizing for what-ifs. Certainly, that is pretty close to what I actually see when the lists are increased.

Also, the "error" was pretty consistent initially for different sized models

I hope that helps

David

WS_Sizing_52964.xlsx

James.sharrett

@DavidSmith in your model calculator, you don't account for time in your calculations. Example scenario:

Customers = 21000
Sales People = 307
Product Types = 9
Line item (numeric) = 1

give 58,023,000

If I put those in a module to track sales by customer, sales person and product type by day and the model has two years doesn't this result in:

58,023,000 * 365 * 2 = 42,356,790,000 cell * 0.000000009313 = 394.5 GB

Misbah

@James.sharrett

Yes, Time should be part of it and if your timescale is daily then your model size will be more than 315GB.

However you are not adding the size that list items take up i.e., (21000*500 Bytes) + (307*500 Bytes) + (9*500) - It won't add up that much but it definitely is one of the reasons that your model size grow when your lists grow

58,023,000 *365*2 *8 =

338,854,320,000

which is roughly equal to 316 GB

Thanks,

Misbah

DavidSmith

@James.sharrett

The example I attached was from a model without time or versions in it.

The principle still applies, for modules, you need to cell count * line item format

There will always be a small correction error, as per my spreadsheet.

What I was highlighting is the impact large lists have; one should not forget those in the estimations

David

James.sharrett

Thanks David.

JLD

Hi David,
Did list property with formula and without formula differ in size?

Thanks,
Jud

agpolestar

Hi

The error is due to the conversion factor being used. In essential, the Bytes to GB conversion should use (1024*1024*1024 = 1073741824).

If this number is compared with 1 billion, one can calculate the deviation is 93%.

Best

Ankit

kglearn

With the example below, if I had one sales person assigned to a customer, and I wanted to remove sparsity and merged these, I am confused how this impacts the size. Do these counts include parents? I assume that if I has sales people with customer under them, my count would be 210307, so my cell count would go from 8,023,000 to 1,892,763. If I have 5 accounts (numeric line items), do I multiply 1,892,763 by 5?

I this correct?

Customers = 21000
Sales People = 307
Product Types = 9
Line item (numeric) = 1

58,023,000 * 365 * 2 = 42,356,790,000 cell * 0.000000009313 = 394.5 GB

Irish

Try looking at your Line Item subsets, List Subsets and Subsdiary views. This may create the difference.

Email me on yash.crushna2601@outlook.com

Lolen

There is an answer

Quick Links

Can you help?

Unanswered questions

Excel date format for February 2030, 2031 and so forth don't align with Anaplan format
Hello, I’m running into a recurring issue when importing CSV files into Anaplan, specifically with dates in February for the years 2028, 2029, and beyond. Here’s what’s happening: In Excel, the date format is set to Custom (e.g., 2/26/2025). When imported into Anaplan, the date is interpreted as 26-Feb, where: Month = Feb…
RANKCUMULATE not working when adding additional dimensions to module
I have an issue where I am getting the expected result from RANKCUMULATE when using one dimension, but when I add an additional scenario dimension to the module, it doesn't calculate the way I'd expect. Here are some screenshots to explain the case: Module 1 - calculates cumulative total for list items in list "Age"…
Introducing Anaplan API Python SDK
Hey everyone, I wanted to share the Anaplan Python SDK with you. It's a Python Library that wraps all Anaplan APIs and makes it easier to interact with Anaplan programmatically. It is mostly designed with Data Integration Scenarios in mind, but it does support all APIs including ALM, SCIM, Audit, and Cloud Works. Please…