BSo Will never Die and here Is Why - Developing Essbase Applications - page 120

Figure 4.3 Hourglass on a stick. (From Oracle Essbase Administration Services. With permission.)
Figure 4.4 Hourglass on a stick—calc all application log.
That is substantially fewer reads and writes than the standard hourglass design.
Fewer reads and writes often translate to better performance. however, all is not rosy
with the hourglass on a stick format. When switching to the hourglass on a stick
design, there are a few concerns. First, the calculator cache needs to be tuned again.
In the second example, the cache anchor is now Scenario where it was market before
the change. Instead of being the anchor dimension, market is now in the bitmap. BSo
will now be able to track the market dimension members during aggregations using
the calculator cache.
Secondly, using the hourglass on a stick design approach causes Essbase to use the
last dimension to distribute data to the individual file when using parallel exports.
When the final dimension is large, the data is distributed fairly evenly across all of the
output files. If the last dimension has few members, there is an increased chance of an
imbalance. For example, assume that the last dimension is yEAr with members Fy11,
Fy12, Fy13, and Fy14. Also assume that Fy11 is the only member with data. A paral-
lel data export that specifies four output files will have data in the first file, but only
header information in files two, three, and four. to compound the felony, should the