Ansätze zum Partitionieren von Tabellen in SQL Server

Question

Die Datenbank, mit der ich arbeite, ist derzeit über 100 GiB und verspricht, im Laufe des nächsten Jahres wesentlich größer zu werden. Ich versuche ein Partitionierungsschema zu entwerfen, das mit meinem Datensatz funktioniert, aber bis jetzt kläglich gescheitert ist. Mein Problem besteht darin, dass Abfragen für diese Datenbank in der Regel die Werte mehrerer Spalten in dieser großen Tabelle testen und in Ergebnismengen enden, die sich in unvorhersehbarer Weise überlappen.

Jeder (die DBAs, mit denen ich arbeite) warnt davor, Tabellen über eine bestimmte Größe zu haben, und ich habe die Lösungen untersucht und ausgewertet, die alle auf einem Datenmerkmal beruhen, das logisch ist Tabellenpartitionierung Leider sehe ich angesichts der Struktur meiner Tabellen keinen Weg, dies zu erreichen.

Hier ist die Struktur unserer beiden Haupttabellen, um dies zu relativieren.

Beachten Sie, dass jede der obigen Spalten als Abfrageparameter verwendet werden kann.

Answer 1

Anstatt zu raten, messen. Sammeln Sie Nutzungsstatistiken (queries run), schauen Sie sich die eigenen Statistiken wie sys.dm_db_index_usage_stats an und dann treffen Sie eine fundierte Entscheidung: Die Partition, die die Datengröße am besten ausgleicht und beste Affinität für die am häufigsten ausgeführten Abfragen bietet, ist ein guter Kandidat. Natürlich müssen Sie Kompromisse eingehen.

Vergessen Sie auch nicht, dass partitioning pro Index ist (wo 'Tabelle' = einer der Indizes), nicht pro Tabelle, so ist die Frage nicht, worauf zu partitionieren, aber welche Indizes zu Partition oder nicht und welche Partitionierung zu verwendende Funktion. Ihre geclusterten Indizes für die beiden Tabellen werden offensichtlich die wahrscheinlichsten Kandidaten sein (es ist nicht viel sinnvoll, nur einen nicht gruppierten Index zu partitionieren und den geclusterten nicht zu partitionieren), wenn Sie nicht gerade ein Redesign Ihrer geclusterten Schlüssel in Erwägung ziehen ist wirklich welche Partitionierungsfunktion für Ihre Clustered-Indizes zu wählen.

Wenn ich eine Vermutung wagen würde ich sagen, dass für alle Daten, die im Laufe der Zeit (wie "Fälle" mit einem "Jahr") sammelt die natürlichste Partition ist die sliding window.

Answer 2

Wenn Sie keine andere Wahl haben, können Sie die Anzahl der Partitionstabellen nach Schlüsselmodul partitionieren. Sagen wir, dass Sie in 10 Tabellen partitionieren möchten. Sie Tabellen definieren:
Case00
Case01
...
Case09

Und Sie Daten von Unique partitionieren oder PrimaryKey-Modul 10 und legen Sie jeden Datensatz in der entsprechenden Tabelle (Abhängig von Ihrem einzigartigen Unique Sie Möglicherweise muss die manuelle Zuweisung von IDs gestartet werden.

Wenn Sie eine Abfrage ausführen, müssen Sie dieselbe Abfrage für alle Tabellen ausführen und UNION verwenden, um die Ergebnismenge in ein einzelnes Abfrageergebnis zusammenzuführen.

Es ist nicht so gut wie das Partitionieren der Tabellen basierend auf einer logischen Trennung, die der erwarteten Abfrage entspricht, aber es ist besser, als die Größenbeschränkung einer Tabelle zu erreichen.

Answer 3

Eine weitere mögliche Sache (vor der Partitionierung) ist Ihr Modell.

Sind Sie in einer normalisierten Datenbank? Gibt es weitere Schritte, die die Performance durch unterschiedliche Wahlmöglichkeiten bei der Normalisierung/De-/Partial-Normalisierung verbessern könnten?Gibt es Möglichkeiten, die Daten in ein Kimball-dimensionales Sternmodell zu transformieren, das optimal für das Reporting/Abfragen ist?

Wenn Sie keine Partitionen der Tabelle (Schiebefenster, wie erwähnt) löschen oder verschiedene Partitionen anders behandeln (Sie sagen, dass irgendwelche Spalten in der Abfrage verwendet werden können), bin ich nicht sicher, was Sie versuchen um aus der Partitionierung herauszukommen, die Sie noch nicht aus Ihrer Indexierungsstrategie herausholen können.

Mir sind keine Tabellenlimits für Zeilen bekannt. AFAIK, die Anzahl der Zeilen ist nur durch den verfügbaren Speicherplatz begrenzt.