VERTRIEB: 1-800-867-1380

Überlegungen zur Migration partitionierter Daten zu einer Azure SQL-Datenbank

Letzte Aktualisierung: April 2014

Die Datenpartitionierung ist ein bewährtes, bekanntes Verfahren zur Verwaltung umfangreicher Datenbanksysteme in lokalen Lösungen. Bei diesem Verfahren werden die Daten in einer großen Datenbank aufgeteilt und über Partitionen verteilt. Dies geschieht hauptsächlich, um die Verwaltbarkeit, Leistung und Verfügbarkeit der Datenbank zu verbessern. Datenbankadministratoren und Datenbankentwickler mit SQL Server-Hintergrund haben die Partitionierung u. a. aus folgenden Gründen eingesetzt:

  • Effizientere Datenverwaltung

  • Verbesserte Reaktionsfähigkeit von Abfragen

  • Höhere Parallelität von Abfragen

  • Erweitern der Rechenleistung durch Nutzung mehrerer physischer Server

  • Sicherstellen einer Verfügbarkeitsstufe

  • Aufheben physischer Speicherbeschränkungen

  • Reduzieren des Tabellenumfangs

Wenn Sie die Migration einer lokalen SQL Server-Umgebung zur Azure SQL-Datenbankplattform in Betracht ziehen, können zusätzliche Gründe für die Datenpartitionierung vorliegen, beispielsweise:

  • Mehrinstanzenfähigkeit

  • Höhere Serverleistung

  • Vermeiden von Einschränkungen

  • Nicht verfügbare Daten

  • Günstigere Speicherkosten

  • Einschränkungen der Datenkapazität

Die folgenden Funktionen von SQL Server werden normalerweise zum Partitionieren von Daten in lokalen Lösungen verwendet: Replikation, Tabellenpartitionierung, partitionierte Sichten, verteilte partitionierte Sichten, Dateigruppenstrategien und datenbankübergreifende Abfragen (verteilte Abfragen). Bis auf partitionierte Sichten werden diese Funktionen von Azure SQL-Datenbanken nicht unterstützt. SQL-Datenbanken unterstützen eine Lösung mit horizontaler Skalierung, die in der lokalen Version nicht verfügbar ist.

Wenn die migrierte Lösung einfach ist und nur auf einer einzelnen Datenbank basiert, die keine bedeutenden Ressourcen erfordert, besteht eine hohe Wahrscheinlichkeit, dass keine Funktionen verwendet werden, die eine Datenpartitionierung bewirken. Wenn in der Lösung einige der oben erwähnten Funktionen verwendet werden oder eine hohe Rechenleistung beansprucht wird, erfordert das Transponieren der Funktionen zur SQL-Datenbank wahrscheinlich einen Neuentwurf des Datenbankmodells.

Autoren: Shaun Tinline-Jones
Mitwirkende: Sreedhar Pelluru
Prüfer: Rama Ramani, Valery Mizonov, Kun Cheng, Steve Howard

Im Hinblick auf die Partitionierung kann die Replikation beispielsweise in folgenden Szenarien verwendet werden:

  • Verschieben von Datenteilmengen aus mehreren Quellen an einen einzelnen Ort

  • Eine einzelne Datenbank dient als Datenbank mit Lese-/Schreibzugriff, und mehrere Abonnenten dieser Datenbank dienen als schreibgeschützte Datenbanken mit Lastenausgleich.

  • Teilmengen von Daten werden von verschiedenen Benutzern basierend auf Parametern wie dem geografischen Standort verwendet, und anschließend werden Daten in eine Lösung repliziert, in der all diese Teilmengen (Herausgeber) kombiniert werden.

Die typischsten Gründe zum Implementieren der Replikation lauten:

  • Erstellen eines schreibgeschützten Replikats einer OLTP-Datenbank mit Lese-/Schreibzugriff.

  • Beibehalten einer betriebsbereiten Standbykopie einer Datenbank.

  • Auffüllen eines Datenstagingbereichs.

  • Ausschließliches Bereitstellen relevanter Daten für eine Teilmenge von Benutzern.

  • Verbessern der Rechen- und Verwaltungseffizienz auf Grundlage von Datenteilmengen.

SQL-Datenbanken unterstützen keine Replikation. Die SQL-Datenbankfunktion, die am besten mit der Replikationsfunktion verglichen werden kann, ist die Azure SQL-Datensynchronisierung. Diese Funktion nutzt Trigger, Change Data Capture (CDC)-Tabellen und geplante Aufträge für die Datenreplikation. Es ist zwar möglich, bestimmte Tabellen zu replizieren, die Auswahl einer Teilmenge von Daten aus einer Tabelle ist jedoch nicht möglich.

Ermitteln Sie zunächst die Aufgaben des lokalen Replikationsentwurfs. Besteht der Zweck in der Notfallwiederherstellung, bietet die SQL-Datenbank ein Äquivalent. Besteht der Zweck in geografischer Notfallwiederherstellung, bietet die SQL-Datenbank derzeit noch kein Äquivalent. Sollen Verarbeitungsressourcen ausgelagert werden, wobei Abonnenten den identischen Entwurf verwenden, bietet eine SQL-Datenbank eine Option für horizontale Skalierung.

