web-dev-qa-db-fra.com

Tables de stadification SQL: clé primaire clôturée ou tas

Nous prenons des fichiers TXT plats héritables et les insérons dans des tables de scène avec SSIS. La question se pose si la table doit avoir une principale index de clé en cluster ou non. Ceci est une importation de fichiers plate directe sans transformation.

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) Avant ETL, les tables de mise en scène sont tronquées. Il n'y a pas de suppression ni de mises à jour. Seulement des insertions.

truncate table dbo.[CustomerTransaction]

2) Puis désactivez tous les index avant ETL.

alter index all on dbo.[CustomerTransaction] DISABLE

3) Nous effectuons un flux de données SSIS avec une charge rapide par défaut, que je lis est équivalente à l'insert en vrac. Aucune transformation ne se produit ici.

4) Ensuite, réenable tous les index après l'importation est effectué.

alter index all on dbo.[CustomerTransaction] REBUILD

5) Les tables de mise en scène sont ensuite sélectionnées sur la jointure et les clauses et placées dans Datawarehouse. C'est pourquoi nous avons des index non clusters. Après le chargement de l'entrepôt de données, nous tronquons les tables de mise en scène.

Nous entendons des informations sur lesquelles les tables d'étape ETL sont bonnes en tant que tas. Cependant, apprendre également des problèmes de fragmentation et de performance avec des tas. Lire tous les articles ci-dessous

Je lis des opinions contradictoires. Un arbre binaire regroupé est des maux de tête de maintenance pour importation ETL. Autre dit que les tas ont des problèmes de performance avec la fragmentation. Nos tests de performance ne montrent pas beaucoup de différence, mais nos données peuvent changer plus tard. Nous devons donc faire une bonne décision de conception.

https://sqlsunday.com/2016/09/01/compeling --Case-for-heaps/

https://www.msqlTips.com/sqlservertip/4961/sql-server-insert-performance-for-Clustered-indexes-vs-heap-tables/

http://kejser.org/clustered-indexes-vs-heaps/

https://www.red-gate.com/simple-talk/sql/database-administration/sql-server-heaps-and-their-fragmentation/

Nous savons une bonne raison d'avoir une identité, c'est pour l'étiquetage des lignes, mais la question est principalement sur les internes et les performances.

sql-serverdatabase-designsql-server-2016performanceetlperformance-tuning
6
user162241

Nous avons eu un scénario similaire et récemment commuté nos tables de stockage à partir d'index regroupés aux tas. Le premier grand avantage pour nous était que nous voulions permettre des charges SSIS simultanées dans la même table d'intermédiaire. Vous pouvez le faire avec un index en cluster, mais vous courez probablement dans beaucoup de blocage, en particulier avec une colonne d'identité. Le deuxième grand avantage était de réduire les frais généraux de chargement des tables de mise en scène. Nous avons constaté que nos charges allaient beaucoup plus vite sur des tas par rapport aux index en cluster.

Nos tests de performance ne montrent pas beaucoup de différence, mais nos données peuvent changer plus tard. Nous devons donc faire une bonne décision de conception.

Êtes-vous sûr que cela est vrai? Dans la question, vous dites que vous tronquez vos tables de stockage avant la charge. Si une partie de votre processus de charge change, il doit être très simple d'ajouter ou de supprimer un index en cluster pendant que les tables sont vides. Il n'y a pas de mouvement de données impliqué. Cela ne sonne pas comme si vous bénéficiez d'un index en cluster. Je vais donc l'essayer comme un tas et surveiller les performances.

2
Joe Obbish

Avoir une colonne d'identité ne vous oblige pas à l'utiliser comme clé d'index en cluster.

Vous avez raison que les tas fonctionnent bien ici. Je considérerais que Thomas Kejser soit l'autorité sur le sujet et c'est bon que vous l'avez énuméré comme une de vos ressources.

En ce qui concerne la fragmentation dans les tas - ne se produit pas sur INSERT-SEULEMENT.

EDIT: Parcourez cet article sur Insertion parallèle et remarquez les comparaisons entre les tas et les index en cluster. https://blogs.msdn.microsoft.com/sqlcat/2016/07/21/real-world-parallel-insert-Quelle-hyou-need-a-nom/

5
Rob Farley