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

Question

这是我使用SQLServer 2008 R2数据库表的方案

（更新：正在进行向SQL Server 2014 SP1的迁移，因此可以在此处使用SQL Server 2014）。

A.维护表（事实表）中的每日历史记录B.使用事实表和维表创建Tableau图形

创建表要遵循的几个步骤

1. 来自源数据库的表的副本将被推送到我的SQLServer DAILY，其中包含120,000至130,000行，大约20列

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

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

源系统数据：

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

C。 第三天，我们得到123,000条记录（第二天的数据是新插入的1,000条，第二天的数据被修改/更新了1,000条，第二天的数据是121,000条）

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

2周-200万行

1个月-500万行

1年-例如65-7000万行

12年-假设有10亿行（10亿）

3. 必须保留12年的历史

什么是将数据存储在表中以应对这种情况的正确策略，在生成报告时还应提供足够的性能？

• 按月对表进行分区（表将包含约500万行）？
• 考虑仅每天在表中复制差异数据（仅新行和修改行），但是无法使用Approach-2创建Tableau报告。

事实表方法：

必须使用事实表和维度表来创建Tableau图形，以用于诸如

• 每周条形图的样本数量

• 每周（X轴上的第几周）绘图仪图，以获取平均样本值（在Y轴上）

• 按质量划分的每周（x轴上的第几周）平均样品值（Y轴上）

如何处理这种情况？

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

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

Answer 1

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

使用标准的事实维度设计，并尝试避免使用变通办法来调整实际架构，以节省空间-从长远来看，这通常会给您带来麻烦。

对于久经考验的仓储设计，我喜欢Kimball组的模式，例如《数据仓库生命周期工具包》。

Answer 2

您的情况有一些不同的要求。 因此，我建议根据标准数据仓库三层模型拆分需求。

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

DWH模型

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

1. 3NF

将来可能会很麻烦。 如果使用正确，则具有很高的灵活性。 上市时间很长（取决于复杂性）。 历史化可能变得复杂。

2. 星型模式（用于DWH存储！）

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

3. 资料库

上市时间中等。 比3NF更容易理解，但对于习惯星型模式的人们可能会感到困惑。 由于业务规则是在下游实施的，因此可以自动进行历史化，可并行化并且非常灵活，以适应不断变化的业务需求。 快速扩展。

4. 锚模型

我尚未使用的另一种高度灵活的方法。 在某种程度上与Data Vault是相同的方法，但有一些区别。

展示模型

现在，要表示DWH层中从未触及的数据，再没有比Star Schema更适合的了。 同样，在创建星形模式时，您可以实现业务逻辑。

前端

没关系，请使用您喜欢的工具。

在您的情况下，实现DWH（使用这些模型之一）并在其之上放置表示模型将是明智的。 如果星型模式存在任何问题，您始终可以使用新更改重新生成它。

注意：如果将星形模式用作DWH模型，则必须先使用一些复杂的转换逻辑才能在表示层中重新创建星形模式。

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

编辑

为了澄清我的最后一个笔记，请参阅此博客文章： http : //www.tobiasmaasland.de/2016/08/24/why-your-data-warehouse-is-not-a-data-warehouse/