集群列存储索引和外键

我正在使用索引对数据仓库进行性能优化。我对SQL Server 2014相当陌生，Microsoft描述了以下内容：

“我们将群集列存储索引视为存储大型数据仓库事实表的标准，并期望在大多数数据仓库场景中使用该索引。由于群集列存储索引是可更新的，因此您的工作负载可以执行大量的插入，更新，和删除操作。” http://msdn.microsoft.com/en-us/library/gg492088.aspx

但是，如果您进一步阅读文档，则会发现存在以下限制和限制：

“不能具有唯一性约束，主键约束或外键约束。”

这让我很困惑！出于各种原因（数据完整性，语义层可见的关系...），在数据仓库中具有外键是一种很好的做法（不是强制性的）

因此，Microsoft提倡针对数据仓库方案使用集群列存储索引。但是，它不能处理外键关系？！

我对此是否正确？您还建议其他哪些方法？过去，我在数据仓库场景中使用了非集群列存储索引，并为数据负载进行了删除和重建。但是，SQL Server 2014然后没有为数据仓库添加任何真正的新价值？

— 溢出堆栈
source

随着功能的成熟，您将看到越来越多的功能受支持（哎呀，2012年，列存储索引是只读的！）。同时，您将获得一个折衷-出色的性能，但有局限性，或相同或相同。我也不相信他们的意思是说DW中的每个表都应具有群集的列存储索引，并且任何表都不应具有任何约束-任何DW中的表数量可能有限，这会给您带来巨大的冲击。降压。

— 亚伦·伯特兰

当心-它可以处理联接。加入完全不需要FK关系。它在那里处理参照完整性-很好，但是可以在数据仓库中省略。是的，是有风险的，但是也会带来性能提升。

— TomTom

还有-“没有真正的新价值”？您的意思是可写和群集听起来对您来说不是改善吗？让用户能够实时查询数据，而不必等待删除和重建以获取更多当前数据，这对您的用户来说似乎不是一件好事，对您而言却减少了维护工作？耸耸肩

— 亚伦·伯特兰

您可以通过创建索引视图来拥有（唯一）索引。看来索引维护的基础结构已经存在。只是普通索引尚未实现。

— usr

@AaronBertrand在具有带外键的事实表的DWH方案中，群集列存储索引不起作用。这与Microsoft期望将其作为存储大型事实表的标准形成鲜明对比。我希望你能证明我错了...？因为我喜欢SQL Server。

— 2014年

Answers:

您在这里有很多问题：

问：（缺少外键）使我非常困惑！出于多种原因（数据完整性，语义层可见的关系等），在DWH中使用Fk是一种好习惯（并非强制性）。

答：正确，在数据仓库中使用外键通常是一个好习惯。但是，群集的列存储索引尚不支持该功能。

问：因此，MS提倡针对DWH方案使用群集列存储索引，但是它不能处理FK关系？

答：微软为您提供工具。如何使用这些工具取决于您。

如果最大的挑战是数据仓库中缺乏数据完整性，那么您想要的工具是带有外键的常规表。

如果最大的挑战是查询性能，并且您愿意在加载过程中检查自己的数据完整性，那么所需的工具就是群集的列存储索引。

问：但是SQL 2014却没有为DWH添加真正的新价值？

答：幸运的是，群集列存储并不是SQL Server 2014中唯一的新功能。例如，查看新的基数估计器。

问：为什么对我最喜欢的功能的实施方式如此生气和痛苦？

答：您抓住了我-您并未真正提出这个问题-但我还是会回答。欢迎来到第三方软件的世界，在这里，并非所有内容都是根据您的确切规范构建的。如果您对想要在Microsoft产品中看到的更改充满热情，请访问Connect.Microsoft.com。在他们的反馈过程中，您可以提交更改，其他人可以将其投票，然后产品团队将其读取并告诉您为什么他们不实施。有时。大多数时候，他们只是将其标记为“无法修复，无法在我的计算机上运行”，但是，有时候您确实会得到一些答案。

— 布伦特·奥扎尔
source

“正确，在数据仓库中使用外键通常是一个好习惯。”-> SQLCAT-构建大型关系数据仓库的十大最佳实践 ……“为每个外键构建非聚集索引。” ->无需执行链接中提到的FK关系，并且由于列存储，非CI也是多余的，所以这将指向事实表中不需要FK，您是否同意？对您对此的想法感兴趣。

— 阿德里安·托里

...并且对于维：“避免在事实表与维表之间强制使用外键关系，以加快数据加载速度。您可以使用NOCHECK创建外键约束来记录这些关系；但不要强制执行。确保数据完整性通过“转换查找”，或在数据源处执行数据完整性检查”

— Adrian Torrie 2015年

我可以理解，您会感觉到一些自己缺少的东西。但这仅仅是因为它们不见了。

但是，当外键只是一个概念（我们在当时通过触发器实现）时，而不是诸如约束之类的物理实现时，SQL Server被成功使用。声明式引用完整性至少在SQL Server 7.0中存在，但比当前的实现弱得多。

关于Clustered ColumnStore Index的值，它确实提供了索引并且行是可更新的。您可能会发现此讨论很有价值：http : //sqlwithmanoj.com/2014/07/24/maintaining-uniqueness-with-clustered-columnstore-index-sql-server-2014/

Manoj指出，有一种方法可以在此表的顶部创建索引/材质化视图，并将聚类键作为PK（表/视图的第一列）。当然，是否适合您是您必须做出的决定。

但是，正如亚伦·伯特兰（Aaron Bertrand）和汤姆·汤姆（TomTom）所说，这都是为了提高性能。如果您能够解决与您有关的其他问题（我相信它们是可以解决的），那么您将获得很多好处。因此，请使用ColumnStore自己可以执行和管理缺少的功能。

— 皇家空军
source

这个问题与SQL 2014有关，但是我想根据SQL 2016对列存储索引所做的更改来提供其他信息，因为可能很难理清不同版本中的限制，并且这个问题在Google上仍然相当高：

对于SQL 2016，Microsoft描述了一种使用非聚集btree索引（现在可以将其作为集群列存储表上的辅助索引添加）强制外键约束的方法，前提是该约束被添加到列存储索引之前： https：// docs .microsoft.com / zh-CN / sql / relational-databases / indexes / columnstore-indexes-design-guidance

Niko Neugebauer也有一篇关于此的博客文章。实际上有可能直接在列存储表上创建唯一/外部约束（我一直在工作中采用这种方法）：http ://www.nikoport.com/2015/09/15/columnstore-indexes-part-66- sql-server-2016中的更多群集列存储改进/

— 己烯
source