Über unsMediaKontaktImpressum
Dr. Jens Graupmann 17. September 2019

Datenbanken – Technologien im Überblick

Von klassischen Universal-Datenbanksystemen über analytische disk-basierte und In-Memory-Datenbanken bis hin zu speziellen Cloud-only-Systemen: Jede Ausprägung der Datenbank-Technologie hat besondere Vorzüge für bestimmte Use Cases. In der Wahrnehmung am Markt zielen die meisten Hersteller jedoch eher darauf ab, ihr Produkt als Lösung für alle Herausforderungen der Digitalisierung zu platzieren – in der Realität unterscheiden sich die Ansätze jedoch zum Teil erheblich in Bezug auf den optimalen Einsatzzweck, Performance, Skalierbarkeit und Kosten.

Will man Datenbanksysteme kategorisieren, bietet sich zunächst die typische – wenn auch sehr grobe – Unterteilung in relationale und nicht-relationale Lösungen an. Während relationale Datenbank-Management-Systeme (RDBMS) die Daten basierend auf typisierten Spalten in Relationen speichern und mit SQL arbeiten, nutzen nicht-relationale Datenbanken andere Paradigmen, wie etwa Objektbasierung, schemalose Dokumente- oder generische Key-Value-Zuordnungen. Die meisten der nicht-relationalen Datenbanken werden als NoSQL-Datenbanken kategorisiert, obwohl sich sehr verschiedene Vertreter in dieser Gruppe tummeln. Doch gerade diese Benennung ist etwas irreführend: Stand "No SQL" zunächst tatsächlich für "kein SQL", so wurde dies später zu "Not Only SQL", nachdem sich der deutlich treffendere Ansatz, diese Gruppe als "noRel" für "nicht-relational" zu bezeichnen, nicht durchsetzte.  

RDBMS sind die in der Praxis am weitesten verbreiteten Datenbanken – typische Vertreter sind Oracle, IBM DB2 oder Microsoft SQL Server. Sie sind grundsätzlich relativ einfach zu integrieren und zu nutzen – nicht zuletzt aufgrund der zumindest zu großen Teilen standardisierten Sprache SQL und ihren genormten Schnittstellen JDBC und ODBC. Allerdings ist auch in diesem Segment der Markt vielfältig und nicht einfach zu durchschauen. Mächtige proprietäre Erweiterungen und undurchsichtige Lizenzmodelle erschweren die Entscheidung.

Mit wachsenden Datenmengen zeigen klassische RDBMS Performance-Schwächen. So geht es im transaktionalen Bereich (OLTP – Online Transaction Processing) um die zeitnahe Verarbeitung einer großen Anzahl von Transaktionen ohne Zeitverzug. Sowohl der Overhead der relationalen Struktur als auch technische Skalierungsprobleme bei klassischen Datenbanksystemen haben die Entwicklung zahlreicher NoSQL-Datenbanken vorangetrieben. Auf der anderen Seite opfern NoSQL-Datenbanken im Gegenzug häufig die unbedingte Datenkonsistenz und Integrität (CAP-Theorem). Einen weiteren – oft auch vermeintlichen – Vorteil bieten NoSQL-Datenbanken auch dadurch, dass sie nicht an ein festes Schema gebunden sind, das im Vorfeld definiert werden muss (Schema on read).

Somit kombinieren NoSQL-Datenbanken extreme Skalierbarkeit mit Flexibilität in transaktionslastigen Anwendungsfällen, vor allem dann, wenn eine RDBM-typische Konsistenz nicht vollständig erforderlich ist.

Wie die Daten genau abgespeichert und verwaltet werden, entscheidet das jeweils zugrunde liegende Modell. Die Auswahl reicht hier von dokumentenbasierten und objektorientierten Datenbanken über Key-Value-Store-Systeme bis hin zu Graphdatenbanken und spaltenorientierten Modellen.

Anforderungen der Business Intelligence

