Optimieren der Leistung mithilfe von In-Memory-Technologien in Azure SQL-Datenbank und Azure SQL Managed Instance

  • Artikel

Gilt für:Azure SQL Managed Instance

Mit In-Memory-Technologien können Sie die Leistung Ihrer Anwendung verbessern und die Kosten Ihrer SQL Managed Instance potenziell verringern. In-Memory OLTP ist in der Dienstebene Unternehmenskritisch von Azure SQL Managed Instance verfügbar.

Verwendungszwecke von In-Memory-Technologien

Durch die Verwendung von In-Memory-Technologien können Sie Leistungsverbesserungen bei verschiedenen Workloads erzielen:

  • Transaktionsverarbeitung (Online Transactional Processing, OLTP), bei der die meisten Anfragen kleinere Datenmengen lesen oder aktualisieren, z. B. bei CRUD-Vorgängen (create/read/update/delete).
  • Analyse (Online analytical processing, OLAP), bei denen die meisten Abfragen komplexe Berechnungen zu Berichtszwecken enthalten, sowie regelmäßig geplante Prozesse, die Ladevorgänge (oder Massenladevorgänge) durchführen und/oder Datenänderungen in bestehende Tabellen schreiben. Häufig werden OLAP-Workloads regelmäßig aus OLTP-Workloads aktualisiert.
  • Gemischte Verarbeitung (Hybrid Transaction/Analytical Processing, HTAP), bei der sowohl OLTP- als auch OLAP-Abfragen für den gleichen Satz Daten ausgeführt werden.

In-Memory-Technologien können die Leistung dieser Workloads verbessern, indem sie die zu verarbeitenden Daten im Arbeitsspeicher behalten, eine native Kompilierung der Abfragen verwenden oder eine erweiterte Verarbeitung wie z.B. Batchprozesse und SIMD-Anweisungen ausführen, die in der zugrunde liegenden Hardware verfügbar sind.

Übersicht

Azure SQL Managed Instance verfügt über die folgenden In-Memory-Technologien:

  • In-Memory-OLTP erhöht die Anzahl von Transaktionen pro Sekunde und reduziert die Latenz für die Transaktionsverarbeitung. Szenarien, die von In-Memory-OLTP profitieren sind: hoher Durchsatz bei der Transaktionsverarbeitung z.B. Handel treiben, Spielen, Datenerfassung von Ereignissen oder IoT-Geräten, Zwischenspeichern, Laden von Daten, temporäre Tabellen und Szenarien mit Tabellenvariablen.
  • Gruppierte Columnstore-Indizes reduzieren den Speicherplatzbedarf (bis um das Zehnfache) und verbessern die Leistung für Berichts- und Analyseabfragen. Verwenden Sie sie mit Faktentabellen in Ihren Data Marts, um mehr Daten in Ihrer Datenbank zu speichern und die Leistung zu verbessern. Sie können sie auch mit Verlaufsdaten in der Betriebsdatenbank verwenden, um bis zu zehnmal mehr Daten zu archivieren und abfragen zu können.
  • Nicht gruppierte Columnstore-Indizes für HTAP helfen beim Gewinnen von Einblicken in Echtzeit in Ihr Geschäft, indem Sie die Betriebsdatenbank direkt abfragen, ohne einen aufwendigen ETL-Prozess (Extrahieren, Transformieren, Laden) ausführen zu müssen und darauf zu warten, dass das Data Warehouse aufgefüllt wird. Nicht geclusterte Columnstore-Indizes sorgen für eine schnelle Ausführung von Analyseabfragen in der OLTP-Datenbank und reduzieren gleichzeitig die Auswirkungen auf die Betriebsworkload.
  • Speicheroptimierte geclusterte Columnstore-Indizes für HTAP ermöglichen eine schnelle Transaktionsverarbeitung sowie die sehr schnelle gleichzeitige Ausführung von Analyseabfragen derselben Daten.

Columnstore-Indizes und In-Memory-OLTP wurden 2012 bzw. 2014 in SQL Server eingeführt. Azure SQL-Datenbank, Azure SQL Managed Instance und SQL Server weisen dieselbe Implementierung von In-Memory-Technologien auf.

