Separate Application for Consolidation and Planning
Hi All,
Does anyone have the Consolidation and Planning in separate applications?
If so, what are the reasons for having them separate or what are the challenges.
Forum Discussion
Multiple reasons-
Huge data size, millions of records added every period.
Longer processing times on the SQL DB
For file based loads, one app ha sonly one harvest folder, this has been an issue as well.
Larger Data Units
Scalability issues, Performance issues when Consolidations and Planning tasks are running in parallel.
I believe even in OneStream book, they give an example of retail company with data volumes in millions of records and how splitting the application is recommended. I understand its theoretical but we do not see any benefits of having them both together in our current setup.
Also, we do not see any extensibility really being used.
I have few more factors as well, happy to discuss if anyone has really done the split or considered doing it.
RamuV wrote:
Larger Data Units [...]
Also, we do not see any extensibility really being used.
I'm sure the other problems are real, but this is typically the root of most performance issues. Using extensibility properly, one should be able to split data across cubes and scenario types in ways that will keep DUs small and performance snappy (assuming decent rules). There is nothing linking the size of DUs in an Actual scenario to the size of DUs in a Planning scenario in a different Cube. The data tables will get big, but then it's kinda of a SQL Server problem that can be dealt with.
My fear is that the number of records will likely continue to be an issue even when splitting apps, OneStream is not an ERP. I would check whether those records might be a result of excessive explosion during import or calculation, and if there are ways to aggregate some of them through BiBlend instead (pre-cube-load, or even leaving them outside the cube altogether). If the problem is the volume of data, splitting apps is likely not a long-term solution.