Eine Datenbank-Engine (oder Speicher-Engine) ist die zugrundeliegende Softwarekomponente, die ein Datenbankverwaltungssystem (DBMS – engl. „Data Base Management System“) verwendet, um Daten einer Datenbank zu erstellen, zu lesen, zu aktualisieren und zu löschen. Die meisten Datenbankverwaltungssysteme besitzen ihre eigene Programmierschnittstelle (API), die es dem Benutzer erlaubt, die darunterliegende Engine zu verwenden, ohne den Umweg über die Benutzeroberfläche des DBMS gehen zu müssen.
Der Begriff „Datenbank-Engine“ wird häufig austauschbar mit „Datenbank-Server“ oder „Datenbankverwaltungssystem“ verwendet. „Datenbankinstanz“ bezieht sich auf die Prozesse und Speicherstrukturen der laufenden Datenbank-Engine.
Speicher-Engines
Viele moderne DBMS unterstützen mehrere Speicher-Engines innerhalb desselben Datenbanksystems. Als Beispiel unterstützt MySQL sowohl InnoDB als auch MyISAM.
Viele Speicher-Engines unterstützen Transaktionen.
Name | Lizenz | Transaktionen |
---|---|---|
Aria | GPL | Nein |
BlitzDB | GPL | Nein |
Falcon | GPL | Ja |
InnoDB | GPL | Ja |
MyISAM | GPL | Nein |
InfiniDB | CPL | Nein |
TokuDB | GPL | Ja |
WiredTiger | GPL | Ja |
XtraDB | GPL | Ja |
RocksDB | BSD | Ja |
Weitere Engine-Typen sind:
- eingebettete Databank-Engines
- In-Memory-Datenbank-Engines
Entwurfsüberlegungen
Eine Datenbank ist – bis auf triviale Anwendungen (wie z. B. bei einem Haushaltsbuch) – speicherintensiv. Das bedeutet meist, dass der Inhalt einer Datenbank nur in kleineren Stücken (Fragmenten) von einem Rechnersystem bearbeitet werden kann. Hier kommt es auf eine sinnvolle Optimierung des Umgangs mit den Fragmenten an (Fragmentgröße, Anzahl gleichzeitig bearbeiteter Fragmente, Verteilung der Fragmente auf unterschiedliche Speicherorte und -medien usw.).
Datenbankfragmente werden im Datenbankspeicher in Datenstrukturen und Gruppierungen angelegt, die sowohl speichereigene Merkmale (z. B. Clustergrößen bei Festplatten) als auch effektive Algorithmen zur Manipulation von Daten vorteilhaft nutzen. In der Regel ist der Speicher selbst so konzipiert, dass er die Anforderungen verschiedener speicherintensiver Anwendungen (einschließlich Datenbanken) erfüllt. Ein DBMS nutzt im Betrieb oft mehrere Speicherarten gleichzeitig (z. B. Arbeitsspeicher und persistenten Speicher wie Festplatten).
Im Prinzip kann der Datenbankspeicher als linearer Adressraum betrachtet werden, in dem jeder Datensatz eine eindeutige Adresse besitzt. In der Praxis wird nur ein sehr kleiner Prozentsatz der Adressen direkt verwendet, da sie ebenfalls Speicher benötigen. Auf die meisten Daten wird indirekt zugegriffen. Dies kann mittels Verschiebeberechnungen (Index-Abstand von einem Referenzpunkt) geschehen oder mit Datenstrukturen, die unter Verwendung von Zeigern Zugriffspfade auf alle benötigten Daten in effektiver Weise definieren. Ein Beispiel hierfür sind Bayer-Bäume.
Datenbankspeicherhierarchie
Während des Betriebes befindet sich eine Datenbank gleichzeitig in unterschiedlicher Speichertechnik, die eine Speicherhierarchie bildet. Aufgrund der Architektur heutiger Rechner befindet sich der größte Teil der Datenbank, die das DBMS beherbergt, (teilweise repliziert) in flüchtigem Speicher. Daten die verarbeitet werden, sind im Prozessorregister oder Prozessor-Cache abgelegt. Diese Daten werden aus dem Arbeitsspeicher gelesen, bzw. dorthin geschrieben, üblicherweise über den Speicherbus. Der Arbeitsspeicher übermittelt Daten an externe Speicher, üblicherweise über Standard-Speicherschnittstellen oder das Netzwerk (z. B. Fibre-Channel, iSCSI). Ein Speicherverbund, hat üblicherweise wiederum eine eigene Speicherhierarchie, von einem schnellen Cache, der aus (flüchtigem und schnellem) DRAM besteht und (wieder über Standardschnittstellen) mit Laufwerken, möglicherweise mit unterschiedlichen Geschwindigkeiten, verbunden ist, wie SSDs und magnetischen Plattenlaufwerken (nicht-flüchtig). Die Laufwerke können mit Magnetspeicherbändern verbunden sein, auf denen üblicherweise die am seltensten benötigten Teile einer großen Datenbank abgelegt sind, oder Generationen von Datenbanksicherungen.
Es besteht häufig ein Zusammenhang zwischen Speichergeschwindigkeit und Preis, wobei schneller Speicher noch dazu üblicherweise flüchtig ist.
Datenstrukturen
Eine Datenstruktur ist ein abstraktes Konstrukt, das Daten in wohldefinierter Weise ablegt. Eine effiziente Datenstruktur ermöglicht schnellen Zugriff und Veränderung der Daten. Dieser Zugriff kann das Einfügen, Löschen, Ändern und Abfragen von Daten auf verschiedene Weisen beinhalten. Bei bestimmten Operationen kann ein bestimmter Datenstrukturtyp geeignet sein, bei anderen hingegen nicht. Ein Datenstrukturtyp wird bei der Entwicklung des DBMS danach ausgewählt, wie gut er für die Art der Daten, die er beinhaltet und die darauf anzuwendenden Operationen, geeignet ist. Bei der Auswahl der Datenstruktur für eine bestimmte Aufgabe wird ebenfalls die Art des Speichermediums auf dem sie abgelegt wird berücksichtigt (z. B. Zugriffsgeschwindigkeit, minimale Größe der zuzugreifenden Speicherblöcke usw.). Einige DBMS bieten Datenbankadministratoren die Flexibilität, um zwischen verschiedenen Datenstrukturen die für die Nutzerdaten unter Leistungsaspekten geeignetste auszuwählen. Manche Datenstrukturen besitzen auswählbare Parameter, um die Datenbankleistung abzustimmen.
Datenbanken können Daten in vielen unterschiedlichen Datenstrukturtypen ablegen. Übliche Beispiele sind die folgenden:
- sortierte/unsortierte Einfachdateien
- Hashtabellen
- B+-Bäume
- ISAM
- Heaps
Datenorientierung und Gruppierung
Im Gegensatz zur herkömmlichen Zeilenorientierung können relationale Datenbanken auch spaltenorientiert oder korrelational organisiert sein.
Im Allgemeinen werden wesentliche Leistungsverbesserungen erreicht, indem unterschiedliche Arten von Datenbankobjekten, die für gewöhnlich zusammen verwendet werden, im Speicher in räumlicher Nähe gruppiert werden. Dies erlaubt es, die benötigten zusammenhängenden Objekte aus dem Speicher mit einer minimalen Anzahl an Eingabeoperationen (teilweise erheblich zeitaufwändig) zu erhalten. Sogar bei In-Memory-Datenbanken bietet Gruppierung Leistungsvorteile durch die gemeinsame Verwendung großer Puffer für Eingabe-Ausgabe-Operationen im Speicher, mit ähnlichem Ergebnisverhalten.
Zum Beispiel kann es vorteilhaft sein, einen Datensatz „Artikel“ im Lager mit allen seinen jeweiligen „Bestellung“-Datensätzen zu gruppieren. Die Entscheidung, ob bestimmte Objekte gruppiert werden oder nicht, hängt von den Verwendungsstatistiken des Objektes, der Objektgröße, Puffergrößen, Speichertypen usw., ab.
Datenbankindizierung
Indizierung ist eine Methode, die manche Speicher-Engines verwenden, um die Datenbankleistung zu erhöhen. Die vielen Arten an Indizes teilen die gemeinsame Eigenschaft, dass sie die Notwendigkeit verringern, beim Ausführen einer Abfrage jeden Eintrag zu untersuchen. In großen Datenbanken kann dies die Abfragezeit um Größenordnungen verringern. Die einfachste Form eines Indexes ist eine sortierte Liste von Werten, die mittels binärer Suche verarbeitet wird und einen beigefügten Verweis auf die Position des Datensatzes besitzt, analog zum Index am Ende eines Buches. Dieselben Daten können über mehrere Indizes verfügen (z. B. kann eine Datenbank mit Angestellten sowohl nach Nachnamen, als auch nach Einstellungsdatum indiziert sein).
Indizes beeinflussen die Leistung, aber nicht die Ergebnisse. Datenbankdesigner können daher Indizes hinzufügen oder entfernen, ohne die Geschäftslogik anpassen zu müssen. Dies reduziert die Wartungskosten, wenn der Datenbankumfang und die Anzahl der Abfragen wachsen. Indizes verbrauchen zusätzlichen Platz in der Datenbank und müssen nach jeder Datenänderung aktualisiert werden. Indizes können daher den Datenzugriff beschleunigen, verlangsamen aber die Datenwartung. Diese beiden Eigenschaften bestimmen, ob die Vorteile eines Indexes seine Nachteile aufwiegen.
Siehe auch
- Btrieve's Micro-Kernel Datenbank-Engine
- Berkeley DB
- c-treeACE Datenbank-Engine
- FLAIM Datenbank-Engine
- Microsoft Jet Datenbank-Engine
- MySQL Cluster, auf der NDB-Speicher-Engine von MySQL
- NuoDB
Einzelnachweise
- ↑ Lightstone, Teorey, Nadeau: Physical Database Design. 2007, ISBN 0-12-369389-6.
Weblinks
- http://dev.mysql.com/tech-resources/articles/storage-engine/part_3.html
- MySQL Administrator's Bible Chapter 11 „Storage Engines“