Was sind transaktionale Datenbanken?

Transaktionale Datenbanken sind für laufende Produktionssysteme optimiert – alles von Websites über Banken bis hin zu Einzelhandelsgeschäften. Sie sind hervorragend darin, einzelne Datenzeilen sehr schnell zu lesen und zu schreiben und dabei die Datenintegrität zu wahren.

Transaktionale Datenbanken sind nicht speziell für die Analytik konzipiert, aber oft werden sie zu De-facto-Analytikumgebungen, weil sie bereits als Produktionsdatenbanken im Einsatz sind. Weil es sie seit Jahrzehnten gibt, sind sie vertraut und zugänglich und allgegenwärtig.

Wenn Ihre Organisation nicht über einen bereits vorhandenen separaten Analysestapel verfügt, besteht einer der schnellsten Wege, mit der Durchführung von Analysen zu beginnen, darin, ein Replikat Ihrer transaktionalen Datenbank zu erstellen. Dies stellt sicher, dass analytische Abfragen nicht versehentlich geschäftskritische Produktionsabfragen behindern, und es ist nur ein minimaler zusätzlicher Einrichtungsaufwand erforderlich. Der Nachteil dabei ist, dass diese Datenbanken für die Verarbeitung von Transaktionen und nicht für die Analyse konzipiert sind. Sie für die Analytik zu verwenden, ist ein guter Anfang, aber Sie werden womöglich früher an Grenzen stoßen und Workarounds benötigen, als dies bei einem analytikspezifischen Set-up der Fall wäre.

Transaktionale Datenbanken sind Zeilenspeicher, was bedeutet, dass die Daten auf der Platte als Zeilen und nicht als Spalten gespeichert werden. Das ist zum Beispiel praktisch, wenn Sie alles über einen Kunden in der Benutzertabelle wissen müssen, weil Sie nur die Daten abgreifen, die Sie benötigen. Wenn Sie jedoch versuchen, die Kunden in einem bestimmten Postleitzahlenbereich zu zählen, sind solche Zeilenspeicher nicht ideal, da Sie nicht nur die PLZ-Spalte, sondern auch die Spalten Name, Adresse und user_id laden müssen.

Wozu sind transaktionale Datenbanken wirklich hervorragend geeignet?

Sicherstellung der Datenintegrität

Transaktionale Datenbanken sind so konzipiert, dass sie ACID-konform sind, was sicherstellt, dass Schreibvorgänge in die Datenbank entweder erfolgreich sind oder insgesamt fehlschlagen, wodurch beim Schreiben von Daten in die Datenbank ein hohes Maß an Datenintegrität erhalten bleibt. Transaktionale Datenbanken sind daher kritisch für Geschäftstransaktionen, bei denen ein hohes Maß an Datenintegrität erforderlich ist (das kanonische Beispiel ist Bankwesen, wo eine ganze Transaktion – Abbuchung von einem Konto und Gutschrift auf ein anderes – entweder erfolgreich sein oder fehlschlagen soll).

Geringe Latenzzeit

Weil transaktionale Datenbanken für Produktionssysteme ausgelegt sind, sind sie sehr gut für Operationen geeignet, die in Millisekunden abgeschlossen sein müssen. Wenn Sie Analytik auf einem transaktionalen Replikat Ihrer Produktionsdatenbank durchführen, ist das Replikat wahrscheinlich nahezu synchron mit der Master-Datenbank (d. h. mit einer Latenz unter einer Sekunde).

Betriebssystem-Überwachung

Die Arbeit mit Daten aus transaktionalen Datenbanken zur Erstellung eines operativen Echtzeit-Snapshots ist ein perfekter Analytik-Anwendungsfall für transaktionale Datenbanken, weil die durch die Replikation verursachte Latenz so gering ist. Wenn Sie versuchen, die Support-Workloads oder den Bestand oder ein anderes Betriebssystem zu überwachen und Entscheidungen auf der Grundlage möglichst aktueller Daten treffen müssen, ist die Replikation der Produktionsdatenbank möglicherweise die beste Option.

Beliebte transaktionale Datenbanken

Architektur

Zeilenspeicher

Transaktionale Datenbanken sind Zeilenspeicher, was bedeutet, dass eine ganze Zeile von Daten zusammen gespeichert wird, mit der Annahme, dass ein Benutzer, wenn er einen Datensatz lesen möchte, er alle über diesen Datensatz verfügbaren Daten abrufen möchte. Abfragen gegen eine transaktionale Datenbank durchsuchen jede Datenzeile vollständig und zeigen dann nur die durch die Datenbankabfrage ausgewählten Spalten an.

