Entwerfen verteilter partitionierter Sichten
Wenn Sie verteilte partitionierte Sichten entwerfen, um ein vereintes Datenbanksystem (Gruppe von vereint verwalteten Datenbankservern) zu implementieren, beachten Sie Folgendes:
Ermitteln Sie die Muster der SQL-Anweisungen, die von der Anwendung ausgeführt werden.
Ermitteln Sie, welche Beziehungen es zwischen den Tabellen gibt.
Gleichen Sie die Aufrufhäufigkeit der SQL-Anweisungen gegen die Partitionen ab, die Sie anhand der Analyse der Fremdschlüssel definiert haben.
Definieren Sie die Senderegeln für die SQL-Anweisungen.
Muster der SQL-Anweisungen, die von der Anwendung ausgeführt werden
Entwickeln Sie eine Liste, die die SQL-Anweisungen enthält, die von der Anwendung während typischer Verarbeitungsintervalle ausgeführt werden. Unterteilen Sie die Liste in Kategorien für SELECT-, UPDATE-, INSERT- und DELETE-Anweisungen, und sortieren Sie die Liste in jeder Kategorie nach der Häufigkeit der Ausführung. Wenn SQL-Anweisungen auf gespeicherte Prozeduren verweisen, verwenden Sie die SELECT-, INSERT-, UPDATE- und DELETE-Basisanweisungen aus den gespeicherten Prozeduren. Wenn Sie eine vorhandene SQL Server-Datenbank partitionieren möchten, können Sie eine solche Liste mit SQL Server Profiler erstellen.
Die Empfehlung, die Häufigkeit von SQL-Anweisungen zu verwenden, ist eine sinnvolle Annäherung für eine typische OLTP-Datenbank (Online Transaction Processing, Online-Transaktionsverarbeitung) oder Website-Datenbank, bei der verteilte partitionierte Sichten am besten funktionieren. Diese Systeme sind dadurch gekennzeichnet, dass sie einzelne SQL-Anweisungen aufweisen, die im Vergleich zu den Abfragen eines Decision Support-Systems (OLAP-Systems) relativ kleine Datenmengen abrufen. Wenn jede SQL-Anweisung auf eine kleine Datenmenge verweist, führt das einfache Auswerten der Häufigkeit jeder Anweisung zu einer angemessenen Abschätzung des Datenverkehrs im System. Viele Systeme umfassen jedoch einige Gruppen von SQL-Anweisungen, die auf große Datenmengen verweisen. In diesem Fall sollten Sie einen zusätzlichen Schritt zur Gewichtung dieser Abfragen ausführen, um deren größere Datenanforderungen zu berücksichtigen.
Beziehungen der Tabellen
Dahinter verbirgt sich die Absicht, die Tabellen zu finden, die anhand derselben Dimension (z. B. Teilenummer oder Abteilungsnummer) partitioniert werden können, sodass sich alle Zeilen, die zu einzelnen Vorkommen dieser Dimension gehören, letztlich auf demselben Mitgliedsserver befinden. So könnten Sie beispielsweise ermitteln, dass sich die Datenbank nach Regionen partitionieren lässt. Damit dies unterstützt wird, müssen sogar Tabellen, die keine Regionsnummer in ihren Schlüsseln haben, in einer Weise partitioniert werden können, die sich auf eine Region bezieht. In einer solchen Datenbank kann (auch wenn die Customer-Tabelle keine Spalte für die Regionsnummer hat), wenn Regionen als Zusammenfassungen ganzer Bundesländer oder Provinzen definiert sind, die Customer.StateProvince-Spalte verwendet werden, um die Kunden in einer Weise zu partitionieren, die sich auf die Region bezieht.
Da sie die Beziehungen zwischen Tabellen definieren, sind explizite und implizite Fremdschlüssel die wesentlichen Elemente, anhand derer sich feststellen lässt, wie Daten partitioniert werden können. Sehen Sie sich die Definitionen der expliziten Fremdschlüssel an, um zu ermitteln, wie Abfragen häufig Zeilen einer Tabelle verwenden, um Zeilen in einer anderen Tabelle zu finden. Sehen Sie sich außerdem die impliziten Fremdschlüssel oder die Arten an, auf die SQL-Anweisungen Werte aus den Zeilen einer Tabelle verwenden, um in Verknüpfungsoperationen auf Zeilen einer anderen Tabelle zu verweisen, selbst wenn es keine spezielle Fremdschlüsseldefinition gibt. Da implizite Fremdschlüssel nicht explizit als Teil des Datenbankschemas definiert sind, müssen Sie die von der Anwendung generierten SQL-Anweisungen überprüfen, um feststellen zu können, ob es Anweisungen gibt, die Tabellen über Nicht-Schlüsselspalten verknüpfen. Implizite Fremdschlüssel sind üblicherweise indiziert, um die Verknüpfungsleistung zu steigern. Aus diesem Grund sollten Sie auch die in der Datenbank definierten Indizes überprüfen.
Aufrufhäufigkeit der SQL-Anweisungen gegen die Partitionen
Gleichen Sie die Aufrufhäufigkeit der SQL-Anweisungen gegen die Partitionen ab, die Sie anhand der Analyse der Fremdschlüssel definiert haben. Wählen Sie die Partitionierung aus, die die in der Anwendung verwendete Mischung von SQL-Anweisungen am besten unterstützt. Wenn einige Tabellen an mehreren Stellen partitioniert werden können, können Sie anhand der Aufrufhäufigkeit der SQL-Anweisungen ermitteln, welche der Partitionen die größte Zahl der SQL-Anweisungen erfüllt. Die Tabellen, auf die SQL-Anweisungen am häufigsten verweisen, sollten diejenigen sein, die Sie zuerst partitionieren. Legen Sie anhand der Häufigkeit, mit der auf die Tabellen verwiesen wird, die Prioritäten für die Reihenfolge fest, in der die Tabellen partitioniert werden sollen.
Ein weiteres Kriterium für die Entscheidung, ob eine Tabelle partitioniert werden soll, ist das Muster der SQL-Anweisungen:
Partitionieren Sie eine Tabelle, wenn mehr als 5 % der Anweisungen, die auf die Tabelle verweisen, INSERT-, UPDATE- oder DELETE-Anweisungen sind und wenn die Tabelle anhand der von Ihnen ausgewählten Dimension partitioniert werden kann.
Belassen Sie auf jedem Mitgliedsserver eine vollständige Kopie der Tabelle, wenn weniger als 5 % der Anweisungen, die auf die Tabelle verweisen, INSERT-, UPDATE- oder DELETE-Anweisungen sind. Sie müssen außerdem definieren, wie Aktualisierungen so vorgenommen werden, dass alle Kopien der Tabelle aktualisiert werden. Wenn eine hohe Transaktionsintegrität erforderlich ist, können Sie Trigger schreiben, die im Zusammenhang einer verteilten Transaktion verteilte Aktualisierungen aller Kopien vornehmen. Wenn keine hohe Transaktionsintegrität erforderlich ist, können Sie einen der SQL Server-Replikationsmechanismen verwenden, um Aktualisierungen von einer Kopie der Tabelle an alle anderen Kopien weiterzugeben.
Partitionieren oder kopieren Sie eine Tabelle nicht, wenn zwar mehr als 5 % der Anweisungen, die auf die Tabelle verweisen, INSERT-, UPDATE- oder DELETE-Anweisungen sind, die Tabelle aber nicht anhand der von Ihnen ausgewählten Dimension partitioniert werden kann.
Senderegeln für SQL-Anweisungen
Die Senderegeln müssen festlegen können, welcher Mitgliedsserver die jeweilige SQL-Anweisung am effizientesten verarbeiten kann. Die Regeln müssen eine Beziehung zwischen dem Kontext der Benutzereingabe und dem Mitgliedsserver herstellen, der den größten Teil der Daten enthält, die für die Anweisung erforderlich sind. Die Anwendungen müssen in der Lage sein, einen Teil der vom Benutzer eingegebenen Daten zu nehmen und diesen gegen die Senderegeln abzugleichen, um zu bestimmen, welcher Mitgliedsserver die SQL-Anweisung verarbeiten sollte.