Sie haben hier ein paar Fragen:
Ist es möglich, READS in Azure SQL DB zu skalieren? Ja.
Abhängig von dem Dienst, den Sie verwenden, wie z. B. Active Secondary Replicas von Azure SQL DB , kann Ihre Lesearbeitslast automatisch auf mehrere Server skaliert werden, ohne dass große Änderungen an Ihrem Anwendungscode erforderlich sind. Sie müssen Ihrer Anwendung jedoch noch eine separate Verbindungszeichenfolge hinzufügen, in der ApplicationIntent = ReadOnly angegeben ist, damit sie wissen, dass es sicher ist, Ihre Leseabfrage auf ein lesbares Replikat zu verschieben.
Ist es möglich, WRITES in Azure SQL DB zu skalieren? Ja, wenn Sie den Code ändern.
Das Dokument, mit dem Sie verknüpft haben, Datenpartitionierung , enthält eine Reihe von Entwurfsrichtlinien, die Sie beim Codieren Ihrer Anwendung verwenden können. Dies sind jedoch tatsächlich Codeänderungen, keine Funktion von Azure SQL DB, die Sie genauso umdrehen wie sekundäre Replikate.
Es liegt an Ihnen, eine Codeebene so zu gestalten, dass Ihre App, wenn sie eine Abfrage ausführen muss, eine Verbindung zum entsprechenden Speicherort herstellt.
Stellen Sie es sich wie das World Wide Web vor: Bei Stack Overflow werden Schreib-Workloads auf StackOverflow.com, DBA.StackExchange.com, ServerFault.com und andere Websites aufgeteilt. Sie als Benutzer müssen jedoch wissen, auf welcher Site die Daten enthalten sind, auf die Sie schreiben möchten. Sie können keine Antwort auf diese Frage bei ServerFault.com veröffentlichen. Diese Logik ist in Ihr Gehirn integriert - und dieselbe Logik muss in Ihre App integriert werden, wenn Sie Schreibvorgänge auf mehreren Servern skalieren möchten.
Es gab einen kurzen Moment, in dem Microsoft dachte, sie würden diese Arbeit mit Azure SQL DB-Verbänden für Sie erledigen , aber das war schnell veraltet .
Sind mit SQL Server die gleichen Dinge möglich? Ja.
Das Skalieren von Lesevorgängen ist so einfach wie:
- Kaufen Sie weitere SQL Server und bauen Sie sie in eine Verfügbarkeitsgruppe ein
- Hinzufügen einer weiteren Verbindungszeichenfolge in Ihrer App unter Angabe von ApplicationIntent = ReadOnly
- Profitieren!
Das Skalieren von Schreibvorgängen ist nicht so einfach und erfordert Codeänderungen wie in Azure SQL DB.
Führt einer von beiden einen echten Lastausgleich durch? Nein.
Weder Azure SQL DB noch SQL Server Always On Availability Groups verteilen die Last wirklich auf mehrere Secondaries. Sie können in eine Situation geraten, in der ein Replikat eine Handvoll schrecklicher Abfragen ausführt und der Rest im Leerlauf sitzt. In dieser Situation können immer noch neue Abfragen sowohl den unterlasteten als auch den überlasteten Servern gleichermaßen zugewiesen werden.
Ein echter Lastausgleich - die Arbeitsanforderungen über mehrere Replikate hinweg ähnlich zu halten - bleibt dem Leser als Übung überlassen.
