我应该将 nvarchar(max) 维度放在我的数据仓库中的什么位置？

Question

我正在为新的数据仓库设计 ERD。

• SQL Server 2016
• “事实”表的聚集列存储索引
• 松散星型模式

我将“事实”放在引号中并说“松散星型模式”，因为使用聚集列存储，我可以将许多维度直接放入“事实”表中，而无需担心行宽的典型问题。我的许多维度都进入了“事实”表。我正在创建一些维度表和代理键，但前提是除了暗淡描述本身之外，暗淡还具有属性。

这给我带来了一些非常广泛、高基数的领域，即nvarchar(max). 不必太深入，将这些字段视为非规范化列表。我需要针对我的一个数据源的粒度对列表进行非规范化。我确实在另一个事实表中对其进行了规范化，但不是我在此数据源中出现的事实表。

用户需要这些字段来搜索我正在显示的数据集市中的关键字。在我当前的设计中，它们位于聚集列存储“事实”表中。用户将经常查询事实表而不触及nvarchar(max)字段。

有没有比聚集列存储表更正确的将宽维度放入我的数据仓库的地方？

Joe Obbish告诉我，我们目前无法放入nvarchar(max)CCI。创建一个 LOB 表作为我的“事实”表的扩展对我来说是最佳实践吗？

我们将来可能会添加其他语言。目前和在可预见的期限内，该nvarchar栏仅包含英语。

Answer 1

Microsoft 建议对大型数据仓库表使用 CCI，但有一些注意事项，包括：

在以下情况下不要使用聚集列存储索引：

• 该表需要 varchar(max)、nvarchar(max) 或 varbinary(max) 数据类型。或者，设计列存储索引，使其不包含这些列。

简而言之，您的选择是完全放弃VARCHAR(MAX)列存储，在不包含该列的表上创建非聚集列存储索引，或者将 LOB 列移动到单独的表。您说最终用户有时会在不查询VARCHAR(MAX)列的情况下访问表，因此我会尽可能尝试使用列存储，以便这些查询可以获得全部好处。

如果我正在设计它，我的第一次尝试是使用非聚集列存储索引测试您的工作负载，该索引包括除列之外的每一列VARCHAR(MAX)。这是一个单独的索引，因此您将为列带来额外的存储空间，但如果您看到典型的 CCI 压缩率，它只会额外增加 10%。这是最简单的设计，将使您能够利用 SQL Server 2017 的可用性将VARCHAR(MAX)列包含在聚集列存储索引中。Niko Neugebauer 写了一篇关于在 SQL Server vNext 中使用 LOB 数据对 CCI 进行一些测试的博客文章，您可以在此处找到该文章。