0

对于相对较小的事实表(每个表平均 3000 万行),这是最好的索引和分布设计。每个表的结构类似于以下:

CREATE TABLE FactTable (
    TimeDimensionID INT NOT NULL,
    DimensionID1 VARCHAR (10) NOT NULL,
    DimensionID2 VARCHAR (10) NOT NULL,
    DimensionID3 VARCHAR (10) NOT NULL,
    DimensionID4 VARCHAR (10) NOT NULL,
    Measure1 INT,
    Measure2 FLOAT,
    Measure3 DECIMAL (10.2),
    Measure4 DECIMAL (10,2)
)

TimeDimensionID、DimensionID1、DimensionID2、DimensionID3和DimensionID4的并集在事实表中是唯一的。目前,我们在 5 个字段中有一个聚集且唯一的主键。

  • 将这些表迁移到 SQL Azure 数据仓库的最佳索引和分布是什么?我们正在考虑将 CLUSTERED INDEX(DimensionID1、DimensionID2、DimensionID3 和 DimensionID4)用于使用 TimeDimensionID 字段的索引和哈希分布。
  • CLUSTERED INDEX 必须包含 TimeDimensionID 字段,即使散列分布是针对该字段的?
  • 这种设计是正确的还是我们应该使用 COLUMN STORE INDEX,即使表实际上只有不到 1 亿行?
  • 我们应该考虑为事实表使用复制表吗?
4

1 回答 1

0

一些建议:

  • 如果可能,请将您的 DimensionID 从 varchar 移动到 int/bigint。您将获得更好的性能、更少的存储空间和更低的成本。
  • 暂时忘记聚集索引。
  • 创建您的表散列分布,但不是日期,这将热点您的数据。
  • 将表创建为 CLUSTERED COLUMNSTORE INDEX
  • 不要复制您的 FACT 表,而是复制您的 DIMENSIONS。
于 2019-03-07T00:15:21.120 回答