© Diego Schtutman/Shutterstock.com, © Tomacco/Shutterstock.com
Ein Wiki mit PHP und der multimodalen Datenbank ArangoDB

Hurtig, hurtig!


Von der Lochkarte bis zur Datenbank in der Cloud und Big Data war es zwar ein weiter Weg. In der Moderne angekommen zählt das Urgestein der Programmiersprachen, PHP, nach wie vor nicht zum alten Eisen und spricht stattdessen angeregt und munter mit nahezu allen Datenbanksystemen. Zum Beispiel könnte schnell, schnell (wiki, wiki) ein kleines Wiki erstellt werden, vielleicht sogar auf Basis einer multimodalen Datenbank.

Zur Erfolgsgeschichte von PHP hat die Verfügbarkeit von Datenbank-Extensions und -Libraries einen wesentlichen Teil beigetragen. Als in den frühen Jahren des Web die ersten Anwendungen wie etwa Foren oder Content-Management-Systeme entstanden, mussten die damit erzeugten und verwalteten Daten gespeichert und wieder abgerufen werden können. PHP stellte somit das Bindeglied zwischen Datenbanksystemen und der Auslieferung der Webseiten durch den Webserver dar. In der ursprünglichen Bedeutung von PHP als serverseitige Skriptsprache wurden Daten aus der Datenbank abgerufen, möglicherweise in einem nächsten Schritt aufbereitet und das Ergebnis dem Webserver und somit dem Browser als fertige HTML-Seite übermittelt. Die dynamische Webseite war geboren – eine speziell für den jeweiligen Nutzer erzeugte Seite, die dessen Daten in irgendeiner Form berücksichtigte.

In dieser Zeit wurde auch der Begriff des LAMP-Stacks geprägt – ein Akronym für das Betriebssystem Linux, den Webserver Apache, das relationale Datenbanksystem MySQL und eben die Programmier- bzw. Skriptsprache PHP. Der LAMP-Stack stellte die Basis für zahlreiche Anwendungen und Webauftritte dar, woran sich bis heute nichts geändert hat. Obwohl auch auf stark frequentierten Angeboten wie etwa der Wikipedia vertreten, wurde die Landschaft der Datenbanken spätestens seit dem Aufkeimen des Web 2.0 und der damit verbundenen Dienste heterogener. Bis dahin wurden im Zusammenspiel mit PHP hauptsächlich relationale Datenbankmanagementsysteme aus dem Open-Source-Bereich wie MySQL oder PostgreSQL genutzt. Die Entwicklung und die wachsende Nutzung von sozialen Netzwerken, Videoportalen, Suchmaschinen, Marktplätzen etc. stellte die Anbieter jedoch vor neue Herausforderungen. Unternehmen wie Google, Facebook Amazon, eBay oder Twitter hatten mit stark steigendem Datenumfang zu kämpfen, daneben bekamen Kriterien wie Verfügbarkeit und Ausfallsicherheit einen höheren Stellenwert als etwa strikte Konsistenz.

Es war einmal …

Amazons CTO Werner Vogels prägte den Ausdruck der „letztendlichen Konsistenz“ (Eventual Consistency) und gab zu verstehen, dass es Anwendungen gibt, die zugunsten einer höheren Lese- und Schreibperformance in Situationen mit vielen gleichzeitigen Zugriffen oder aufgrund der Partitionstoleranz, d. h. der Bewältigung eines Ausfalls eines oder mehrerer Teilsysteme in einem skalierbaren, weltweit verteilten System, mit Inkonsistenzen umgehen müssen [1]. Da die bis dato verfügbaren Lösungen nicht mit den Anforderungen Schritt halten konnten, entwickelten die Unternehmen kurzerhand eigene Konzepte. Daraus entstanden Produkte, die jeweils Lösungen für spezifische Aufgaben darstellen. Teilweise wurden die Ergebnisse als Open Source von den Unternehmen selbst bereitgestellt, andererseits auch von der Community entwickelt. Diese Alternativen zu relationalen Datenbanksystemen fanden auch abseits der Internetriesen weite Verwendung. Um der wachsenden Bedeutung gerecht zu werden, sollte 2009 eine Konferenz für „Open Source, verteilte, nichtrelationale Datenbanken“ stattfinden. Aus einer Diskussion um die Namensfindung entstand NoSQL, was zunächst als Gegenposition zu relationalen Datenbanken interpretiert wurde. Um die Abgrenzung abzuschwächen, erfolgte der Versuch, NoSQL als Akronym für „Not only SQL“ zu etablieren, womit nicht der Ersatz von relationalen Datenbanken, sondern deren Ergänzung in den Vordergrund rückte [2], [3].

