如何設計和處理事實表中的指數增長？

Question

這裏是我的情況與SQLServer 2008 R2數據庫表

（更新：遷移到SQL Server 2014 SP1正在進行中，因此SQL Server 2014可以在這裏使用）。

A.維持日常歷史表中（這是一個事實表） B.用事實和維度表

幾個步驟來創建表

1. 創建畫面圖表從源數據庫中的表副本將被推送到我的SQLServer DAILY，其中包含120,000到130,000行，其中20列約爲

a。第一天，我們得到了12萬條記錄，樣本結構如下。

（新建或修改的記錄黃色高亮顯示）

源系統數據：

灣第2天，我們得到的，說的122000條記錄（2000是新插入和1000被修改/更新前一天的數據和119,000是因爲它是由前一日）

℃。第3天，我們得到123000條記錄（新插入1,000條，第2天數據修改/更新1,000條，第2天數據更新爲121,000條）

1. 由於每日曆史已經維持在事實表中，在一個星期內表有一個百萬行，

2周 - 第2個百萬行

1個月 - 500萬行

爲1年 - 比如65-70萬行

12年 - 比如說1個十億行（1000萬美元）

12年的歷史一直維持

什麼可能是數據存儲在正確的策略處理這種情況的表格應該在生成報告時提供足夠的性能？

• 按月對錶進行分區（表中將包含約500萬行）？
• 想到僅在表中每日複製差異數據（僅限新的和修改的行），但無法使用Approach-2創建表格報告。

事實表途徑：

的Tableau圖形必須使用用於場景的事實和維度表等

創建

• 每週柱狀圖爲採樣計數

• 每週（在X軸上的週數）平均值的繪圖儀圖形樣品值（在Y軸上）

• 每週（week no。在x軸上）根據質量的平均樣本值（在Y軸上）

如何處理這種情況？

請提供關於遵循方法的參考。

我們應該在事實表上創建任何索引嗎？

Answer 1

一個數據倉庫可以處理數百萬行這些天沒有很多困難。許多人有數百億行，然後事情變得有點困難。你應該看看這兩種表格的分區情況，以及在列表存儲壓縮和頁面壓縮方面的表現。大型倉庫經常使用兩者。 2008 R2現在已經很老了，並且注意到在當前版本的SQL Server的這個領域已經取得了巨大的進步。

使用標準的事實維度設計，並儘量避免調整實際模式與變通辦法只是爲了節省空間 - 通常會長期咬你。

對於久經考驗的倉儲設計，我喜歡Kimball團隊的模式，例如，數據倉庫生命週期工具包手冊。

Answer 2

你的情況有幾個不同的要求。因此，我建議根據標準數據倉庫三層模型分解需求。

• DWH模型（Δ-驅動，作爲歷史，高性能）
• 表現模型（同樣，高性能，應該適合的Tableau）
• 前端

DWH模型

基本上，你有三種不同的方法，所有的優點和缺點。

1. 3NF

可能變得非常麻煩的道路。如果使用得當，則具有高度靈活性。上市時間長（取決於複雜性）。歷史化可能變得複雜。

1. Star Schema（用於DWH存儲！）

有一個非常非常快速的上市時間。當業務規則或業務結構發生變化時，維護將變得非常複雜。對於一個非常小的企業非常有用，但對於想要擴展其商業智能基礎架構的企業來說並非如此。如果星型模式是DWH的主要模型，則歷史化可能會變得混亂。

數據保險庫

具有中等時間到市場。比3NF更容易理解，但對於習慣於星型模式的人來說可能令人費解。自動歷史化，可並行化，並且對於不斷變化的業務需求非常靈活，因爲業務規則在下游實施。快速縮放。

錨建模

其中我還沒有使用的另一種高度靈活的方法。與Data Vault存在某種相同的方法，但有一些差異。

演示模型

現在，來表示DWH層永不觸碰一次數據，沒有什麼比適合星模式更好。另外，在創建星型模式時，您可以實現業務邏輯。

前端

要不要緊，把你喜歡的工具。

在你的情況下，實現一個DWH（使用其中一個模型）並將表示模型放在它上面會很明智。如果星型模式存在任何問題，您可以隨時重新生成新的更改。

注：如果你會使用星型模式的數據倉庫模型，您不能重新創建在表示層的星型模式，而無需使用一些複雜的轉換邏輯開始。

注意：此外，有時星形模式被視爲DWH。我認爲這對於任何可能變得更加複雜的要求來說都不是很好。

編輯

要澄清我的最後一個音符，看到這篇博客文章：http://www.tobiasmaasland.de/2016/08/24/why-your-data-warehouse-is-not-a-data-warehouse/