it-swarm.com.de

Was sind gültige Verwendungsszenarien für HEAP-Tabellen?

Ich führe derzeit einige Datenimporte in ein Altsystem durch und habe festgestellt, dass dieses System keinen einzelnen Clustered-Index verwendet. Eine schnelle Google-Suche führte mich in das Konzept der HEAP-Tabellen ein. Jetzt bin ich gespannt, in welchen Verwendungsszenarien eine HEAP-Tabelle einer Cluster-Tabelle vorgezogen werden sollte.

Soweit ich verstanden habe, wäre eine HEAP-Tabelle nur für Audit-Tabellen nützlich und/oder wenn Einfügungen weitaus häufiger vorkommen als Auswahlen. Dies würde Speicherplatz und Festplatten-E/A sparen, da kein Clustered-Index verwaltet werden muss und die zusätzliche Fragmentierung aufgrund der sehr seltenen Lesevorgänge kein Problem darstellt.

31
marc.d

Die einzigen gültigen Verwendungen sind für

  • staging-Tabellen, die in Import/Export/ETL-Prozessen verwendet werden.
  • ad-hoc-, temporäre und kurzfristige Sicherung von Tabellen mit SELECT * INTO..

Staging-Tabellen sind normalerweise ziemlich flach und werden vor/nach der Verwendung abgeschnitten.

Beachten Sie, dass ein Clustered-Index im Vergleich zur Datengröße normalerweise nur wenige kleine Daten enthält: Die Daten sind die niedrigste Ebene der Indexstruktur.

Heap-Tabellen haben auch Probleme. Zumindest diese:

Siehe auch

22
gbn

Wichtige Überlegungen

Ich sehe einen wichtigen Vorteil für Heaps und einen für Clustertabellen sowie eine dritte Überlegung, die in beide Richtungen gehen kann.

  • Ein Haufen erspart Ihnen eine Indirektionsebene. Indizes enthalten Zeilen-IDs, die direkt (nicht wirklich, aber so direkt wie möglich) auf einen Speicherort verweisen. Daher sollte eine Indexsuche für einen Heap ungefähr die Hälfte einer nicht gruppierten Indexsuche für eine gruppierte Tabelle kosten.

  • Ein Clustered-Index wird dank eines (fast) freien Index per se sortiert. Da sich der Clustering-Index in der physischen Reihenfolge der Daten widerspiegelt, nimmt er relativ wenig Platz über den eigentlichen Daten selbst ein, die Sie natürlich trotzdem speichern müssen. Da es physisch geordnet ist, kann ein Entfernungsscan für diesen Index sehr effizient zum Startpunkt und dann zum Endpunkt zippen.

  • Indizes auf Heaps verweisen auf RIDs, die 64 Bit sind. Wie bereits erwähnt, verweisen die nicht gruppierten Indizes in einer gruppierten Tabelle auf den Clustering-Schlüssel, der kleiner (32-Bit INT), gleich (64-Bit BIGINT) oder sein kann größer (eine 48-Bit-Version DATETIME2() plus eine 32-Bit-GUID INT oder eine 128-Bit-GUID). Offensichtlich führt eine breitere Referenz zu größeren und teureren Indizes.

Platzanforderungen

Mit diesen beiden Tabellen:

CREATE TABLE TmpClustered
(
ID1 INT NOT NULL,
ID2 INT NOT NULL
)
ALTER TABLE TmpClustered ADD CONSTRAINT PK_Tmp1 PRIMARY KEY CLUSTERED (ID1)
CREATE UNIQUE INDEX UQ_Tmp1 ON TmpClustered (ID2)

CREATE TABLE TmpNonClustered
(
ID1 INT NOT NULL,
ID2 INT NOT NULL
)
ALTER TABLE TmpNonClustered ADD CONSTRAINT PK_Tmp2 PRIMARY KEY NONCLUSTERED (ID1)
CREATE UNIQUE INDEX UQ_Tmp2 ON TmpNonClustered (ID2)

... jeder mit 8,7 Millionen Datensätzen gefüllt war, benötigte der Speicherplatz 150 MB für Daten für beide; 120 MB für die Indizes der gruppierten Tabelle, 310 MB für die Indizes der nicht gruppierten Tabelle. Dies zeigt, dass der Clustered-Index schmaler als ein RID ist und dass der Clustering-Index meistens ein "Werbegeschenk" ist. Ohne die eindeutigen Indizes auf ID2 sinkt der erforderliche Indexspeicherplatz für die nicht gruppierte Tabelle auf 155 MB (die Hälfte, wie zu erwarten), aber nur 150 KB für die gruppierte PK - fast nichts.

