Authors: Warren Pereira and Andrew Tauro, Performance Architects
Oracle’s Essbase is a popular multidimensional database platform that powers business analytics solutions the world over, both on-premise and as Software-as-a-Service (SaaS, in the “cloud”). The name stands for “Extensible Spreadsheet Database” because this database’s dimensions provide multiple views of a dataset, and you can drive complex calculations off of these datasets.
Dimensions can be defined as characteristics of the data, which vary from financial items such as charts of accounts, business entities, and physical or logical characteristics such as materials and markets. As a result of the multi-dimensional nature of Essbase databases, they are usually simplistically referred to as “cubes,” after one of the primary three-dimensional objects that we are familiar with. However, Essbase databases are not restricted to just three dimensions, as they usually consist of at least seven to nine dimensions.
Data can be stored in an Essbase cube or database using either the “Block Storage Option” (BSO) or “Aggregate Storage Option” (ASO). This blog post provides descriptions and an overview of when to use each storage type.
Block Storage Option (BSO)
Essbase originally launched only with the BSO storage option, which is generally used in scenarios which do not need high dimensionality, but involve complex business logic. With this option, dimensions are tagged as “dense” or “sparse” (the probability of data occurring in intersections involving a dimension).
Using BSO, data can be loaded at all levels of a dimension and is stored in logical structures called “data blocks” which make use of page and index files. Calculation scripts and member formulas can be used to perform complex calculations, such as allocations and metrics-based projections, which usually cannot be accomplished using simple hierarchical roll ups.
This storage option prefers fewer dimensions. As the dimension count increases, performance of a BSO cube drops nonlinearly. Another drawback of this approach is that as the dataset size and/or dimensionality rises, the disk space required grows almost exponentially. BSO databases do not scale very well, and as a result dataset size is an important consideration when designing a BSO cube.
Data is loaded at leaf nodes. Stored data size increases when the cube is calculated.
Aggregate Storage Option (ASO)
ASO is frequently used for reporting solutions, that do not involve complex calculations. In a typical ASO solution, the hierarchies are aggregated in a bottom-up manner.
An ASO cube can handle a higher number of dimensions than BSO, without adverse impact to performance. Data can only be loaded at the leaf nodes of the hierarchies, or “Level 0” as referred to in Essbase terminology. Data is aggregated on-the-fly, usually very quickly. This makes a huge difference in the amount in disk space ASO requires over BSO. For larger databases, partial aggregations can be set up, called “Aggregation Views,” that reduce the “cost” of a query.
With all of their merits, ASO cubes slow down immensely when the hierarchy is dynamic, or uses a member formula. For this reason, it is not recommended to use ASO for calculations, but it can serve as a great source of data to drive calculations in another system.
A remedy for both storage options’ shortcomings is to use a “hybrid” approach, where actuals data is stored in an ASO cube (since it is large and does not need to be calculated) with a transparent partition to connect to a BSO cube, which can use the actuals data as source to generate the forecast data via calculation. The calculated forecast can then be fed back to the ASO cube. This plays to the strengths of each type of storage option.
Still confused about which storage option to use with your Essbase solution? Email us at communications@performancearchitects.com and we’ll be happy to help you out!