Freigeben über

Onlinetransaktionsverarbeitung (OLTP)

  • Artikel

Die Verwaltung von Transaktionsdaten mithilfe von Computersystemen wird als Onlinetransaktionsverarbeitung (Online Transaction Processing, OLTP) bezeichnet. OLTP-Systeme zeichnen Geschäftsinteraktionen auf, die im täglichen Betrieb der Organisation bzw. des Unternehmens stattfinden, und unterstützen das Abfragen dieser Daten, um Rückschlüsse zu ziehen.

Transaktionsdaten

Transaktionsdaten sind Informationen, mit denen Interaktionen in Zusammenhang mit den Aktivitäten einer Organisation nachverfolgt werden. Bei diesen Interaktionen handelt es sich in der Regel um Geschäftstransaktionen, etwa von Kunden erhaltene Zahlungen, Zahlungen an Zulieferer, Produkte im Bestand, entgegengenommene Aufträge oder bereitgestellte Dienste. Transaktionsereignisse, die die Transaktionen selbst darstellen, enthalten in der Regel eine Zeitdimension, einige numerische Werte und Verweise auf andere Daten.

Transaktionen müssen normalweise unteilbar und konsistent sein. Unteilbarkeit bedeutet, dass eine gesamte Transaktion immer als eine Arbeitseinheit erfolgreich ist oder fehlschlägt und nie in einem halb abgeschlossenen Zustand belassen wird. Wenn eine Transaktion nicht abgeschlossen werden kann, muss das Datenbanksystem einen Rollback für alle Schritte ausführen, die im Rahmen der Transaktion bereits durchgeführt wurden. In einem herkömmlichen Managementsystem für relationale Datenbanken (RDBMS) erfolgt dieser Rollback automatisch, wenn eine Transaktion nicht abgeschlossen werden kann. Konsistenz bedeutet, dass Transaktionen die Daten immer in einem gültigen Zustand hinterlassen. (Hierbei handelt es sich um sehr informelle Beschreibungen von Unteilbarkeit und Konsistenz. Es gibt offiziellere Definitionen für diese Eigenschaften, etwa ACID.)

Transaktionsdatenbanken können mit verschiedenen Sperrstrategien (etwa pessimistisches Sperren) hohe Konsistenz für Transaktionen unterstützen, um eine hohe Konsistenz aller Daten im Unternehmenskontext für alle Benutzer und Prozesse zu gewährleisten.

Die Datenspeicherebene in einer dreischichtigen Architektur ist die am häufigsten verwendete Bereitstellungsarchitektur, die Transaktionsdaten verwendet. Eine dreischichtige Architektur setzt sich üblicherweise aus einer Präsentationsebene, einer Geschäftslogikebene und einer Datenspeicherebene zusammen. Eine ähnliche Bereitstellungsarchitektur ist die n-schichtige Architektur, die mehrere mittlere Ebenen für die Verarbeitung von Geschäftslogik enthalten kann.

Typische Merkmale von Transaktionsdaten

Transaktionsdaten weisen tendenziell die folgenden Merkmale auf:

Anforderung BESCHREIBUNG
Normalisierung Stark normalisiert
Schema Schema beim Schreiben, strikte Erzwingung
Konsistenz Hohe Konsistenz, ACID-Garantien
Integrität Hohe Integrität
Verwendung von Transaktionen Ja
Sperrstrategie Pessimistisch oder optimistisch
Aktualisierbar Ja
Erweiterbar Ja
Workload Intensive Schreibvorgänge, moderate Lesevorgänge
Indizierung Primäre und sekundäre Indizes
Bezugsgröße Kleine bis mittlere Größe
Modell Relational
Datenform Tabellarisch
Abfrageflexibilität Sehr flexibel
Skalieren Klein (MBs) bis groß (einige TBs)

Verwendung dieser Lösung

OLTP ist die geeignete Wahl, wenn Sie Geschäftstransaktionen effizient verarbeiten und speichern und sofort auf konsistente Weise für Clientanwendungen verfügbar machen müssen. Verwenden Sie diese Architektur, wenn sich spürbare Verzögerungen bei der Verarbeitung negativ auf den täglichen Betrieb des Unternehmens auswirken würden.