Hinweis

Ein detailliertes Schritt-für-Schritt-Tutorial zur Demonstration der Leistungsvorteile der In-Memory-OLTP-Technologie unter Verwendung der AdventureWorksLT-Beispieldatenbank und ostress.exe finden Sie unter In-Memory-Beispiel in Azure SQL Managed Instance.

Vorteile von In-Memory-Technologien

Aufgrund der effizienteren Abfrage- und Transaktionsverarbeitung tragen In-Memory-Technologien auch zur Kostensenkung bei. Sobald Sie sich in der Dienstebene Unternehmenskritisch von Azure SQL Managed Instance befinden, müssen Sie die SQL Managed Instance in der Regel nicht mehr aktualisieren, um Leistungssteigerungen zu erzielen. In einigen Fällen können Sie möglicherweise sogar zu einem niedrigen Tarif wechseln und dennoch in den Genuss von Leistungsverbesserungen durch In-Memory-Technologien kommen.

In diesem Artikel werden Aspekte von In-Memory-OLTP und Columnstore-Indizes beschrieben, die für Azure SQL Managed Instance spezifisch sind. Außerdem sind darin Beispiele aufgeführt:

  • Sie erfahren etwas über die Auswirkung dieser Technologien auf Speicher und die Grenzwerte für die Datengröße.
  • Sie erfahren, wie Sie das Verschieben von Datenbanken, die diese Technologien nutzen, zwischen verschiedenen Tarifen verwalten.
  • Sie finden zwei Beispiele, in denen die Verwendung von In-Memory-OLTP und Columnstore-Indizes veranschaulicht wird.

Weitere Informationen zu In-Memory-OLTP in SQL Server finden Sie unter:

In-Memory-OLTP

In-Memory-OLTP-Technologie ermöglicht extrem schnelle Datenzugriffsvorgänge, indem sämtliche Daten im Arbeitsspeicher behalten werden. Die Technologie nutzt auch spezialisierte Indizes, die native Kompilierung von Abfragen sowie latchfreien Datenzugriff zur Verbesserung der Leistung der OLTP-Workload. Es gibt zwei Möglichkeiten, die In-Memory-OLTP-Daten zu organisieren:

  • Speicheroptimiertes Rowstoreformat, in dem jede Zeile ein separates Arbeitsspeicherobjekt darstellt. Dies ist ein klassisches In-Memory-OLTP-Format, das für OLTP-Workloads mit hoher Leistung optimiert ist. Es gibt zwei Arten von speicheroptimierten Tabellen, die im speicheroptimierten Rowstoreformat verwendet werden können:

    • Dauerhafte Tabellen (SCHEMA_AND_DATA), bei denen die im Arbeitsspeicher platzierten Zeilen nach einem Serverneustart beibehalten werden. Diese Art von Tabellen verhält sich wie herkömmliche Rowstoretabellen, bietet aber die zusätzlichen Vorteile von speicherinternen Optimierungen.
    • Nicht dauerhafte Tabellen (SCHEMA_ONLY), bei denen die Zeilen nach einem Neustart nicht beibehalten werden. Diese Art von Tabelle ist für temporäre Daten (z.B. zum Austausch von temporären Tabellen) oder für Tabellen konzipiert, in die schnell Daten geladen werden müssen, bevor sie in dauerhafte Tabellen verschoben werden (so genannte Stagingtabellen).

  • Speicheroptimiertes Columnstoreformat, bei dem Daten in Spaltenform organisiert sind. Diese Struktur wurde für HTAP-Szenarien konzipiert, in denen Sie Analyseabfragen in der gleichen Datenstruktur ausführen müssen, in der Ihre OLTP-Workload ausgeführt wird.

Hinweis

Die In-Memory-OLTP-Technologie wurde für Datenstrukturen entwickelt, die vollständig im Arbeitsspeicher verbleiben können. Da die In-Memory-Daten nicht auf einen Datenträger ausgelagert werden können, müssen Sie sicherstellen, dass Sie SQL Managed Instance mit ausreichend Arbeitsspeicher verwenden. Weitere Informationen finden Sie unter Datengröße und Speicherkapazität für In-Memory-OLTP.

