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

  • Artikel

Gilt für: Azure SQL-Datenbank

Mit In-Memory-Technologien können Sie die Leistung Ihrer Anwendung verbessern und die Kosten Ihrer Datenbank potenziell verringern.

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-Datenbank 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-Datenbank.

Vorteile von In-Memory-Technologien

Aufgrund der effizienteren Abfrage- und Transaktionsverarbeitung tragen In-Memory-Technologien auch zur Kostensenkung bei. Sie müssen in der Regel nicht zu einem höheren Datenbanktarif wechseln, um Leistungsvorteile 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.

Mithilfe von In-Memory-OLTP konnten Quorum Business Solutions ihre Workload verdoppeln und ihre DTUs um 70 % verbessern. Weitere Informationen finden Sie unter In-Memory OLTP in Azure SQL-Datenbank.

Hinweis

In-Memory-OLTP ist in den Dienstebenen „Premium (DTU)“ und „Unternehmenskritisch (virtuelle Kerne)“ von Azure SQL-Datenbank verfügbar. Die Hyperscale-Dienstebene unterstützt eine Teilmenge von In-Memory OLTP-Objekten. Weitere Informationen finden Sie unter Einschränkungen von Hyperscale.

Columnstore-Indizes sind in allen Dienstebenen mit Ausnahme des Basic-Tarifs und der Standardebene verfügbar, wenn das Dienstziel unter S3 liegt. Weitere Informationen finden Sie unter Ändern der Dienstebenen von Datenbanken mit Columnstore-Indizes.

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

  • Die Auswirkung dieser Technologien auf Speicher und die Grenzwerte für die Datengröße.
  • Wie Sie das Verschieben von Datenbanken, die diese Technologien nutzen, zwischen verschiedenen Tarifen verwalten.
  • Eine veranschauliche Verwendung von In-Memory OLTP sowie Columnstore-Indizes.

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

In-Memory-OLTP

Die In-Memory-OLTP-Technologie ermöglicht extrem schnelle Datenzugriffsvorgänge, indem sämtliche Daten im Arbeitsspeicher gespeichert 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 eine Datenbank 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. Jedes Dienstziel verfügt über ein Speicherkontingent oder eine Obergrenze für speicheroptimierte Tabellen, die als In-Memory-OLTP-Speicher bezeichnet werden.

Jedes unterstützte Singleton-Dienstziel und jedes Pool für elastische Datenbanken beinhaltet eine bestimmte Menge an In-Memory-OLTP-Speicher:

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 Dienstziel oder elastischem Pool zu wechseln.

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

Hinweis zu Pools für elastische Datenbanken

Bei Pools für elastische Datenbanken wird der In-Memory-OLTP-Speicher von allen Datenbanken im Pool gemeinsam genutzt. Aus diesem Grund kann die Verwendung in einer Datenbank andere Datenbanken möglicherweise beeinträchtigen. Zwei Lösungen dafür sind:

  • Konfigurieren Sie eine Max eDTU oder Max vCore für Datenbanken, die niedriger als die eDTU- oder V-Kern-Anzahl für den ganzen Pool ist. Dadurch wird auch die In-Memory-OLTP-Speicherauslastung in jeder Datenbank im Pool proportional begrenzt.
  • Konfigurieren Sie eine Min eDTU oder Min vCore, die größer als 0 ist. Mit diesem Minimalwert wird sichergestellt, dass jede Datenbank im Pool die Menge des In-Memory-OLTP-Speichers zur Verfügung hat, die der konfigurierten Min eDTU oder Min vCore entspricht.

Ändern der Dienstebenen für Datenbanken, die In-Memory-OLTP-Technologien verwenden

In-Memory-OLTP wird in den Dienstebenen „Universell“, „Standard“ und „Basic“ von Azure SQL-Datenbank nicht unterstützt. Daher ist es nicht möglich, eine Datenbank mit In-Memory-OLTP-Objekten in einen dieser Tarife zu skalieren. Wenn Sie eine Datenbank auf eine dieser Dienstebenen skalieren wollen, entfernen Sie alle speicheroptimierten Tabellen und Tabellentypen sowie alle nativ kompilierten T-SQL-Module oder konvertieren Sie sie in festplattenbasierte Objekte und reguläre T-SQL-Module.