Besonders in den letzten Jahren haben sich die Anforderungen in Bezug auf die Datenverarbeitung stark verändert: Zum einen sehen sich IT-Abteilungen extrem stark wachsenden Datenmengen gegenüber. Zum anderen werden diese Daten keineswegs nur gespeichert oder gar archiviert. Vielmehr erwachsen Daten und ihre Interpretation zur Grundlage für das Geschäft insgesamt. Data-native, data-driven Business Analytics & AI sind die Schlagworte der Stunde. Die Erfassung, Aggregation, Auswertung und Interpretation von Daten wird zum entscheidenden Erfolgsfaktor in vielen Branchen, um konkurrenzfähig zu bleiben.

Welches Datenbank-System sich am besten eignet, ist nun kaum mehr nur danach zu entscheiden, ob es relational oder nicht-relational arbeitet. Die Anforderungen an die Analyse riesiger Datenmengen sind komplex und müssen neben technischen Anforderungen zusätzlich verschiedene Sourcing-Optionen bedenken. Wie kann etwa eine cloud-basierte Infrastruktur nützlich sein: nur als kurzfristige Abdeckung primär hardware-seitiger Ressourcen-Engpässe oder als vollständiges Outsourcing beispielsweise in Form einer Database-as-a-Service-Lösung? Hybride Infrastrukturen, gemischt mit verschiedenen Ausprägungen von IaaS zu SaaS, eröffnen weitere, zahlreiche Möglichkeiten.

Data Analytics braucht Relationen und Performance

Für analytische Anwendungsfälle ist die Speicherung in Relationen vorteilhafter. Zwar zeichnen sich NoSQL-Datenbanken durch hohe Performance beim Abarbeiten von Transaktionen aus, bei der Datenanalyse kommt es jedoch eben genau auf die Verknüpfung oft großer Datenmengen durch Joins, Aggregationen und analytische Funktionen an. Aus diesem Grund sind hier relationale Datenbanken das Mittel der Wahl. Allerdings sind klassische relationale Multi-Purpose-Datenbanken auch hier oft nicht in der Lage, die geforderte Performance und Skalierbarkeit zu liefern. Aus diesem Grund hat sich das Segment der analytischen Datenbank (Analytics Database oder auch Analytical Database) gebildet: Datenbanken, die relational arbeiten, eine leistungsfähige SQL-Abdeckung aufweisen und eine Reihe konzeptioneller und architekturseitiger Technologien zum Steigern der Performance und Bewerkstelligen von Skalierbarkeit aufweisen.

Massive Parallel Processing (MPP) ist eine davon. Datenbank-Management-Systeme, die MPP nutzen, verteilen das Bearbeiten von Anfragen auf mehrere Server in einem Computer-Cluster. Jeder Infrastruktur-Knoten übernimmt dabei einen anderen Teil der Berechnung, am Ende werden die Teil-Ergebnisse wieder aggregiert. In solchen Shared-(Almost)-Nothing-Architekturen arbeitet jeder Knoten unabhängig mit seinem eigenen Prozessor und Hauptspeicher. Die Bezeichnung "Almost"-Nothing verweist auf die Tendenz, dass die einzelnen Knoten nicht ihren eigenen dedizierten Massenspeicher nutzen, sondern einen skalierbaren Shared-Storage-Ansatz verfolgen. Die Technologie ermöglicht es, relativ unkompliziert durch Skalierung – sprich das Hinzuschalten weiterer Server im Cluster – die Kapazität in Hinblick auf die Datenmenge sowie die Performance nahezu linear zu steigern. Sie eignen sich deshalb sehr gut als Basis für stark wachsende und extrem große Data Warehouses.

Aber auch bei den Analytics Databases mit MPP-Technologie gibt es Unterschiede. Der wichtigste in Bezug auf die Performance ist die Frage, von welchem Speichermedium die benötigten Daten geladen werden. Traditionelle Datenbank-Systeme basieren auf klassischem Sekundärspeicher, also Festplatten, die lokal angebunden oder als SAN konfiguriert sind. Festplatten-basierte Systeme sind inhärent deutlich langsamer, da Datenblöcke erst auf dem Sekundärspeicher lokalisiert und in den Hauptspeicher geladen werden müssen, während die Daten bei hauptspeicher-basierten Datenbanken per direktem Zugriff ausgewertet werden können.