In einer SQL-Datenbank ermöglicht horizontale Skalierung durch horizontale Partitionierung auf der Datenbankebene der Anwendung eine höhere Skalierbarkeit und Leistung. Mindestens eine Tabelle in einer Datenbank wird nach Zeilen unterteilt und auf mehrere Datenbanken aufgeteilt. Dieser Typ von horizontaler Partitionierung wird häufig als "Sharding" bezeichnet.

Die Daten partitionierter Tabellen werden in Einheiten aufgeteilt, die über mehrere Dateigruppen in einer Datenbank verteilt sein können. Die Daten werden horizontal partitioniert, sodass Gruppen von Zeilen einzelnen Partitionen zugeordnet werden. Eine große Tabelle wird normalerweise in folgenden Fällen partitioniert: Die Tabelle enthält derzeit oder zukünftig große Datenmengen, die auf unterschiedliche Weise genutzt werden, die Leistung bei Tabellenabfragen und -updates ist nicht erwartungsgemäß, oder Wartungstasks, z. B. Sicherungen, dauern zu lange. Die Tabellenpartitionierung wird üblicherweise implementiert, um Daten auf unterschiedlichen Volumes zu speichern, die Effizienz von Sicherungen/Wiederherstellungen zu verbessern, die Abfrageleistung zu optimieren und die Parallelität von Abfragen zu steigern.

SQL-Datenbanken unterstützen derzeit keine Tabellenpartitionierung. Falls die Überlegungen den Datenträgerkapazitäten gelten, kommt eine SQL-Datenbank in dieser Hinsicht ohne Tabellenpartitionierung aus. Sie können bei der Migration in die SQL-Datenbank auch eine Lösung mit horizontaler Skalierung verwenden.

Mit partitionierten Sichten kann eine umfangreiche Tabelle in einer Datenbank in eine Reihe kleinerer Tabellen unterteilt werden, die bestimmte Teilmengen der Daten enthalten, und dann eine UNION ALL-Sicht aus den kleinen Tabellen erstellt werden, sodass die Sicht als einzelne Tabelle mit sämtlichen Daten dargestellt wird. Partitionierte Sichten haben in der Regel denselben Verwendungszweck wie partitionierte Tabellen.

Da eine SQL-Datenbank partitionierte Sichten unterstützt, sollte die Migration partitionierter Sichten zur SQL-Datenbank unkompliziert verlaufen.

Mit einer verteilten partitionierten Sicht werden horizontal partitionierte Daten aus einem Satz von Elementtabellen verknüpft, die über verschiedene Datenbankinstanzen auf unterschiedlichen Datenbankservern verteilt sind. Sie können verteilte partitionierte Sichten verwenden, um die Verarbeitungsleistung unterschiedlicher Datenbankserver zu nutzen, die Abfrageleistung zu verbessern, indem eine umfangreiche Tabelle in kleinere Tabellen aufgeteilt wird, und die Verarbeitungslast gleichmäßig auf eine Konfiguration mit horizontaler Skalierung von Datenbankservern zu verteilen.

SQL-Datenbanken unterstützen derzeit noch keine verteilten partitionierten Sichten. Ziehen Sie die Verwendung einer Lösung mit horizontaler Skalierung in Betracht.

Dateigruppen sind benannte Sammlungen von Dateien. Sie werden zur Vereinfachung der Verteilung von Daten sowie von Verwaltungsaufgaben, wie z. B. Sicherungs- und Wiederherstellungsfunktionen, verwendet. Sie werden normalerweise verwendet, um die Datenbankleistung zu verbessern, indem Daten verteilt auf mehreren Datenträgern, mehreren Datenträgercontrollern oder RAID-Systemen (Redundant Array of Independent Disks) gespeichert werden. Wenn mehrere Dateigruppen verwendet werden, können die Dateien in einer Datenbank einzeln gesichert und wiederhergestellt werden.

Dateigruppen werden in SQL-Datenbanken nicht unterstützt. Wenn Sie Dateigruppen zu Verwaltungszwecken verwenden, können Sie diese Aufgabe künftig getrost der SQL-Datenbank überlassen. Steht jedoch die Leistung im Vordergrund, sollten Sie die Verwendung einer Lösung mit horizontaler Skalierung in Erwägung ziehen.

Datenbankübergreifende Abfragen (verteilte Abfragen) werden üblicherweise für den Zugriff auf Daten verwendet, die über mehrere SQL Server-Instanzen verteilt sind.

Das Datenzugriffsmodell von SQL-Datenbanken unterstützt derzeit keine datenbankübergreifenden Abfragen. Der USE-Befehl wird ebenfalls nicht unterstützt. Es ist möglich, datenbankübergreifende Joins oder Vergleiche in der Anwendung zu programmieren, nachdem die Daten aus den geeigneten Datenbanken zurückgegeben wurden. Ziehen Sie die Verwendung einer Lösung mit horizontaler Skalierung in Betracht, da dies die von SQL-Datenbanken unterstützte Partitionierungslösung darstellt.

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft