How ASo Works and how to Design for Performance - Developing Essbase Applications - page 248

( K ey L ength KL ) + data bytes (bundles of 16 * 8 bytes for each data element), or a total
of KL + 128 bytes . We know that not all cubes have a nice, even multiple of 16 members
in the Compression dimension. If the combination of all of the other non-Compression
dimensions together are thought of as an ASo Sparse key (Sk), not all Sk combina-
tions will necessarily have data values for each of the members of the Compression
dimension. ( Note : Sk is a term coined by the author and not normally used in ASo.) to
minimize the wasted space, ASo does something additional for dimensions tagged as
Compression: It adds 4 bytes to the record, which tells ASo which of the 16 members of
the bundle are actually populated for this SK . Furthermore, the 32 bits found in these 4
bytes are broken into 16 sets of 2 bits. As we know, 2 bits can hold 4 unique values and
ASo utilizes one of the four values to indicate that data exist. ASo goes on to indicate
whether each of the 16 potential bundle members requires 2, 4, 6, 8, or 0 bytes to hold
the actual fact data.
7.4.3.3.2 Average Value Length (AVL) Wait, less than 8 bytes? Where did that come
from? ASo recognizes that not all pieces of fact data require all 8 bytes (the length of a
double precision floating point number) to represent the required precision. The exact
method of data value storage and its relation to precision are not disclosed. The algo-
rithm is clearly skewed to minimize storage of values requiring no more than two digits
after the decimal. This is hinted at in the DBAg where it provides some guidance to get-
ting the most compressible data. The following is reprinted with permission from oracle
Corporation, Oracle Essbase Administrators Guide Release 11.1.2.1 (oracle Press, 1996,
2011) Chap. 62, p. 939):
average value length
The average value length is the average storage size, in bytes, required for the
stored values in the cells. It can vary between 2 bytes and 8 bytes with 2 bytes
being the best. Without compression, it takes 8 bytes to store a value in a cell. With
compression, it can take fewer bytes, depending on the value length. For example,
10.050001 might take 8 bytes to store even when compressed, but 10.05 may only
take 2 bytes (4 bytes to store when compressed). Dimensions with a smaller aver-
age value length compress the database better.
rounding the data values to no more than two digits after the decimal point can
reduce the average value length, improving compression.
The Average value Length (AvL) refers to the number of bytes required to store your
fact data across all of the data in your cube. This is similar to the analysis that is required
to calculate the ABF discussed above. The Database -> Properties -> Compression tab
provides some guidance to the size reduction you gain with use of the Compression
dimension. In Figure 7.7, you can see the ABF and AvL. you also can see the effects on
AvL of loading nearly identical data into the two cubes. Cube AS2stc55 (top) has three
decimal values for each of two of the compressed members [original Price] and [Price
Paid], while cube AS2tc55z (bottom) has two decimal values for [original Price] and
[Price Paid]. The cubes are otherwise identical. Figure 7.8 shows the data as loaded for
these two cubes:
(Be aware that on a large cube, opening up the Compression tab could take a
considerable amount of time. Be patient and do not ctrl-alt-dlt out of EAS during this
process.)