我认为columnstores的工作方式是,如果您将102,400多行批量加载到一个列存储的分布中,它会自动压缩它。我没有在Azure SQL DW中观察到它。
我正在做以下CTAS声明:
create table ColumnstoreDemoCTAS
WITH (CLUSTERED COLUMNSTORE INDEX, DISTRIBUTION=HASH(Column1))
AS
select top 102401 cast(1 as int) as Column1, f.*
from FactInternetSales f
cross join sys.objects o1
cross join sys.objects o2
现在我检查列存储行组的状态:
select t.name
,NI.distribution_id
,CSRowGroups.state_description
,CSRowGroups.total_rows
,CSRowGroups.deleted_rows
FROM sys.tables AS t
JOIN sys.indexes AS i
ON t.object_id = i.object_id
JOIN sys.pdw_index_mappings AS IndexMap
ON i.object_id = IndexMap.object_id
AND i.index_id = IndexMap.index_id
JOIN sys.pdw_nodes_indexes AS NI
ON IndexMap.physical_name = NI.name
AND IndexMap.index_id = NI.index_id
LEFT JOIN sys.pdw_nodes_column_store_row_groups AS CSRowGroups
ON CSRowGroups.object_id = NI.object_id
AND CSRowGroups.pdw_node_id = NI.pdw_node_id
AND CSRowGroups.distribution_id = NI.distribution_id
AND CSRowGroups.index_id = NI.index_id
WHERE t.name = 'ColumnstoreDemoCTAS'
ORDER BY 1,2,3,4 desc;
我最终得到一个包含102401行的OPEN行组。我是否误解了列店的这种行为? Azure SQL DW是否与众不同?
如果我从SSIS批量插入相同数量的行作为一个缓冲区,我会看到相同的行为。
我尝试了Drew建议插入超过650万行,我仍然最终得到所有OPEN行存储:
create table ColumnstoreDemoWide
WITH (CLUSTERED COLUMNSTORE INDEX, DISTRIBUTION=HASH(Column1))
AS
select top 7000000 ROW_NUMBER() OVER (ORDER BY f.ProductKey) as Column1, f.*
from FactInternetSales f
cross join sys.objects o
cross join sys.objects o2
cross join sys.objects o3
答案 0 :(得分:2)
将数据放在群集列存储中不会减少返回的行数。相反,它将压缩存储的数据,以便占用更少的磁盘空间。这意味着查询移动的数据越少,存储费用就越低,但结果会保持不变。话虽这么说,您的数据目前驻留在deltastore中,因此您不会看到任何压缩。由于SQL DW的体系结构,我们将数据分成若干组。这使我们可以更轻松地并行化计算和扩展,但也意味着每个组都拥有它自己的columnstore / deltastore,因此您需要加载更多行以获得压缩优势。
除了分发结构之外,与SQL数据仓库相比,SQL Server的阈值也有所不同。对于DW,阈值为1,048,576,直到缺陷得到解决,如@JRJ所述。现在,Azure SQL DW的阈值与SQL系列的其余部分一样为120,400。一旦您的分布中的行超过此值,您就会看到您的行已被压缩。
您可以在此处找到有关加载到列存储的更多信息:https://msdn.microsoft.com/en-US/library/dn935008.aspx
答案 1 :(得分:1)
这是服务中的缺陷。修复程序目前正在推出。例如,如果您在日本西部尝试这样做,您将看到行为正如您所期望的那样。