Als Online Transaction Processing (OLTP) wird die Echtzeit-Datenverarbeitung bezeichnet, die beispielsweise hinter Geldautomatenabhebungen, Kreditkartenzahlungen, Ticket- und Reservierungssystemen, Online-Shopping und dem elektronischen Handel im Allgemeinen steht.

Online Transaction Processing - Definition

OLTP-Systeme sind speziell für die Verarbeitung einer großen Anzahl von Transaktionen durch eine Vielzahl gleichzeitiger Benutzer ausgelegt.

OLTP-Datenbanken bilden das Backend oder die Speicherebene für E-Commerce und die meisten modernen Computeranwendungen. Während Online-Transaction-Processing-Datenbanken traditionell relationale SQL-Datenbanken sind, können auch einige NoSQL-Datenbanken für dieselben Zwecke verwendet werden. Im Folgenden werden wir uns hauptsächlich auf relationale SQL-Datenbanken beziehen.

OLTP vs. OLAP

OLTP-Datenbanken verarbeiten in der Regel eine große Anzahl kleiner, schneller Transaktionen von vielen Benutzern. Bei diesen Transaktionen wird die Datenbank auf garantiert konsistente Weise verändert, wobei sogenannte CRUD-Operationen (Create, Read, Update, Write) innerhalb der einzelnen Transaktionen verwendet werden.

OLTP-Datenbanken unterstützen zwar manchmal auch analytische Abfragen, aber diese Funktionalität wird häufig in spezielle separate OLAP-Datenbanken (Online Analytical Processing) oder Data Warehouses ausgelagert. Online-Transaction-Processing-Datenbanken sind darauf optimiert, Daten zu sammeln, zu verarbeiten und die entsprechenden Ergebnisse wie einen Geschäftsumsatz oder einen Auftrag in die entsprechende Tabelle zurückzuschrieben. OLAP-Datenbanken hingegen sind für die Datenanalyse optimiert. Allerdings versuchen Hersteller wie Oracle, OLTP- und OLAP-Funktionen zunehmend in einer einzigen Datenbank zu vereinen.

CRUD (Create, Read, Update und Delete) bezeichnet den grundlegenden Satz von Datenbankoperationen. In einer SQL-Datenbank:

• INSERT-Anweisungen erstellen Datensätze (Create),

• SELECT-Anweisungen lesen Datensätze (Read),

• UPDATE-Anweisungen aktualisieren Datensätze (Update) und

• DELETE-Anweisungen löschen Datensätze (Delete).

Diese Anweisungen bilden die DML (Data Manipulation Language). SQL-Datenbanken unterstützen darüber hinaus auch DDL (Data Definition Language), um Datenbanken, Tabellen, Indizes, Ansichten und andere Datenbankobjekte zu definieren.

Eine Datenbanktransaktion in einer SQL-Datenbank ist ein Wrapper für eine Folge von SQL-Anweisungen mit zwei möglichen Endpunkten: COMMIT oder ROLLBACK des Stapels. Bei einer Banküberweisung wird zum Beispiel ein Betrag von einem Konto abgehoben und derselbe Betrag auf ein anderes Konto eingezahlt. Wenn beide Vorgänge erfolgreich sind, wird die Transaktion bestätigt. Schlägt einer der beiden Vorgänge fehl, wird die Transaktion - die beide Vorgänge umfasst - auf den Ausgangszustand zurückgesetzt, so dass der Gesamtbetrag auf den beiden Konten konstant bleibt.

Datenbanktransaktionen sollten alle vier ACID-Eigenschaften aufweisen: Atomarität, Konsistenz, Isolation und Dauerhaftigkeit.

• Atomarität wird, wie oben beschrieben, durch Transaktions-Commits und -Rollbacks gewährleistet. Die gesamte Transaktion wird als ein einziger, in sich geschlossener atomarer Vorgang behandelt.

• Konsistenz ist das Endprodukt einer ordnungsgemäßen Transaktionsimplementierung: Der Gesamtbetrag auf den an der Überweisung beteiligten Konten bleibt konstant.

