Hyperion Essbase入门（六）存储

转自：http://hi.baidu.com/sheenshine/item/4e2076e96f241c0b570f1dd3

要更好地理解Essbase的计算过程，就需要理解Essbase的存储结构，记得以前学习Oracle数据库里内置的OLAP的时候，教材只是交代了OLAP是以BLOB的形式存储在数据库字段里的，当时对于BLOB里的实际存储结构并没有特别多的说明，但是学Essbase的时候，Essbase里的确交代了Essbase数据库里存储原理的更加详细的信息，从而也就容易明白为什么稠密维度和稀疏维度对于Essbase数据库性能和大小至关重要的影响。

立方体里的“立方体”
和通常的关系数据库一样，Essbase使用两种基本的数据结构来存储数据，一种是数据块，另一种是索引，当用户请求一个数据的时候，Essbase一般而言先通过索引找到包含该数据的数据块，然后把该数据块复制到内存中，来完成数据的处理过程。可是什么是Essbase的数据块，什么是Essbase的索引呢？Essbase的数据块和索引和普通关系数据库的概念有比较大的区别。这是因为Essbase数据块和索引来源于多维数据库的“稠密”和“稀疏”的概念。

Essbase的最小的一个IO操作单位是数据块，而数据块在Essbase里的定义则是由所有的稠密维度组成的“小立方体”组成，一个形象化的表示数据块的例子是当稠密维度只有两个的时候（例子中的稠密维度只有两个，销售数量和时间），则这个“小立方体”则退化为一个Excel表格，如下图：

这个完完全全就是一个数据块在现实中表现出来的样子，也就是一个有两个稠密维度的数据块的真实样子。

一般而言，我们在Smart View操作Essbase的数据的时候通常都是以稠密维度做为行和列来展现Essbase里的数据。数据块又由数据单元（data cell，也就是上图中每一个Excel单元格）组成，每个数据单元包含8个字节的硬盘数据，数据单元里真正存储着维度交叉后的数据值（稠密维度空间的值）。
不管是否存在数据，任何一个稠密维度空间里的数据单元都是存在的，所以可以想像，当我们在设计不恰当的时候把一个稀疏维度当成稠密维度来设计，就会在这个稠密“小立方体”里留下很多空着的但是仍然占着8个字节存储的空单元格。

那么稀疏维度的作用是什么呢？ Essbase使用所有存在至少一个实际组合的稀疏维度来形成Essbase里所说的索引文件指向由稠密维度组成的“小立方体”，稀疏维度不存在的组合并不会在索引里存在记录，因而也不会因为大量不存在的值而浪费大量的空间（比如上面的例子假设我们还有两个稀疏维度，一个是客户，一个是产品），则这个由两个稠密维度和两个稀疏维度组成的多维数据库可以想像成在由稀疏维度组成的二维坐标空间了，稀疏地放着由稠密维度组成的小立方体。如下图：

当Essbase寻找一个数据的时候，先是从由稀疏维度组成的索引里去寻找一个数据块（“小立方体”），然后把这个小立方体拷贝到内存里，最后才真正处理这个“小立方体”里的真正存储着数据的Essbase的数据块。

从这个描述可以看出，Essbase里的数据块和索引的概念和关系数据库很不一样，稠密维度对于Essbase的数据存储至关重要，因为所有具有稠密属性的维度所形成的一个小立方体就是我们所说的Essbase的数据块，所以一旦一个Essbase的outline设计完成了，也就意味着该数据库的数据块决定了，数据块的大小是所有稠密属性成员数的乘积。

为什么会这么设计呢，因为Essbase总是希望能够在一次内存处理里尽量处理更多的数据，如果数据块里有很多空的单元（稀疏维度必然导致空单元），则会大大降低处理效率，但是如果把所有稠密的单元组成的所谓“小立方体“放到内存里，自然而然就可以在一次处理里处理许多数据，这个也是我们设计维度需要考虑的一个问题，定义一个维度是稠密还是稀疏并不是一件无关紧要的事情，而是会真正对性能有很大关系的决定。如果把一个稀疏维度定义为稠密维度，比如会造成每一个数据块有非常多的空值，而浪费大量的空间，并且降低数据处理的性能。