Analytische Datenzentren sind hingegen Spaltenspeicher, in denen jedes Feld unabhängig gespeichert wird. Dadurch werden analytische Datenzentren für das Lesen von Daten, aber nicht für das Schreiben von Daten optimiert, da das Schreiben in eine analytische Datenbank mit der Ausführung vieler gleichzeitiger Schreibvorgänge über mehrere Spalten hinweg verbunden ist.

Dies bedeutet jedoch auch, dass analytische Datenbanken im Allgemeinen effizienter und schneller bei der Durchführung von Aggregationen sind. Die Durchführung einer Aggregation eines Datensatzes aus einer transaktionalen Datenbank setzt voraus, dass jede einzelne Zeile vor der Aggregation gescannt wird. Es ist effizienter, nur die Spalte zu scannen, die Sie aggregieren möchten, wodurch analytische Datenzentren für komplexere Analysen besser geeignet sind.

Für Unternehmen mit kleinen Datenmengen kommt dieses Problem möglicherweise nicht ins Spiel, aber mit zunehmender Menge der verfügbaren Daten werden diese Unterschiede deutlicher.

ACID-Transaktionen

ACID ist eine Reihe von Eigenschaften, die beschreiben, wie transaktionale Datenbanken konstruiert sind, um die Integrität der Schreibvorgänge in die Datenbank zu erhalten.

Eigenschaft Beschreibung
Atomarität Wenn auch nur ein Teil der Transaktion fehlschlägt, schlägt die gesamte Transaktion fehl. Auf diese Weise muss jede Transaktion zu 100 % gelingen, um erfolgreich in die Datenbank aufgenommen zu werden.
Konsistenz Eine Transaktion wird entweder in die Datenbank geschrieben (wodurch die Datenbank von einem gültigen Zustand in einen anderen überführt wird) oder die Transaktion wird rückgängig gemacht.
Isolation Transaktionen, die noch nicht abgeschlossen sind, können nicht durch andere Transaktionen bearbeitet/verändert werden.
Dauerhaftigkeit Ist eine Transaktion einmal in die Datenbank geschrieben, bleibt sie dort auch im Falle eines Datenbankversagens erhalten.

Unten ist ein Beispiel aufgeführt, das die Bedeutung von ACID als Funktion des Designs von transaktionalen Datenbanken unterstreicht. Angenommen, Sie haben zwei Personen, die um einen Sitz bei einer Fluggesellschaft konkurrieren.

Person A bucht einen Sitzplatz, und Person B bucht mehrere Sitzplätze auf einmal.

  • Atomarität – Wenn Person A ihre Transaktion erfolgreich abschließt, scheitert die Transaktion von Person B, weil bereits ein Platz in ihrem Korb beansprucht wurde.
  • Konsistenz – Person A und Person B können nicht beide ein Ticket für den gleichen Sitzplatz haben.
  • Isolation – Die Transaktion von Person B wird dann und nur dann abgebrochen, wenn die Transaktion von Person A vollständig erfolgreich war und in die transaktionale Datenbank geschrieben wurde und umgekehrt.
  • Dauerhaftigkeit – Wenn die Datenbank ausfällt, nachdem Person A erfolgreich ihren Sitzplatz beansprucht hat, kann Person A ihren Kauf am Flughafen immer noch einlösen.

Position innerhalb des Datenstacks

Wenn transaktionale Datenbanken für analytische Services genutzt werden, werden sie meist als Replikat der Produktionsdatenbank konfiguriert. Diese Konfiguration ist umfassend dokumentiert und für die meisten DBA oder Ingenieure ziemlich leicht einzurichten.

Anbieter von Cloud-Datenbanken bieten einfache Möglichkeiten zur Bereitstellung des Replikats. Es ist empfehlenswert, dieses Setup zu verwenden, anstatt Analytik direkt auf Ihrer Produktionsdatenbank durchzuführen, da analytische Abfragen erhebliche Ressourcen in Anspruch nehmen können und die Leistung Ihrer Produktionsdatenbank, die für das Schreiben von Daten verwendet werden sollte, beeinträchtigen könnten. In den meisten Fällen sollte die Replikatdatenbank höchstens einige Sekunden hinter der Produktionsdatenbank zurückliegen.

Einschränkungen

Wenn Sie ein Replikat Ihrer Produktionsdatenbank für Analytik auf einer transaktionalen Datenbank verwenden, können Sie in einigen Fällen normalerweise keine Daten in dieses Replikat schreiben. Dies liegt daran, dass die Aufgabe des Replikats die exakte Spiegelung der Produktionsdatenbank ist, und ein auf dem Replikat ausgeführter Schreibvorgang würde nicht auf der Masterdatenbank gespiegelt werden.

