我们使用遗留的平面txt文件并将它们插入到带有SSIS.The的舞台表中,出现了表是否应该具有主聚集键索引的问题。这是直接的平面文件导入,没有转换。
create table dbo.CustomerTransaction
(
CustomerName varchar(255),
PurchaseLocation varchar(255),
Productid int,
AmountSold float,
CustomerAddress varchar(50)
)
create table dbo.CustomerTransaction
(
-- discussion for adding this column
CustomerTransactionId int primary key clustered identity(1,1)
CustomerName varchar(255),
PurchaseLocation varchar(255),
Productid int,
AmountSold float,
CustomerAddress varchar(50)
)
-- both tables have nonclustered indexes
create nonclustered index idx_ProductId on dbo.CustomerTransaction(ProductId)
create nonclustered index idx_CustomerAddress on dbo.CustomerTransaction(CustomerAddress)
-- Actually have more indexes, tables above are just for sample 1)在ETL之前,暂存表被截断。没有删除和更新。只有插入。
truncate table dbo.[CustomerTransaction]2)然后禁用ETL之前的所有索引。
alter index all on dbo.[CustomerTransaction] DISABLE3)在默认快速加载的情况下进行SSIS数据流,所读取的数据流相当于批量插入。这里不发生转换。
4)然后在完成导入后重新启用所有索引。
alter index all on dbo.[CustomerTransaction] REBUILD5)然后在join和where子句上选择分期表,并将其放入datawarehouse。这就是为什么我们有非聚集索引。加载数据仓库后,我们将截断暂存表。
我们听到的消息是ETL的舞台表是好的堆。但是,还学习了堆的碎片和性能问题。阅读以下所有文章
我正在阅读相互矛盾的意见。一种说法是二叉树群集是导入ETL的维护难题。其他人说堆在碎片上有性能问题。我们的性能测试并没有显示出很大的差异,但是我们的数据以后可能会发生变化。所以我们需要做出一个好的设计决策。
https://sqlsunday.com/2016/09/01/compelling-case-for-heaps/
http://kejser.org/clustered-indexes-vs-heaps/
我们知道拥有身份的一个很好的理由是行标签,但问题主要是内部和表现。
发布于 2018-11-11 16:51:57
我们有一个类似的场景,最近将我们的暂存表从聚集索引切换到了堆。我们的第一个最大优势是,我们希望允许将并发的SSIS加载到相同的暂存表中。您可以使用聚集索引来实现这一点,但是您可能会遇到很多阻塞,特别是使用identity列。第二个最大的优势是减少了加载分阶段表的开销。我们发现,与聚集索引相比,堆上的负载要快得多。
我们的性能测试并没有显示出很大的差异,但是我们的数据以后可能会发生变化。所以我们需要做出一个好的设计决策。
你确定这是真的吗?在问题中,您说您在加载之前截断了暂存表。如果加载过程的某些部分发生了更改,那么在表为空时添加或删除聚集索引应该非常简单。不涉及数据移动。听起来似乎您不会从聚集索引中获得任何好处,所以我会尝试将其作为堆并监视性能。
发布于 2018-11-10 10:33:30
拥有标识列并不强制您将其用作聚集索引键。
你说的对,堆在这里很好。我认为托马斯·凯泽是这方面的权威,你把他列为你的资源之一是件好事。
至于堆中的碎片-不是仅在插入时发生的。
编辑:阅读这篇关于并行插入的文章,并注意堆和聚集索引之间的比较。https://blogs.msdn.microsoft.com/sqlcat/2016/07/21/real-world-parallel-insert-what-else-you-need-to-know/
https://dba.stackexchange.com/questions/222247
复制相似问题