如何设计和处理事实表的指数增长？

Posted 2023-03-29

【中文标题】如何设计和处理事实表的指数增长？

【英文标题】：How to design and handle exponential growth in fact table?

【发布时间】：2016-08-17 19:46:52

【问题描述】：

这是我使用 SQLServer 2008 R2 数据库表的场景

（更新：正在迁移到 SQL Server 2014 SP1，所以这里可以使用 SQL Server 2014）。

A.在表中维护每日历史记录（这是一个事实表） B. 使用事实表和维度表创建表格图

创建表格的几个步骤

源数据库中的表副本将每天推送到我的 SQLServer，其中包含大约 20 列的 120,000 到 130,000 行

一个。第一天，我们得到了 120,000 条记录，示例结构如下。

（修改或新记录以黄色突出显示）

源系统数据：

b.第二天，我们得到了 122,000 条记录（2,000 条是新插入的，1,000 条是根据前一天的数据修改/更新的，119,000 条是前一天的）

c。第 3 天，我们得到 123,000 条记录（1,000 条是新插入的，1,000 条在第 2 天的数据上修改/更新，121,000 条是从第 2 天开始的）

由于必须在 Fact 表中维护每日历史记录，因此该表在一周内将有 100 万行，

2 周 - 200 万行

1 个月 - 500 万行

1 年 - 比如说 65 - 7000 万行

12 年 - 比如说 10 亿行（10 亿）

12年历史要维持

在表中存储数据以处理这种情况的正确策略是什么，并且在生成报告时也应该提供足够的性能？

按月对表进行分区（表将包含大约 500 万行）？ 想过每天只在表格中复制差异数据（仅限新行和修改的行），但无法使用 Approach-2 创建表格报告。

事实表方法：

Tableau 图表必须使用事实表和维度表来创建，例如

样本计数的每周条形图

平均样本值的每周（X 轴上的周数）绘图仪图表（Y 轴上）

按质量划分的每周（X 轴上的周数）平均样本值（Y 轴上）

如何处理这种情况？

请提供有关遵循方法的参考。

我们应该在事实表上创建任何索引吗？

【问题讨论】：

用更多细节更新了场景，SQL Server 2014 SP1 可以用于这个场景。

【参考方案1】：

如今，数据仓库可以轻松处理数百万行数据。许多有数百亿行，然后事情变得有点困难。您应该查看随时间变化的表分区以及列存储压缩和页面压缩，以了解那里有什么。大型仓库经常使用两者。 2008 R2 在这一点上已经很老了，请注意，在当前版本的 SQL Server 中这方面已经取得了巨大的进步。

使用标准的事实维度设计，并尽量避免为了节省空间而使用变通办法来调整实际架构 - 从长远来看，这通常会影响您。

对于经过验证、久经考验的仓储设计，我喜欢 Kimball 集团的模式，例如数据仓库生命周期工具包一书。

【参考方案2】：

您的情况有几个不同的要求。因此，我建议按照标准的数据仓库三层模型来拆分需求。

DWH 模型（增量驱动、历史化、高性能） 演示模型（同样，高性能，应该适合 Tableau） 前端

DWH 模型

基本上，这里有三种不同的方法，各有优缺点。

3NF

以后可能会变得很麻烦。如果使用得当，是高度灵活的。上市时间很长（取决于复杂性）。历史记录可能会变得复杂。

星型架构（用于 DWH 存储！）

上市时间非常非常快。当业务规则或业务结构发生变化时，维护将变得极其复杂。对于非常小的企业很有帮助，但对于想要扩展其商业智能基础设施的企业则不然。如果星型模式是 DWH 主模型，则历史化可能会变得一团糟。

数据保险库

上市时间适中。比 3NF 更容易理解，但对于习惯了星型模式的人来说可能会令人费解。自动历史化、可并行化并且非常灵活地适应不断变化的业务需求，因为业务规则是在下游实现的。快速扩展。

锚定建模

我还没有使用过的另一种高度灵活的方法。在某种程度上与 Data Vault 的方法相同，但有一些不同。

演示模型

现在，要在 DWH 层中表示永不接触的数据，没有什么比 Star Schema 更合适的了。此外，在创建星型模式时，您可以实现业务逻辑。

前端

没关系，拿你喜欢的工具吧。

在您的情况下，实现 DWH（使用其中一种模型）并将演示模型放在其上是明智的。如果星型模式有任何问题，您可以随时使用新的更改重新生成它。

注意：如果您将星型模式用作 DWH 模型，则如果不使用一些复杂的转换逻辑，就无法在表示层中重新创建星型模式。

注意：此外，有时星型模式被视为 DWH。对于任何可能变得更复杂的要求，我认为这不是一个很好的用途。

编辑

要澄清我的最后一条注释，请参阅这篇博文：http://www.tobiasmaasland.de/2016/08/24/why-your-data-warehouse-is-not-a-data-warehouse/