In-Memory-Verarbeitung mit Random Access

Besonders geeignet für die performante Analyse von großen Datenmengen sind analytische Datenbanken, die das spaltenbasierte Speichern mit In-Memory-Verarbeitung kombinieren. In-Memory-Datenbanken (IMDB) nutzen den Hauptspeicher zur Beschleunigung der Berechnungen. Die Daten werden dabei im Hauptspeicher vorgehalten, was einen schnellen Zugriff ermöglicht. Im Gegensatz zu diskbasierten Systemen, die zunächst die entsprechenden Blöcke vom Sekundärspeicher laden müssen, kann hier jede Speicherzeile direkt über ihre Speicheradresse angesprochen werden. So erfolgt die Berechnung von Ergebnissen um Größenordnungen schneller. Grundsätzlich hängt bei IMDBs demnach die Dimensionierung des Hauptspeichers von der Menge der zu verarbeitenden Daten ab. Verschiedene Datenbank-Anbieter offerieren unterschiedliche Ansätze, die von "Alles im Hauptspeicher" über "Hot Data im Hauptspeicher" bis hin zu "In-Memory-Add-on für die klassische Datenbank" reichen.

Die beiden bekanntesten Datenbanksysteme, die von Beginn an auf In-Memory-Technologie und spaltenbasierte Datenhaltung setzten, sind SAP HANA und Exasol (wobei SAP HANA zusätzlich auch zeilenbasierte Speicherung einsetzt). SAP liefert dabei mit dem Alles-im-Hauptspeicher-Ansatz die stringenteste Form: Alle Daten stehen permanent im Hauptspeicher zur Verfügung, zu keiner Zeit muss von der Festplatte nachgeladen werden. Lediglich für das Absichern der Persistenz der Daten ist ein diskbasierter Speicher notwendig. Die Verarbeitung der eigentlichen Anfragen findet jedoch ausschließlich über den Hauptspeicher statt. Gerade bei den schnell wachsenden Datenmengen im Data-Analytics-Bereich wird die dafür notwendige Dimensionierung des Hauptspeichers zur echten Herausforderung. Er muss zunächst mindestens so groß wie die erwartete Datenmenge sein und Kapazitäten haben, um parallele Anfragen vieler Nutzer zu puffern und temporäre Zwischenergebnisse zu speichern. Und nicht nur das: Ist nicht ausreichend Hauptspeicher für die Anfrageverarbeitung verfügbar, muss sofort nachgerüstet werden, um Performance-Engpässe oder sogar die Nichtverfügbarkeit der Datenbank zu vermeiden.

Die IMDB von Exasol hält primär die sogenannten "heißen Daten" im Hauptspeicher vor. Durch Algorithmen optimiert reduziert das System so den Bedarf an Hauptspeicher – dort werden nur die Daten vorgehalten, die gerade benötigt werden beziehungsweise wahrscheinlich benötigt werden. In der Praxis machen diese etwa ein Drittel der Gesamt-Rohdaten-Menge aus, oft sogar noch weniger. Da die Daten zusätzlich komprimiert werden, ergibt sich so oft ein Verhältnis von Hauptspeicherbedarf zu Rohdatenmenge von 1:10 oder besser.

Architektonisch betrachtet zählt Exasol somit zu den hybriden Hauptspeicher-Datenbanken, aufgrund der Kombination aus dem Verarbeiten von "heißen Daten" im Hauptspeicher und dem Verwalten der "kalten Daten" auf Sekundärspeicher. Der Vorteil: Der Bedarf an Hauptspeicher ist deutlich geringer und Daten, die nicht oder selten in Analysen benötigt werden, vergeuden keinen teuren RAM. Außerdem können Peaks in der Hauptspeichernutzung problemlos abgefangen werden, ohne den Hauptspeicher erweitern zu müssen. Sollen nun aber Daten vom Sekundärspeicher nachgeladen werden, so minimieren effiziente Lademechanismen und intelligente Algorithmen die Auswirkung auf die Gesamtperformance.