OLTP-Systeme sind zur effizienten Verarbeitung und Speicherung von Transaktionen sowie zum effizienten Abfragen von Transaktionsdaten konzipiert. Die effiziente Verarbeitung und Speicherung einzelner Transaktionen durch ein OLTP-System wird zum Teil durch Datennormalisierung erzielt, d. h. die Aufteilung der Daten in kleinere weniger redundante Blöcke. Dies steigert die Effizienz, da das OLTP-System so eine große Anzahl von Transaktionen unabhängig voneinander verarbeiten kann und die zusätzliche Verarbeitung entfällt, die zum Aufrechterhalten der Datenintegrität erforderlich ist, wenn redundante Daten vorhanden sind.

Herausforderungen

Die Implementierung und Verwendung eines OLTP-Systems kann einige Herausforderungen mit sich bringen:

  • OLTP-Systeme eignen sich nicht immer gut zum Verarbeiten von Aggregaten für große Datenmengen, es gibt jedoch Ausnahmen, beispielsweise eine sorgfältig geplante SQL Server-basierte Lösung. Analysen der Daten, die auf Aggregatberechnungen für Millionen einzelner Transaktionen beruhen, sind für ein OLTP-System sehr ressourcenintensiv. Ihre Ausführung kann viel Zeit in Anspruch nehmen und andere Transaktionen in der Datenbank verlangsamen oder blockieren.
  • Bei der Ausführung von Analysen und Erstellung von Berichten für stark normalisierte Daten sind die Abfragen in der Regel komplex, da die meisten Abfragen die Daten mithilfe von Verknüpfungen denormalisieren müssen. Zudem erfordern die Namenskonventionen für Datenbankobjekte in OLTP-Systemen oft sehr kurze und prägnante Namen. Die stärkere Normalisierung in Verbindung mit diesen Namenskonventionen macht es für Geschäftsbenutzer schwierig, OLTP-Systeme ohne die Hilfe eines Datenbankadministrators oder Datenentwicklers abzufragen.
  • Das unbegrenzte Speichern des Verlaufs von Transaktionen und das Speichern von zu vielen Daten in einer Tabelle können je nach Anzahl gespeicherter Transaktionen die Abfrageleistung beeinträchtigen. Die allgemeine Lösung besteht darin, ein relevantes Zeitfenster (z. B. das aktuelle Geschäftsjahr) im OLTP-System zu verwalten und historische Daten in andere Systeme auszulagern, beispielsweise in einen Data Mart oder ein Data Warehouse.

OLTP in Azure

Anwendungen wie in App Service-Web-Apps gehostete Websites, in App Service ausgeführte REST-APIs, mobile Anwendungen oder Desktopanwendungen kommunizieren in der Regel über eine REST-API-Zwischenstufe mit dem OLTP-System.

In der Praxis sind die meisten Workloads keine reinen OLTP-Workloads. Meist gibt es auch eine analytische Komponente. Darüber hinaus besteht ein zunehmender Bedarf an Funktionen zur Echtzeit-Berichterstellung, beispielsweise zur Ausführung von Berichten für das Betriebssystem. Dies wird auch als hybride Verarbeitung von Transaktionen/Analysen (Hybrid Transactional and Analytical Processing, HTAP) bezeichnet. Weitere Informationen finden Sie unter Online analytical processing (OLAP) (Analytische Onlineverarbeitung (OLAP)).

In Azure erfüllen alle folgenden Datenspeicher die grundlegenden Anforderungen für OLTP und die Verwaltung von Transaktionsdaten:

Wichtige Auswahlkriterien

