Azure SQL数据仓库中的事实表设计

时间:2019-03-06 14:55:02

标签: azure-sql-database azure-sqldw sql-data-warehouse azure-sql-data-warehouse

对于相对较小的事实表(每张表平均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数据仓库的最佳索引编制和分配方式是什么?我们正在考虑使用TimeDimensionID字段将聚簇索引(DimensionID1,DimensionID2,DimensionID3和DimensionID4)用于索引和哈希分布。
  • 即使散列用于该字段,聚集索引也必须包含TimeDimensionID字段?
  • 这种设计是否正确?即使表实际上少于1亿行,我们还是应该使用COLUMN STORE INDEX吗?
  • 我们应该考虑为事实表使用复制表吗?

1 个答案:

答案 0 :(得分:0)

一些建议:

  • 如果可能,请将DimensionID从varchar移到int / bigint。您将获得更好的性能,更少的存储空间和更低的成本。
  • 暂时忘记聚簇索引。
  • 创建哈希散列的表,但不是按日期创建,这将使您的数据热点。
  • 将表创建为CLUSTERED COLUMNSTORE索引
  • 不复制您的FACT表,而是复制您的DIMENSIONS。