Wie skaliert man SQL Server 2008 oder 2012?

Wie skaliert man SQL Server 2008 (oder 2012)? Grundsätzlich gibt es zwei Möglichkeiten:

Vergrößern:

Wenn die CPU gebunden ist, kann ich deutlich sehen, dass von 1 CPU-Kern auf 2 auf 4 übergegangen wird. Oder wenn die RAM-Auslastung in die Höhe schießt, fügen Sie einfach mehr RAM hinzu. Nimmt SQL Server 2008/2012 tatsächlich die Lücke auf und skaliert auf diese Weise unter der Annahme, dass sich die Anwendungsebene NICHT ändert? Um Spekulationen zu minimieren, nehmen wir an, ich mache nichts Dummes wie das Brennen von CPU-Zyklen, Cross-Joins usw.

Scale out:

Es ist nicht sehr klar, wie das Skalieren funktionieren würde. Ich meine, wenn ich einen anderen SQL-Server direkt neben meinem ersten hinzugefügt habe, woher weiß die Abfrage, auf welchem ​​Server sie ausgeführt werden soll? Befindet sich vorne ein Load Balancer (und wird er mit der SQL Server-Software geliefert?)? Enthält es Änderungen auf Anwendungsebene, damit die Skalierung funktioniert? Oder muss ich haben , um die Daten Scherbe und benutzerdefinierten Code haben , dass Anrufe auf den richtigen Datenbankserver auf den Daten abhängig Schlüssel Sharding?

Würde mich über Beiträge von erfahreneren Leuten freuen.

SQL Server skaliert nicht als solches . Es vergrößert sich.

Es gibt 3 Bereiche, um dies zu tun, vorbehaltlich der Einschränkungen der Edition

• CPU-Kerne
• RAM
• Lager

Verwenden Sie natürlich eine höhere Edition, z. B. Enterprise

SQL Server shardet nicht und jede solche Lösung (Sie können nach MySQL-Sharding-Lösungen suchen) erhöht die Komplexität und den Overhead eines Systems.

Das Skalieren eines Servers (+ Standby-Knoten / Spiegel) ist mit RAM, SSDs, mehr Festplattenvolumes zum Verteilen von E / A, separaten Laufwerken für Tempdb und Protokolle usw. In der Regel recht einfach

Wenn Sie feststellen, dass SQL Server CPU-gebunden ist, ist das Design und / oder die Indizes und / oder die schlecht geschriebenen Abfragen normalerweise schlecht, es sei denn, Sie haben eine massive Last.

Wie gbn sagt, skaliert SQL nicht wirklich wie andere RDBMs. Es gibt jedoch einen Aspekt der Skalierung, den viele Menschen übersehen, und der darin besteht, immer ein separates System für Berichtszwecke zu haben.

Lassen Sie niemals zu, dass Berichte gegen die Produktion laufen. Erstellen Sie sich eine Berichtsdatenbank auf einem anderen Server.

Im Idealfall enthält Ihr Berichtssystem nur Daten, die für die Berichte benötigt werden, und ist anders strukturiert und optimiert als Ihr Produktionssystem.

Die Daten werden nach Bedarf in das Berichtssystem eingespeist (dh eine stündliche Aktualisierung der Produktion, des täglichen Feeds usw.).

Ein schneller und schmutziger (und äußerst ineffizienter) Ansatz besteht darin, einfach eine vollständige Kopie der Produktionsdatenbank auf einem anderen Server zu haben. Diese Kopie kann über vollständige Sicherungen, Versand von Transaktionsprotokollen, Spiegelung (mit Snapshot), Replikation usw. verwaltet werden.

Ich empfehle diesen Ansatz jedoch nicht. Vollständige Sicherungen und Wiederherstellungen benötigen Zeit, insbesondere bei größeren Datenbanken. Die Replikation ist kompliziert und problematisch. Durch den Protokollversand erhalten Sie eine schreibgeschützte Datenbank. Das Spiegeln mit Snapshots ist zwar eine gute Antwort, Sie haben jedoch immer noch ein Produktionsschema, das nicht für Berichtszwecke optimiert ist.

Ein separates Berichtssystem ist der richtige Weg.

Wenn die CPU gebunden ist, kann ich deutlich sehen, dass von 1 CPU-Kern auf 2 auf 4 übergegangen wird. Oder wenn die RAM-Auslastung in die Höhe schießt, fügen Sie einfach mehr RAM hinzu. Nimmt SQL Server 2008/2012 tatsächlich die Lücke auf und skaliert auf diese Weise unter der Annahme, dass sich die Anwendungsebene NICHT ändert?

Die verschiedenen Editionen von SQL Server unterliegen unterschiedlichen Einschränkungen hinsichtlich der CPU und des Speichers, die sie verwenden werden. Abgesehen davon lautet die Antwort "Ja". Wenn freie CPU-Zyklen oder Speicherseiten verfügbar sind, verwendet der Server diese normalerweise bei Bedarf, sofern nicht anders konfiguriert.

Oder muss ich die Daten sharden und über benutzerdefinierten Code verfügen, der den richtigen Datenbankserver aufruft?

Grundsätzlich ja. "Skalieren" wird häufig durchgeführt, wenn Sie Sperrenkonflikte vermeiden müssen. Wenn Sie lange laufende Abfragen mit umfangreichen Sperren haben, möchten Sie diese möglicherweise von interaktiven Echtzeitabfragen oder Abfrageaktualisierungszyklen trennen, die von Benutzern gestartet wurden, die eine Schnittstelle bedienen und auf eine sofortige Antwort warten. Um dies zu gewährleisten, sind natürlich Änderungen an der Anwendung erforderlich (oder zumindest Änderungen an der Middleware, wenn Sie ein 3-Tier-Design haben).