Im Umgang mit SQL-Tabellen gibt es zwei wesentliche Partitionierungen:

  • vertikale Partitionierung
  • horizontale Partitionierung
Partitionierte Tabellen - Faktenladen mit "Fast = TRUE" (Teil 1)
Quelle: https://www.bissantz.de/know-how/data-warehousing/partitionierte_tabellen/

In diesem Artikel widme ich mich der horizontalen Partitionierung, da sie in meinen Augen die häufiger verwendete Partitionierung ist.

Ausgangssituation

Ausgang ist eine Tabelle mit 500 Millionen Elementen, auf die eine Abfrage mit einer Where Clause ausgeführt wird. Diese Abfrage dauert ohne besonderer Vorbereitung der Tabelle 2:41 min. Das ist wirklich lange.

In der ersten Ausbaustufe der Performance-Erhöhung wird ein Non-Clustered Index auf die Spalte eingefügt, auf die mit der Where Clause gefiltert wird. Danach dauert die Abfrage nur mehr 1 min. Dh. die Zeit wurde mehr als halbiert.

Noch mehr kann man aber herausholen, wenn man die die Tabelle partitioniert.

Horizontale Partitionierung

In diesem Fall ist eine horizontale Partitionierung sinnvoll, weil die Anzahl der Spalten mehr aus überschaubar ist, aber die Anzahl der Zeilen ist sehr groß. Bei der horizontalen Partitionierung werden die Daten auf mehrere Partitionen aufgeteilt, die optimalerweise in unterschiedlichen File-Groups gespeichert werden. Um noch mehr an Performance herauszuholen, kann es darüber hinaus sinnvoll sein, die File-Groups auf unterschiedlichen Festplatten zu speichern.

Table Partitioning in SQL Server
Quelle: https://www.sqlshack.com/how-to-automate-table-partitioning-in-sql-server/

Eine horizontale Partitionierung besteht aus 2 Schritten:

Bevor man sich jedoch an die Arbeit macht, dass man die Daten partitioniert, sollte man sich Gedanken machen, wie man die Daten aufteilt. Pauschale Antworten hier zu geben, ist gefährlich. Die Daten sollten aber jedenfalls so partitioniert werden, dass auf die einzelnen File-Groups gleichermaßen zugegriffen wird. Und diese auf unterschiedlichen Festplatten liegen. Ich spreche in dem Zusammenhang bewusst von Festplatten (oder SSDs) und nicht von Partitionen, da auf einer Festplatte auch mehrere Partitionen liegen können. Handelt es sich um Einzelplatten sollte man berücksichtigen, dass die Last auf die Platten gleichermaßen verteilt wird. zB Gibt es 6 DB-Partitionen und 3 liegen auf Festplatte 1 und 3 liegen auf Festplatte 2, dann sollte sichergestellt werden, dass die Last auf die 2 Platten gleichermaßen aussieht. Grundsätzlich gilt das selbe für RAID-Systeme, wenngleich man in der Regel nicht mehrere RAID-Arrays in einem Rechner hat. Durch die Performancesteigerungen von RAIDs ist das aber unter Umständen zu vernachlässigen.

Bevor wir uns der Umsetzung widmen, möchte ich noch ein paar von meinen Studenten regelmäßig gestellten Fragen nachgehen:

  • Kann man Partitionen über mehrere Spalten erstellen? In MS SQL ist die partition function auf eine Spalte limitert. Aber man kann sich mit mit sog. persisted computed colums behelfen. (das sind Spalten, die aus mehreren Spalten bestehen – zB mittels CONCAT). Eine weitere Möglichkeit wäre eine Checksum Spalte (Checksum oder besser Hashbytes, da es bei CRC32 zu Hash Collisionen kommen kann) – näheres dazu hier: Checksumen (Hash) Berechnungen in SQL
  • Braucht man bei der Partitionierung einen Primary Key? Grundsätzlich sind SQL-Tabellen ohne Primärschlüssel gültig und man kann auch Tabellen ohne PK partitionieren. Wenn man einen PK hat, muss eine der im PK verwendeten Spalten die Partitions-Spalte sein. In der Theorie zu relationalen Datenbanken benötigt eine Tabelle per Definition einen Primärschlüssel
  • Ist Partitionierung Bestandteil der ANSI/ISO Standards? Nein und das wird es in meinem Verständnis auch nie sein. Es handelt sich dabei um eine physische Speichermethode die von Hersteller zu Hersteller unterschiedlich umgesetzt ist oder gar nicht existiert.

Schritt 1:

Links: