mar*_*cob 6 sql-server sql-server-2014 columnstore
阅读有关SQL Server 2014中的聚簇列存储索引的信息,我想知道是否有一个包含大量列的表仍然是一种反模式.目前为了缓解具有大量列的单个表的问题,我使用垂直分区但是具有可用的聚簇列存储索引,这不应该是必需的.这是正确的还是我错过了什么？
示例: 让我们以性能计数器的日志为例,原始数据可能具有以下结构:
????????????????????????????????????????????????????????????????? ? Time ? Perf1 ? Perf2 ? ... ? ... ? ... ? Perf1000 ? ????????????????????????????????????????????????????????????????? ? 2013-11-05 00:01 ? 1 ? 5 ? ? ? ? 9 ? ? 2013-11-05 00:01 ? 2 ? 9 ? ? ? ? 9 ? ? 2013-11-05 00:01 ? 3 ? 2 ? ? ? ? 9 ? ? 2013-11-05 00:01 ? 4 ? 3 ? ? ? ? 9 ? ?????????????????????????????????????????????????????????????????
拥有1000列这样的表是邪恶的,因为一行很可能跨越多个页面,因为通常不太可能对所有度量感兴趣,但查询总是会产生IO成本等等.等等..解决这种垂直分区通常会有所帮助,例如,可以按类别(CPU,RAM等)对不同表中的性能计数器进行分区.
相反具有这样的表作为一个聚集列存储索引不应该出现这样的问题,因为数据将被存储列明智的,涉及对每个查询的IO将大约只请求列,仅此而已不管列的总数桌子.
它当然没有水平存储那么“糟糕”，但 1000 有点超出了极限。我们的数据仓库通常有包含 100 - 200 列的表，并且它们通过列存储索引足够快速。假设您有完美的列存储索引，每个查询应该只查看特定的垂直索引，因此非常高效。但是，如果您的列存储索引对于查询来说不是最佳的，那么 SQL Server 必须在索引之间进行一些跳转，而这些跳转并不好。
这方面没有经验法则。您必须在您的特定环境中进行基准测试才能回答这个问题。