Ein nicht gruppierter Index eines 32-Bit-Felds in einer gruppierten Tabelle mit einem 32-Bit-Index (nominell insgesamt 64 Bit) benötigte also 120 MB, während ein Index eines 32-Bit-Felds in einem Heap mit einem 64-Bit-Feld RID (nominell insgesamt 96 Bit) benötigte 155 MB, etwas weniger als die 50% ige Erhöhung, die man naiv von 64-Bit- auf 96-Bit-Schlüssel erwarten würde, aber natürlich gibt es Overhead, der den effektiven Größenunterschied verringert.

Das Auffüllen der beiden Tabellen und das Erstellen ihrer Indizes dauerte für jede Tabelle gleich lange. Bei einfachen Tests mit Scans oder Suchvorgängen stellte ich keine wesentlichen Leistungsunterschiede zwischen den Tabellen fest, die mit dem Microsoft-Whitepaper übereinstimmen, das von gbn hilfreich verknüpft wurde. Das Papier zeigt einen signifikanten Unterschied für den gleichzeitigen Zugriff. Ich bin mir nicht sicher, warum das passiert, hoffentlich jemand mit mehr Erfahrung als ich mit hochvolumigen OLTP -Systemen können es uns sagen.

Das Hinzufügen von ~ 40 Bytes zufälliger Daten variabler Länge änderte diese Äquivalenz nicht nennenswert. Das Ersetzen der INT durch breite UUIDs war ebenfalls nicht möglich (jede Tabelle wurde in etwa gleichem Maße verlangsamt). Ihr Kilometerstand kann variieren, aber in den meisten Fällen ist ob ein Index verfügbar, wichtiger als welche Art.

Krimskrams

Wenn Sie einen Bereichsscan für einen nicht gruppierten Index durchführen - entweder weil die Tabelle ein Heap ist oder der Index nicht der gruppierte Index -, müssen Sie den Index scannen und dann für jeden Treffer eine Suche anhand der Tabelle durchführen. Dies kann sehr teuer sein, daher ist es manchmal billiger, nur die Tabelle zu scannen. Sie können dies jedoch mit einem Deckungsindex umgehen. Dies gilt unabhängig davon, ob Sie Ihre Tabelle geclustert haben oder nicht.

Wie @gbn betonte, gibt es keine einfache Möglichkeit, einen Haufen zu komprimieren. Wenn Ihre Tabelle jedoch im Laufe der Zeit allmählich zunimmt - ein sehr häufiger Fall -, entsteht wenig Verschwendung, da der durch Löschungen freiwerdende Speicherplatz durch neue Daten gefüllt wird.

Einige der Diskussionen zwischen Heap- und Clustertabellen, die ich gesehen habe, machen ein merkwürdiges Strohmann-Argument, dass ein Heap ohne Indizes einer Clustertabelle unterlegen ist, da er immer einen Tabellenscan erfordert. Dies ist sicherlich richtig, aber der aussagekräftigere Vergleich ist "große, gut indizierte Clustertabelle" mit "großer, gut indizierter Heap". Wenn Ihre Tabelle sehr klein ist oder Sie immer Tabellenscans durchführen, spielt es keine Rolle, ob Sie sie gruppieren oder nicht.

Da jeder Index in einer Clustertabelle auf den Clustering-Index verweist, decken sie praktisch alle Indizes ab. Eine Abfrage, die auf eine indizierte Spalte und die Cluster-Spalte (n) verweist, kann einen Index-Scan ohne Tabellensuche durchführen. Dies ist im Allgemeinen nicht hilfreich, wenn Ihr Clustering-Index ein synthetischer Schlüssel ist. Wenn es sich jedoch um einen Geschäftsschlüssel handelt, den Sie ohnehin abrufen müssen, handelt es sich um eine nette Funktion.

TL; DR

Ich bin ein Data Warehousing-Typ, kein OLTP Experte. Für Faktentabellen verwende ich fast immer einen Clustering-Index für das Feld, für das meistens Bereichsscans erforderlich sind, normalerweise ein Datumsfeld Dimensionstabellen, die ich auf der PK gruppiere, damit sie für Zusammenführungsverknüpfungen mit Faktentabellen vorsortiert sind.

