• Artikel

Verbessern der Skalierbarkeit

Anwendungen der mittleren Ebene verwenden oft eine einzelne Datenbank zum Speichern von Daten. Dies kann zu Beeinträchtigungen der Skalierung führen, da die Auslastung der Datenbank steigt. Wenn Anwendungen mehr Lesevorgänge als Schreibvorgänge ausführen, wie es bei einem webbasierten Katalog der Fall ist, können Sie den Anteil der Arbeitsauslastung für Lesevorgänge dezentral skalieren, indem Sie die schreibgeschützten Daten auf mehreren Datenbanken zwischenspeichern und die Clients gleichmäßig mit den verschiedenen Datenbanken verbinden, um die Auslastung aufzuteilen.

Im folgenden Diagramm wird eine Konfiguration dargestellt, in der Anwendungs- und Webserver Daten von einem der drei Cacheserver verwenden.

Verwenden der Replikation zum Skalieren der Leseaktivität

Wenn Ihre Anwendung zudem eine erhöhte Verfügbarkeit erfordert und/oder wenn es erforderlich ist, dass Lesevorgänge und Aktualisierungen für einen bestimmten Benutzer an einen bestimmten Anwendungsserver und anschließend an einen bestimmten Cacheserver fließen, ziehen Sie das Beispiel unter Verbessern der Verfügbarkeit und der Skalierbarkeit zurate.

Beispiel mit Adventure Works Cycles

Adventure Works Cycles ist eine zum Demonstrieren von Datenbankkonzepten und -szenarien erfundene Produktionsfirma. Weitere Informationen finden Sie unter AdventureWorks2008R2-Beispieldatenbanken.

Adventure Works Cycles hat kürzlich seine Website aktualisiert und so folgende neue Features integriert:

  • Online-Produktbestellungen für Kunden.

  • Online-Überprüfung des Bestellstatus.

  • Bessere Suchfunktionen in den Produktinformationen.

Durch die nun mögliche Produktbestellung über die Website wurde die Aktivität auf dem einzigen Computer mit Microsoft SQL Server im Unternehmen erheblich gesteigert. Die Administratoren von Adventure Works beschlossen, diesen Computer als Quelle für replizierte Daten zu verwenden. Alle Leseaktivitäten wurden dezentral auf die drei zusätzlichen Computer, auf denen SQL Server ausgeführt wird, skaliert, um Daten des Quellcomputers zwischenzuspeichern. Die Cachecomputer verarbeiten sämtliche Leseaktivitäten, beispielsweise Suchvorgänge im Produktkatalog oder die Überprüfung des Bestellstatus durch den Benutzer. Alle Schreibaktivitäten werden an die Quelldatenbank geleitet.

Allgemeine Anforderungen für dieses Szenario

Anwendungen, die aus Gründen der Skalierbarkeit die Replikation verwenden, haben folgende Anforderungen, die eine geeignete Replikationslösung erfüllen muss:

  • Das System muss die Transaktionskonsistenz aufrechterhalten.

  • Das System sollte geringe Latenzzeiten bieten: Aktualisierungen am Quellcomputer müssen schnell in den Cache gelangen.

  • Das System sollte einen hohen Durchsatz sicherstellen: Es sollte in der Lage sein, die Replikation vieler Transaktionen durchzuführen.

  • Die Replikationsverarbeitung sollte nur einen minimalen Aufwand an der Quelle mit sich bringen.

  • Die im Zwischenspeicher erforderlichen Daten können eine Teilmenge der auf der Quelle verfügbaren Daten sein.

Typ der für dieses Szenario zu verwendenden Replikation

SQL Server verwendet ein Modell, das sich auf Abläufe aus dem Verlagswesen stützt, um die Komponenten des Replikationssystems zu beschreiben. Zu den Komponenten zählen der Verleger, der Abonnent, Veröffentlichungen und Artikel sowie Abonnements. Weitere Informationen zu den Komponenten des Systems finden Sie unter Das Replikationsveröffentlichungsmodell (Übersicht).

In dem oben stehenden Diagramm fungiert der Verleger als Quelle. Einige oder sämtliche Daten der Quelle sind in der Veröffentlichung enthalten, wobei jede Datentabelle einen Artikel darstellt (Artikel können auch andere Datenbankobjekte sein, z. B. gespeicherte Prozeduren). Jeder Cache ist ein Abonnent der Veröffentlichung, der das Schema und Daten als Abonnement erhält.

SQL Server bietet verschiedenen Replikationstypen für unterschiedliche Anwendungsanforderungen: die Snapshotreplikation, die Transaktionsreplikation und die Mergereplikation. Für dieses Szenario wird am besten die Transaktionsreplikation implementiert, da sie sich gut dafür eignet, die im vorherigen Abschnitt aufgeführten Anforderungen zu erfüllen. Weitere Informationen zur Transaktionsreplikation finden Sie unter Transaktionsreplikation (Übersicht) and Funktionsweise der Transaktionsreplikation.

Die Transaktionsreplikation erfüllt die Hauptanforderungen für dieses Szenario programmbedingt:

  • Transaktionskonsistenz

  • Geringe Latenzzeit

  • Hoher Durchsatz

  • Minimaler Aufwand

Die wichtigste Option, die bei diesem Szenario berücksichtigt werden muss, ist die Filterung. Bei der Transaktionsreplikation können Sie Spalten und Zeilen filtern, sodass die Tabellen der Abonnenten nur die für Ihre Anwendung erforderlichen Daten enthalten. Weitere Informationen finden Sie unter Filtern von veröffentlichten Daten.

Schritte für die Implementierung dieses Szenarios

Für die Implementierung dieses Szenarios müssen Sie zunächst eine Veröffentlichung und Abonnements erstellen und anschließend die einzelnen Abonnements initialisieren. Klicken Sie auf die folgenden Links, um weitere Informationen zu den einzelnen Schritten zu erhalten:

Nachdem das Abonnement initialisiert wurde und Daten zwischen dem Verleger und den Abonnenten fließen, müssen Sie möglicherweise folgende Themen zurate ziehen, um Informationen zu allgemeinen Verwaltungs- und Überwachungsaufgaben zu erhalten: