Algorithm 有人知道OLAP的内部结构吗？

我对数据库内部结构略知一二。实际上，我以前实现过一个小型、简单的关系数据库引擎，使用磁盘上的ISAM结构和BTree索引等诸如此类的东西。这很有趣，也很有教育意义。我知道，我对仔细设计数据库模式和编写查询更加了解，因为我对RDBMS如何在后台工作有了更多的了解

但我对多维OLAP数据模型一无所知，而且我很难在互联网上找到任何有用的信息

信息是如何存储在磁盘上的？多维数据集由哪些数据结构组成？如果MOLAP模型不使用带有列和记录的表，那么。。。什么？特别是在高维数据中，什么样的数据结构使MOLAP模型如此高效？MOLAP实现是否使用类似于RDBMS索引的东西

---

为什么OLAP服务器在处理即席查询方面做得更好？在普通关系数据库中可能需要数小时才能处理的相同类型的聚合可以在OLTP多维数据集中以毫秒为单位进行处理。使之成为可能的模型的底层机制是什么？

我已经实现了两个系统，它们模仿OLAP多维数据集的功能，下面是我们为使它们工作所做的几件事情

核心数据保存在一个n维数组中，全部在内存中，所有键都是通过指向底层数组的指针层次结构实现的。通过这种方式，我们可以为相同的数据设置多组不同的键。数组中的数据相当于事实表，通常它只有几条数据，在一个实例中，这是卖出的价格和数量

>P>底层数组通常是稀疏的，所以一旦创建它，我们就用来删除所有的空白单元来保存内存-大量的硬核指针算法，但是它是有效的。

因为我们有键的层次结构，所以我们可以很容易地编写例程来向下/向上钻取层次结构。例如，我们将通过查看月份键来访问数据的年份，月份键反过来映射到天和/或周。在每一个层次上，我们都会在构建多维数据集的过程中聚合数据，从而使计算速度大大加快

我们没有实现任何类型的查询语言，但我们支持在所有轴上向下钻取（在我们最大的多维数据集中最多7个），这与用户喜欢的UI直接相关

>P>我们在C++中实现了核心的东西，但是现在我认为C是足够快的，但是我担心如何实现稀疏数组。

希望这会有所帮助，听起来很有趣。

这本书相当详细地阐述了SSAS 2008的一些特点。这并不是一个“SSAS在引擎盖下的工作原理”，但它很有启发性，尤其是在数据结构方面。（关于精确的算法没有那么详细/具体。）作为这个领域的业余爱好者，我从这本书中收集了一些东西。这是关于SSAS MOLAP的全部内容：

• 尽管人们都在谈论多维数据集，事实表（又称度量组）的数据仍然是基本上存储在二维表中的，每个事实一行。许多OLAP操作似乎最终包括对2D表中的行进行迭代
• 然而，MOLAP中的数据可能比相应SQL表中的数据小得多。一个技巧是，每个唯一的字符串只存储一次，在“字符串存储”中。然后，数据结构可以以更紧凑的形式引用字符串（基本上是通过字符串ID）。SSA还以某种形式压缩MOLAP存储中的行。我认为这种收缩可以让更多的数据同时留在RAM中，这很好
• 类似地，SSA通常可以迭代数据的子集，而不是整个数据集。一些机制正在发挥作用：
  • 默认情况下，SSAS为每个维度/属性值构建哈希索引；因此，它“立即”知道磁盘上的哪些页面包含相关数据，比如1997年
  • 有一种缓存体系结构，其中数据的相关子集存储在RAM中，与整个数据集分开。例如，您可能缓存了一个子多维数据集，该子多维数据集只有几个字段，并且只涉及1997年的数据。如果一个查询只询问1997年左右，那么它将只在该子多维数据集上迭代，从而加快速度。（但请注意，“子立方体”在第一近似值下只是一个二维表格。）
  • 如果您是预定义的聚合，那么这些较小的子集也可以在多维数据集处理时预计算，而不仅仅是按需计算/缓存
• SSAS事实表行的大小是固定的，这可能在某种形式上有所帮助。（与之相反，在SQL中，您可能有可变宽度的字符串列。）
• 缓存体系结构还意味着，一旦计算了聚合，就不需要从磁盘重新提取聚合，并一次又一次地重新计算聚合

无论如何，这些都是在SSA中起作用的一些因素。我不能说没有其他重要的东西