Es gibt mehrere Gründe, Clustering-Indizes zu verwenden. Wenn jedoch keiner dieser Gründe zutrifft, lohnt sich der Overhead möglicherweise nicht. Ich vermute, es gibt eine Menge "Wir haben es immer so gemacht" und "Es ist nur eine bewährte Methode" hinter Leuten, die Clustered-Indizes universell verwenden. Versuchen Sie beide mit Ihren Daten und Ihren Laden und sehen Sie, was am besten funktioniert.

9

Ich denke, "Die einzig gültige Verwendung ist das Staging von Tabellen, die in Import/Export/ETL-Prozessen verwendet werden", ist, gelinde gesagt, ein wenig einschränkend. Sie müssen den erwarteten Anwendungsfall eines bestimmten Systems nehmen und dann basierend auf den Vorzügen von Heaps oder indexorganisierten Tabellen auswählen (ich weiß, ein Oracle-Begriff, aber er beschreibt ihn gut).

Unser Lager lädt täglich ca. 1,5 Milliarden Zeilen und muss hochgradig gleichzeitige Schreib- und Verarbeitungsvorgänge sowie Lesevorgänge unterstützen. Der relationale Speicher unterstützt eine OLAP -Datenbank, und daher handelt es sich bei den Lesevorgängen in der Regel hauptsächlich um Tabellenscans. Die generierten Berichte und nachgeschalteten Feeds sind im Allgemeinen auch nicht selektiv genug, sodass ein Index nützlich wäre Das System unterstützt ein verschiebbares Datenfenster. Sobald eine Tabelle geladen ist, schreiben wir selten wieder darauf. Angesichts der eher schlechten Implementierung der Tabellenpartitionierung, die Sch-M-Sperren für Partitionsaufteilungen, -wechsel und -zusammenführungen im Vergleich zu Sch-S-Sperren für Lesevorgänge usw. erfordert. Das System musste viele Tabellen verwenden, obwohl wir auch einige partitionierte Tabellen haben. Die Verwendung vieler Tabellen erleichtert die Segmentierung von Daten und Bereinigungszyklen und reduziert gleichzeitig Konflikte.

Daher verarbeitet der zusätzliche Overhead einer indexorganisierten Tabelle (gruppierte Tabelle) in einigen beliebigen Spalten die Möglichkeit, die Partitionen OLAP] zu verarbeiten und einige Tabellenscanabfragen durchzuführen und dann 3 Tage später löschen bedeutet, dass es sich einfach nicht lohnt. Beachten Sie, dass in unserem Fall die Daten von einem großen Rastercluster zurückkommen, sodass auch keine Reihenfolge für die Daten vorliegt, sodass das Einfügen in eine Tabelle mit einem Clustered-Index eingeführt werden könnte andere Probleme wie "Hot Spots" und Seitenaufteilungen und dergleichen.

Außerdem halte ich das Argument, dass Seiten verstreut sind, für etwas unaufrichtig. Bei Clustered-Indizes können die Seiten auch über die Datei verteilt sein. Es ist nur so, dass nach der Neuindizierung (unter der Annahme von mehr als 1000 Seiten) dies möglicherweise besser ist als ein Heap, aber dann mussten Sie auch neu indizieren.

Es ist auch möglich, Platz mit spärlichen Spalten und Komprimierung zu sparen, wenn dies ein Problem darstellt. Es ist richtig, dass in einigen Fällen die Auswahl einer Tabelle mit einem Clustered-Index schneller sein kann, aber Sie müssen dies mit den Ressourcen abwägen, die zum Laden und Verwalten erforderlich sind.

[Bearbeiten] Ich sollte wahrscheinlich klarstellen, dass nur unsere nicht partitionierten Faktentabellen Haufen sind. Partitionierte Tabellen und Dimensionstabellen verfügen alle über gruppierte Indizes, um effiziente Suchvorgänge usw. zu unterstützen. [Bearbeiten2] 2,5 bis 1,5 Milliarden korrigiert. Tut, diese beiden Zahlen sind nebeneinander. Was passiert, wenn Sie Antworten auf einem Telefon eingeben?.

5
Phil Stephenson