Beantworten Sie die folgenden Fragen, um die Auswahl einzuschränken:

  • Möchten Sie einen verwalteten Dienst verwenden, anstatt Ihre eigenen Server zu verwalten?

  • Gelten für Ihre Lösung bestimmte Abhängigkeiten bezüglich der Kompatibilität mit Microsoft SQL Server, MySQL oder PostgreSQL? Die Treiber, die Ihre Anwendung zur Kommunikation mit dem Datenspeicher unterstützt, oder die Annahmen, die sie bezüglich der verwendeten Datenbank trifft, können die zur Auswahl verfügbaren Datenspeicher begrenzen.

  • Sind Ihre Anforderungen im Hinblick auf den Durchsatz von Schreibvorgängen besonders hoch? Wenn dies der Fall ist, sollten Sie eine Option auswählen, die In-Memory-Tabellen bereitstellt.

  • Ist Ihre Lösung mehrinstanzenfähig? Wenn dies der Fall ist, sollten Sie Optionen mit Unterstützung für Kapazitätspools erwägen, bei denen mehrere Datenbankinstanzen anstelle von festen Ressourcen pro Datenbank einen Pool für elastische Ressourcen nutzen. Dadurch können Sie die Kapazität besser auf alle Datenbankinstanzen verteilen und die Kosteneffektivität Ihrer Lösung verbessern.

  • Müssen Ihre Daten mit geringer Wartezeit in mehreren Regionen lesbar sein? Wenn dies der Fall ist, sollten Sie eine Option auswählen, die lesbare sekundäre Replikate unterstützt.

  • Muss Ihre Datenbank über geografische Regionen hinweg hoch verfügbar sein? Wenn dies der Fall ist, sollten Sie eine Option auswählen, die die geografische Replikation unterstützt. Erwägen Sie auch die Optionen, die ein automatisches Failover vom primären Replikat zu einem sekundären Replikat unterstützen.

  • Gelten für Ihre Datenbank bestimmte Sicherheitsanforderungen? Wenn dies der Fall ist, sollten Sie die Optionen erwägen, die Funktionen wie Sicherheit auf Zeilenebene, Datenmaskierung und transparente Datenverschlüsselung bieten.

Funktionsmatrix

In den folgenden Tabellen sind die Hauptunterschiede der Funktionen zusammengefasst:

Allgemeine Funktionen

Funktion Azure SQL-Datenbank SQL Server auf einer Azure-VM Azure Database for MySQL Azure Database for PostgreSQL
Verwalteter Dienst Ja Keine Ja Ja
Unterstützte Plattformen – Windows, Linux, Docker – –
Programmierbarkeit1 T-SQL, .NET, R T-SQL, .NET, R, Python SQL SQL, PL/pgSQL, PL/JavaScript (v8)

[1] Ohne Clienttreiberunterstützung, wodurch viele Programmiersprachen eine Verbindung mit dem OLTP-Datenspeicher herstellen und diesen verwenden können

Skalierbarkeitsfunktionen

Funktion Azure SQL-Datenbank SQL Server auf einer Azure-VM Azure Database for MySQL Azure Database for PostgreSQL
Maximale Größe der Datenbankinstanz 4 TB 256 TB 16 TB 16 TB
Unterstützung von Kapazitätspools Ja Ja Nr. Nein
Unterstützung des Aufskalierens von Clustern Nein Ja Nr. Nein
Dynamische Skalierbarkeit (Hochskalieren) Ja Keine Ja Ja

Funktionen für Analyseworkloads

Funktion Azure SQL-Datenbank SQL Server auf einer Azure-VM Azure Database for MySQL Azure Database for PostgreSQL
Temporale Tabellen Ja Ja Nr. Nein
In-Memory-Tabellen (speicheroptimiert) Ja Ja Nr. Nein
Columnstore-Unterstützung Ja Ja Nr. Nein
Adaptive Abfrageverarbeitung Ja Ja Nr. Nein

Verfügbarkeitsfunktionen

Funktion Azure SQL-Datenbank SQL Server auf einer Azure-VM Azure Database for MySQL Azure Database for PostgreSQL
Lesbare sekundäre Replikate Ja Ja Ja Ja
Geografische Replikation Ja Ja Ja Ja
Automatisches Failover zum sekundären Replikat Ja Nr. Nr. Nein
Wiederherstellung bis zu einem bestimmten Zeitpunkt Ja Ja Ja Ja

Sicherheitsfunktionen

Funktion Azure SQL-Datenbank SQL Server auf einer Azure-VM Azure Database for MySQL Azure Database for PostgreSQL
Sicherheit auf Zeilenebene Ja Ja Ja Ja
Datenmaskierung Ja Ja Nr. Nein
Transparent Data Encryption Ja Ja Ja Ja
Beschränken des Zugriffs auf bestimmte IP-Adressen Ja Ja Ja Ja
Beschränken des Zugriffs, um nur VNet-Zugriff zuzulassen Ja Ja Ja Ja
Microsoft Entra-Authentifizierung Ja Keine Ja Ja
Active Directory-Authentifizierung Nein Ja Nr. No
Mehrstufige Authentifizierung Ja Keine Ja Ja
Unterstützung von Always Encrypted Ja Ja Nr. Nein
Private IP-Adresse Nein Ja Nr. Nein

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Nächste Schritte