Datengröße und Speicherkapazität für In-Memory-OLTP

In-Memory-OLTP enthält speicheroptimierte Tabellen, die zum Speichern von Benutzerdaten verwendet werden. Diese Tabellen sind müssen in den Arbeitsspeicher passen. Dieses Konzept wird als In-Memory-OLTP-Speicher bezeichnet.

Die unternehmenskritische Dienstebene enthält eine bestimmte Menge an Max In-Memory OLTP-Speicher, die durch die Anzahl der vCores bestimmt wird.

Die folgenden Elemente werden bis zu Ihrer In-Memory-OLTP-Speicherkapazitätsobergrenze angerechnet:

  • Aktive Benutzerdatenzeilen in speicheroptimierten Tabellen und Tabellenvariablen. Alte Zeilenversionen werden nicht bis zur Kapazitätsobergrenze angerechnet.
  • Indizes von speicheroptimierten Tabellen.
  • Betriebsmehraufwand von ALTER TABLE-Vorgängen.

Wenn Sie die Obergrenze erreichen, erhalten Sie einen Fehler vom Typ „Kontingent aufgebraucht“ und können dann keine Daten mehr einfügen oder aktualisieren. Eine Lösung dieses Fehlers besteht darin, Daten zu löschen oder zu einem höheren Datenbank- oder Pooltarif zu wechseln.

Weitere Informationen zur Überwachung der In-Memory-OLTP-Speichernutzung und zum Konfigurieren von Benachrichtigungen, wenn die Obergrenze fast erreicht ist, finden Sie unter Überwachen des In-Memory-OLTP-Speichers.

Ändern der Hardwarekonfiguration oder vCore-Anzahl

Eine Herabstufung Ihrer Hardwarekonfiguration oder der Anzahl der vCores kann sich negativ auf Ihre SQL Managed Instance auswirken.

Die Daten in speicheroptimierten Tabellen müssen innerhalb des Limits für In-Memory-OLTP-Speicher für Ihre Hardwarekonfiguration und vCore-Anzahl liegen. Wenn Sie versuchen, eine Skalierung auf eine Einstellung vorzunehmen, die nicht über genügend verfügbaren In-Memory-OLTP-Speicher verfügt, schlägt der Vorgang fehl.

Feststellen, ob In-Memory-Objekte existieren

Es gibt einen programmatischen Weg, um herauszufinden, ob eine bestimmte Datenbank in Ihrer SQL Managed Instance In-Memory-OLTP unterstützt. Sie können die folgende Transact-SQL-Abfrage ausführen:

SELECT DatabasePropertyEx(DB_NAME(), 'IsXTPSupported');

Wenn die Abfrage 1 zurückgibt, wird In-Memory-OLTP in dieser Datenbank unterstützt.

Die folgenden Abfragen identifizieren alle Objekte, die die In-Memory-Technologie verwenden:

SELECT * FROM sys.tables WHERE is_memory_optimized=1
SELECT * FROM sys.table_types WHERE is_memory_optimized=1
SELECT * FROM sys.sql_modules WHERE uses_native_compilation=1

In-Memory-Columnstore

Die In-Memory-Columnstoretechnologie ermöglicht es Ihnen, eine große Datenmenge in Tabellen zu speichern und abzufragen. Die Columnstoretechnologie verwendet ein spaltenbasiertes Datenspeicherformat und Batchabfragen, um eine bis zu 10-mal höhere Abfrageleistung in OLAP-Workloads zu erzielen also herkömmliche zeilenorientierte Speicher. Sie können im Vergleich zur unkomprimierten Datengröße außerdem eine bis zu 10-mal höhere Datenkomprimierung erzielen.

