B Appendix: RPAS Sizing and Partitioning Considerations

This appendix provides guidelines and information on what to consider when sizing and partitioning RPAS domains. This appendix is not specific to any one solution. It is meant to give general information that will help you size and partition your solutions to achieve optimal performance.

RPAS Sizing

The number of positions within the hierarchies of a solution has an effect on the on-line and batch performance of a domain. When using a global domain, the positions along the partitioned hierarchy will be split among local domains. This partitioning will help in certain areas but is not a reason to include large numbers of positions in a single global domain environment.While there is no hard limit on how big a single global domain environment should be, the number of positions within the lowest level of each hierarchy should not be excessive. There are certain batch operations (loading hierarchies, reshaping arrays, repartitioning data between domains) that will be affected no matter how many local domains are created.

For example, assume that there is a solution that has a product, location and calendar hierarchy. In one environment, you have a single global domain instance with the product hierarchy having 1 million positions at the lowest level, the location hierarchy having 100 positions and the calendar hierarchy having 5 years. In a second environment, you have two global domain instances each with 500,000 product positions, 100 locations and 5 years of data. The loading of the product hierarchy in the first environment will be longer in than the second environment no matter how the local domains are partitioned.

Partitioning Considerations

The purpose of using a global domain and partitioning data across multiple domains is to help reduce contention, provide smaller domains for most users to interact with and to allow for parallel processing during batch. If the partitioning is not done correctly, it can lead to unnecessary contention or poor performance. Here are some key considerations to make when determining how to partition a global domain environment.

Try to keep the database file sizes under 2GB in each local domain. There is no restriction as such to this hard limit in the current RPAS embedded b-tree database, but as a rule of thumb it can be followed to get better performance.
Try to limit to one measure per database in the configuration as it will help in reducing the database contention.
The hierarchy that you partition on should allow the users the ability to work in a single local domain. If users require access to all positions within a hierarchy, that is not a good candidate for partitioning. For example, it does not make sense to partition on the location hierarchy if your business process requires all users to include all locations in each workbook. Unless dictated by business needs, try to avoid partitioning on alternate hierarchy and do the partitioning on the main hierarchy.
The partition level should also be higher than the level at which most of the data is stored. If most data is stored at the division level or below in the product hierarchy, the partition level should be at the division level or above. When data is based above the partition level of the domain, the data will be stored in the master domain. All users across the local domains who require this data will have contention from all other users and not just from the users of the local domains they are currently working with. Try to have as few users as possible to work on the master domain based on the hierarchy levels at which the different user roles operate. Try to have majority of the users to work below the partition level and evenly distributed across local domains.
The partitioning should be set such that the business requirements do not require high usage of the master domain. The performance of a workbook built from the master domain will never match that of a local domain workbook. The heavy usage of workbooks should take place across the local domains. For example, if most of the users only need to see data within a division then the partitioning should not be done below that level. Try to adopt a partitioning strategy which can result in majority of the measures to be at lower base intersection (measures whose intersection is at or below the partitioning dimension) and which can result in having one partition level position per local domain for improved performance and reduced contentions.
The number of users that are in a single local domain should be evenly distributed across all the domains in a global domain environment based on their areas of responsibility. If there are a larger number of users in a single local domain than others, it will not matter how many partitions you create. The domain with the largest user group will always have the potential to experience more contention issues and poor performance. If possible, create more domains and separate more users across those domains.
For very large global domains, we may have the local domains reside outside of the master domain so that they can be distributed amongst multiple file systems for better performance.

Workbook Sizing Considerations

The impact of size for the end user is not limited to only the size of the domain or where they are building a workbook from. The size of the individual workbooks will have a direct affect on the performance they experience. The workbook size is a result of the number of measures and number of positions from each of the hierarchies included in the built workbook.

Note:

The Fusion Client user interface hides the distinction between local and global domains and implicitly establishes user interaction with the domains to which the user has access. A user does not have to explicitly select a domain (through a profile selection during login) to work in the RPAS Fusion Client. For additional information, refer to the Oracle Retail Predictive Application Server User Guide for the RPAS Fusion Client.

The number of measures for a workbook template is static based on what is configured. The more measures that are configured in a template the larger the workbook becomes. As workbooks get larger, workbook operations will take longer. Specifically, operations like save and open are directly related to the overall size of the workbook.

Since the number of measures in a given workbook template are static based on what is configured, the number of positions in each hierarchy is the only factor that the end user controls from workbook to workbook using the same template. Two workbooks for the same template may have completely different performance based on how many positions are included.

The simplest way to compare the size of two workbooks for the same template is to multiply the number of positions for each hierarchy at the base intersection of the template and the measures. For example, assume that there is a workbook that has the majority of measures based at the week/style-color/channel. This workbook always contains 500 measures so that is a constant. If there is one workbook that contains 52 weeks (One year), 300 style colors and 3 channels, the total possible positions at the base level would be slightly over 23 million cells. This does not include any aggregate values a user may view. If a user built the same workbook for two years (104 weeks), the total possible positions double to over 46 million cells. Going back to the first example and include 450 style colors instead of 300, the total possible base level cells would increase to over 35 million.

Although there is no maximum number of cells that should be contained in a workbook, the number does have an impact on performance and therefore should be considered during design. If workbooks contain a total possible number of positions at the base level in the hundreds of millions, not only will the workbook performance be less than ideal but also the user will not be able to manage that level of detail.