29

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

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

信息如何存储在磁盘上？多维数据集包含哪些数据结构？如果 MOLAP 模型不使用包含列和记录的表，那么……什么？尤其是在高维数据中，什么样的数据结构让 MOLAP 模型如此高效？MOLAP 实现是否使用类似于 RDBMS 索引的东西？

为什么 OLAP 服务器在处理即席查询方面表现得如此出色？在普通关系数据库中可能需要数小时才能处理的相同类型的聚合可以在 OLTP 多维数据集中以毫秒为单位进行处理。使这成为可能的模型的基本机制是什么？

4

2 回答 2

20

我已经实现了几个模仿 OLAP 多维数据集的系统，下面是我们为使它们工作而做的一些事情。

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

  2. 底层数组通常是稀疏的，因此一旦创建它，​​我们就会删除所有空白单元格以节省内存 - 大量的硬核指针算法，但它有效。

  3. 由于我们有键的层次结构，我们可以很容易地编写例程来轻松地向下钻取/向上钻取层次结构。例如，我们将通过月份键访问年份数据，而月份键又映射到天和/或周。在每个级别，我们将聚合数据作为构建多维数据集的一部分 - 使计算速度更快。

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

  5. 我们在 C++ 中实现了核心内容，但这些天我认为 C# 可能足够快，但我担心如何实现稀疏数组。

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

于 2009-04-10T05:04:42.990 回答
6

《Microsoft SQL Server 2008 Analysis Services Unleashed 》一书详细阐述了 SSAS 2008 的一些特性。这不是“这就是 SSAS 在幕后工作的确切方式”，但它很有启发性，尤其是在数据结构方面。（关于确切的算法，它没有那么详细/具体。）作为该领域的业余爱好者，我从这本书中收集了一些东西。这都是关于 SSAS MOLAP 的：

  • 尽管所有关于多维立方体的讨论，事实表（又名度量组）数据仍然是，第一个近似值，最终存储在基本的二维表中，每个事实一行。许多 OLAP 操作似乎最终都包括对 2D 表中的行的迭代。
  • 然而，MOLAP 中的数据可能比相应 SQL 表中的数据小得多。一个技巧是每个唯一的字符串只存储一次，在“字符串存储”中。然后，数据结构可以以更紧凑的形式（基本上通过字符串 ID）引用字符串。SSAS 还以某种形式压缩 MOLAP 存储中的行。我认为这种缩小可以让更多数据同时保留在 RAM 中，这很好。
  • 同样，SSAS 通常可以迭代数据的一个子集，而不是整个数据集。有一些机制在起作用：
    • 默认情况下，SSAS 为每个维度/属性值建立一个哈希索引；因此，它“立即”知道磁盘上的哪些页面包含相关数据，例如 Year=1997。
    • There's a caching architecture where relevant subsets of the data are stored in RAM separate from the whole dataset. For example, you might have cached a subcube that has only a few of your fields, and that only pertains to the data from 1997. If a query is asking only about 1997, then it will iterate only over that subcube, thereby speeding things up. (But note that a "subcube" is, to a first approximation, just a 2D table.)
    • If you're predefined aggregates, then these smaller subsets can also be precomputed at cube processing time, rather than merely computed/cached on demand.
  • SSAS fact table rows are fixed size, which presumibly helps in some form. (In SQL, in constrast, you might have variable-width string columns.)
  • The caching architecture also means that, once an aggregation has been computed, it doesn't need to be refetched from disk and recomputed again and again.

These are some of the factors in play in SSAS anyway. I can't claim that there aren't other vital things as well.

于 2012-01-27T03:30:20.783 回答