Applied Dimensionality

Essbase ASO key structure

Posted at — Apr 17, 2009
Essbase ASO key structure

Yay, another post on Essbase )

Internal ASO storage structure is a block box, so unlike BSO. So while Roske haven’t writen a book on ASO option, we have to wonder in the dark. 

The main description of ASO storage is “data is stored as key\value pairs”. This quote comes from ASO Tuning WhitePaper, the only “internals” technical description of ASO out there. It’s for 7, but all the concepts are still valid.

So, “key-value pairs” it is. Key length is very important then, because it directly affects:

  1. size of the database, if you’ve got a billion rows cube, then -1 byte for every cell means 1 Gb less overall cube size (that’s raw size, it’ll be compressed later). 
  2. query processing — for every query cell key got to be calculated for data retrieval. Less key, faster the query, as I think.

You can see the key description on Application Properties page or issuing “query database test.db list aggregate_storage runtime_info;”  MaxL command .

Here’s the sample output. 

parameter                                         value                                            
 Dimension [Date] has [3] levels, bits used                                                        1
 Max. key length (bits)                                                                            1
 Max. key length (bytes)                                                                           8

we see following characteristics of dimension – number of levels and number of bits used to encode values in this dimension. Cell key is concantenation of each dimension keys. 

But that number of bits is pretty cryptic, though. On a project we’re doing we have a couple of 5 mln elements dimensions and key length for them is around 40 bits. If you use simple binary encoding – you can encode 2^40 elements (that’s really a huge number, it contains 14 digits). It’s no a simple binary encoding then. 

So how are dimension elements encoded? 

Well, it’s allways easy afterwards, so I’m not so proud now, as I was when it first struck me )

So I now think that the technique called hierarchial encoding (or indexing) or something similar is used, so each dimension element is encoded the following way: Let’s assume that we have 3 levels in dimension, then the key will be formed like:



Therefore there are a few things to keep in mind while doing big-scale ASO projects:

But that brings up a few more things about ASO i’m thinking of:

  So I’m still waiting for Edward to publish ASO book, there’s a lot of questions. The book seems to be close )

comments powered by Disqus