The Hybrid Dimension Model Combines the Stored Aggregations of BSO with the Dynamic Aggregations of ASO in an Essbase Database

In recent days, there is the amount of time that is necessary to aggregate the database. This only pertains to BSO, and at the very least, it is assumed of the fact those hybridized BSO database has all noninput members (either dense or sparse) set to be dynamically calculated. If this is the case, then there is no need to generate high-level blocks. Technically, Hybrid databases are not obligated to have every upper-level sparse member dynamic. However, in certain cases, aggregation may be necessary. The performance might be somewhere between pure Hybrid and plain BSO, but for now we'll not worry about that. The space necessary on the disk to contain the databases was the second focus area. Furthermore, we were very intrigued by the query performance of the cubes. Even without Hybrid, dynamic calculation of upper-level sparse elements in a cube provides similar gains in terms of aggregation time and disk space utilization. But as everyone who has ever attempted this with a cube of a reasonable size can attest, upper-level query performance is likewise terrible; presumably, Essbase materializes in memory all the blocks that are in between the input data and the upper-level intersection that is being queried.The rationale for Hybrid is compelling: all of the flexibility and power of BSO mixed with the quick aggregation speed of ASO. Hybrid is not yet ready to be the default option when building a new Essbase database; there are still issues that need to be resolved. Essbase practitioners must assess their applications' suitability for Hybrid while it is still in its unfinished stage. As Hybrid gains additional functionalities, this question will become less relevant for BSO and ASO use cases.