Ein Blick in die Geschichte zeigt jedoch, dass bereits vor dem relationalen Modell weitere Datenbankmodelle und -systeme entwickelt wurden. IBM stellte in den 1960er Jahren IMS (Information Management System) vor, das ein hierarchisches Modell abbildet. In den 1970er Jahren wurde UDS (Universelles Datenbanksystem) als Netzwerkdatenbanksystem von Siemens entwickelt. Die Key-Hash-Datenbank DBM von Ken Thompson entstand 1979, in den 1980er Jahren folgte Lotus Notes als dokumentenorientiertes, verteiltes Datenbanksystem. Die 1990er Jahre brachten den LDAP-Standard für Verzeichnisdienste hervor, der auf hierarchischen Strukturen basiert [4].

Der Begriff NoSQL wurde sogar im Jahre 1998 zum ersten Mal verwendet, jedoch nicht in der späteren Bedeutung. Der Entwickler Carlo Strozzi nannte sein relationales Datenbankmanagementsystem NoSQL, da es über keine Implementierung von SQL verfügte, sondern die Kommunikation per Unix-Shellkommandos stattfand, wodurch eine tiefe Integration in das Betriebssystem angestrebt wurde [5].

Datenmodelle

Der Bereich der NoSQL-Datenbanken wird – beinahe mag man die Bezeichnung „klassischerweise“ wählen – kategorisiert in Key-Value Stores (Schlüssel-Wert-Datenbanken), Document Stores/Document Databases (dokumentenbasierte bzw. dokumentenorientierte Datenbanken), Wide Column Stores/Column-Family Stores (spaltenorientierte Datenbanken) und Graph Databases (Graphdatenbanken) [6], [7].

Key-Value Stores implementieren das einfachste Datenmodell. Dabei wird anhand eines Schlüssels (Key) ein Wert (Value) zugewiesen. Alle Datenbankoperationen werden anhand des Keys durchgeführt. Dokumentenorientierte Datenbanken können komplexere Datenstrukturen aufnehmen, dabei bezieht sich der Begriff des Dokuments auf das Format, in dem die Datensätze gespeichert werden. Häufig werden JSON- oder ähnliche Strukturen verwendet, deren Werte auch in Datenbankoperationen berücksichtigt und somit abgefragt werden können. Das Datenmodell der Graphdatenbanken entstammt der Graphentheorie der Mathematik. Graphen bestehen aus Knoten (Vertices) und Kanten (Edges), wobei eine Kante die Beziehung zwischen den Knoten darstellt. Eine einseitige Beziehung wird durch eine gerichtete Kante symbolisiert, eine ungerichtete Kante stellt eine beidseitige Beziehung zwischen den beteiligten Knoten dar. Während in einem einfachen Graphenmodell die Knoten nur aus Objekten eines Typs bestehen und die Kanten nur die Art und Weise der Beziehung in sogenannten Labels oder Properties enthalten, werden im Property-Graph-Modell sowohl Knoten als auch Kanten durch Eigenschaften (Properties) erweitert. Alle Objekte können Attribute in Form von Key-Value-Paaren aufnehmen. Dabei werden Werte gespeichert, die sich auf den Knoten beziehen oder mit denen die in den Kanten spezifizierte Beziehung zwischen den Knoten beschrieben wird. Der Schwerpunkt von Graphdatenbanken liegt auf Anwendungen, die ein effizientes Traversieren (Durchschreiten, Durchlaufen) der vernetzten Informationen voraussetzen, als Stichwörter seien hier kürzeste Wege oder minimale Spannbäume genannt.

Jedes Modell bietet dabei spezifische Eigenschaften, die je nach Anwendung ihre Vorteile ausspielen können. Anstatt nun alle noch so unterschiedlichen Daten in ein Modell zu pressen, etwa sie wie in früheren Jahren in einem RDBMS zu verwalten, wird der Natur der Daten Rechnung getragen. Das führt dazu, dass in einem Anwendungsbereich mehrere verschiedenartige Datenbanksysteme eingesetzt werden können. Martin Fowler nennt diese Art der Datenhaltung Polyglot Persistence, was letztlich bedeutet, dass die Datenbank genutzt wird, die die jeweiligen Anforderungen am besten erfüllt [8]. Beispielsweise finde...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang