“伪造”位图索引有意义吗？答案

【问题标题】：Does it make sense to "fake" bitmap indexes?“伪造”位图索引有意义吗？
【发布时间】：2010-09-21 07:03:27
【问题描述】：

我正在计划软件，它的核心是一个 OLAP 应用程序（它有助于分析计量数据），并将为其数据库提供某种星型模式，因为将从不同角度（时间、来源、类型等），并且请求将要求提供这些维度的聚合数据。查询往往会提供很多行（最多约 100 000 行）。

我对这个主题的研究（另见my question here）似乎表明位图索引是按照我计划的方式搜索数据的好方法。但是，我想支持多个数据库引擎，其中一些不提供其表上的位图索引（特别是 MySQL）。

现在，我当然可以构建和维护自己的位图索引，并使用它来查找指向事实表的行 ID。但是，我怀疑这会破坏索引的全部目的，因为数据库仍将在 B-Tree 中搜索行 ID。有更深的理论背景或更多经验的人可以告诉我，如果我还有什么收获，比如不必在维度表上做慢 JOIN 吗？

如果答案不直截了当，我也希望能得到有关我必须评估的提示。

【问题讨论】：

对于支持位图索引的数据库，我建议使用它们而不是使用所有数据库的最低公分母。

标签： database-design olap

【解决方案1】：

在使用自定义数据结构处理内存中的大量数据时，我对位图索引很幸运，但是在没有好的第三方数据库（类似 postgresql）上实现它们有点尴尬) 用于扩展其索引结构的 API。

一般来说，因为无论如何您都将通过 B-Tree 索引进行搜索，如果以我的经验为指导，您将不会获得任何东西。

所以，不。

如果您的应用程序本质上是 OLAP，并且您有少量自然分组为有序范围的维度，并且您确实需要更改问题的渐近线，那么您可以考虑构建一个类似“和表”的结构您可以使用 2^d 操作查询任何分层答案，如果您正在执行许多相关查询，则可以摊销。

坐标 x 和 y 的 2d 示例，您对 (x1,y1) 到 (x2,y2) 范围内的总和感兴趣。

单独存储，您必须将与该区域成比例的多个条目相加。

使用求和表，对于每个位置 (x,y) 不存储该位置的值，而是存储从 (0,0) 到 (x,y) 的区域的总和。

然后你可以通过询问来回答任何范围查询：

sum(x2,y2) - sum(x1,y2) - sum(x2,y1) + sum(x1,y1)

固定数量的开销（好吧，数据集大小的对数，假设您在 x 和 y 上有一个索引并将其存储在 SQL 中）

如果您有复杂的属性不能分解成范围，但可以处理简单的字典索引、日期等，这当然会分解。

【讨论】：

【解决方案2】：

一些不直接支持位图索引的数据库引擎仍然具有星型优化，可以在不触及事实表的情况下执行此类查询。例如，SQL Server 有一个名为 Index Intersection 的功能，它通过动态构建位图来执行类似的操作。 Microsoft 声称它的性能与位图索引相当。请参阅This posting 了解有关此主题的一些信息。

我不确定 MySQL 是否会这样做，但 Postgresql 肯定会这样做。 IIRC 的一些变体（我认为是 Greenplum）也直接支持位图索引，并且有人谈到将其合并到主数据库引擎中。我不记得这是否已经完成。

我认为您会发现大多数现代 DBMS 平台都提供了一种或另一种星型查询优化，因此您可能不需要重新发明轮子。您可能会发现一两个无法做到这一点，但您始终可以选择不支持它们。

【讨论】：