Es gibt zwei Arten von Columnstoremodellen, die Sie zum Organisieren Ihrer Daten verwenden können:

  • Geclusterter Columnstore, in dem alle Daten in einer Tabelle im Spaltenformat organisiert werden. In diesem Modell werden alle Zeilen einer Tabelle in einem Spaltenformat platziert, das die Daten stark komprimiert und Ihnen eine schnelle Ausführung von Analyseabfragen und -berichten in der Tabelle ermöglicht. Je nach Art Ihrer Daten kann das Datenvolumen um das 10- bis 100-Fache reduziert werden. Das Modell mit Columnstoreclustern ermöglicht auch das schnelle Erfassen großer Datenmengen (Massenladen), da große Datenbatches mit mehr als 100 000 Zeilen vor dem Speichern auf dem Datenträger komprimiert werden. Dieses Modell eignet sich gut für Szenarien mit klassischen Data Warehouses.
  • Nicht geclusterter Columnstore, bei dem die Daten in herkömmlichen Rowstoretabellen gespeichert sind und ein Index im Columnstoreformat vorliegt, der für die Analyseabfragen verwendet wird. Dieses Modell ermöglicht Hybrid Transactional-Analytic Processing (HTAP): die Möglichkeit, leistungsfähige Echtzeitanalysen für eine Transaktionsworkload auszuführen. OLTP-Abfragen werden in einer Rowstoretabelle ausgeführt, die für den Zugriff auf eine kleine Menge an Zeilen optimiert ist. OLAP-Abfragen dagegen werden in einem Columnstore-Index ausgeführt, der sich für Überprüfungen und Analysen besser eignet. Der Abfrageoptimierer wählt das Rowstore- oder Columnstoreformat basierend auf der jeweiligen Abfrage dynamisch aus. Nicht geclusterte Columnstore-Indizes verringern die Größe der Daten nicht, da das ursprüngliche Dataset ohne Änderung in der ursprünglichen Rowstoretabelle beibehalten wird. Der zusätzliche Columnstore-Index sollte sich jedoch in einer Größenordnung befinden, die kleiner ist als der entsprechende B-Struktur-Index.

Hinweis

Die In-Memory-Columnstoretechnologie speichert nur die für die Verarbeitung erforderlichen Daten im Arbeitsspeicher. Daten, die nicht in den Arbeitsspeicher passen, werden auf einem Datenträger gespeichert. Aus diesem Grund kann die Datenmenge in In-Memory-Columnstorestrukturen die Größe des verfügbaren Arbeitsspeichers überschreiten.

Datengröße und Speicher für Columnstore-Indizes

Columnstore-Indizes brauchen nicht in den Arbeitsspeicher zu passen. Daher ist die einzige Obergrenze für die Größe der Indizes die maximale Gesamtgröße der Datenbank. Weitere Informationen finden Sie unter Ressourceneinschränkungen für Azure SQL Managed Instance. Azure SQL Managed Instance unterstützt Columnstore-Indizes in allen Tarifen.

Wenn Sie gruppierte Columnstore-Indizes verwenden, wird eine Spaltenkomprimierung für den Basistabellenspeicher verwendet. Durch diese Komprimierung kann der Speicherbedarf Ihrer Benutzerdaten erheblich reduziert werden, d.h., Sie können mehr Daten in der Datenbank speichern. Die Komprimierung kann außerdem mit spaltenorientierter Archivierungskomprimierung noch weiter erhöht werden. Der Grad der Komprimierung, die Sie erreichen können, hängt von der Art der Daten ab, jedoch ist eine zehnfache Komprimierung nicht ungewöhnlich.

Wenn Sie z.B. eine Datenbank mit einer maximalen Größe von 1 Terabyte (TB) haben und mithilfe von Columnstore-Indizes eine zehnfache Komprimierung erreichen, können Sie insgesamt 10 TB Benutzerdaten in der Datenbank speichern.

Bei Verwendung von nicht gruppierten Columnstore-Indizes wird die Basistabelle weiterhin im herkömmlichen Rowstore-Format gespeichert. Daher sind die Speichereinsparungen nicht so signifikant wie bei gruppierten Columnstore-Indizes. Wenn Sie jedoch mehrere herkömmliche nicht gruppierte Indizes durch einen einzelnen Columnstore-Index ersetzen, können Sie dennoch allgemeine Einsparungen beim Speicherbedarf für die Tabelle erzielen.

Zugehöriger Inhalt