Wenn Sie eine Datenbank der Typen „Unternehmenskritisch“ oder „Premium“ herunterskalieren, müssen Daten in den speicheroptimierten Tabellen in den Im-Memory-OLTP-Speicher passen, der im Ziel-Dienstziel der Datenbank oder des elastischen Pools verfügbar ist. für elastische Datenbanken herunterzuskalieren oder eine Datenbank in einen Pool für elastische Datenbanken zu verschieben, und das Ziel-Dienstziel nicht über genügend verfügbaren In-Memory OLTP-Speicher verfügt, schlägt der Vorgang fehl.

Feststellen, ob In-Memory-OLTP-Objekte existieren

- Es gibt einen programmgesteuerten Weg, um herauszufinden, ob eine vorhandene Datenbank 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.

Mit den folgenden Abfragen werden alle Objekte identifiziert, die entfernt werden müssen, bevor eine Datenbank auf „Hyperscale“, „Universell“, „Standard“ oder „Basic“ herabgestuft werden kann:

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 Columnstore-Indizes, die Sie zum Organisieren Ihrer Daten verwenden können:

  • Geclusterter Columnstore, in dem alle Daten in einer Tabelle im Spaltenformat organisiert werden. In dieser Art von Index 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. Geclusterte Columnstore-Indizes ermöglichen auch 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. Dieser Indextyp 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 zusätzlicher Index im Columnstoreformat vorliegt, der für die Analyseabfragen verwendet wird. Dieser Indextyp ermöglicht Hybrid Transactional-Analytic Processing (HTAP): die Möglichkeit, schnelle 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 kleineren Größenordnung befinden 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 Columnstorestrukturen die Größe des verfügbaren Arbeitsspeichers überschreiten.

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

Columnstore-Indizes müssen nicht vollständig in den Arbeitsspeicher passen. Deshalb ist die einzige Begrenzung der Indexgröße die maximale Gesamtgröße der Datenbank, was in den Artikeln DTU-basiertes Kaufmodell und vCore-basiertes Kaufmodell dokumentiert ist.

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. Das Komprimierungsverhältnis 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. Sie können auch die Datenkomprimierung für den Zeilenspeicher für die Basistabelle verwenden.

Ändern der Dienstebenen für Datenbanken mit Columnstore-Indizes

Wenn Sie das DTU-Kaufmodell nutzen und Ihre Datenbank Columnstore-Indizes enthält, funktioniert Ihre Anwendung unter Umständen nicht mehr, wenn Sie die Datenbank unter das S3-Dienstziel skalieren. Columnstore-Indizes werden nur in den Dienstebenen „Hyperscale“, „Unternehmenskritisch“ und „Premium“ sowie bei Verwendung von S3 und höher in der „Standard“-Dienstebene unterstützt. Columnstore-Indizes werden in der Dienstebene „Basic“ nicht unterstützt. Nach dem Skalieren der Datenbank auf eine nicht unterstützte Dienstebene bzw. ein nicht unterstütztes Dienstziel ist der Columnstore-Index nicht mehr verfügbar. Das System verwaltet den Index beim Ausführen von DML-Anweisungen, nutzt ihn jedoch nie. Wenn Sie später wieder auf eine unterstützte Dienstebene bzw. ein unterstütztes Dienstziel skalieren, kann der Columnstore-Index sofort wieder genutzt werden.

Wenn Sie über einen gruppierten Columnstore-Index verfügen, ist die gesamte Tabelle nicht mehr verfügbar, wenn die Datenbank auf eine nicht unterstützte Dienstebene bzw. ein nicht unterstütztes Dienstziel skaliert wird. Löschen Sie alle gruppierten Columnstore-Indizes, und ersetzen Sie sie vor dem Skalierungsvorgang durch gruppierte Rowstore-Indizes oder -Heaps.

Zugehöriger Inhalt