Zusätzlich zu den reinrassigen IMDB-Vertretern bieten die klassischen, bereits erwähnten Anbieter von relationalen Datenbanken, deren Wurzeln im OLTP-Bereich liegen, In-Memory-Add-Ons an. Dies erscheint sinnvoll, denn die Entwicklung hin zu mehr datenbasierten Geschäftsentscheidungen erfordert Lösungen mit hoher Performance – wenn möglich auf der Basis bestehender Infrastruktur. Ein Anbieterwechsel wäre nicht notwendig, zumeist aufwändige Migrationsprojekte ließen sich vermeiden. Das Implementieren der Add-on-Option erfordert aber in fast allen Fällen sehr wohl Hardware-Erweiterungen und es fallen zusätzliche Lizenzkosten an.

Dabei lässt sich mit einem solchen aufsetzenden Feature nur sehr eingeschränkt "echte" In-Memory-Performance erzielen. Zwar wird auch hier der Hauptspeicher genutzt, um die Verarbeitung der Daten zu beschleunigen, jedoch schleppt das System viele Altlasten in Form zahlreicher zusätzlicher Verarbeitungsstufen mit sich herum. Somit lassen sich Performance-Probleme kurzfristig lösen, allerdings dominieren die Einschränkungen im Vergleich zu einer reinen In-Memory-Lösung. Die Datenbanksysteme sind in der Regel auf einen Server beschränkt, das heißt, sie lassen keinen Scale-Out zu, um die Kapazität im Cluster-Betrieb, bestehend aus mehreren Servern, zu steigern. Zusätzlich konkurrieren die In-Memory-Add-Ons mit der eigentlichen disk-basierten Datenbank um Systemressourcen.

Aus der Cloud: Database-as-a-Service

Neben der beschriebenen Entwicklung hin zu wachsender analytischer Realtime-Verarbeitung großer Datenmengen spielen vor allem Sourcing-Optionen eine wichtige Rolle bei der Auswahl von Datenbanksystemen. Public-Cloud-Plattformen lassen sich zum einen nutzen, um die eigene Datenbank-Infrastruktur – welcher Art auch immer – im Outsourcing-Prinzip auszulagern. Dafür sollte die gewählte Datenbank "cloud ready" sein, also mindestens auf den gängigsten Public-Cloud-Infrastrukturen laufen und flexibel über offene APIs mit weiteren Anwendungen integriert werden können. Dies trifft mehr oder minder komfortabel auf die meisten hier erwähnten Datenbanken zu – sowohl klassische relationale, als auch NoSQL- und In-Memory-Datenbanken sind in einer Cloud-Umgebung lauffähig.

Zum anderen bieten viele Cloud-Dienstleister selbst Datenbanken als Service aus der Cloud an. Amazon Web Services (AWS) beispielsweise stellt im Rahmen seiner Relational Database Services (RDS) mehrere transaktionale Datenbanksysteme verschiedener Hersteller zur Wahl. Dimensionierung und Abrechnung erfolgen – wie in der Cloud üblich – nutzungsabhängig. Redshift und Athena sind Services mit Fokus auf analytische Anwendungsfälle.

