Clustered Columnstore-Indizes und Fremdschlüssel

Ich optimiere ein Data Warehouse mithilfe von Indizes. Ich bin ziemlich neu in SQL Server 2014. Microsoft beschreibt Folgendes:

"Wir betrachten den Clustered-Columnstore-Index als Standard für das Speichern von Faktentabellen für große Data-Warehouses und erwarten, dass er in den meisten Data-Warehousing-Szenarien verwendet wird. Da der Clustered-Columnstore-Index aktualisierbar ist, kann Ihre Workload eine große Anzahl von Einfüge-, Aktualisierungs- und löschen. " http://msdn.microsoft.com/en-us/library/gg492088.aspx

Wenn Sie jedoch weiter in der Dokumentation lesen, finden Sie unter Einschränkungen und Einschränkungen:

Msgstr "Kann keine eindeutigen Bedingungen, Primärschlüsselbedingungen oder Fremdschlüsselbedingungen haben."

Das verwirrt mich sehr! Es wird empfohlen (nicht obligatorisch), Fremdschlüssel aus verschiedenen Gründen im Data Warehouse zu haben (Datenintegrität, für die semantische Ebene sichtbare Beziehungen ...).

Microsoft empfiehlt daher Clustered Columnstore-Indizes für Data Warehouse-Szenarien. Es kann jedoch keine Fremdschlüsselbeziehungen verarbeiten.

Habe ich Recht? Welche weiteren Ansätze würden Sie empfehlen? In der Vergangenheit habe ich in Data Warehouse-Szenarien einen nicht gruppierten Columnstore-Index verwendet, mit Drop und Rebuild für das Laden von Daten. Allerdings fügt SQL Server 2014 dann keinen wirklichen neuen Wert für Data Warehouses hinzu?

Sie haben hier viele Fragen:

F: (Das Fehlen von Fremdschlüsseln) verwirrt mich sehr! Es ist eine gute Praxis (nicht obligatorisch), Fk's aus verschiedenen Gründen in der DWH zu haben (Datenintegrität, für die semantische Schicht sichtbare Beziehungen, ....).

A: Richtig, es ist normalerweise eine gute Praxis, Fremdschlüssel in einem Data Warehouse zu haben. Clustered Columnstore-Indizes unterstützen dies jedoch noch nicht.

F: Also befürwortet MS Clustered Column-Speicherindizes für DWH-Szenarien. Sie können jedoch keine FK-Beziehungen verarbeiten ?!

A: Microsoft stellt Ihnen Tools zur Verfügung. Es liegt an Ihnen, wie Sie diese Tools verwenden.

Wenn Ihre größte Herausforderung in der mangelnden Datenintegrität in Ihrem Data Warehouse besteht, ist das gewünschte Tool die Verwendung herkömmlicher Tabellen mit Fremdschlüsseln.

Wenn Ihre größte Herausforderung die Abfrageleistung ist und Sie bereit sind, Ihre eigene Datenintegrität als Teil des Ladeprozesses zu überprüfen, ist das gewünschte Tool die Clustered-Columnstore-Indexe.

F: Allerdings fügt SQL 2014 dann keinen echten neuen Wert für DWH hinzu?

A: Zum Glück war der Clustered Columnstore nicht das einzige neue Feature in SQL Server 2014. Sehen Sie sich beispielsweise den neuen Cardinality Estimator an.

F: Warum bin ich so wütend und bitter darüber, wie mein Lieblingsfeature implementiert wurde?

A: Du hast mich erwischt - du hast diese Frage nicht wirklich gestellt - aber ich werde sie trotzdem beantworten. Willkommen in der Welt der Software von Drittanbietern, in der nicht alles nach Ihren genauen Spezifikationen erstellt wird. Wenn Sie leidenschaftlich an einer Änderung interessiert sind , die Sie in einem Microsoft-Produkt sehen möchten , lesen Sie Connect.Microsoft.com . Es ist ihr Feedback-Prozess, bei dem Sie eine Änderung einreichen können, andere Personen sie abstimmen können und das Produktteam sie dann liest und Ihnen mitteilt, warum sie sie nicht implementieren. Manchmal. Meistens markieren sie es einfach als "Nicht reparierbar, funktioniert auf meinem Computer", aber hey, manchmal erhalten Sie einige Antworten.

Ich kann verstehen, dass Sie das Gefühl haben, Teile, an die Sie gewöhnt sind, fehlen. Das liegt aber nur daran, dass sie fehlen.

Trotzdem wurde SQL Server erfolgreich eingesetzt, als Fremdschlüssel nur ein Konzept waren (das wir damals durch Trigger implementiert haben), keine physische Implementierung wie eine Einschränkung. Die deklarative referenzielle Integrität war zumindest bei SQL Server 7.0 vorhanden, jedoch viel schwächer als bei der aktuellen Implementierung.

In Bezug auf den Wert des Clustered ColumnStore-Index wird ein Index bereitgestellt, und die Zeilen können aktualisiert werden. Sie finden diese Diskussion möglicherweise hilfreich: http://sqlwithmanoj.com/2014/07/24/maintaining-uniqueness-with-clustered-columnstore-index-sql-server-2014/

Manoj weist darauf hin, dass es eine Möglichkeit gibt, eine indizierte / materialisierte Ansicht über dieser Tabelle mit dem Clustering-Schlüssel als PK (1. Spalte der Tabelle / Ansicht) zu erstellen. Ob das zu Ihnen passt, ist natürlich eine Entscheidung, die Sie treffen müssen.

Aber, wie Aaron Bertrand und TomTom bemerkten, dreht sich alles um eine bessere Leistung. Wenn Sie die anderen Probleme , die Sorge verwalten können (und ich glaube , dass sie sind überschaubar) , dann bekommt man eine ganze Reihe von Vorteilen. So verwenden Sie die columns für das, was der Lage ist zu tun , sich die fehlenden Funktionen und zu verwalten.

Diese Frage bezieht sich auf SQL 2014, ich möchte jedoch angesichts der in SQL 2016 vorgenommenen Änderungen an Columnstore-Indizes zusätzliche Informationen bereitstellen, da es schwierig sein kann, die Einschränkungen in verschiedenen Versionen zu klären, und diese Frage bei Google immer noch recht häufig auftritt:

In SQL 2016 beschreibt Microsoft eine Methode zur Verwendung von nicht gruppierten Btree-Indizes (die jetzt als sekundäre Indizes für eine gruppierte Columnstore-Tabelle hinzugefügt werden können), um Fremdschlüsseleinschränkungen durchzusetzen, vorausgesetzt, die Einschränkung wird vor dem Columnstore-Index hinzugefügt: https: // docs .microsoft.com / de-de / sql / relational-database / indexes / columnstore-indexes-design-guidance

Niko Neugebauer hat auch einen Blogeintrag darüber; Es ist tatsächlich möglich, eindeutige / fremde Einschränkungen für Spaltenspeichertabellen zu erstellen (ich habe diesen Ansatz in meiner Arbeit angewendet): http://www.nikoport.com/2015/09/15/columnstore-indexes-part-66- Weitere Clustered-Columnstore-Verbesserungen in SQL Server 2016 /