SQL Server "Einmal schreiben" Tabelle Clustered Index

Question

Ich habe eine ziemlich eindeutige Tabelle in einer SQL Server-Datenbank, die nicht "typischen" Nutzungskonventionen folgt und nach einem Ratschlag in Bezug auf den gruppierten Index sucht.

Dies ist ein erfundenes Beispiel, folgt aber den realen Daten ziemlich genau.

Die Tabelle hat einen 3-spaltigen Primärschlüssel, der wirklich Fremdschlüssel für andere Tabellen ist, und ein viertes Feld, das die relevanten Daten enthält. Für dieses Beispiel lassen Sie sich sagen, dass die Tabelle wie folgt aussieht:

CREATE TABLE [dbo].[WordCountsForPage](
[AuthorID] [int] NOT NULL, 
[BookID] [int] NOT NULL, 
[PageNumber] [int] NOT NULL, 
[WordCount] [int] NOT NULL 
) 

wir einen etwas hierarchischen Primärschlüssel So haben, mit den einzigartigen Daten, das vierte Feld zu sein.

In der realen Anwendung gibt es insgesamt 2,8 Milliarden mögliche Datensätze, aber das ist alles. Die Datensätze werden im laufenden Betrieb erstellt, während die Daten über die Zeit berechnet werden, und realistisch wird wahrscheinlich nur ein Viertel dieser Datensätze tatsächlich berechnet werden. Sie werden in der Datenbank gespeichert, da die Berechnung eine teure Operation ist und wir dies nur einmal für jede eindeutige Kombination tun wollen.

Heute werden die Daten tausende Male pro Minute gelesen, aber (zumindest für jetzt) ​​gibt es auch Hunderte von Einfügungen pro Minute, da sich die Tabelle selbst füllt (und dies wird noch einige Zeit dauern). Ich würde sagen, dass es für jeden Einsatz 10 Lesevorgänge gibt (heute).

Ich frage mich, ob wir aufgrund des Clustered-Index einen Performance-Hit auf alle diese Einsätze nehmen.

Der Clustered-Index macht Sinn "langfristig", da die Tabelle schließlich schreibgeschützt wird, aber es dauert einige Zeit, um dorthin zu gelangen.

Ich nehme an, ich könnte den Index während der schweren Einfügeperiode nicht geclustert machen und ihn in Cluster ändern, wenn die Tabelle gefüllt wird, aber wie bestimmen Sie, wann der Überkreuzungspunkt wäre (und wie kann ich informieren) ich selbst in der Zukunft, dass die "Zeit gekommen ist")?

Was ich wirklich brauche, ist ein konvertierbarer Index, der zu einer magischen Zeit in der Zukunft von nicht gruppierten zu gruppierten Gruppen übergeht.

Irgendwelche Vorschläge für den Umgang mit diesem?

Answer 1

Eigentlich würde ich mich nicht mit dem Versuch beschäftigen, zuerst einen nicht gruppierten Index zu haben und ihn später in einen gruppierten Index umzuwandeln (das ist eine wirklich chaotische Angelegenheit!).

als die Königin der Indexing, Kimberly Tripp, erklärt in ihrem The Clustered Index Debate Continues.., kann tatsächlich verbessern Ihre INSERT Leistung durch einen gruppierten Index für eine Tabelle mit!

Inserts sind schneller in einer gruppierten Tabelle (aber nur in der "richtigen" gruppierten Tabelle) als im Vergleich zu einem Heap. Das Hauptproblem besteht darin, dass Suchvorgänge in IAM/PFS zum Ermitteln des Einfügeorts in einem Heap langsamer sind als in einer gruppierten Tabelle (wobei der Einfügeort bekannt ist und durch den gruppierten Schlüssel definiert wird). Einfügungen sind schneller, wenn sie in eine Tabelle eingefügt werden, in der die Reihenfolge definiert ist (CL) und wo diese Reihenfolge ständig zunimmt.

Ein Heap ist eine Tabelle, für die kein Clustered-Index definiert ist.

In Anbetracht dieser, und die Mühe und Mühe, die es dauert, von Heap zu einer Tabelle mit einem Clustered-Index zu gehen - ich würde nicht einmal stören. Definieren Sie einfach Ihre Indizes und beginnen Sie, diese Tabelle zu verwenden!