Cache partitioning
As the number of partitions increases, the value of adding additional partitions rapidly diminishes. For example, adding partition 101 to 100 partitions would only change the average amount of data by 1/10,000 the of the total cube size. However, the overhead per partition is constant. We recommend you use this feature with a small dimension. The maximum number of elements is 256. If the partition dimension contains too many elements, cache partitioning is disabled, and a message is written to the log.
This is set by the Alea:CachePartitionDimension
property. Either on the Edit Database
dashboard or with the Cube PutProperties function.
In some cases, more than one cube must be properly partitioned.
Example: Partitioning the Version dimension of a planning cube
You have a cube with a dimension that contains two versions, Actual and Budget. The data for Actual (previous time periods) is already imported and is read-only. The aggregated values are only calculated once. The budget data is constantly updated as it is entered by users. If there is no partition, the aggregated actual data must be recalculated each time budget data is entered. Partitioning the cache on the Version dimension allows the cached actual data to be maintained while the budgeting data changes.
Request
<Alea:Document xmlns:Alea="http://www.misag.com">
<Alea:Request RequestID="42" Class="Cube" Method="PutProperties">
<Alea:Cube Name="Sales">
<Alea:Properties>
<Alea:CachePartitionDimension Name="Version" />
</Alea:Properties>
</Alea:Cube>
</Alea:Request>
</Alea:Document>