在包含350亿行的列存储索引表上重新创建索引

Question

我有一个大表，我需要重建索引。这个表配置了集群列存储索引(CCI)，我们意识到我们需要根据特定的用例对数据进行排序。

用户执行日期范围和相等性查询，但由于数据没有按照他们希望得到的方式排序，因此查询不是最优的。SQL Advisory Team建议将数据组织在右行组中，以便查询可以从取消行组中受益。

表说明:

• 按时间戳1分区，每月PF
• 总行数:310亿
• Est行大小:60字节
• 测试表大小:600gb

表定义:

CREATE TABLE [dbo].[Table1](
    [PkId] [int] NOT NULL,
    [FKId1] [smallint] NOT NULL,
    [FKId2] [int] NOT NULL,
    [FKId3] [int] NOT NULL,
    [FKId4] [int] NOT NULL,
    [Timestamp1] [datetime2](0) NOT NULL,
    [Measurement1] [real] NULL,
    [Measurement2] [real] NULL,
    [Measurement3] [real] NULL,
    [Measurement4] [real] NULL,
    [Measurement5] [real] NULL,
    [Timestamp2] [datetime2](3) NULL,
    [TimeZoneOffset] [tinyint] NULL
)
CREATE CLUSTERED COLUMNSTORE INDEX [Table1_ColumnStoreIndex] ON [dbo].[Table1] WITH (DROP_EXISTING = OFF)
GO

环境:

SQL Server 2014 Enterprise edition .
• 8核，32 GB RAM
• VMWare高性能平台

我的策略是:

1. 删除现有CCI
2. 创建具有正确列的普通集群行索引，这将对数据进行排序
重新创建DROP EXISTING = OFF的CCI。这将把现有的CRI转换为CCI。

我的问题是:

是否有意义重建索引或只是重新加载数据?重新加载可能需要一个月的时间来完成，而重建索引可能需要同样多的时间，也许…
1. 如果我删除现有的CCI，表将扩展，因为它可能不再被压缩了?

Answer 1

310亿行是31,000个完美的行组，行组只是另一个水平分区，因此何时以及如何加载数据非常重要。SQL 2014只支持离线索引构建。

在考虑创建索引和重新加载时，有一些缺点和优点:

• 创建索引是一个单一的操作，所以如果它在任何时候失败，你就失去了你的进度。对于你的数据量，我不建议你这么做。
• 索引构建将创建主字典，因此对于低基数字典编码的列是有益的。
• 批量加载不会创建主字典，但如果由于某些原因批量加载失败，可以重新加载数据。

如果你提供了足够的资源，索引构建和批量加载都将是并行的，这意味着你从基本聚集索引开始的排序将不会被完美地保留，这只是需要注意的事情;在你的数据规模下，如果你有几个重叠的行组，那就没关系了。

如果您的数据将经历更新/删除，并且您重新组织(从SQL19也将进行元组移动)，您的排序可能会随着时间的推移而降低。

我将在date_range列上创建一个Clustered Index order和分区，以便每个分区有50-200个行组(做一些实验)。然后，您可以创建一个分区对齐的Clustered Columnstore Index并一次在一个分区中切换，分区切换将触发索引构建，因此您将从主字典中获益，如果您最终在分区上进行更新/删除，您可以通过重建分区而不是整个表来修复索引质量。如果您决定使用reorganize，那么您仍然需要维护一定程度的排序，因为行组只会在同一个分区内合并。