Data Management and Scalability
Each loaded scenario holds an independent (compressed) copy of the input data, and each executed scenario holds an independent copy of the results. For very large models, performance can be improved by removing any entities from the schema that do not strictly need to be persisted. The
Insight type hint for the corresponding entity element should be removed from the class definition.
For the input data, this would include input data that does not change from scenario to scenario. Such input data could be loaded from a model resource or a data source during the
RUN mode of model execution. The
Insight type hints for the entities in this fixed data should be removed from the class definition.
![]() |
Note Class attributes without
Insight type hints are not persisted or made available to a client through the server API. This drawback can be remedied by calculating in the model useful aggregated metrics from the fixed data and recording these in the results data.
|
Depending on the requirements of the application, it may be possible to improve the performance for handling large volumes of results data by persisting calculated metrics rather than the results data in its entirety. It is possible to engineer the model to make the selection between persisting metrics or the full results data based on a runtime parameter that could be set per scenario.
Optionally, the actual results attributes could be excluded from the result data by initializing the corresponding result entities as empty data structures, or they could be included by copying them to the corresponding result entities. If the copy step is skipped, then the empty entities will occupy negligible space for most scenarios.