Kommentar von Stefano Marmonti, Marklogic Relationale Datenbanken sind ungeeignet

Autor / Redakteur: Stefano Marmonti / Nico Litzel

Laut Forrester Research werden die Ausgaben für Technologie in Europa 2016 um 4,1 Prozent ansteigen, vorwiegend für Applikationen in den Bereichen Big Data und Analytics. Weltweit werden die Investitionen in diese Technologien sogar um 24 Prozent steigen, auf 108 Milliarden US-Dollar. Da Unternehmen immer stärker in die Erfassung und Analyse ihrer Daten mit immer größeren, intelligenteren Anwendungen investieren, sollten sich auch die Anforderungen an die Datenbanken ändern.

Anbieter zum Thema

Der Autor: Stefano Marmonti ist DACH Sales Director bei Marklogic
Der Autor: Stefano Marmonti ist DACH Sales Director bei Marklogic
(Bild: Marklogic)

Die vorherrschende Technologie für die Speicherung und Verwaltung von Daten – die relationale Datenbank – sieht noch immer ziemlich so aus wie zur Zeit ihrer Einführung im Kalten Krieg vor mehr als dreißig Jahren. Damals galten „Daten“ als wenig umfangreich, „sauber“, gut strukturiert und statisch, denn nur in dieser Form konnte man sie speichern.

Heutzutage sehen sich Unternehmen einer Welt mit umfangreichen, schnelllebigen, vielfältigen, volatilen und sich verändernden Daten gegenüber. Sie arbeiten nicht mehr mit einer Handvoll an Systemen, sondern mit Hunderten davon sowie mit Petabytes an Daten.

Mismatch von Daten und Anwendungen

Moderne Anwendungen müssen immer umfassendere Formen verarbeiten und Daten aus verschiedenen Datenquellen integrieren. Sie werden in objektorientierten Programmiersprachen wie Java, JavaScript, Python oder C# entwickelt, um nur einige zu nennen. Diese Sprachen behandeln Datenstrukturen als „Objekte“, die sowohl Daten als auch Code enthalten (das heißt, Attribute und Methoden). Das Problem dabei ist, dass sich diese Art des Umgangs mit Daten grundlegend von der Verarbeitung von Daten durch relationale Datenbanken unterscheidet. Dadurch kommt es zum sogenannten „Impedance Mismatch“, also einer Unverträglichkeit zwischen Datenbank- und Anwendungsprogrammierung.

ORM und seine Nebenwirkungen

Um dieses Problem zu umschiffen, verwenden Software-Entwickler eine Technik, die man als objektrelationale Abbildung, Object Relational Mapping (ORM), bezeichnet. Darunter versteht man eine bidirektionale Active-Active-Verknüpfung zwischen den Objekten der Anwendungsebene und den Daten, wie sie im Schema der relationalen Datenbank abgebildet sind.

Dank ORM können Entwickler mit Regeln und Logiken arbeiten und die aus Anwendungsentwicklungssicht sinnvollsten Ansichten generieren. Bei diesem Ansatz werden Datenbanken einfach als Orte betrachtet, an denen Daten persistent gespeichert und gespeicherte Prozeduren definiert sind. Es steht eine breite Palette an ORM-Tools zur Verfügung, die die Anwendungsentwicklung mit relationalen Datenbanken vereinfachen. Als Beispiele für solche ORM-Tools wären etwa Hibernate für Java, ActiveRecord für Ruby on Rails, Doctrine für PHP und SQLAlchemy für Python zu nennen.

Statt die interessanten Aspekte der Daten eines Objekts zu bewahren, extrahiert ORM die Daten und reißt sie auseinander, wodurch der Verwaltungsaufwand wächst. Dies geschieht zudem, nachdem die Daten im Zuge der Normalisierung schon einmal auf verschiedene Tabellen aufgeteilt wurden. Nehmen wir das Beispiel einer Krankenakte: Denken Sie daran, wie viele verschiedene Daten Teil dieser Akte sind und in einer relationalen Datenbank auf verschiedene Tabellen aufgeteilt werden müssen. Nach dem „Auseinanderreißen“ der Daten und deren Verteilung auf die Tabellen müssen sie dann auf der Anwendungsebene für den Benutzer wieder zusammengefügt oder aggregiert werden. Das bedeutet viel unnötigen Aufwand, viele Verknüpfungen und entweder ein eigenes Framework oder viele Abfragen über mehrere Tabellen (JOIN-Abfragen). Nur so erhält der Benutzer eine tatsächliche Ansicht des eigentlichen Formulars oder Dokuments.

Schwächen des relationalen Modells

Das Ergebnis der herkömmlichen relationalen Architektur sind somit Leistungseinbußen und potenzielle Fehler im Code. Angesichts der schnelllebigen Anwendungsentwicklungszyklen von heute und des Wunsches der Benutzer nach mehr Interaktivität und schnelleren Reaktionen zeigt das relationale Modell seine Schwächen. Statt nach Notlösungen für das unverträgliche relationale Modell zu suchen, gehen die Entwickler zu neuen Modellen mit einem geringeren Abstraktionsgrad und besserer Leistung über.

Die richtige Datenbank für die Entwicklung moderner Anwendungen

Heutzutage können Unternehmen nicht mehr alleine auf das uniforme und unflexible relationale Modell bauen. Aufgrund der heterogenen Daten benötigen sie eine flexible Datenbank, die sowohl strukturierte als auch unstrukturierte Daten verarbeiten kann. Eine NoSQL-Datenbank (NoSQL steht für „Not only SQL“ – „nicht nur SQL“) nimmt bei der Ablösung der unflexiblen relationalen Datenbanken der vergangenen drei Jahrzehnte eine Vorreiterrolle ein. Viele Merkmale von NoSQL-Datenbanken machen diese zur idealen Wahl für moderne Daten:

  • Flexibilität zur Speicherung der vielfältigen, unterschiedlich gearteten und sich verändernden Daten von heute,
  • integrierte Such- und Abfragefunktionen, mit denen sich Daten zu jedem beliebigen Zeitpunkt besser verwerten lassen,
  • Skalierbarkeit und Elastizität, um mit massiven, sich verändernden Datenmengen zurechtzukommen sowie
  • Enterprise-Funktionen zur Unterstützung unternehmenskritischer Anwendungen.

Wenn immer mehr Unternehmen zunehmend in Big Data investieren und nach und nach immer mehr Informationen aus ihren Daten gewinnen wollen, werden Datenbankverantwortliche schnell feststellen, dass das veraltete relationale Datenbankmodell die Anforderungen nicht mehr erfüllt. NoSQL ist aus den oben genannten Gründen eine echte Alternative, die Unternehmen ermöglicht, alle Daten schnell in Informationen umzuwandeln.

(ID:43903316)