Hinter Azure SQL Database und SQL Data Warehouse verbergen sich die transaktionalen und analytischen Datenbankservices von Microsoft. Mit Cloud SQL und Cloud BigQuery hat auch Google einen Datenbankservice für diese Anwendungsfälle im Cloud-Angebot. Diese Auflistung ist keinesfalls vollständig, da das Datenbankangebot der Cloud-Provider mittlerweile sehr vielfältig ist. Die Vorteile dieser Angebote sind die, die mit der Cloud als Infrastruktur einhergehen: flexibel und bedarfsgerecht buchbare Infrastruktur, die mit deutlich niedrigeren Anfangsinvestitionen auskommt als die Erweiterung der Systeme im eigenen Rechenzentrum. Bei professionell betriebenen Cloud-Umgebungen ist die Verfügbarkeit im Allgemeinen sehr hoch, Spezialisten kümmern sich um administrative Aufgaben wie Software-Updates und Patch-Management. Trotz dieser unbestrittenen Vorteile der Cloud sollten Unternehmen immer auch prüfen, ob diese in ihrem jeweiligen individuellen Anwendungsfall zum Tragen kommen. Themen, wie die Gefahr des Vendor-Lockin und die Datensicherheit gemäß Datengrundschutzverordnung, spielen darüber hinaus ebenso eine Rolle, insbesondere dann, wenn der Cloud-Dienstleister ein amerikanischer ist.

Unabhängig von den Kosten selbst passt nicht jedes Preismodell zu jedem Unternehmen. So ist eine streng nutzungsbasierte Abrechnung wie etwa bei Google BigQuery zunächst sehr attraktiv, da bei Nichtnutzung keinerlei Kosten anfallen. Allerdings steigen die Kosten bei intensiver Nutzung rasant an und jede Anfrage kostet bares Geld. In Zeiten, in denen Mitarbeiter eher mehr als weniger Daten analysieren sollen, kann dieses Abrechnungsmodell somit falsche Impulse setzen, da Analysen direkt durch steigende Kosten "bestraft" werden.

Bei allen cloud-basierten Lösungen sollten Unternehmen vorab die über die Laufzeit entstehenden Betriebskosten kritisch prüfen. Oft kommen auch hybride Infrastrukturen in Frage: So könnten beispielsweise geschäftskritische, datenintensive Analyse-Anwendungen im eigenen Rechenzentrum mit Anwendungen aus der Cloud integriert sein. Voraussetzung dafür ist allerdings eine Datenstrategie, die die Konsistenz, die Integration und durchgängige Verarbeitungsprozesse sicherstellt. Die Cloud als Ad-hoc-Lösung für plötzliche Ressourcen-Engpässe ist damit passé, auch ihr Einsatz muss planvoll und strategisch durchdacht erfolgen.

Datenbank-Performance als wichtiges Kriterium

Die Zukunft basiert auf der Analyse von Daten – eine besondere Herausforderung für Datenbanken, sind sie doch der zentrale Speicherort der wachsenden Datenmengen. Während sich die reine Größe einer Datenbank diesem Wachstum relativ einfach anpassen lässt, entstehen die Engpässe bei der zeitnahen Verarbeitung der Daten. Klassische relationale Systeme, die aus dem transaktionalen Bereich abstammen (klassische OLTP-Datenbanksysteme), sind den modernen Performance-Ansprüchen immer weniger gewachsen.

Um diese Herausforderungen zu meistern, stellt sich häufig zunächst die Frage, ob eine bestehende Datenbank-Infrastruktur erweitert oder ersetzt werden soll. Damit verbunden ist die Frage des Sourcings: Soll diese Datenbank weiterhin inhouse betrieben oder beispielsweise ein gemanagter Datenbankservice in der Cloud genutzt werden. Die Auswahl an verschiedenen Datenbank-Technologien ist heute vielfältig – neben Multipurpose-Datenbanken mit zahlreichen Add-on- und Plattform-Optionen gibt es viele Systeme, die für ganz spezielle Anforderungen entwickelt wurden. Offenheit und Integrierbarkeit spielen neben der Performance eine besonders wichtige Rolle, um auch künftig flexibel reagieren zu können. Auch verschiedene Kosten- und Abrechnungsmodelle müssen stets frühzeitig bei der Auswahl berücksichtigt und bewertet werden.

Autor

Dr. Jens Graupmann

Dr. Jens Graupmann ist Experte in den Bereichen Business Development, IT und Produktmanagement. Er ist Vice President of Product Management der Exasol AG.
>> Weiterlesen
Das könnte Sie auch interessieren
botMessage_toctoc_comments_9210