Forum Discussion

100Rub's avatar
100Rub
New Contributor III
7 months ago

Data unit calculation

Hi all,

How do we calculate Data Unit in OneStream ? I know that the largest Data Units should never be above 2-3 million intersections. The sweet spot for OneStream is between 250,000 and 500,000 records. But what can be the maximum possible records in the given example we can have to avoid performance issue in OneStream ? Please consider these dimensions in OneStream.

Thanks

  • Henning's avatar
    Henning
    Valued Contributor II

    Hi, you can check the number of data records in a data unit using System Diagnostics (OSD) from the solution exchange. Create an app snapshot and then check the report that shows the largest data units in the app.

    As I understand you are still in development, so at this stage, the number of data units can only be based on an (educated) estimate. E.g. how much data do you intend to load per period for a given scenario into the entity (provided you use the entity dimension for entities)? Or get some test extract from your ERP and perform some test loads using the entities that are likely to hold most data records. Also, do not forget that loaded data just gives you a rough first indication of the number in your data units. The data is calculated, allocated, transformed, aggregated etc., which can multiply the number of records in a data unit. And, extensibility should be applied in a reasonable way to ensure that the top members in the entity dimension do not end up with massive data units.

    Remember, the data unit is defined by the combination of the following dimensions: Cube, Parent, Entity, Scenario, Consolidation and Time. 

    Your implementation partner should be able to help you with this.

  • Cosimo's avatar
    Cosimo
    Contributor II

    Replying here instead of direct PM since it's the same question.

    As Henning stated, you will only get a good feel on the # of records in a data unit by performing an import. Trying to size based on multiplying # of members in each dimension is impractical as it is unlikely that you will have values for every possible combination of members from each dimension. 

    And to add to what Henning stated, there are more than a few dimensions that you shouldn't use for attempting to calculate the max possible # of records. From your table, I would remove Scenario, Entity, Consolidation, View, Year & period (assumed same time dimension) and Currency (assumed it's handled in Cons dimension).