如何使用類型2緩慢變化的維度索引表以獲得最佳性能

Question

假設您有一個具有類型2緩慢變化維度的表。

讓我們按如下方式表達此表，其中包含以下列：

* [Key]
* [Value1]
* ...
* [ValueN]
* [StartDate]
* [ExpiryDate]

在這個例子中，假設[StartDate]實際上是系統已知給定[Key]的值的日期。 所以我們的主鍵將由[StartDate]和[Key]組成。

當一組新值到達給定[Key]時，我們將[ExpiryDate]分配給某個預定義的高代理值，例如'12 / 31/9999'。 然后，我們為[Key]設置現有的“最新”記錄，使[ExpiryDate]等於新值的[StartDate]。 基於連接的簡單更新。

---

因此，如果我們一直希望獲得給定[Key]的最新記錄，我們知道我們可以創建一個聚簇索引：

* [ExpiryDate] ASC
* [Key] ASC

雖然鍵空間可能非常寬（例如，一百萬個鍵），但我們可以通過[ExpiryDate]最初對它們進行排序來最小化讀取之間的頁數。 由於我們知道給定密鑰的最新記錄將始終具有[12/31/9999]的[ExpiryDate]，因此我們可以將其用於我們的優勢。

但是......如果我們想在給定時間獲得所有[Key] s的時間點快照怎么辦？ 從理論上講，整個鍵空間並非全部同時更新。 因此，對於給定的時間點，[StartDate]和[ExpiryDate]之間的窗口是可變的，因此[StartDate]或[ExpiryDate]的排序永遠不會產生一個結果，其中您要查找的所有記錄都是連續的。 當然，您可以立即丟棄[StartDate]大於您定義的時間點的所有記錄。

---

從本質上講，在典型的RDBMS中，什么索引策略提供了最佳方法來最小化讀取次數以檢索給定時間點的所有鍵的值？ 我意識到我可以通過[Key]對表進行分區來最小化IO，但這肯定不太理想。

或者，是否存在一種不同類型的緩慢變化的維度，以更高效的方式解決這個問題？

Answer 1

懶惰的DBA

您是否在談論恢復維度表中的所有值？ 如果是這樣，那么為什么不添加一個具有額外覆蓋率的非聚集索引，以便您只從索引本身而不是從表中提取值？ 這樣你就可以使用一些附加的“覆蓋”值來掃描B樹，而不是可能執行表掃描？ 我無法保證相對性能，但是值得測試你正在研究的場景。

干杯

Ozziemedes http://ozziemedes.blogspot.com/

Answer 2

如果這確實是一個“緩慢變化的維度”表，我會考慮一個聚簇列存儲索引。 我知道當你問這個問題時這不可用，但無論如何。 你會在這里找到一些很棒的文檔：“ https://msdn.microsoft.com/en-us/library/gg492088.aspx ”和這里“ http://www.nikoport.com/2013/07/05/clustered -columnstore-indexes-part-1-intro / “。

現在，如果你想堅持使用行存儲索引，如果你按順序在表中插入數據，那么我過去所做的就是利用一個標識字段。 您的查詢將是這樣的：

    declare @id;
    select @id = min(ID) from table where date = '12/31/9999';
    select fields from table where key = 112 and id > @id;