• Isolation bedeutet, dass andere Transaktionen keine Zwischenzustände einer Transaktion feststellen können.

• Dauerhaftigkeit bedeutet, dass nach dem Commit einer Transaktion die neuen Werte nicht rückgängig gemacht werden, selbst wenn das System ausfällt.

ACID-Eigenschaften sind in einer einzelnen zentralen Datenbank leichter zu gewährleisten, als in einer geclusterten oder verteilten Database. Einige verteilte Datenbanken beanspruchen zum Beispiel nur eventuelle Konsistenz, so dass sie eine Transaktion als abgeschlossen betrachten, bevor alle Datenbankknoten den Schreibvorgang beendet haben. Das beschleunigt verteilte Transaktionen, erfordert aber, dass spätere Transaktionen, die Konsistenz erwarten, entweder warten müssen, bis alle Schreibvorgänge abgeschlossen sind - oder dass sie vom ursprünglichen Ort der Transaktion lesen müssen.

Verteilte Datenbanken, die eine starke Konsistenz garantieren, haben zwar höhere Transaktionslatenzen, verursachen aber viel seltener Anwendungsfehler als eventuell konsistente Datenbanken - etwa wenn ein entferntes Lesen abgeschlossen wird, bevor eine vorherige Transaktion an allen Stellen fertig geschrieben ist.

OLTP-Datenbanken - Schemata

Um hohe Transaktionsraten zu unterstützen, beinhalten Datenbankschemata für OLTP-Datenbanken in der Regel kleine Zeilengrößen und minimale Indizes. In der Vergangenheit bedeutete das, dass das Datenbankschema in der dritten Normalform erstellt werden musste. Die dritte Normalform (3NF) wurde 1971 von Edgar F. Codd definiert und ist eine Reihe von Anforderungen an Datenbankschemata, um:

• die Duplizierung von Daten zu reduzieren,

• Datenanomalien zu vermeiden,

• die referenzielle Integrität zu gewährleisten und

• die Datenverwaltung zu vereinfachen.

Sie besagt im Wesentlichen, dass jede Tabelle nur Felder enthält, die Attribute des Primärschlüssels sind. Wenn Sie eine Patiententabelle haben, deren Primärschlüssel die Patientennummer ist, müssen sich die Felder auf den Patienten beziehen, nicht auf das Krankenhaus, nicht auf den Arzt und nicht auf den Versicherer, obwohl die Tabelle Verweise (Fremdschlüssel) auf andere Tabellen zu diesen Themen enthalten kann. Bill Kents clevere Zusammenfassung der 3NF lautet: "Jedes Nicht-Schlüssel-Attribut muss einen Fakt über den Schlüssel, den gesamten Schlüssel und nichts als den Schlüssel liefern."

OLTP - Performance messen

Anbieter von relationalen Datenbanken werben oft mit besonders schnellen Benchmark-Ergebnissen für ihre Produkte. Der Haken an der Sache: Oft wurden diese Benchmarks zur Messung der Transaktionsverarbeitungsleistung für die jeweils eigenen Produkte optimiert. Deshalb wurde das Transaction Processing Performance Council gegründet, um herstellerneutrale Benchmarks zu erstellen und zu prüfen. TPC Benchmark C (TPC-C) ist ein weit verbreiteter OLTP-Benchmark.

Es gibt weitere öffentliche Datenbank-Benchmarks, die für sie relevant sein könnten. Darüber hinaus können Sie auch eigene Benchmarks erstellen - allerdings sollten das ehrliche Benchmarks sein, die die reale Nutzung widerspiegeln. Diese sind allerdings meist schwierig zu schreiben und auszuführen.

Insgesamt sollten OLTP-Datenbanken einfach ihre Aufgabe erfüllen, nämlich Transaktionen schnell und dauerhaft aufzuzeichnen. Für die Analyse sollten Sie einen separaten Data Lake oder ein Data Warehouse und einen ETL- oder ELT-Prozess einrichten, um die Analysedatenbank aus der OLTP-Datenbank zu befüllen. OLTP ist eine Sache, OLAP eine andere. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Network World.