Es gibt Ausnahmen davon, da Sie möglicherweise einen beschreibbaren Teil Ihrer Replikat-Datenbank erstellen können, aber dies ist sicherlich eine Einschränkung, die zu berücksichtigen ist und die bestimmte Arten von Operationen komplexer machen kann.

Optimierung

Isolationsebene

Die am niedrigsten hängende Frucht bei der Optimierung Ihrer transaktionalen Datenbank für Analytik ist die Verringerung der Isolationsebene. Die Isolationsebene steuert, welche Arten von Operationen eine Tabelle „sperren“, so dass eine geringere Isolation die Replikatsverzögerung verringert und die Verwendung von Sperrbedingungen durch die Datenbank moderiert. Da Sie diese Einstellungen nur auf dem Read-only-Replikat ändern, sollte dies sicher sein.

Indizierung

Die singulär größte Leistungssteigerung für Ihre transaktionale Datenbank ist die Einrichtung guter Indizes. Indizes sind, wie der Name schon sagt, die Art und Weise, wie die Datenbanken bestimmte Spalten anordnen, so dass sie sofort wissen, wo verschiedene Zeilen auf der Platte liegen. Die Indizierung von Fremdschlüsseln für häufig verbundene Tabellen und Zeitstempel für zeitlich geordnete Tabellen kann die analytische Abfrageleistung erheblich verbessern, indem die Anzahl der für JOINs gescannten Zeilen reduziert wird.

Der einzige Nachteil des Hinzufügens von Indizes besteht darin, dass jeder zusätzliche Index Speicherplatz auf der Festplatte beansprucht. Eine gute Indizierungsstrategie besteht also darin, eine schnellere Leistung zu erreichen, ohne dass der Speicherplatz knapp wird.

Verringerung der Redundanz

Die Verringerung der Datenredundanz ist ebenfalls eine gute Möglichkeit, die Leseleistung von Tabellen zu erhöhen. Die Speicherung von Daten in der dritten Normalform ist ein gängiges Muster, um dies zu erreichen. Dies kann die Breite von häufig gelesenen Zeilen drastisch reduzieren und weniger benutzte Teile der Daten in ihre eigenen Tabellen verschieben, die dann nur bei Bedarf mit JOIN verbunden werden können.

Datenmatrix

Auch eine spärlich besetzte Datenmatrix kann die Leistung stark beeinträchtigen. Die häufigsten Datensätze, die eine spärlich besetzte Matrix aufweisen, sind Dinge wie medizinische Aufzeichnungen, Server-Protokolle und Sammlungen unstrukturierter Daten. Spaltendatenbanken sind im Kern für den Umgang mit einer spärlichen Datenmatrix ausgelegt.

Wenn Sie einen Reihenspeicher verwenden, benötigen Sie wahrscheinlich einen oder mehrere Workarounds. Eine Möglichkeit, damit umzugehen, besteht darin, Spalten in Ihrer Tabelle in mehrere Tabellen zu fragmentieren. Diese Strategie kann die Anzahl der pro Abfrage verwendeten Spalten reduzieren. Das Einrichten eines Entitäts-Attribut-Wert-Schemas kann ebenfalls hilfreich sein, wenn Sie eine extrem spärliche Matrix haben, aber dies erhöht die Komplexität von analytischen Abfragen. Ein Tool mit einer robusten Modellierungsebene wie Looker kann eine solche Strategie unterstützen, wohingegen das Schreiben von SQL von Grund auf sehr sperrig werden kann.

Datentransformationen

Eine weitere ausgezeichnete Möglichkeit zur Abfrageoptimierung besteht darin, teure Berechnungen in SQL durchzuführen, bevor die Abfrage ausgeführt wird. Die Verwendung von Datentransformationen zur Verarbeitung der Rohzeilen zur Erstellung von Aggregaten oder DISTINCTs im Vorfeld beschleunigt Abfragen erheblich. Der wichtigste Nachteil besteht darin, dass ein Rollup Ihrer Daten die Auflösung verringert und ständig gepflegt und aktualisiert werden muss, wenn neue Daten hinzugefügt werden.

Entdecken Sie Ihre Liebe zur Analytik.

Business Intelligence, Big-Data-Analyse oder eine 360°-Ansicht Ihrer Kunden.
Was auch immer Sie benötigen, Looker steht Ihnen zur Seite. Sprechen Sie einfach mit unseren Datenexperten.

Demo anfordern