NoSQL-Datenbanken. Einführung, Überblick und Einschätzung (Entwurf/Version 03/2022)

©2021, 2022 Josef L. Staud

Autor: Josef L. Staud

Stand: März 2022, Korrekturen Mai 2024

Umfang des gedruckten Textes: 53 Seiten

Dieser Text richtet sich an die Teilnehmer meiner Seminare.
Geplanter Erscheinungstermin: 2025

Aufbereitung für's Web

Diese HTML-Seiten wurden mithilfe eines von mir erstellten Programms erzeugt: WebGenerator2 (Version 2021). Es setzt Texte in HTML-Seiten um und ist noch in der Entwicklung. Die „maschinelle“ Erstellung erlaubt es, nach jeder Änderung des Textes diesen unmittelbar neu in HTML-Seiten umzusetzen. Da es nicht möglich ist, nach jeder Neuerstellung alle Seiten zu prüfen, ist es durchaus möglich, dass irgendwo auf einer „abgelegenen“ Seite Fehler auftreten. Ich bitte dafür um Verzeihung und um Hinweise (hs@staud.info).

Die Veröffentlichung im Web erfolgt ab 2022 in zwei Versionen: Mit und ohne Frame-Technologien. Zu meinem Bedauern wird die Frame-Technologie inzwischen von den Verantwortlichen als unerwünscht angesehen und es häufen sich die Hinweise, dass bestimmte Browser Frame-basierte Seiten nicht mehr korrekt interpretieren können. Deshalb habe ich eine zweite Version meines Programms WebGenerator erstellt, die ohne Frames realisiert ist. Sie ist derzeit (März 2022) in der ersten Version fertig, aber noch nicht perfekt. Das sollte sie aber im Laufe des Jahres 2022 werden.

Frames?

Urheberrecht

Dieser Text ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Textes oder von Teilen dieses Textes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.

Warenzeichen und Markenschutz

Alle in diesem Text genannten Gebrauchsnamen, Handelsnamen, Marken, Produktnamen, usw. unterliegen warenzeichen-, marken- oder patentrechtlichem Schutz bzw. sind Warenzeichen oder eingetragene Warenzeichen der jeweiligen Inhaber. Die Wiedergabe solcher Namen und Bezeichnungen in diesem Text berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Gesetzgebung zu Warenzeichen und Markenschutz als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

Prof. Dr. Josef L. Staud

 

Inhaltsverzeichnis der Text-Version

1 Neue Anforderungen, neue Datenbanken. 6

1.1 Neue Datenbanktechnologien. 6

1.2 BigData. 7

1.2.1 Parallelwelten. 7

1.2.2 Ursache 1: Immer mehr Daten in den Rechnernetzen. 8

1.2.3 Ursache 2: Internet der Dinge und Industrie 4.0. 10

1.2.4 Immenser Speicherbedarf und Vielfalt 12

2 Einführung und Grundlagen. 13

2.1 Vorläufer. 13

2.2 NoSQL-Datenbanken. 14

2.3 NoSQL-Kernsysteme. 17

2.4 Grundlagen. 19

2.4.1 ACID vs. BASE.. 19

2.4.2 Volume, Velocity, Variety. 22

2.4.3 Skalierbarkeit 23

2.4.4 Parallelisierung mit Hilfe des MapReduce-Frameworks. 25

2.4.5 Schemafreiheit und -flexibilität 27

3 Systemtypen. 33

3.1 Key/Value - Datenbanken. 33

3.2 Graphendatenbanken. 36

3.3 Dokumentendatenbanken. 38

3.4 Spaltenorientierte Datenbanken. 44

4 Literatur 48

 

Abkürzungsverzeichnis


ANSI

American National Standards Institution

DBMS

Datenbankmanagementsystem

DBS

Datenbanksystem

DML

Data Manipulation Language

DV

Datenverarbeitung

ERM

Entity Relationship - Modell

ERP

Enterprise Ressource Planning. Eingeführte Bezeichnung für integrierte prozessorientierte Standardsoftware.

fA

funktionale Abhängigkeit

FA-Diagramm

Diagramm der funktionalen Abhängigkeiten

IRS

Information Retrieval System

IT

Informationstechnologie. Heute benutzt als Bezeichnung für die Abteilung, in der die Computer der Organisation betrieben werden.

OODBS

Objektorientiertes Datenbanksystem

OODM

Objektorientierte Datenmodellierung

PC

Personal Computer

RDBS

Relationales Datenbanksystem

SPARC

Standards Planning and Requirements Committee

SQL

Structured Query Language

vs.

versus (im Vergleich zu, im Gegensatz zu)


 

1 Neue Anforderungen, neue Datenbanken

1.1 Neue Datenbanktechnologien

Eigentlich war man mit den relationalen Datenbanken und Datenbanksystemen gut bedient, doch in den letzten 20 Jahren hat sich die Situation grundlegend gewandelt. Im Kern geht es dabei darum, dass unstrukturiert genannte Information auch Gegenstand von digitaler Erfassung, Speicherung, Verwaltung und Verarbeitung wurde.

Dies betraf zuerst Texte, nicht als Attributsausprägung, sondern als Langtext, dann Dokumente (sozusagen strukturierte Texte), Graphen und Netzwerke (motiviert durch die Beziehungsdaten des Internet), Audio- und Video-Daten und einige mehr.

Diese Informationen konnten nicht sinnvoll mit relationalen Datenbanken verwaltet werden. Die erste Herausforderung bestand also darin, datenverwaltende Systeme für diese Informationsarten zu finden. Das geschah im Übrigen schon in den 1990er-Jahren bei den Anbietern von sog. Online-Datenbanken (in Deutschland bei den Fachinformationszentren), nur damals noch nicht Internet-basiert und auf der Basis proprietär programmierter Lösungen.

Dieses Beschreibungsmerkmal ist also nur wichtig, weil es unterschiedliche Datenbankarchitekturen erzwingt.

Die zweite Herausforderung stellten die großen Datenmengen dar. Selbst wenn es mal gelang, einige dieser "neuen" Daten in eine relationale Datenbank zu packen, erwiesen sich die Antwortzeiten der relationalen Datenbanksysteme als zu langsam. Diese Herausforderung verlangte also nach "mehr und schnellerer Hardware" (vertikale Skalierung durch immer stärkere Server, leistungsfähigere Prozessoren).

Vertikale Skalierung

Die dritte Herausforderung bestand darin, dass diese Daten teilweise nicht nur "im Internet" entstehen, sondern dort auch verwaltet werden müssen (horizontale Skalierung).

Horizontale Skalierung

Es entstand also Leidensdruck, der zu verschiedenen neuen Angeboten führte:

Leidensadruck

  • Neue Speichertechniken (spaltenorientierte Datenbanken, vgl. Abschnitt 4.3)
  • Neue Datenstrukturen, die einfacher zu verwalten sind (Key/Value-Daten, vgl. Abschnitt 3.1)
  • Neue Hardware-Lösungen („InMemory“, vgl. für eine Kurzdarstellung [Staud 2015, Abschnitt 24.11])
  • Neue Art der Datenhaltung (in Netzwerken, horizontal skaliert, NoSQL-Datenbanken)
  • Neue Auswertungsmöglichkeiten

Sehr schnell wurde erkannt, dass diese Informationsarten und die mit ihnen möglichen Auswertungen im Rahmen des Informationsmanagements der Organisationen genutzt werden müssen, so dass sich neue Aufgaben für die Verwaltung der Daten ergaben.

Leidensdruck

Wie auch im sonstigen Leben bewegen sich in der Informatik und Wirtschaftsinformatik die Dinge meist nur, wenn Leidensdruck entsteht. Wenn also Probleme mit den herkömmlichen Mitteln nicht, nicht mehr oder nur mit sehr hohem Aufwand gelöst werden können.

Hier war es so, dass „das Internet“ zu einem Medium geworden war, das intensiv und immer mehr für geschäftliche Transaktionen genutzt wurde. Dies erforderte die Verwaltung der dabei anfallenden Daten.

Dafür wiederum erwiesen sich die damals dominanten Datenbanktechniken (relationale Datenbanken) als nicht tauglich, v.a. als die Datenmenge immer größer wurde. So wurden neue Datenbanktechniken („für das Internet“) entwickelt, zuerst bei Google und den anderen großen im Internet tätigen Untenehmen, dann darüberhinaus.

So weit so gut, die dabei entstehenden NoSQL-Systeme sind da und bewähren sich.

Überraschend ist, dass der Leidensdruck gar nicht so groß hätte sein müssen, wäre da nicht ein blinder Fleck in der Wahrnehmung des Datenbankgeschehens durch die Informatik. Diese hat einen wichtigen Bereich das Datenbankgeschehens, in dem es schon seit den 1960er Jahren um unstrukturierte Information aller Art ging, schlicht übersehen. Dieser Bereich (vgl. für eine kurze Anmerkung Abschnitt 2.1, eine umfangreichere Darstellung ist in Vorbereitung) kennt für so gut wie alle Arten „unstrukturierter Informationen“ Datenbank­lösungen, die auch nicht in den Softwarelaboren hängen blieben, sondern jeden Tag im Einsatz sind.

1.2 BigData

Seit einigen Jahren wird der Begriff Big Data genutzt, um die großen Datenmengen, die mittlerweile in der digitalisierten Welt entstehen, zu kennzeichnen. Dabei geht es inzwischen nicht mehr um MegaByte (MB) oder Gigabyte (GB), sondern um Tera-, Peta- und Zetabyte. Der Grund für das Entstehen dieser Datenmengen ist, dass sie in digitalen Systemen entstehen und daher leicht erfasst werden können und dass die digitalen Systeme aller Art intensiv genutzt werden.

1.2.1 Parallelwelten

Eine Quelle ist das Internet, das für viele Menschen nicht nur ein Hilfsmittel für Kommunikation und Informationsspeicherung geworden ist, sondern mit seinen Möglichkeiten

  • dort die geschäftlichen Aktivitäten zu tätigen,
  • die sozialen Beziehungen in Clique, Kohorte (vgl. unten) und vielleicht auch Familie zu pflegen,
  • dort kriminelle Aktivitäten zu entwickeln,
  • als Plattform für die Selbstdarstellung zu dienen,
  • Kommunikation unterschiedlichster Art zu ermöglichen (Mail, Telefonie, SMS, ...),
  • von dort - aus der Cloud - Rechenleistung zu beziehen,

den Charakter einer Parallelweltzur realen angenommen hat. Dafür spricht auch, dass sich dort, genauso wie in der wirklichen Welt, nicht nur eine Rotlichtszene, sondern auch sehr aktive kriminelle und terroristische Milieus gebildet haben und - so sagen einige Prognosen - dort in der Zukunft auch Kriege geführt werden (cyber war).

Kohorte: Die, mit denen man zusammen das Leben verbringt und die nicht unbedingt zum Freundeskreis gehören. Je nach Alter z.B. die Schulklasse, die anderen Beschäftigten am Arbeitsplatz, die Menschen, mit denen man im Rahmen seiner Freizeitaktivitäten zu tun hat, usw.

Clique: Freundeskreis. Die, deren Urteil einem wichtig ist.

Diese Parallelweltberuht auf Rechnernetzen mit großen Serverrechenzentren, PCs (und Smartphones) der Nutzer und dem leistungsstarken weltumfassenden Telekommunikationsnetz. Sie ist so erfolgreich, dass ihm schon die Adressen ausgingen und deshalb neue längere Adressen eingerichtet werden mussten. Das "alte" IPv4 hatte einen Adressraum von 232 (etwas über vier Milliarden) IP-Adressen, das neue IPv6 erlaubt 2128 (rund 340 Sextillionen) Adressen. Dies sollte erst mal reichen.

Grundlage 1: Rechnernetze

Sie beruht aber auch auf sehr leistungsstarken Speichermedien, die inzwischen bei erschwinglichen Preisen Terabyte von Daten der unterschiedlichsten Art verwalten können. Diese Speicherkapazität kann über verteilte Netzwerkarchitekturen beliebig und flexibel ausgebaut werden.

Grundlage 2: Datenbanken

Der Bedarf an Datenübertragungskapazitäten, an Rechner- und Speicherkapazität im Internet (das heutzutage den wesentlichen Teil des globalen Computernetzwerks beansprucht), wird noch weiter wachsen. Die zwei wichtigsten Ursachen hierfür sollen aufgezeigt werden.

Immer mehr Daten in den Rechnernetzen

1.2.2 Ursache 1: Immer mehr Daten in den Rechnernetzen

Das weltweite Rechnernetz ist tatsächlich eine Parallelwelt geworden, in der inzwischen nicht nur die Wirtschaft wichtige Anteile ihrer Aktivitäten abwickelt. Um nur die wichtigsten zu nennen:

  • Kommunikation über das Internet und Verwaltung der dabei entstehenden Daten in großen Datenbanken.
  • Nutzung von Service-Rechenzentren, die irgendwo "im Internet" angesiedelt sind (oft Cloud genannt). Dies können Entwicklungsumgebungen sein, einfache Anwendungen (Mail-Server, Finanzbuchhaltung, usw.) oder eine ganze ERP-Software. Dabei wird Geschäftstätigkeit ins Internet verlagert und damit in eine vernetzte Umgebung. Wenn ein Unternehmen seine Geschäftsprozesse mit einer Software in der Cloud abwickelt, werden die Handlungen dieses Unternehmens durch Netzstrukturen realisiert. Z.B. liegen die Kundendaten dann "in der Cloud", die Rechnung wird dort erstellt, evtl. durch einen sog. WebService in ein PDF-Dokument überführt und vom selben Web-Dienstleister versandt.

ERP-Software: Enterprise Ressource Planning. Damit wird eine prozessorientierte integrierte Standardsoftware bezeichnet. Produkte dieser Art beruhen auf einem umfassenden (oft unternehmensweiten) Datenmodell.

WebService: Einfach ausgedrückt ein Programm, das per Internet angeboten wird und das ein Unternehmen in seine Geschäftsprozesse einbauen kann.

Alles das schafft bereits Bedarf an zuverlässiger und robuster Netzkapazität und an leistungsstarken Speichermedien. Doch was ist das gegenüber dem, was wir Menschen in unserem privaten Leben, das viele ja auch ins Internet verlagert haben, an Bedarf erzeugen? Auch hier nur die wichtigsten diesbezüglichen Aktivitäten:

  • Repräsentationen von uns im Netz (oft Profilegenannt) pflegen, die von uns selbst oder von anderen erstellt wurden. Es geht darum, uns im Social Web zu präsentieren, uns darzustellen, mit Informationen aller Art.
  • Beziehungen pflegen im Social Web, z.B. unter dem Gesichtspunkt "Wer teilt mit wem welche Vorlieben?" Dies sind netzwerkartig strukturierte Informationen, die eine besondere Herausforderung an Speicherung und Verarbeitung stellen. Sie haben die Tendenz immer weiter zu wachsen, weil schon die Plattformbetreiber sie erfassen und auswerten und andere Unternehmen dies inzwischen auch tun.
  • Bilder auf entsprechende Plattformen laden.
  • Videosequenzen hoch- oder runterladen.
  • im sonstigen SocialWeb des Internet.
  • Ständiges automatisiertes Daten sichern "in die Cloud".
  • SMS - Nachrichten versenden.
  • Kommunikation per Mail.
  • Kommunikation mit Gruppen, z.B. durch Twitter.
  • Spielen im Internet, auch in weltweit organisierten Gruppen.
  • Telefonieren über das Internet. Die vollständige Umstellung auf IP-Telefoniewird gerade umgesetzt.
  • Radio hören über das Internet.
  • Fernsehen über das Internet.
  • Einkaufen auf der Basis von Geschäftsprozessen, die in Software "gegossen" wurden.
  • Log-Dateien erfassen und auswerten. Hinweise hierzu finden sich in [Wartala 2012].
  • Daten zum Kaufverhalten auf Shopping-Seiten im Internet und ihr in Beziehung stzen mit vielen Millionen Werbemittelsichtkontakten von Online-Werbung [Wartala 2012, S. 9].
  • Daten aus Suchmaschinen zum Suchverhalten der Nutzer.
  • Überwachung von Logistikvorgängen durch Logistikunternehmen.
  • im Kundenbeziehungsmanagement (CRM) - ganz allgemein und v.a. auch bei Internetunternehmen.

Vgl. auch die Ausführungen in [Wartala 2012, S. 15ff].

Bei den meisten dieser Aktivitäten entstehen Daten, die dauerhaft gespeichert werden.

1.2.3 Ursache 2: Internet der Dinge und Industrie 4.0

Lange Zeit blieb der Einsatz von PCs, Workstations und der größeren Systeme auf den Arbeitsplatz in der Firma oder zu Hause beschränkt. Durch die Kombination von Computertechnik mit modernen Kommunikationseinrichtungen eröffnen sich jedoch viele weitere Einsatzgebiete. Zum Beispiel beim Mobiltelefon (engl. mobile phone) oder Handy. Es wurde vom mobilen Telefon zum universellen Kommunikationsendgerät, den Smartphones, weiterentwickelt. Dies wurde ermöglicht durch die Einführung leistungsstarker Übertragungsstandards, v.a. UMTS (Universal Mobile Telecommunications System; bis zu 42 MBit/Sekunde) und LTE (Long Term Evolution) (ab 2010, ernsthaft dann 2012; bis zu 300 MBit/Sekunde). Diese Smartphones erlauben einen leistungsstarken Internet-Zugang. Und die Entwicklung geht ständig weiter.

Die Gerätevielfalt nimmt fast täglich zu und reicht bis zu am Körper tragbaren Rechnern (wearable computer), etwa in Form von Armbanduhren, Brillen oder eingenäht in "intelligente" Kleidung. Die Einsatzbereiche sind vielfältig: Sie lassen beide Hände zum Arbeiten frei, können als mobiles Navigationssystem oder als Überwachungseinheiten für Körperparameter (z.B. Blutdruck, Temperatur usw.) dienen. Will man den Kommunikationsaspekt betonen, spricht man in diesem Zusammenhang auch vom Internet der Dinge.

Internet der Dinge

Die technische Realisierung erfolgt so, dass winzige Computer mit Sensoren und Kommunikationsfähigkeit (z.B. RFID, Radio Frequency Identification) ausgestattet werden. Diese können dann programmiert und den (realen) Dingen unseres Daseins zugefügt werden: Bekleidung, Haushaltsgeräte, Gebäudeteile, ... Da sie sehr klein sein können, ist dies auch möglich. Die "Dinge" werden also z.B. mit einem RFID-Etikett versehen. Das ist ein winziger Computerchip, der mit einer Miniaturantenne versehen ist. Auf dem Chip lassen sich viele Informationen speichern. Z.B. ein elektronischer Produktcode (EPC, Electronic Product Code), mit dem es möglich ist, jedes weltweit hergestellte Produkt eindeutig zu identifizieren. Ebenso eventuelle Liefer-, Bestands- und weitere Informationen zum Produkt (z.B. das Verfallsdatum) . Der RFID-Chip kann entlang der Transportkette an jeder Station von RFID-Lesegeräten mittels Funksignalen gelesen und ausgewertet werden. Typischerweise werden die Daten an ein System vernetzter Computer gesandt, die dann die gewünschten Aktivitäten veranlassen (z.B. die Steuerung der Produktion oder der Lieferkette oder Inventarkontrolle von Lagern).

Technische Realisierung

Auch (größere) Tiere erhalten heute oftmals solch ein Gerät implementiert, was u.a. ermöglicht, dass die Fütterung der Tiere individuell gestaltet werden kann, weil der ebenfalls in das Gesamtsystem integrierte Fütterungsautomat erkennt, welches Tier gerade herangekommen ist und - auf der Basis weiterer gemessener Werte - die Fütterung steuert. Auch hierfür werden Daten gespeichert und verwaltet.

Es geht also um alle Gegenstände unseres täglichen Lebens. Diese sollen mit Geräten ausgestattet werden, die Informationen verarbeiten und versenden können und die auch interaktionsfähig sind. Daher rühren die oftmals in der Presse lancierten Beispiele von der Waschmaschine, die warnt, wenn man einen Pullover mit zu hoher Temperatur waschen möchte. Oder vom Kühlschrank, der selbsttätig den Einkaufszettel erstellt oder die benötigten Waren gleich selbst bestellt. Diese alles führt zu noch mehr Adressbedarf (IPv6 sollte aber reichen, siehe oben), zu noch mehr Kommunikation und zu noch viel mehr Information und Informationsverarbeitung.

Diese Technologie, die auf den schon älteren eingebetteten Systemen aller Art basiert, eignet sich natürlich auch hervorragend dazu, Geräte im Haus, Auto oder Büro zu steuern oder zu überwachen. So öffnen oder schließen sie beispielsweise Fenster oder Jalousien und regeln die Heizung abhängig von der Tageszeit, vom Wetter oder vom Einfallswinkel der Sonne. Damit ist eine Kostensenkung bei Heizungs- oder Kühlungssystemen möglich. Die integrierten Haussysteme sollen möglichst alle elektrischen Geräte verknüpfen. Angefangen vom Aufzug bis zur Stereoanlage, die sich beim Betreten des Hauses einschaltet und jeweils unterschiedliche Musik auswählt, je nach Tageszeit und je nachdem, wer das Haus betritt. Diesen Trend zur Durchdringung der (Internet-basierten) Computer- und Kommunikationstechnologie in nahezu alle Lebensbereiche fasst man unter den Begriffen Ubiquitous oder Pervasive Computing zusammen (ubiquitous = allgegenwärtig, überall zu finden).

Haussysteme

Dieses sog. Internet der Dinge wird die "Vermaschung" der Computernetze deutlich erhöhen. Es entsteht damit unterhalb der globalen, nationalen und regionalen Ebene eine Vernetzung, die im lokalen Umfeld stattfindet.

"Lokale Vernetzung"

Im Bereich der Industrie, vor allem der Produktionssteuerung und der Logistik, wird das Internet der Dinge zu Industrie 4.0. Auch hier werden "Dinge" (Bauteile, Produkte, Maschinen, Anlagen) mit kommunikationsfähigen "intelligenten" Systemen ausgestattet, mit denen sie kommunizieren, Umweltbedingungen aufnehmen und innerhalb der gesetzten Grenzen handeln können.

Industrie 4.0

Die Zahl 4 rührt von der Einteilung der Industriegeschichte in industrielle Revolutionen her. Die Erste: Einführung mechanischer Produktionsanlagen mit Wasser- und Dampfkraft (Ende 18. bis Beginn 20. Jahrhundert); Die Zweite: arbeitsteilige Massenproduktion mithilfe elektrischer Energie (bis in die 1970-er Jahre); Die Dritte: Einsatz von Elektronik und IT zur weiteren Automatisierung der Produktion (bis heute). Vgl. [Lange 2013, S. 110].

Gedacht ist hier an Produktion und Logistik, die in Echtzeit über das Internet vernetzt werden sollen und zwar über die gesamte Wertschöpfungskette hinweg, nach Möglichkeit sogar unternehmensübergreifend. Weil die Vernetzung über das Internet erfolgen soll und weil auch Software zur Steuerung der Kontrollflüsse nötig ist, spricht man hier auch von Cloud-Lösungen, denn natürlich ist die steuernde Software am besten in den Rechenzentren der Cloud aufgehoben.

Im Kern geht es also um die

"... Verbindung der realen Industrie-Abläufe mit den sie steuernden virtuellen Softwaresystemen in Echtzeit und ohne kostentreibende Medienbrüche" [Anmerkung]

Eine der Basistechnologien von Industrie 4.0 ist das oben vorgestellte RFID. Indus­trie 4.0 bringt also eine weitere intensive Vernetzung mit sich, jetzt zwischen den physikalischen Objekten unserer Welt. Hinweise auf damit verbundene Risiken und offene Fragen finden sich in [Lange 2013].

Der erwartete Nutzen ist groß, denn schließlich soll eine weitere Automatisierung mit "intelligenten" Elementen erreicht werden. Dies könnte Einsparungen in der Produktion, Logistik und Lagerhaltung ermöglichen, da z.B. die Teile miteinander und mit steuernden Elementen kommunizieren könnten. Ein möglicher Vorteil könnte auch sein, niedrige Losgrößen leichter zu angemessenen Kosten herstellen zu können. Dies käme dem Trend zu immer mehr individualisierten Produkten entgegen.

1.2.4 Immenser Speicherbedarf und Vielfalt

Alle diese Aktivitäten führen zu einem immensen Speicherbedarf, denn für die meisten dieser Aktivitäten gilt: Was wären sie ohne abgespeicherte Daten? Vor allem diese können ausgewertet werden. Neben der Größe der Datenmengen ist ein zweiter Punkt wichtig, will man die jüngste Entwicklung im Datenbankbereich verstehen, die große Vielfalt der "neuen" Daten:

  • Netzwerkdaten aus dem Social Web und anderen Bereichen des Internet. Hier erfassen die Daten die Kontaktaufnahmen zwischen Teilnehmern am Netz. Daten dieses Typs werden am besten als Graphen verarbeitet.
  • Faktendaten aus dem Social Web. Die hier entstehenden Informationen beruhen auf Dokumenten.
  • Andere sog. unstrukturierte Daten.

In den folgenden Kapiteln betrachten wir nun, welche Techniken, Methoden und Systeme dafür heute zur Verfügung stehen.

2 Einführung und Grundlagen

2.1 Vorläufer

Der Begriff NoSQL-Datenbanken dient in der Literatur zum einen zur Abgrenzung von relationalen Datenbanken. Damit sind Datenbanken gemeint, die nicht relational sind, die also nicht auf Relationen („Tabellen“) mit ihren Attributen aufbauen (vgl. [Staud 2021]). Sie werden oft unstrukturiert genannt.

Unstrukturiert

Meist wird der Begriff dann aber präzisiert auf Datenbanken in der "Web-2.0-Welt". Dabei wird auf die sozialen Netzwerke wie Facebook, Twitter, usw. verwiesen, in denen sehr große Datenmengen entstehen und verarbeitet werden sollen.

Wie so vieles in der Entwicklung der Anwendungssysteme entstanden auch die NoSQL-Datenbanken aus einem Leidensdruck heraus: Die relationalen Datenbanksysteme sind für die in Relationen (Tabellen) fassbare attributbasierte Information, wie sie in [Staud 2021, Kap. 4 – 13] beschrieben wird, sehr gut geeignet, nicht aber für andere Arten von Information, wie einfache Fakteninformation (z.B. Dokumente), textliche Information, Beziehungsdaten, chemische Strukturformeln, Bildinformation, Zeitreihen und viele andere.

Not only SQL

Deshalb entstanden schon in den 1960er-Jahren, lange bevor der Begriff NoSQL-Datenbanken aufkam, alternative datenverwaltende Systeme für „unstrukturierte Daten“. Die wichtigsten sind:

Frühe Anstrengungen

  • volltextverarbeitende Systeme mit invertierten Listen (Information Retrieval Systeme genannt). Die Suchmaschinentechnologie beruht im Kern auf deren Technologie.
  • Faktendatenbanken mit einfachen Fakten zu Unternehmen, Personen usw. Fakten können dabei schlicht als Attribute mit ihren Ausprägungen gesehen werden.
  • Dokumentationssysteme mit attribut- und textbasierter Information
  • Chemiedatenbanken mit ihren Systemen zur Verwaltung von chemischen Strukturformeln (genauer: deren Repräsentation im Rechner)

Daneben gab es aber noch viele andere. Vgl. für einen Ein- und Überblick:

  • [Staud 1985] (zu Statistischen Datenbanken: Zeitreihen und Merkmalsräumen)
  • [Staud 1986a, b] (zu Online-Datenbanken aller Art; "Online-Datenbanken" wurden damals, die über das Internet erreichbaren Datenbanken genannt)
  • [Staud 1986c] (zu Wirtschaftsdatenbanken)
  • [Staud 1987a] (zu "Factual-Type Online Databases for Humanities and Social Sciences")
  • [Staud 1987b] (zu "Factual-Type Online-Databases - Statistical Data")
  • [Staud 1987c, d] (Online Wirtschaftsdatenbanken 1987 - Verzeichnis)
  • [Staud 1987e] (Wirtschaftsdatenbanken - Typen und Themen)
  • [Staud 1989] (zu Fakteninformation in Öffentlichen Datenbanken)
  • [Staud 1991a] (zu Online Datenbanken. Aufbau, Struktur, Abfragen)
  • [Staud 1991b] (zu Statistischen Datenbanken - Anbieter und Produzenten)
  • [Staud 1993] (Fachinformation Online - Überblick Online-Datenbanken)

Mehr Literatur findet sich in http://www.staud.info/literatur/li_f_1.htm.

Zur Abgrenzung von den heutigen NoSQL-Datenbanken sollen diese „frühe Datenbanken für unstrukturierte Informationen“ genannt werden (kurz: frühe unstrukturierte Datenbanken).

„Frühe unstrukturierte Datenbanken“

Dies waren und sind Datenbanken mit sorgfältig zusammengestellten Informationen zu bestimmten Fachgebieten. Sie werden von darauf spezialisierten Organisationen sorgfältig gepflegt und gegen Bezahlung zur Abfrage und Auswertung angeboten. Wichtige Organisationen sind hier das FIZ Karlsruhe und STN International.

Vgl. für Übersichten

https://www.fiz-karlsruhe.de/de/ produkte-und-dienstleistungen/produkte-dienstleistungen

und

http://stn-international.de/sites/default/files/STN/brochures/stnfile-kat.pdf

Die Vielfalt ist hier sehr groß. Die wichtigsten Datenbanktypen sind:

  • Dokumentendatenbanken (auch Faktendatenbanken) zur Verwaltung beliebiger Dokumente.
  • Bibliographische Datenbanken . zur Verwaltung bibliographischer Information.
  • Volltextdatenbanken zur Verwaltung von Texten, die über die Ausprägungen von Eigenschaften hinausgehen.
  • Patentdatenbanken, in denen Patzentschriften mit all ihren Informationsarten (Fakten, Kurztexte, Langtexte, technische Zeichnungen) verwaltet werden.
  • Statistische Datenbanken mit Zeitreihen
  • Statistische Datenbanken mit Merkmalsräumen
  • Datenbanken zu Naturwissenschaften
  • Datenbanken mit chemischen Informationen

2.2 NoSQL-Datenbanken

NoSQL-Datenbanken, die ja eigentlich nicht-relationale Datenbanken sind, werden ebenfalls als Datenbanken gesehen, die unstrukturierte Informationen verwalten. Hinzugekommen sind gegenüber den frühen Systemen für unstrukturierten Datenbanken die sehr viel größeren Datenmengen (BigData, vgl. Abschnitt 1.2) und der „Heimatort Internet“. Letzteres bedeutet, dass sie als verteilte Datenbanken auf Servern des Internet betrieben werden.

Wegen dieser Heimatwelt ist die Thematik NoSQL-Datenbanken eng verknüpft mit der von verteilten Systemen und verteilten Datenbanken:

Datenbanken auf verteilten Systemen

„Large scale distributed file systems such as Google File System and parallel processing paradigm/environments such as MapReduce have been the foundation of a new ecosystem with data management contributions in major database conferences and journals.” [Pivert (Hrsg.) 2018, xiv]

Auch der Grund wird gleich ausformuliert:

„The sheer size of the data sets requires some form of distribution (at least at the architecture if not at the logical level), preventing it from being stored close to the end user [Ngyen Pivert (Hrsg.) 2018, S. 2]

Bedeutung hat dies v.a., weil diese Architektur (große Datenmengen/verteilt) bis in die Datenstrukturen wirkt. Ein Grund (von mehreren) für die Entwicklung wichtiger Datenstrukturen für NoSQL-Datenbanken war, dass in Datenbanken auf verteilten Systemen im Internet relationale Datenstrukturen nicht tauglich sind. Vgl. Kapitel 3.

Wie auch bei den frühen datenverwaltenden Systemen für unstrukturierte Daten ist auch bei NoSQL-Datenbanken die Vielfalt sehr groß. In Abschnitt 2.4 findet sich eine Aufzählung wichtiger Typen von NoSQL-Systemen.

In der einschlägigen Literatur zu diesem Thema werden oft die Begriffe Datenbanksystem und Datenbank nicht klar getrennt. Dies macht die Lektüre - v.a. für Einsteiger in das Thema - nicht einfacher. Trotzdem bleibt es dabei: Datenbanksysteme sind die entsprechenden Softwareprodukte (Anwendungssysteme) zur Verwaltung von Datenbeständen, Datenbanken die Datenbestände.

Definition

Es gibt kein umfassendes formales Modell für NoSQL-Datenbanken, aber es gibt die Forderung ein solches zu erarbeiten. Olivier Pivert formulierte im Jahr 2018 folgende Einschätzung:

„First and foremost, in our sense, a formal model of NoSQL databases and queries is yet to be defined. The model should play the same role that relational algebra played as a foundation for SQL.” …”First, it must allow us to model data as it exists in current – and future – NoSQL systems, from the simple key-values store, to the more complex document store, while at the same time retaining compatibility with the relationaol model.” [Pivert (Hrsg.) 2018, S. 6]

Dies ist allerdings eine anspruchsvolle Aufgabe, die angesichts der Verschiedenheit der Daten in vollem Umfang nicht zu leisten ist. Es sei denn, man zieht sich auf ein sehr abstraktes theoretisch anspruchsloses Konzept wie die Key/Values zurück. Dazu unten mehr.

Definitionsmerkmale

Hier beschränken wir uns auf die in der Literatur genannten Definitionsmerkmale. NoSQL-Datenbanksysteme werden wie folgt definiert:

1. Das Datenmodell ist nicht-relational.

2. Sie sind ausgerichtet auf verteilte Architekturen und horizontale Skalierbarkeit.

3. Es herrscht Schemafreiheit bzw. es liegen nur schwächere Schemarestriktionen vor.

4. Meist wird eine einfache Datenreplikation, aufbauend auf einer verteilten Architektur unterstützt.

5. Es liegt eine einfache API (Application Programming Interface; Programmierschnittstelle) vor.

6. Das Konsistenzmodell ist anders als bei relationalen Datenbanksystemen: Eventually Consistent und BASE, aber nicht ACID

Vgl. beispielhaft [Edlich, Friedland, Hampe u.a. 2011, S. 2], [Gull 2011].

zu Punkt 1:

Dieser Punkt grenzt gegenüber relationalen Datenbanken ab. Die Anforderungen an relationale Datenbanken (Attributbasiertheit, Relationen als Grundelemente, relationales Schemadesign, relationale Abfragesprache SQL) werden hier nicht gefordert.

zu Punkt 2:

Dies war ein wichtiger Motivator. Ursache sind die riesigen Datenmengen. Dies können heute Peta-, Exa- und Zetabyte umfassen. Vgl. Abschnitt 1.2.2 für Beispiele. Relationale Datenbanksysteme brechen unter dieser Last und der damit entstehenden Notwendigkeit zur horizontalen Skalierung zusammen.

zu Punkt 3:

Schemaänderung meint Änderung des Datenmodells und (vor allem) der logischen Datenorganisation. Das also, was mit SQL durch Alter Table realisiert wird. Dies ist mit relationalen Datenbanksystemen bei laufendem Betrieb sehr aufwändig und auch nicht ungefährlich für den Datenbestand. Mit NoSQL-Anwendungen soll dies einfacher zu lösen sein.

zu Punkt 4:

Dies ergibt sich aus dem Design der meisten NoSQL-Anwendungen, das auf verteilten Netzwerkarchitekturen beruht. In solchen Strukturen muss leicht repliziert werden können. So kann mit CouchDB eine Datenbank mit einem einzigen Befehl repliziert werden.

zu Punkt 5:

Dieser Punkt reicht tief. Da das normale Instrumentarium eines klassischen Datenbanksystems (z.B. eine komfortable Abfrage- und Auswertungssprache) nicht zur Verfügung steht und auch die dort möglichen inhaltlichen (relationalen) Verknüpfungen nicht und außerdem die Datenstruktur selbst fast semantikfrei ist (meist nur Key/Value-Paare, siehe unten), muss hier wesentlich mehr (eigentlich fast alles) rund um die Datenabfrage und -auswertung programmiert werden. Deshalb ist eine einfache Programmierschnittstelle (API) unabdingbar.

Noch tiefer (mit [Edlich, Friedland, Hampe u.a. 2011, S. 51]):

Das dominante Entwurfsmuster für heutige verteilte Anwendungen wird REST genannt. Es hat sich "... in seiner Inkarnation http als extrem erfolgreich hinsichtlich der Skalierbarkeit erwiesen." Problematisch wird es bei komplexen Abfragen. Dann müssen die NoSQL-Anwender diese als MapReduce-Abfragen formulieren .

REST (Representational State Transfer) gilt als die Basis für die Skalierbarkeit des World Wide Web von einem einzelnen kleinen Server am CERN im Jahr 1990 zum weltumspannenden Netzdienst mit Milliarden von Nutzern heutzutage. Nicht die effizienteste Ausnutzung des Einzelsystems steht im Vordergrund, sondern die effektive Verteilung der Systemlast auf viele Maschinen. Die Plattform skaliert nahezu linear mit der Anzahl der verfügbaren Maschinen [ebenda] .

zu Punkt 6:

In NoSQL-Anwendungsbereichen sind die Anforderungen relationaler Datenbanksysteme an Konsistenz der Daten und Sicherheit der Transaktionen (ACID) nicht realisierbar. Vielleicht auch nicht nötig, wie die einschlägige Fachliteratur meint. Insgesamt wird nicht ACID (Atomar, Konsistent, Isoliert, Dauerhaft) realisiert, sondern BASE(basic available, soft state, eventually consistent). Vgl. Abschnitt 2.4.1.

2.3 NoSQL-Kernsysteme

Folgende NoSQL-Kernsysteme werden in der Literatur genannt (mit zum Teil leicht abweichenden Bezeichnungen):

  • Wide Column Stores/Column Families
  • Dokumentenorientierte Datenbanken (Document Stores, Document Full Text Search)
  • Key/Value Tuple Stores
  • Ordered-Key-Value Stores
  • BigTable
  • Graphdatenbanken (auch: Graph Ordered-Key-Value Stores)
  • RDF-Data. (RDF: Resource description framework). Dient zur konzeptionellen Beschreibung von Wissen. Vgl. [Ingallali, Ienco und Poncelet 2018]

[Edlich, Friedland, Hampe u.a. 2011], [Welkenbach und Schmutz 2012], [Kurowski 2012], [Wolff, Hunger, Spichale und George 2013], [Nguyen 2018]. Vgl. die (auch vergleichenden) Abbildungen zu Struktur und Speicherkonzept dieser datenverwaltenden Systeme in [Welkenbach und Schmutz 2012, "Abb. 2"].

Auf eine wichtige Eigenschaft der meisten NoSQL-Datenbanken weisen Wolff et al. hin:

NoSQL-Datenbanken vermeiden "weitestgehend" die Erfassung von Beziehungen zwischen den Datensätzen. "Wenn Datensätze stark miteinander in Beziehung stehen, ist es schwer, die Daten auf mehrere Server zu verteilen" [Wolff, Nitschinger und Trelle 2014, Pos. 38].

Und damit ist, so kann man ergänzen, horizontale Skalierbarkeit wesentlich erschwert und bei großen Datenmengen mit verlangten schnellen Antwortzeiten nicht mehr möglich.

Beispiele und einige ihrer Fundstellen

Beispiele für NoSQL-Systeme:

  • Apache HBase (Beschrieben in [Fondermann, Spichale und George 2014, Kapitel 3], [Wolff, Hunger, Spichale und George 2013, Kapitel 4], [Edlich, Friedland, Hampe u.a. 2011, S. 64ff].
  • Amazon SimpleDB. Beschrieben in [Edlich, Friedland, Hampe u.a. 2011, S. 96ff]
  • CouchDB: Beschrieben in [Kurowski 2012, Kapitel 2], [Wolff, Nitschinger und Trelle 2014, Kapitel 2], [Edlich, Friedland, Hampe u.a. 2011, S. 118ff], [Gull 2011]
  • MongoDB: Beschrieben in [Kurowski 2012, Kapitel 3], [Wolff, Nitschinger und Trelle 2014, Kapitel 4], [Edlich, Friedland, Hampe u.a. 2011, S. 131ff].
  • Hadoop: Beschrieben in [Wartala 2012].
  • Redis. Beschrieben in [Kurowski 2012, Kapitel 4], [Edlich, Friedland, Hampe u.a. 2011, S. 152ff], [Trelle 2014].
  • Cassandra. Beschrieben in [Wolff, Hunger, Spichale und George 2013, Kapitel 3], [Edlich, Friedland, Hampe u.a. 2011, S. 82ff]
  • Riak (NoSQL-Key-Value-Store). Beschrieben in [Wolff, Nitschinger und Trelle 2014, Kapitel 3], [Edlich, Friedland, Hampe u.a. 2011, S. 179ff].
  • Neo4j. [Wolff, Hunger, Spichale und George 2013, Kapitel 2], [Edlich, Friedland, Hampe u.a. 2011, S. 290ff]
  • ArangoDb von triAGENS (hps@ct.de). Quelloffen mit Applikations-Framework Foxx 2.0.

Vgl. die Übersicht zu NoSQL-Datenbanken in [Edlich, Friedland, Hampe u.a. 2011, S. 371ff] ("Orientierung im Datenbankraum").

Abschließend kann hier mit Perkins et al. darauf hingewiesen werden, dass die Datenbanksysteme in diesem Umfeld oftmals "open source" sind und auf "*nix"-Systemen laufen. [Perkins, Redmond und Wilson 2018, Pos. 149]

Systembasis

Im Folgenden werden nun weitere Begriffe und Konzepte aus diesem Umfeld geklärt.

2.4 Grundlagen

2.4.1 ACID vs. BASE

Datenbanken müssen bezüglich ihrer Datenhaltung bestimmte Bedingungen erfüllen. Die wichtigste ist, dass sie ihren Anwendungsbereich korrekt beschreiben (modellieren) und dass diese Beschreibung über alle Schreibzugriffe hinweg immer korrekt bleibt. Dies wird mit Konsistenz der Datenbank bezeichnet. Die Schreibzugriffe auf den Datenbestand, Transaktionen genannt, können einfach sein, z.B. nur einen Wert ändern oder komplexer und aus mehreren Schritten bestehen.

Konsistenz

Beispiele:

  • Eine Überweisung, z.B. initiert vom PC eines Kunden über einen Zahlungsdienstleister bis zur Datenbank des Verkäufers, durchläuft zahlreiche Schritte und tangiert einige Datenbanken.
  • Eine einfache Datenänderung in einer Datenbank besteht oberflächlich betrachtet nur aus einem Schritt. Schaut man etwas genauer auf die technische Ebene sind hier aber auch mehrere Schritte erkennbar, insbesondere wenn der Zugriff über das Internet erfolgt.

Die klassischen Anforderungen an Veränderungen in der Datenbank (Transaktionen) werden durch die Begriffe Atomicity, Consistency, Isolation und Durability beschrieben. Die jeweils ersten Buchstaben ergeben das Akronym ACID, mit dem sie bezeichnet werden.

ACID

„Klassisch“

Damit sind hier in der Regel relationale Datenbanken gemeint. Es können aber auch objektorientierte sein. Sie bauen auf Attributen auf, sind also attributorientiert, haben ein festes Schema (Relationen, Klassen, …) und eine ausgefeilte Methodik. Sie dienen in allen Organisationen, insbesondere in Unternehmen, zur Realisierung der Geschäftsprozesse. Nicht gemeint sind alle die, deren Informationen früher als unstrukturiert bezeichnet wurden (mit Fakten, echten Texten, chemischen Strukturformeln, Key/Value-Daten, Graphen, usw.) und die heute unter dem Begriff NoSQL-Datenbanken diskutiert werden.

Anforderungen an Datenbanken

Die klassischen Anforderungen werden hier nur wegen der Abgrenzung zu den veränderten Anforderungen der NoSQL-Welt beschrieben.

Atomicity bedeutet, dass jede Transaktion ganz oder gar nicht realisiert wird. Es darf also keine unvollständigen Transaktionen geben. Beispiele:

Atomicity

  • Eine Transaktion soll die Gehälter aller Mitarbeiter in der Personaldatenbank um 5% erhöhen. Würde sie ohne erfolgreichen Abschluss abbrechen, müssten einige auf die Erhöhung erst mal verzichten.
  • Ein einfacher Schreibvorgang in der Datenbank, z.B. zur Änderung eines Kontostandes, könnte aus den Schritten Lesen (des zu ändernden Werts), Zwischenspeichern (desselbigen), Löschen (des bisherigen Werts), Schreiben (des neuen Werts), Löschen (des Zwischenspeichers) bestehen. Wenn innerhalb dieser Schritte ein Abbruch erfolgt, z.B. durch einen Systemfehler, muss der „alte“ Zustand wiederhergestellt werden.
  • Falls die Transaktion aus mehreren Schritten besteht, wie z.B. die oben angeführte Online-Überweisung, müssen alle Schritte erfolgreich abgeschlossen werden, erst dann darf die Zahlung als erledigt eingetragen werden. Ansonsten hat eine Rückabwicklung zu erfolgen.

Die Software für die Durchführung der Transaktion (insbesondere die Datenbanksoftware) muss also prüfen, ob eine vollständige Erledigung realisiert ist. Falls nicht, wird die unvollständige Transaktion rückabgewickelt und der alte Zustand der Datenbank wieder hergestellt.

„Zustand der Datenbank“

Schon seit den Zeiten von Scheer (einem der Gründer des Faches Wirtschaftsinformatik) spricht man in der Wirtschaftsinformatik bei jeder Veränderung der Daten von einem neuen Zustand, in den die Datenbank gebracht wurde. Damit kann man die Konsistenzthematik auch so beschreiben, dass jede Transaktion, ausgehend von einem korrekten Zustand wieder zu einem solchen führen sollte.

Hiermit wird die Konsistenz (semantische Korrektheit) der Daten angesprochen. Diese muss immer gewährleistet sein. Sie kann nicht nur durch fehlerhafte Transaktionen beeinträchtigt werden, sondern auch durch sonstige Fehler im Umgang mit der Datenbank.

Consistency

Diese Forderung beschreibt eine Bedingung für die Realisierung korrekter Transaktionen. Jede Transaktion soll isoliert von anderen Transaktionen durchgeführt werden. Erst nach ihrer erfolgreichen Durchführung soll der veränderte Zustand der Daten anderen Transaktionen zur Verfügung stehen.

Isolation

Ohne diese Bedingung wäre folgendes möglich: Eine Transaktion A greift auf unvollständige Daten einer Transaktion B zu, vielleicht sogar auf Daten, die wegen Abbruch von B später rückabgewickelt werden.

Grundlage dieser Forderung ist also, dass während einer nicht erfolgreich abgeschlossenen Transaktion die Datenbank nicht in einem konsistenten Zustand ist und dass die betroffenen Daten währenddessen nicht von deren Transaktionen genutzt werden sollten.

Damit ist gemeint, dass alle Änderungen durch Transaktionen dauerhaft (persistent) sind und nicht verlorengehen. Das Datenbanksystem muss also in der Lage sein, Systemfehler (durch Hardware- oder Software-Probleme) abzufangen. Bei vielen Datenbanksystemen geschieht dies, indem alle Schreibvorgänge in einer Protokolldatei (hier Log genannt) festgehalten werden. Mit ihm kann dann (hoffentlich) der korrekte Zustand nach einem Fehler wieder hergestellt werden.

Durability, Persistenz

Soweit die Anforderungen an klassische Datenbanken in Organisationen (v.a. Unternehmen), für deren Geschäftsprozesse im Personalwesen, in der Finanzbuchhaltung, bei der Leistungserbringung, usw.

Nimmt man die ersten Buchstaben der englischen Begriffe, kann man das Akronym ACID bilden, das in der Fachliteratur für diese Anforderungen steht.

ACID

„Neue“ Anforderungen - BASE

Obige Anforderungen konnten bei NoSQL-Datenbanken nicht gefordert bzw. eingehalten werden. Die dort arbeitenden Entwickler merkten sehr bald, dass damit keine effizienten Datenbanken erschaffen und betrieben werden konnten. Deshalb wurden neue Kritereien entwickelt, die den neuen Anforderungen und dem neuen Umfeld (verteilte Datenbestände) entsprechend gestaltet waren.

Wegbereiter dieser Entwicklung war Eric Brower, der erstens die Anforderungen an Datenbanken im Web und zweitens, in seinem CAP-Theorem, deren eingeschränkte Realisierbarkeit zeigte.

CAP-Theorem

Der Ausgangspunkt sind hier große Datenmengen (BigData), im Internet verteilte Datenbanken und damit Netzwerkknoten, auf denen Daten gespeichert sind. Dafür wurden, inspiriert durch die Erfahrungen bei den ersten großen Internetfirmen (Google, usw.), folgende Anforderungen als wünschenswert erkannt:

  • (absolute) Konsistenz (Consistency)
  • (hohe) Verfügbarkeit (Availability)
  • Ausfalltoleranz (Partition Tolerance)

(1) Konsistenz (C von Consistency) bezogen auf Transaktionen.

Dies bedeutet, dass die verteilte Datenbank nach Abschluss einer Transaktion einen konsistenten Zustand erreicht. Dabei geht es v.a. darum, dass bei einer Änderung der Daten in einem Knoten, alle folgenden Lesezugriffe - egal über welchen Knoten - den aktualisierten Wert liefern. Dies bedeutet, dass der aktualisierte Wert erst dann wieder gelesen werden kann, wenn alle replizierenden Knoten aktualisiert sind.

Wenn in einem WebShop eine Bestellung getätigt und der Lagerbestand verändert wird, sollte die nächste Abfrage des Lagerbestandes erst erfolgen können, wenn alle Knoten den aktualisierten Wert aufweisen.

Beispiel

(2) Verfügbarkeit (A von Availability) eines Datenservice bezogen auf ein Netz.

Systeme müssen weiterarbeiten, auch wenn eines der Systeme nicht mehr antwortet. Dies beruht auf der Forderung nach einer akzeptablen Reaktionszeit. Bei Bestellvorgängen im E-Commerce sind schnelle Reaktionen nötig, sonst sinkt der Umsatz.

Pivert formuliert wie folgt:

„Availability is the property that every request receives a response that is not an error (however, the answer can be outdated)” [Pivert (Hrsg.) 2018, S. 3]

(3) Ausfalltoleranz (P von Partition Tolerance). Damit ist gemeint, dass der Ausfall eines Knotens oder einer Kommunikationsverbindung zwischen den Knoten einer verteilten Datenbank (z.B. durch Netzwerkfehler) nicht zum Ausfall des gesamten Systems führen soll. Das System soll weiterhin auf Anfragen von außen reagieren können.

In klassischen Datenbanken (z.B. relationalen) wird Konsistenz vor Verfügbarkeit gestellt.

Die damalige Entwicklergemeinschaft erkannte und formulierte auf ihren Tagungen, dass nur zwei dieser Ziele erreicht werden können. Hier hat insbesondere Eric Brower mit dem von ihm formulierten CAP-Theorem einen wichtigen Beitrag geleistet.

Alternatives Konsistenzmodell BASE

Da die hohe Verfügbarkeit und die Ausfalltoleranz als absolut dominant angesehen werden, muss man die Anforderungen an die Konsistenz lockern. Somit muss das eigentliche Konsistenzmodell ACID durch ein anderes ersetzt werden, das BASE („Lauge“) genannt wird. Mit ihm sind die Hauptanforderungen an horizontal skalierte Datenbanken wie folgt formuliert:

  • BA von Basically Available: Das System ist erstmal grundsätzlich immer verfügbar.
  • S von Soft State: Der Zustand des Systems ist nicht immer gleich.
  • E von Eventually Consistent: Der Datenbestand ist nicht immer gleich wieder konsistent [Kurowski 2012].

Bezüglich der Konsistenz wird nur verlangt, dass "irgendwann" der konsistente Zustand wieder erreicht wird und nicht nach jeder Transaktion. Dieses Ziel kann auf unterschiedliche Art erreicht werden. Vgl. hierzu und zu den Wegen, wie dieses Ziel erreicht werden kann [Edlich, Friedland, Hampe u.a. 2011, S. 34].

Basically Available

Nguyen fasst diese Problematik wie folgt zusammen:

„The basic tenets of the approach is that operations on the system (queries as well as updates) must be as fast as possible and therefore no global synchronization between nodes of the system should occur at the time of operation.

This, in turn, implies that after an operation, the system may be in an inconsistent state (where several nodes have different views of the global data set.” [Nguyen 2018, S. 3]

Singh und Ahmad stellen das dadurch mögliche Defizit sehr deutlich klar:

„Most NoSQL databases offer a concept of eventual consistency in which database changes are propagated to all nodes so queries for data might not return updated data immediately or might result in reading data that is not accurate which is a problem known as stale reads.” [Singh und Ahmad 2021, S. 8]

2.4.2 Volume, Velocity, Variety

Mit diesem Datenumfang sind Aufgaben verbunden, die mit Relationalen Datenbanksystemen kaum zu lösen sind. Vgl. unten. Diese grundlegenden Herausforderungen im BigData-Umfeld werden in der Literatur oft durch die Stichworte Volume, Velocity und Variety (3V) beschrieben:

  • Volume: Masse an Daten, die pro Zeiteinheit gespeichert werden müssen. Diese ist in BigData-Anwendungsbereichen sehr groß. Hier ist inzwischen von mehreren Terabytes die Rede (Stand 2021). Eine Ursache dafür ist, dass inzwischen in immer größerem Umfang auch Ereignisse und die mit ihnen verbundenen Daten erhoben werden. [Sellami und Defude 2018, S. 93].
  • Velocity: Geschwindigkeit, mit der die Daten gesammelt, persistent (dauerhaft) gespeichert, verarbeitet und wieder aufgefunden werden können (Batch oder in Echtzeit). Diese muss, v.a. wegen der Datenmenge, sehr hoch und auch mittels der Systemarchitektur gesichert sein.
  • Variety: Unterschiedlichkeit der Daten, oft beschrieben als unterschiedliche Grade von Strukturiertheit mit der Skala völlig unstrukturiert, semistrukturiert, stark strukturiert.

Es gibt Vorschläge für weitere „Vs“ (vgl. [Sellami und Defude 2018, S. 94]):

  • Veracity (“… and represents the quality of data (accuracy, freshness, consistency, etc).”)
  • Data Volatility (“… representing for how long the data is valid and for how long it should be stored.”)

Solche Anwendungen sind (beim heutigen Stand der Technik) im Regelfall nur mit verteilten Systemen realisierbar. Diese müssen darüberhinaus leicht skalierbar sein, Parallelverarbeitung erlauben, Replikation von Daten erleichtern und eine hohe Ausfallsicherheit aufweisen.

Anforderungen

2.4.3 Skalierbarkeit

In diesen Anwendungsbereichen liegen nicht nur große Datenmengen vor, die meist auf verteilten Systemen betrieben werden müssen, sondern solche, deren Umfang sich auch kurzfristig verändern kann. Daran müssen die datenverwaltenden Systeme angepasst werden. Diese Fähigkeit wird Skalierbarkeit genannt und nach horizontal und vertikal unterschieden.

Vertikale Skalierbarkeitmeint den Ausbau der eigenen Hardware. Also z.B. durch Nutzung größerer Server. Um es mit [Kurowski 2012, Kapitel 1] zu sagen:

Vertikale Skalierbarkeit

"Vertikale Skalierung ist das Tuning einer abgeschlossenen Datenbankeinheit durch Hinzufügen von Rechenleistung oder Speicher, ....."

Und evtl. durch Umstellung auf eine InMemory-Lösung (vgl. für eine Kurzdarstellung [Staud 2015, Abschnitt 24.11]), kann man ergänzen. Dies alles reicht derzeit (wer kann die Entwicklung der Hardware schon prognostizieren?) allerdings nicht aus für die in den BigData - Anwendungsbereichen anfallenden Daten, weshalb hier die horizontale Skalierbarkeit benötigt wird.

Horizontale Skalierbarkeit meint den Ausbau des Netzwerks, in dem die Daten verwaltet werden. Dies erfolgt durch das Hinzufügen weiterer abgeschlossener Datenbankeinheiten. Sie ist für die Bewältigung großer Datenmengen oft die bessere Alternative bzw., ab einer gewissen Datenmenge die einzige Möglichkeit (es muss immer wieder gesagt werden: beim derzeitigen Stand der Hardwaretechnologie). Das bedeutet, dass für größere Datenmengen oder höhere Performanceanforderungen einfach mehr Server genutzt werden und umgekehrt Server wegfallen, wenn die Anforderungen geringer werden.

Horizontale Skalierbarkeit

Nun bedarf die Skalierbarkeit nicht nur einer angemessenen Hardwarelösung, sprich Netzwerkstruktur, sondern auch eines datenverwaltenden Systems, mit dem die Skalierung realisiert werden kann (grundsätzlich, bzw. mit vertretbarem zeitlichen Aufwand). Relationale Datenbanken leisten dies nur eingeschränkt. Edlich et al. fassen ihre diesbezüglichen Erkenntnisse wie folgt zusammen: Der Einsatz relationaler Datenbanksysteme führt zu ...

Geeignete datenverwaltende Systeme

"... nicht vertretbaren Antwortzeiten, insbesondere bei gleichzeitiger Replikation, die oft auch gewünscht ist. ... Sobald Tabellen und Indizes eine Datenmenge erreicht hatten, die eine Verteilung über mehr als eine Maschine erfordert, stellten die verantwortlichen Entwickler und Administratoren fest, dass sie für eine akzeptable Reaktionszeit nur mit Workarounds und Eingriffen in den Quellcode der verwendeten Datenbanksysteme Herr der Lage werden konnten" [Edlich, Friedland, Hampe u.a. 2011, S. 30].

Dies ist ohne Probleme nachvollziehbar. Für relationale Datenbanken gilt wegen der ausgeprägten internen Verknüpfungsstruktur (vgl. [Staud 2021, Kapitel 5 bis 13]), die wiederum durch die Art der Daten begründet ist, die Notwendigkeit, Transaktionen nach den ACID-Prinzipienzu realisieren. Dies ist ein Kernprinzip der Architektur relationaler Datenbanksysteme. Nur so kann die Konsistenz dieser intensiv verknüpften Daten aufrechterhalten werden.

Es werden also andere datenverwaltende Systeme und im übrigen auch "einfachere" Datenstrukturen benötigt. Da fügt es sich gut, dass ein "Großteil der Daten im Web 2.0 ohne Relationen" (gemeint sind hier nicht die entsprechenden Konzepte der relationalen Theorie, sondern schlicht die Beziehungen zwischen Tabellen bzw. Basiskomponenten) sind, so [Edlich, Friedland, Hampe u.a. 2011, S. 151].

Insgesamt also: Für relationale Datenbanken reicht es aus bzw. muss es (will man gute Reaktionszeiten) ausreichen, vertikal zu skalieren, indem eine leistungsfähigere Hardware angeschafft wird, bis hin zu InMemory-Lösungen (vgl. [Staud 2015, Abschnitt 24.11] für einen Überblick). Mit dem Internet-Boom entstanden Datenmengen, die (in der der derzeitigen Entwicklungsphase) nur durch verteilte Verarbeitung bewältigt werden können und die einer horizontalen Skalierbarkeit bedürfen.

Zusammenfassung

2.4.4 Parallelisierung mit Hilfe des MapReduce-Frameworks

Zur horizontalen Skalierung und zur Lösung rechenintensiver Aufgaben gehört die Parallelverarbeitung. Nur wenn die jeweilige Aufgabe sich auf die Rechner im Netz verteilen lässt, kann sie in angemessener Zeit gelöst werden. Voraussetzung für BigData-Lösungen ist also ein Programmiermodell, das sich leicht parallellisieren lässt [Wartala 2013, S. 17]. Z.B. das MapReduce-Framework. Es wurde bei Google 2004 eingeführt [Nguyen 2018, S. 2f] und stellt ein Programmiermodell für die Kopplung verteilter Dateisysteme dar, auch Cluster-Dateisystem genannt [Wartala 2012, S. 18]. Kerngedanke ist die Daten-Lokalität.

Aufgaben verteilen mit MapReduce

"Die Verarbeitung großer Datenmengen auf einem verteilten System ist nur sinnvoll, wenn diese Daten den jeweiligen Verarbeitungsprozessen zur Verfügung stehen, sprich: Die Anwendungen müssen zu den Daten kommen, nicht die Daten zu den Anwendungen" [Wartala 2012, S. 17].

Es geht also, mit anderen Worten, um die nebenläufige Berechnung in Computerclustern, bei der Seiteneffekte wie Verklemmungen (deadlock) und Wettlaufsituationen (race conditions) vermieden werden.

Nguyen beschreibt die Methode treffend wie folgt:

Zusammenfassung

„ … MapReduce paradigm consists of decomposing a generic, high-level computation into a sequence of lower-level, distributed, map and reduce operations. Assuming some data elements are distributed over several nodes, the map operation is applied to each element individually, locally on the node where the element resides.“ [Nguyen 2018, S. 4]

Computercluster

„Ein Rechnerverbund oder Computercluster, meist einfach Cluster genannt (vom Englischen für „Rechner-Schwarm“, bezeichnet eine Anzahl von vernetzten Computern. Der Begriff wird zusammenfassend für zwei unterschiedliche Aufgaben verwendet: die Erhöhung der Rechenkapazität (HPC-Cluster, engl. high performance computing – Hochleistungsrechnen) und die Erhöhung der Verfügbarkeit (HA-Cluster, engl. high available – hochverfügbar). Die in einem Cluster befindlichen Computer (auch Knoten, vom englischen nodes oder Server) werden auch oft als Serverfarm bezeichnet.“ Quelle: Gekürzt nach Wikipedia, Stichwort Computercluster. Abgerufen im März 2022.

Realisierung

Im Kern ist dies wie folgt realisiert. Eine Funktion map() („Map-Funktion“) nimmt als Eingabeparameter eine Liste mit Key/Value-Paaren und eine Funktion für deren Verarbeitung entgegen und verarbeitet sukzessive alle Elemente der Liste. In der ersten Phase („map phase“) werden dafür die Daten auf die einzelnen Knoten des verteilten Systems übertragen. Sie gibt dann die durch die Funktion modifizierte Liste (wiederum Key/Value-Paare) zurück. Im Rahmen einer konkreten Verarbeitung entstehen mehrere solcher Listen. Diese werden mit Hilfe einer Funktion reduce() („Reducer-Funktion“) zusammengeführt und weiterverarbeitet. Bezogen auf ein verteiltes Dateisystem auf vielen Rechnerknoten eines Clusters, stellt sich dies wie folgt dar: Auf jedem Rechnerknoten werden die Daten zur Verfügung gestellt, die genau der Map-Prozess auf diesem Rechner benötigt. Dann werden parallel die Ergebnislisten der Mapper-Funktionen eingesammelt und nach erfolgreicher Weiterverarbeitung (Reduzierung) wieder in das verteilte Dateisystem geschrieben.

Key/Value-Paare

Es geht also nur um die Verarbeitung von Key/Value-Paaren mit ihrer doch recht mageren Semantik. Dies ist gegenüber den Möglichkeiten von SQL deutlich vereinfacht. Die Semantik muss dann vom Anwendungsprogramm geliefert werden. Entwickelt wurde dieses Programmiermodell von Google-Entwicklern.

Weitergehende Beschreibungen finden sich in [Wartala 2012, S. 17], [Edlich, Friedland, Hampe u.a. 2011, S. 17], [Fondermann, Spichale und George 2014, Kapitel 2] und [Schrempp 2012, Kapitel 2], [Nguyen 2018].

Nguyen weist auf die Nähe dieses Konzepts zur funktionalen Programmierung hin:

“Interestingly, such low-level operations where known both from the functional programming language community (usually under the name map and fold) and from the database community where the map phase can be used to implement selection and projection, and the reduce phase roughly corresponds to aggregation, grouping and ordering.” [Nguyen 2018, 3]

Die meist genutzte MapReduce-Implementierung ist das Apache Hadoop-Framework [Perkins, Redmond und Wilson 2018, Pos. 2105-2113]. Es ist ein auf Java basierendes Open Source Framework für die skalierbare und verteilte Verarbeitung großer Datenmengen auf vielen Rechnern innerhalb eines Netzwerks. Es implementiert den MapReduce-Algorithmus auf einem verteilten Dateisystem [Wartala 2012, S. 9]. Vorgeschlagen wurde es erstmals von Google [ebenda, S. 21] für deren Dateisystem HDFS. Dies ist ein verteiltes Dateisystem, d.h. es kann über Rechnergrenzen hinaus existieren. Vgl. für eine Beschreibung [Wartala 2012, S. 22ff].

Beispiel
Apache Hadoop

Hadoop wird z.B. für HBase benötigt (Vgl. [Fondermann, Spichale und George 2014, Kapitel 1], [Wartala 2012]).

Semantikdefizite

Auffällig an dieser Lösung für die Thematik „BigData/verteilt“ ist, dass in den Daten nur noch sehr wenig Semantik vorhanden ist. Da Key/Value-Daten auf eine elementare Grundstruktur reduziert sind (z.B.: zum Schlüssel 1007 gehört 100.000) ist der ganze Rest (100.000 ist das Gehalt einer Person mit dem Schlüssel 1007, sie gehört zur Abteilung xyz, usw.), im jeweiligen Anwendungsprogramm zu hinterlegen. Dies erfordert einen großen Programmieraufwand. Mehr dazu in Abschnitt 3.1.

Vgl. Abschnitt 3.1 für Key/Value-Daten

Kurowski weist (2012) darauf hin, dass die für NoSQL-Lösungen verwendeten Systeme bzw. Systemkomponenten eigentlich nichts Neues sind, aber durch den Begriff „NoSQL“ ins Bewusstsein und zu Bedeutung gelangten:

„Die Techniken selbst sind nicht neu, es handelt sich dabei um eine Kombination aus alten Verfahren wie die Speicherung mit selbstdefinierten Schlüsseln und alternative Abfragetechniken, aber erst durch ein Wort ist diese Technik in das Bewusstsein gelangt.“ [Kurowski 2012, Pos. 19]

2.4.5 Schemafreiheit und -flexibilität

Die Einrichtung einer Datenbank verlangt normalerweise vorab die Festlegung, wie die gespeicherten Daten strukturiert sein sollen. Da gab und gibt es viele Möglichkeiten. Sehen wir von den mittlerweile historischen klassischen Lösungen (v.a. Hierarchische Datenbanken und Netzwerkdatenbanken) und auch von den „frühen“ Datenbanken für „unstrukturierte Daten“ ab, waren dies vor allem die objektorientierten und die relationalen Datenbanken.

  • Für relationale Datenbanken werden Relationen (Tabellen mit bestimmter Struktur und Eigenschaften) festgelegt, die zu beschreibende Entitäten und ihre Attribute erfassen. Diese werden dann noch mit gegenseitigen Beziehungen ausgestattet. Was entsteht, wird relationales Datenmodell genannt. Vgl. [Staud 2021] für eine umfassende Darstellung.
  • Für objektorienterte Daten werden nach festen Regeln Klassen gebildet. Auch diese sind tabellenartige Gebilde, die Objekte und Attribute erfassen. Zusätzlich werden hier auch noch Methoden zur Verarbeitung der Daten angegeben. Die insgesamt zu bildenden Klassen werden ebenfalls in Beziehungen gesetzt und stellen das Klassendiagramm dar, das objektoriente Modell. Vgl. [Staud 2019] für eine umfassende Einführung in die objektorientierte Modellierung.

Die dabei entstehenden Datenmodelle werden auch als Schema bezeichnet. Dieses wird dann in der sog. physischen Struktur der Datenbank umgesetzt. Zum Beispiel werden aus Attributen Felder und aus Attributsausprägungen Einträge in Felder. Ein solches Schema (Modell) für eine Datenbank kann einen komplexen Aufbau haben und ist recht stabil über die Zeit. Eine Änderung im laufenden Betrieb ist aufwändig.

Schema

Nun erwies es sich, dass solche komplexen und fixen Strukturen im Bereich der verteilten Datenbanken im Internet nicht effizient betrieben werden konnten. Eine Ursache dafür sind die u.U. langen Antwortzeiten, die notwendig wären, um solche komplexen Strukturen in vernetzten und verteilten Datenbanken zu bewältigen. Vgl. dazu das nächste Kapitel.

Ohne Schema?

Deshalb kam recht schnell der Wunsch auf, diese Datenbanken ohne ein Schema (Modellvorstellungen) zu betreiben. Dies wurde dann auch sehr weitgehend umgesetzt. Bei vielen Datenbanken blieb als einziger Modellaspekt nur der Zusammenhang zwischen einem Eigenschaftswert (Value), den man gerne mit einer Attributsausprägung gleichsetzen kann, und einem identifizierenden Schlüssel (Key) für den Wert. Dieser hält fest, was oder wer durch den Wert beschrieben wird. Damit entstehen die sog. Key/Value-Strukturen. Vgl. dazu Abschnitt 3.1. Alle übrigen semantischen Aspekte, die ansonsten in den Datenmodellen bzw. Datenstrukturen erfasst sind, müssen, soweit sie benötigt werden, in den Anwendungsprogrammen umgesetzt werden.

Beispiel Dokumente

Ein weiterer Impuls in Richtung Lockerung der fixen Modellstrukturen ergab sich bei den Datenbanken, die hier Dokumentendatenbanken genannt werden. Diese bestehen aus unterschiedlichen Feldern (Attributen, Texten, usw.), die zusammen ein Realweltphänomen beschreiben.

Schemaflexibilität

Realweltphänomen

Der Begriff steht für das, was ansonsten meist Objekt, Entität oder auch Ding genannt wird. Also für etwas, das beschrieben wird, hier mit Mitteln der Datenbanktechnologie. Zumeist also mit Attributen.

Dokumente können z.B. Unternehmen, Personen und Patente beschreiben sowie eine notarielle Vereinbarung oder ein beliebiger Vertrag sein.

Auch hier versuchte man zuerst, relationale Datenbanken einzusetzen. Grundsätzlich sind Dokumente damit erfassbar. Dies stieß aber, auch ohne verteilte und vernetzte Datenbanken, schnell an Grenzen. Drei Faktoren waren dafür die Ursache:

(1) Die relationale Datenbanktheorie „geht davon aus“, dass die Beschreibungen der einzelnen Datenbankobjekte in Datensätzen weitgehend gleich sind. Stellen wir uns dafür die einzelnen Datensätze einer Personaldatenbank vor. Bei einer einfachen Modellierung können diese tatsächlich gleich sein. Modelliert man allerdings anspruchsvoller, gilt dies nicht mehr. Eine Person ist Programmierer, die andere arbeitet in der Hausverwaltung, beide haben damit automatisch spezifische Attribute und unterschiedliche Datensätze. Abgebildet auf die relationale Theorie liegt damit folgende Struktur vor: Alle Datenbankobjekte haben bestimmte Attribute gemeinsam, andere sind nur für bestimmte Objekte gültig. In der relationalen Theorie wird dies durch Normalisierung, Zerlegung der Relationen und Einfügen von relationalen Verknüpfungen bewältigt. Dies ist aber in NoSQL-Anwendungen nicht gern gesehen (bzw. nicht möglich). Dazu unten mehr.

(2) Einzelne Dokumente sind verschachtelt. D.h. ein Key/Value-Paar kann auch wieder ein Objekt sein, eine Liste enthalten, usw.

(3) Änderungen des Schemas kommen, wegen der Dynamik dieser Anwendungsbereiche, oft vor. Diese sollten mit wenig Aufwand und schnell realisiert werden können. Z.B., wenn neue Attribute hinzukommen oder vorhandene wegfallen.

Wege zur Schemafreiheit

Eines der Mittel, die Schemafreiheit zu realisieren, ist Versionierung, d.h. Versionen von Werten (z.B. Attributsausprägungen) mehrfach zu halten (vgl. Abschnitt 3.3). Zum Beispiel kann die Anwendung von Anfang an erweiterte Daten nutzen (mit einem Feld mehr als aktuell benötigt), ein Hintergrundprozess konvertiert die Daten und schreibt sie als neue Version. Es gibt dann nur ein kleines Zeitfenster, in dem das Lesen der Daten die alte Version ohne das neue Feld zurückliefert, was in diesen Anwendungsbereichen als tolerierbar angesehen wird.

Versionierung

Mit dem Begriff Schemafreiheit ist auch gemeint, dass das vorhandene Schema zur Laufzeit ohne großen Aufwand geändert werden kann und dass die einzelnen Dokumente einen unterschiedlichen Aufbau (eine unterschiedliche Attributzusammensetzung) haben können. Wolff et al. beschreiben dies am Beispiel von Cassandra wie folgt:

Schemaänderungen

Zur Laufzeit können weitere Spalten (gemeint sind Attribute) hinzugefügt werden, "ohne dass das Cassandra-Schema explizit geändert werden muss. So könnte beispielsweise eine Entität Benutzer um zusätzliche Attribute zur Erfassung des Geburtsdatums und des Geburtsorts erweitert werden, ohne dass Attribute zuvor definiert werden" [Wolff, Hunger, Spichale und George 2013, Kapitel 3].

Wolff et al. weisen aber auch darauf hin (wiederum am Beispiel Cassandra), dass es den Prozess des Schemadesigns doch gibt:

Cassandra

"Der Keyspace sowie die notwendigen Spaltenfamilien mit all ihren Parametern sollten vorab definiert werden. Columns mit einem Sekundärindex müssen zwingend definiert werden."

Columns=

Sie weisen dann darauf hin, dass hier, wie bei Relationalen Datenbanksystemen, das Schema auch noch nachträglich geändert werden kann und dass deshalb die Bezeichnung "dynamisches Schema" geeigneter wäre [Wolff, Hunger, Spichale und George 2013, Kapitel 3].

Hier einige Beispiele für konkrete Umsetzungen und deren Konsequenzen. Wolff et al. beschreiben den Modellierungsaspekt mit "BigTable und damit HBase" wie folgt:

BigTable, HBase

Das logische Datenmodell ähnelt dem relationalen (mit Tabellen, Zeilen und Spalten). Es gibt aber keine referentielle Integrität, keine Transaktionen und beliebige Indexe und kein SQL.

Der Zugriff erfolgt mit einer einfachen API mit nur vier Befehlen (Put, Get, Scan und Delete).

Zeilen (Tupel) haben einen eindeutigen Schlüssel (row key) mit dem die Anwender auf die eigentlichen Spalten zugreifen können, die ebenfalls einen Schlüssel haben (column key).

API: Programmierschnittstelle (Application Program Interface)

Als Folge der notwendigen oben beschriebenen eingeschränkten Konsistenz muss versioniert werden. Dies geschieht auf unterschiedliche Weise. Bei HBase werden die Werte in den Zeilen versioniert und - so die systemweite Vorgabe - drei Versionen der Werte aufgehoben. Auch ein Zeitstempel ist für die Daten möglich, dann kann man auch auf historische Werte zugreifen [Wolff, Hunger, Spichale und George 2013, Kapitel 4].

Trelle beschreibt die Situation für MongoDB. An sich, führt er aus, gilt MongoDB als schemafrei, trotzdem nimmt das Schemadesign einen hohen Stellenwert ein. Er sieht die Schemafreiheit als einen "rein technischen Aspekt", der für performante Anwendungen und zur Beherrschung der fehlenden dokumentenübergreifenden Transaktionen durch Überlegungen zur Strukturierung der Datenablage ergänzt werden muss. [Trelle 2014, S. 177f]

MongoDB

Auch Wolff et al. weisen auf die Schemaflexibilität von MongoDB hin:

"Es gibt keinen Mechanismus, der Dokumenten innerhalb einer Collection eine bestimmte Struktur oder Datentypen für bestimmte Felder aufzwingt ..... Ob es fachlich Sinn macht, völlig unterschiedliche Dokumentarten in einer Collection zu verwalten, beurteilen Sie besser selbst." [Wolff, Nitschinger und Trelle 2014]

Abschließend hierzu noch ein Beispiel aus [Trelle 2014, S. 17], ein Produktkatalog mit unterschiedlichen Produkttypen innerhalb einer Collection:

> db.produkte.insert({

typ: "dvd",

titel: "Lost Higway",

regie: "DavidLynch"

})

> db.produkte.insert({

typ: "cd",

titel: "Highway to hell",

band: "AC/DC"

})

Die zwei Befehle fügen jeweils ein Dokument (einen Datensatz) ein, allerdings mit jeweils einem unterschiedlichen Attribut.

In der Sprache der relationalen Theorie kann die flexible Schemabildung in diesem Bereich der NoSQL-Welt (Dokumente) wie folgt zusammengefasst werden:

  • Die Schemabildung besteht darin, Objekte zu identifizieren und ihnen Eigenschaften (Attribute, Key/Values, ...) zuzuordnen.
  • Die Objekte werden in Collections gruppiert.
  • Key/Value-Paare können verschachtelt sein und Informationen aller Art enthalten.
  • Dokumente bestimmter Objekte können unterschiedliche Key/Value-Paare aufweisen.
  • Neue Attribute können bei einem "neuen Dokument" einfach hinzugefügt und überflüssig gewordene einfach gelöscht werden.
  • Theoretisch könnten auch Dokumente abgespeichert werden, deren Schnittmenge gemeinsamer Attribute nur sehr gering ist. Dass dies nicht sinnvoll ist, wird auch im obigen Zitat von Wolff et al. deutlich.
  • Es gibt keine Verknüpfung zwischen unterschiedlichen Objekttypen, nur einfache Verweise sind bei einigen Systemen möglich.
  • Es gibt keine Transaktionen über die Grenzen von Collections.
  • Feldnamen müssen bei jedem Dokument mit abgespeichert werden [Trelle 2014, S. 33].

Dies sollte das Ausmaß an Flexibilität aufzeigen wie auch ihre Konsequenzen andeuten. Zu den Konsequenzen gehört der Verzicht auf die Ausmodellierung von Zusammenhängen zwischen den Daten. Schrempp beschreibt dies wie folgt:

"Aufgrund des einfachen Datenmodells dieser Technologien wird bei NoSQL meistens ein Ansatz verwendet, bei dem die Daten so vorliegen, dass alle relevanten im Datensatz selber vorhanden sind und keine Navigation zu anderen Datensätzen nötig ist. Beispielsweise können mit einem Kunden auch gleich seine Bestellungen gespeichert werden" [Schrempp 2012, Pos. 216].

Dies ist wohl notwendig, hat aber auch Nachteile. Zum Beispiel eine hohe Redundanz in den Daten. Vor allem aber eine Verlagerung des Wissens um die Zusammenhänge zwischen den Daten in die Programme. Diese werden daduch sehr viel aufwändiger – auch bei Änderungen.

Ermöglicht wird dies, indem im wesentlichen die semantisch relativ anspruchslosen Transaktionen auf diese Weise realisiert werden. Z.B. die Teilnahmen am Social Web, die Kontakte zwischen Portalen und Kunden, die Käufe von Kunden, Marketing auf der Basis des Kundenverhaltens.

 

3 Systemtypen

In diesem Kapitel werden die wichtigsten Datenbank(system)typen aus diesem Bereich kurz vorgestellt.

Dabei erfolgt, wegen derer systemprägenden Bedeutung, eine Konzen­tration auf die verarbeiteten Datenstrukturen. Die Situation bzgl. der Informationsverarbeitung wird von Nguyen treffend beschrieben. Er führt für die gegenwärtigen NoSQL-Systeme aus:

„Each of these solutions comes with its integrated query interface (some with high-level query languages, others with a low-level operator API). But besides data store, we also find processing engines such as Apache Hadoop (providing MapReduceinterface), Apache Spark (general cluster computing) or Apache Flink (stream-oriented framework), and each of these frameworks can target several of the aforementioned stores.” [Nguyen 2018, S. 12f]

Es gibt also keine übergreifende Abfrage- und Auswertungssprache (wie SQL für relationale Datenbanken). Die Auswertungen stellen Programmierlösungen dar.

3.1 Key/Value - Datenbanken

Für diesen Systemtyp sind auch die Begriffe Schlüssel-Wert-Paare, Key/Value - Systeme und Key/Value Stores in Gebrauch.

Grundstruktur

Es wurde oben schon vorgestellt: Key/Value Datenbanken beruhen auf einer sehr einfachen Datenstruktur. Sie verwalten Daten, die lediglich aus einem Schlüssel und einem Wert bestehen, ähnlich wie Felder in Programmiersprachen (mehr dazu unten).

Einige Systeme erlauben die Verwaltung komplexer "value types", wie "hashes or lists", was aber nicht grundsätzlich verlangt ist. Manche erlauben auch das "iterating through the keys", aber auch das ist nicht grundsätzlich verlangt. [Perkins, Redmond und Wilson 2018, 237-242]

Im Gegensatz zu klassischen Datenbanken (relational, objektorieniert, …) bezieht sich der Begriff "Schlüssel" hier auf die jeweilige Eigenschaft, nicht auf die gesamte beschreibende Information eines Objekts (vgl. die Anmerkung zu diesem Key-Begriff in [Staud 2015, Abschnitt 24.10). Der Wert einer solchen Key/Value-Kombination, diese wird hier auch Datensatz genannt wie die objektbeschreibenden Gegenstücke mit mehreren Attributen der physischen Datenorganisation, ist in der Regel ein Byte-Array.

Schlüssel?

Kurowski vergleicht diese Struktur mit den assoziativen Feldern (arrays) in PHP und schreibt:

"Flüchtig betrachtet ist ein Key Value Store erst einmal nichts weiter als ein assoziatives Array, bei dem der Key der Index des Arrayeintrags ist. Daher kann man sagen, dass auch die PHP-eigenen assoziativen Arrays durchaus als Key Value Store funktionieren:

 

$autohaus["id:1"]='Meier"

$autohaus["id:2"]=array("name":"Müller", "stadt":"Berlin")

echo "Autohaus 1: ".$autohaus["id:1"] -> Meier

echo "Autohaus 2 ist in ".$autohaus["id:2"] ["stadt"] -> Berlin

 

Genau diesen Ansatz verfolgen alle Key Value Stores. Daten werden gespeichert und anhand des Keys wieder abgerufen." [Kurowski 2012, Kapitel 4 (E-Book)]

Assoziative Felder (am Beispiel PHP)

Was sind assoziative Felder (arrays) in PHP?

Bei "normalen" Feldern (arrays) in Programmiersprachen werden die einzelnen Einträge über eine automatisch vergebene laufende Nummer angesprochen. So führt
$gew = array(87.5, 88.3, 90.1, 89.6, 87.4) zu einem Feld (z.B. mit den Ergebnissen der morgendlichen Gewichtsmessung), dessen Elemente automatisch durchnummeriert sind, beginnend bei 0.

Assoziative Felder dagegen enthalten eine eindeutige Schlüsselbezeichnung ("key"), mit deren Hilfe die Elemente angesprochen werden können. Beispiel:

$gew = array("Montag"=>87.5, "Dienstag"=>88.3, "Mittwoch"=>90.1, "Donnerstag"=>89.6, "Freitag"=>87.4).

Key und Value: Die Funktion array() macht $gew zu einem Feld mit Einträgen, die aus drei Elementen bestehen. Dem Schlüssel (Key), dem zugehörigen Wert (Value) und dem Operator "=>". Zu der Frage, ob dieser Key im datentechnischen Sinn wirklich ein Schlüssel ist, vgl. Abschnitt 3.3.

Datentechnisch (im klassischen Sinn) liegen damit Attributsbezeichnungen und Attributsausprägungen vor und damit - im Hintergrund - Realweltphänomene (Objekte, Beziehungen, ...), die beschrieben werden.

Dass datenverwaltende System für diesen Datentyp ist kein Datenbanksystem im klassischen Sinn. Perkins et al. nennen es ein Dateisystem, das einen Key/Value-Speicher darstellt, bei dem man sich den Dateizugang ("file path") über die "Keys" und den Dateieinhalt als Key/Value-Speicher vorstellen kann [Perkins, Redmond und Wilson 2018, 237-242].

Das datenverwaltende System

Speichern und Abrufen sind dann auch die Hauptfunktionen dieser Systeme. In Redis werden die Einträge mit SET getätigt und die Daten mit GET abgerufen [Kurowski 2012, Kapitel 4]:

Hauptfunktionen

>SET meinAuto Skoda Superb -> "OK"

>GET meinAuto -> Skoda Superb

Die Bezeichnung "meinAuto" ist der Key (eigentlich: Attributsbezeichnung) und "Skoda Superb" der Wert, d.h. die Attributsausprägung.

Die Datentypen können bei einem solchen System, das doch recht einfache Datenstrukturen anbietet, durchaus vielfältig sein. Redis z.B. kennt integer, string, hash, list und (sorted) set [Kurowski 2012, Kapitel 4]. Eine besondere Rolle spielt bei diesem System der Datentyp Hash. Die Daten werden anhand eines Keys in einer "Hashtable" [Kurowski 2012, Kapitel 4] verwaltet.

Datentypen

Schlüssel, Zugriffe, Verarbeitung

Unter einem Schlüssel im obigen Sinn kann also nur genau ein Wert (eine Attributsausprägung, ...) abgelegt werden. Dieser kann jede Art von Zeichen enthalten. Mehr zum möglichen Aufbau dieser Schlüssel findet sich in [Kurowski 2012, Kapitel 4]. Auch die Abfrage kann nur über diesen Schlüssel erfolgen, was die Situation für Auswertungen natürlich erschwert. Da verwundert es nicht, wenn einzelne Systeme weitere Zugriffsmöglichkeiten anbieten. Wolff et al. beschreiben für Riak, dass es neben der Abfrage nach Schlüsseln auch sekundäre Indizes gibt. Das ermöglicht den Zugriff nicht nur über den Schlüssel, sondern über andere Attribute [Wolff, Nitschinger und Trelle 2014, Pos. 396].

Der Einbau semantisch begründeter Beziehungen, wie bei relationalen Datenbanken, findet hier aber nicht statt. Es gibt also keine relationalen Verknüpfungen [Edlich, Friedland, Hampe u.a. 2011, S. 151], [Trelle 2014, S. 3].

Eine wie auch immer geartete Verarbeitung der Daten ist direkt nicht vorgesehen. Sie wird mit Programmierkonzepten und MapReduce (vgl. Abschnitt 2.4.4) realisiert, das für solche dann typischerweise im Netz verteilten Daten konzipiert wurde [Wartala 2012, S. 17].

Einfache Datenstruktur

Diese Datenstruktur ist also recht einfach. Die Schemabildung (Modellierung) und die logische Datenstruktur fällt auf das Elementarste zurück: Ohne die Zuweisung einer identifizierenden Information zu einer beschreibenden (Attributsbezeichnung Personalnummer zur Nummer selbst) geht es einfach nicht.

Allerdings können oftmals die Schlüssel in Namensräume und Datenbanken aufgeteilt werden, so dass die Daten wenigstens ein Stück weit gruppiert werden.

Eine solche Datenstruktur bedeutet, dass die Struktur und Semantik des Anwendungsbereichs in den Daten so gut wie nicht repräsentiert ist. Lediglich der elementare Zusammenhang zwischen beschreibender und identifizierender Information liegt vor und - sozusagen im Hintergrund - der Bezug auf bestimmte Objekte des Anwendungsbereichs. Der ganze Rest muss von der Anwendungssoftware bzw. den Programmierern geleistet werden. Dazu unten mehr.

Weitgehend semantikfrei

Vorteile

Ein großer Vorteil dieser Art der Datenspeicherung ist, dass verteilte Datenhaltung und Skalierbarkeit leicht zu realisieren sind [Wolff, Nitschinger und Trelle 2014]. Von daher ist auch der Druck in Richtung Verzicht auf (relationale) Verknüpfungen zu verstehen. Verknüpfungen über Server hinweg würden die Skalierbarkeit erschweren. Insgesamt können als Hauptmotiv für eine solche Verwaltung von Daten die riesigen Datenmengen des Internet und die Notwendigkeit der schnellen Reaktionszeit gesehen werden.

Für eine vertiefte Betrachtung der verschiedenen Ausprägungen dieses Systemtyps vgl. [Wolff, Hunger, Spichale und George 2013].

Beispiele

Edlich et al. nennen folgende Beispiele für diesen Systemtyp: Redis, Chordless, Riak, Membase, Voldemort, Azure Table Store, Tokyo Cabinet, BerkeleyDB, Scalaris, GT.M [Edlich, Friedland, Hampe u.a. 2011, S. 151].

3.2 Graphendatenbanken

Die Begriffe Graph und Netzwerk beschreiben eine vernetzte Struktur. In einer solchen gibt es Knoten und Beziehungen zwischen diesen. Bei Netzwerken können diese Beziehungen mit Werten versehen sein. Vgl. für eine Einführung in die Graphentheorie [Kastens und Büning 2008, Kapitel 5], [Gumm und Sommer 2011, Abschnitt 4.9].

Bei Graphendatenbanken liegen ebenfalls Knoten und Beziehungen vor, die hier aber beide Eigenschaften haben können und zwar als Key/Value-Paare. Das wirklich hervorstechende Merkmal von Graphendatenbanken ist, dass sie ein effizientes "Durchqueren" des Graphen/Netzwerks entlang der Beziehungen erlauben. [Perkins, Redmond und Wilson 2018, 286-289]

Man stelle sich als Knoten Präsentationen von Menschen im SocialWeb vor und als Verbindung eine Beziehung, die "mag ich" ausdrückt. Oder, mit Bezug auf die Weltwirtschaft, die einzelnen Nationalstaaten als Knoten und die Ein- und Ausfuhren zwischen diesen als Beziehungen.

Beispiele

Das ist eigentlich ein altes Thema. Der Verfasser dieses Texte hat bereits 1983 soziometrische Netzwerke und v.a. Welthandelsnetzwerke untersucht und Programme für deren Erfassung, Verarbeitung und graphische Darstellung geschrieben [Staud 1983]. Das Thema hat aber durch die weltweite Vernetzung und die Internet- bzw. SocialMedia - Aktivitäten heute eine sehr viel größere Bedeutung gewonnen.

Graphen und Netzwerke sind in den Relationen der relationalen Theorie nur schwer abbildbar, v.a., wenn die Zeiten für Zugriff und Auswertung kurz sein müssen und der Datenbestand groß ist. Deshalb bedarf es eigener Lösungen, abseits der klassischen Datenbanktechnologie. Während der Verfasser 1983 noch die Lösung selbst programmieren musste und v.a. mit dem Problem zu kämpfen hatte, Netzwerke zwischen 100 Nationalökonomien mit der damaligen Hardware zu verwalten, gibt es heute entsprechende datenverwaltende Systeme, die Beziehungsgeflechte mit Millionen Verknüpfungen verwalten können. Die dabei entstehenden Datenbestände werden in der einschlägigen Literatur Graphendatenbanken genannt. Die aktuelle Situation beschreiben Wolff et al. wie folgt:

Netzwerke

"Graphendatenbanken sind vor allem auf die effiziente Speicherung von komplexen, vernetzten Domänen ausgerichtet. In den Graphen sind die Entitäten als Knoten durch getypte Kanten miteinander verbunden. Beide können beliebige Attribute enthalten." [Wolff, Nitschinger und Trelle 2014]

Anmerkung: Domäne steht für Anwendungsbereich (vom. engl. domain).

Datenmodell, Schema

Die Modellvorstellung ist also die eines Graphen (gerichtet oder ungerichtet) oder auch Netzwerks. Vgl. für Beispiele hierzu [Staud 1983]) und die Präsentation von Graphen in der sog. Adjazenzmatrix (Nachbarschaftsmatrix), der Matrix mit den Beziehungswerten.

Anwendungsbereiche

Anwendungsbereiche sind neben den schon erwähnten sozialen Netzen auch sonstige Empfehlungssysteme, die Bild- und Textanalyse, die Wissensrepräsentation, das Semantic Web, Linked Open Data bis zu Geoinformationssystemen, einfach alle Anwendungsbereiche, bei denen die zu verwaltende Information nicht nur aus einzelnen Datensätzen besteht, sondern bei denen auch die verknüpfende Information erfasst wird, bzw. im Mittelpunkt steht. Bei all diesen Anwendungen besteht die gesuchte Information nicht mehr länger nur aus einzelnen, zur Suchanfrage passenden Datensätzen, sondern aus Informationen über die Art und Weise der Verknüpfungen dieser Datensätze untereinander" (vgl. auch [Edlich, Friedland, Hampe u.a. 2011, S. 217]).

Beispiele sind Neo4j und SonesDB. Neo4j ist beschrieben in [Wolff, Hunger, Spichale und George 2013, Kapitel 2].

Beispiele

RDF

Oben war schon mehrfach die Rede von RDF-Daten. RDF bedeutet Resource description framework. Es dient zur konzeptionellen Beschreibung von Wissen in Graphendatenbanken:

„The Semantic Web is rapidly growing, generating large volumes of Resource Description Framework (RDF) datastored in Linked Open Data” [Amann, Curé und Naacke 2018]

Amann et al. Geben eine Kurzbeschreibung:

“The Resource Description Framework (RDF) is a family of W3C specifications for linking and sharing data on the Web. … It includes a graph-oriented abstract data model with optional schema definitions and a highlevel declarative query language called SPARQL. … In particular, RDF data graphs can be produced without a predefined schema and SPARQL allows querying both schema and instance information simultaneously.” [Amann, Curé und Naacke 2018, S. 22]

Bei dieser Zitatstelle findet sich auch ein Beispiel für einen RDF Graph.

Vgl. Amann, Curé und Naacke 2018 („Distributed SPARQL Query Processing: A Case Study with Apache Spark”) sowie Ingallali, Ienco und Poncelet 2018 („Querying RDF Data: A Multigraph-based Approach“) für eine weitergehendee Beschreibungen.

3.3 Dokumentendatenbanken

Was ist ein Dokument?

Das Grundkonzept des Schemas (Datenmodells) sind hier sog. Dokumente. Für zahlreiche Beispiele vgl. [Staud 1991, Kapitel 7]. Damals nannte man sie Faktendatenbanken.

Beschrieben werden beliebige Informationsträger, die auch identifiziert werden. Es gibt also Felder, wovon eines ein Schlüssel ist. Beispiele sind Unternehmen, Personen, Verträge.

Dies entspricht den Datensätzen im Sinne der klassischen sequentiellen Dateien, bei denen jeder Datensatz aus mehreren Feldern besteht. Die einzelnen Felder enthalten meist die Ausprägungen von Attributen (hier Werte genannt), wie gewohnt. Einzelne können aber auch längere Texte enthalten oder andere Informationsarten wie Arrays und eingebettete Dokumente (so bei MongoDB). Auch verschachtelte Strukturen sind möglich, ein Feld kann also wiederum ein Dokument enthalten.

Wer mit der relationalen Theorie Kontakt hatte, erkennt, dass die relationale Speicherung solcher Datensätze einige modelltechnische Anstrengungen verlangt.

Die aktuelle Sicht der Informatik ist wie folgt:

Ein Dokument kann als eine geordnete Liste von Key/Value-Paaren gesehen werden (zu Key/Value-Paaren vgl. oben).

Mit den Worten von Perkins:

“In short, a document is like a hash, with a unique ID field and values that may be any of a variety of types, including more hashes.” [Perkins 2018, Pos. 270-277 (E-Book)]

Es werden hier also nicht nur einzelne Key/Value-Paare verwaltet, wie bei (den meisten) Key/Value-Datenbanken, sondern semantisch begründete Zusammenstellungen, die dem entsprechen, was man ansonsten Tupel (und dann später auf der physischen Ebene Datensatz) nennt.

Bezugspunkt für Datenbankobjekte

Dokumente beziehen sich auf bestimmte Objekte, die sie beschreiben. Dies können Unternehmen, Personen, Geschäftspartner, usw. sein, einfach alles, was identifiziert (hier durch ein Attribut mit der Endung "id" gekennzeichnet) und durch weitere Attribute ("key values") beschrieben wird.

Informationsträger

Bei CouchDB (einem wichtigen Vertreter dieses Systemtyps) werden die Datendokumente im JSON-Format (vgl. unten) gespeichert. Auch alle Arten binärer Daten (Bilder, PDF-Dateien, HTML-Dateien, CSS-Dateien, MP3-Dateien) sowie virtuelle Dokumente (entsprechend den Views der relationalen Datenbanken) können mit den Dokumenten abgelegt werden [Gull 2011, S. 73f]. In CouchDB erfolgt die Zuordnung über ein Attribut _attachements.

Speicherung mit CouchDB

Im Unterschied zu Datensätzen (einer Datei, bzw. Tupeln einer Relation), die ja alle denselben Aufbau haben, können Dokumente einen unterschiedlichen Aufbau haben (wie bei den Key/Value-Datenbanken schon vorgestellt). Dies wird hier als Vorteil gesehen. Angenommen, die Dokumente beschreiben Unternehmen (für eine Wirtschaftsdatenbank). Dann ist die Gesamtzahl der Key/Value - Paare evtl. 500, verschiedene Unternehmen können aber unterschiedlich viele haben. Werden z.B. auch Tochtergesellschaften durch 100 Key/Value - Paare beschrieben, dann haben Unternehmen ohne solche auch keine entsprechenden Felder/Feldeinträge.

Unterschiedlicher Aufbau

Dies ist tatsächlich ein altes Problem, es wurde auch immer gelöst, vgl. die Faktendatenbanken früherer Zeiten, heute wird es von der NoSQL-Bewegung thematisiert. Denn natürlich haben die großen Internetanbieter - v.a. die aus dem Social Web - eine Unmenge solcher Daten gespeichert ("Profile", usw.) und wollen sie verarbeiten.

Beispiele für Dokumente dieses Typs finden sich in [Trelle 2014, S. 13].

Die datenverwaltenden Systeme für Dokumentendatenbanken bieten auch einige Datenbankfunktionen an, z.B. Indexierung, Ad Hoc-Abfragen und Replikation.

Etwas genauer lassen sich die Unterschiede zwischen Dokumenten (in der NoSQL-Fassung) und Tupeln (Datensätzen) der relationalen Theorie so beschreiben:

(1) Unterschiedliche Anzahl von Key/Value-Paaren bei den Dokumenten.

Dem entspricht bei relationalen Datenbanken eine unterschiedliche Attributzusammensetzung der Tupel (Datensätze). In der relationalen Theorie wird dies durch eine Generalisierung / Spezialisierung beseitigt und es entstehen mehrere verknüpfte Relationen (vgl. [Staud 2021, Abschnitt 14.1]). Zusammen bleiben da nur die Datensätze, die genau denselben Aufbau haben, wie es sich für die dort definierten Dateien gehört.

Dieser Verzicht auf einen einheitlichen Aufbau der Dokumente führt dazu, dass die Feldbezeichnungen ("Keys") bei jedem Dokument/bei jedem Feld (Key) mitgeführt werden müssen.

Zur Erinnerung: In den sequenziellen Dateien (vgl. [Staud 2021, Abschnitt 21.3]), die den Relationen zugrunde liegen, wird die Bezeichnung der Felder (der Attribute) nur am Dateianfang angegeben, danach ist sie wegen der fixierten Struktur sequentieller Dateien nicht mehr nötig.

(2) Eingebettete Dokumente

Dokumente können verschachtelt sein. Dies bedeutet, dass in einem Wert (ein Wert in einem Key/Value-Paar / einer Attributsausprägung) ein ganzes Dokument erfasst wird. Z.B. also bei Dokumenten zu einem Unternehmen eine ganze Unternehmensbeschreibung für den "Key" (das Feld) Tochtergesellschaft. Dies würde in einem relationalen Datenmodell zu einer eigenen Relation führen, die beiden Relationen wären durch Schlüssel/Fremdschlüssel verknüpft.

(3) Weitere Informationsarten in den Werten (Key Values)

Es können über Attribute hinausgehende weitere Informationsarten gespeichert werden. Also z.B. die Rede des Vorstandsvorsitzenden von der letzten Hauptversammlung Früher nannte man die BLOB (Binary Large Object, ein Begriff der Datenbanktheorie). Diese würden in relationalen Datenbanken zu eigenen Relationen führen und über Attribute mit der Ausgangsrelation werden.

Bei all diesen Punkten verzichtet die NoSQL-Lösung auf Komplexität (z.B. auf Verknüpfungen). Dies vereinfacht das Datenmodell und den Datenbestand. Er kann dann z.B. leichter (auch horizontal) skaliert werden.

JSON

Wie oben schon ausgeführt, sind Dokumente hier als JSON-Datenstrukturen realisiert. JSON bedeutet JavaScript Object Notation. Es ist ein sog. leichtgewichtiges Datenaustauschformat (www.json.org), leicht les- und schreibbar für Menschen wie Programme (ebenda), das auf einer Untermenge der JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999 beruht. Betont wird sein von formalen Sprachen unabhängiges Textformat, seine Syntax ist bei der "C-Programmiersprachen-Familie" angesiedelt. Basiselement sind Key/Value - Paare, wie oben vorgestellt.

Quelle:

Grundlage von JSON sind zwei Strukturen:

  • Eine Sammlung von Key/Value - Paaren (Eigenschaften). Dies entspricht dem, was in anderen formalen Sprachen object, record, struct, dictionary, hash table, keyed list, oder associative array genannt wird.
  • Eine geordnete Liste von Werten. Dies entspricht den Konzepten array, vector, list oder sequence anderer formaler Sprachen.

Dies sind, da hat die Quelle tatsächlich recht, universelle Datenstrukturen. Auch die Datensätze der üblichen Dateitechniken lassen sich da unterbringen. Es geht also zum einen um die elementare Zusammenstellung identifizierender und beschreibender Information, zum anderen um die Zusammenstellung solcher Informationen zur Beschreibung von ganzen Realweltphänomenen (Objekten, Beziehungen, usw.). Die konkrete Ausgestaltung in JSON ist wie folgt:

Universelle Datenstrukturen

  • Objekte ("Realweltphänomene") werden als ungeordnete Menge von Key/Value-Paaren gesehen. Eine Objektbeschreibung beginnt und endet mit einer geschweiften Klammer. Nach der Objektbezeichnung folgt ein Doppelpunkt, danach die Key/Value-Paare, jeweils durch ein Komma getrennt.
  • Ein array ist eine sortierte Sammlung von Werten. Er beginnt und endet mit einer eckigen Klammer. Die Werte sind durch Kommata getrennt.
  • Datentypen sind der Nullwert (null), Boolean (true, false), Ziffern, Zeichenketten (in Anführungszeichen), die oben angeführten arrays und Objekte.
  • Eine Zeichenkette ist eine Folge von Unicode-Zeichen, die in doppelten Anführungszeichen stehen.
  • Ein Buchstabe wird als single character string repräsentiert

Hier ein Beispiel aus [Gull 2012, S. 299], wo sich zahlreiche weitere Beispiele finden. Die Objekte dieses Beispiels sind Städte und ihre Verkehrsinfrastruktur:

{

"_id": "city_münchen",

"_rev": "2-54a357f5e0172cb2c35b4b2ea88fa366",

"country": "Deutschland",

"cityName": "München",

"subName": "U-Bahn",

"memos": "Wurde zur Olympiade in den 1970ern eröffnet.",

"type": "city",

"created_at": "2011-05-08T17:11:09.007Z"

}

Das binäre Format von JSON wird BSON (Binary JSON) genannt.

Ist ein "Key" ein Schlüssel?

Jetzt wird es Zeit, den Begriff key in key/value zu hinterfragen. Bezogen auf ein Objekt (mit einer identifizierenden und üblicherweise mehreren beschreibenden Informationen) ist er nicht sinnvoll, da außer dem Schlüssel (der id) meist kein weiteres identifizierendes Attribut vorhanden ist. Besser wäre, wie es in einigen wenigen Quellen auch getan wird, von name/value pairs zu sprechen, denn es geht ja nur um die Bezeichnung der Eigenschaft (Bezeichnung des Attributs). Da sich aber in der einschlägigen Literatur der Begriff key/value durchgesetzt hat, soll er auch hier verwendet werden.

Betrachtet man, wie bei den Key/Value-Datenbanken, die einzelnen Eigenschaften isoliert (was ja eigentlich nicht sinnvoll ist, denn eine Objektbeschreibung benötigt mindestens zwei Key/Values), erscheinen die Attributbezeichnungen als Schlüssel. Im obigen Beispiel: country für sich betrachtet ist identifizierend - für Staaten - nicht für Städte und ihre Verkehrseinrichtungen.

Vgl. zu obigem auch die Syntaxdiagramme in [Gull 2012, S. 299].

Schlüssel, Id

Jedes Dokument hat (auch hier) einen eindeutigen Schlüssel, in MongoDB gibt es dafür einen Datentyp ObjectId [Trelle 2014, S. 7]. Er wird im Feld _id verwaltet. Schlüssel müssen hier natürlich ausgefeilter sein als in relationalen Datenbanken. Zum Beispiel besteht bei MongoDB die ObjectId aus 12 Bytes mit folgender Bedeutung: Zeitstempel mit 4 Bytes, Maschine mit 3 Bytes, PID mit zwei Bytes, Zähler mit 3 Bytes. Der Zeitstempel gibt die Sekunden seit dem 1.1.1970 an [Trelle 2014, S. 36].

Schlüssel für Dokumente

Erläuterung:

Maschine: Computer, auf dem die ID erzeugt wurde. Hashwert des Hostnamens.

PID: Identifikation des laufenden Prozesses.

Zähler: einfacher Zähler, der inkrementiert wird. "Damit können von einem Prozess ... 16 MB ... Dokumente pro Sekunde eingefügt werden, bevor es zu Kollissionen kommt." [Trelle 2014, S. 36]

Auf dem Primärschlüssel liegt ein Index [Trelle 2014, S. 37], so dass Suchvorgänge wesentlich beschleunigt werden.

Indexierung

Versionierung

Das Ändern von Daten läuft hier wie folgt ab (am Beispiel CouchDB): Ist ein Feld zu ändern, wird das gesamte Dokument geladen und verändert. Dann wird das gesamte Dokument als neue Version abgespeichert [Gull 2011, S. 72]. Deshalb erhalten Dokumente eine Revisions-ID, die bei jedem Update verändert wird, so dass ein gezieltes Auffinden der Änderungen ermöglicht wird.

Ändern von Daten

Die Kennzeichnung der Versionen ist (bei CouchDB) wie folgt: Am Anfang steht eine fortlaufende Nummer, woraus erkennbar ist, wie oft das Dokument gespeichert wurde. Es folgt ein Bindestrich und nach diesem ein von CouchDB berechneter MD5-Hashwert [Gull 2011, S. 73]. MD5 bedeutet Message-Digest Algorithm 5. Dieser Hashwert ist eine Prüfsumme mit der Länge 128 Bit, die aus einer beliebigen Zeichenfolge erzeugt werden kann [Gull 2011, S. 339].

Kennzeichnen von Versionen

Mehrfachzugriffe bewältigen

Das klassische Vorgehen bei Mehrfachzugriffen ist, dass ein Datensatz gesperrt ist, solange der Zugriff erfolgt. Dies ist bei verteilten Daten und der gleichzeitigen Forderung nach möglichst sofortiger Anfragebeantwortung nicht möglich. Hier mussten also andere Lösungen gefunden werden. Eine davon wird MVCC (Multi-Version-Concurrency-Control genannt). Sie kontrolliert konkurrierende Zugriffe auf eine Datenbank und führt sie effizient aus und zwar so, dass normalerweise keine Blockaden bei den einzelnen Zugriffen auftreten. Außerdem muss die Datenbankkonsistenz gesichert werden. Um die Effizienzforderung zu erfüllen, müssen Transaktionen nicht warten, bis Datenbankobjekte verfügbar sind. Dazu werden verschiedene versionierte Objekte im Speicher vorgehalten und den jeweiligen Transaktionen angeboten [Gull 211, S. 340]. Auf diese Weise werden lesende Zugriffe niemals blockiert. Allerdings geht dies zu Lasten des Speicherplatzes, da viele verschiedene Versionen eines Objekts vorgehalten werden müssen.

MVCC

Wieso MVCC?

Diese Datenbanksysteme übertragen die Daten zwischen den Rechnerknoten mit dem HTTP-Protokoll. So auch CouchDB. Das HTTP-Protokoll ist zustandslos (stateless), was bedeutet, dass eine Übertragung wie folgt realisiert wird: Es wird eine Anfrage (request) an den Server gesendet, die Netzwerkverbindung wird geöffnet, die Daten werden gesendet und/oder empfangen, die Verbindung wieder geschlossen und der Server verliert die Informationen zur Anfrage wieder. D.h. der Client packt alle notwendigen Informationen in diese eine Anfrage [Gull 2011, S. 30]. Dadurch wird die Kontrolle der Daten dem Datenbankserver entzogen, sie liegt bei der Anwendung und ein Verfahren wie MVCC muss für die Abstimmung der Zugriffe sorgen.

Datenmodell, Schema

Damit ergibt sich eine, gegenüber den relationalen Datenbanken, wesentlich veränderte Struktur des Datenmodells (Schemas). Elementarer Bestandteil sind die Dokumente, mit der Flexibilität bzgl. ihres Aufbaus (unterschiedliche Key/Value - Paare). Eine weitergehende Strukturierung erfolgt, ähnlich den Key/Value - Datenbanken, durch Collections. Dies sind Gruppierungen von Dokumenten nach inhaltlichen / fachlichen Gesichtspunkten, die beim Umgang mit den Daten Bedeutung haben. Z.B. können in MongoDB innerhalb einer Abfrage nur Dokumente aus einer Collection durchsucht und zurückgeliefert werden [Trelle 2014, S. 93]. Direkt vom System her kommen zum Datenmodell noch hinzu die Versionen von Dokumenten.

Das, was man als relationale Verknüpfung kennt, gibt es bei diesem Datenbanksystemtyp nicht. Es gibt aber Referenzen auf Objekte. Diese können manuell oder mittels sogenannter DBRef-Verweise verwaltet werden. Verwendet man DBRefs, wird neben der ObjektId des referenzierten Dokuments auch der Name der Collection und ggf. sogar der Name der Datenbank gespeichert. Ein Beispiel:

Verknüpfungen zwischen Dokumenten (Referenzen)

{$ref: <collectionName>, $id: <ObjectId>, $db: <dbName>} [Trelle 2014, S. 39].

Somit kann zumindest ein Stück weit die Beziehungssemantik von Daten („Müller arbeitet in der Abteilung IT)erfasst werden.

Ein Datenmodell wie dieses erlaubt ein Vorgehen, wie es Edlich et al. für MongoDB beschreiben:

Beispiel MongoDB

"Das Schema wird mit Einfügen eines Dokuments zur Laufzeit erzeugt." [Edlich, Friedland, Hampe u.a. 2011, S. 133]

Und, so kann man ergänzen, wird mit jedem abweichenden Dokument verändert.

Auf einen wichtigen Nachteil dieser Schemaausgestaltung und -flexibilität weist Trelle hin: Es gibt keine Transaktionen, die mehr als ein Dokument umfassen und selbst bei Operationen auf nur einem Dokument ist kein explizites Rollback möglich [Trelle 2014, S. 7].

Beispiele

Apache CouchDB, MongoDB, Lotus Notes [Gull 2011, S. 19].

3.4 Spaltenorientierte Datenbanken

Ausgangspunkt der Begrifflichkeit hier ist die zweidimensionale Tabelle mit Daten, die im Fall der relationalen Theorie in jeder Zeile ein Objekt beschreibt und dass die Einträge jeder Zeile zusammen gespeichert werden. Bei spaltenorientierten Datenbanken ist es dagegen so, dass jede Spalte ein Datenbankobjekt beschreibt und dass die Werte der Spalten zusammen gespeichert werden.

Durch diese Art der Speicherung können bestimmte Datenbankoperationen und -auswertungen schneller ausgeführt werden.

Zeilenorientiert - Spaltenorientiert

Für Relationen gibt es die konzeptionelle Vorstellung einer Tabelle, die dann durch einige Festlegungen ("flat table", ...) zur Relation wird (vgl. die Kapitel 4 – 13 ind [Staud 2021]). Dabei stehen die Attribute nebeneinander und beschreiben die Tupel. In jedem Tupel stehen dann die Attributsausprägungen genauso nebeneinander. Auch bei der physischen Datenorganisation relationaler Datenbanken ist dies dann so. Aus Tupeln werden Datensätze, am Anfang der Datei ist der Dateikopf mit den Attributsbezeichnungen, Datentypen, usw., dann folgen die Datensätze, einer nach dem anderen, jeweils Ausprägung nach Ausprägung. Deshalb werden diese Datenbanken als zeilenorientiert bezeichnet.

Zeilenorientierung

Vgl. Abschnitt 21.3 von [Staud 2021], wo dieses Speicherprinzip am Beispiel der sequentiellen Datei beschrieben wird.

Diese "Zeilenorientierung" ist gut im Sinne sparsamer Datenzugriffe, wenn mehrere Attribute einer Relation abgefragt werden, z.B. die Namen, Vornamen und Gehälter der Angestellten. Sprünge beim Lese- oder Schreibzugriff gibt es dann im wesentlichen nur, wenn von Tupel zu Tupel weitergegangen wird. Hat man nun aber Abfragen, bei denen ein bestimmtes Attribut über sehr viele Tupel, also eine Ausprägung über sehr viele Datensätze, abgefragt wird, ist diese Anordnung hemmend. Von jedem Datensatz wird ja nur eine Ausprägung gelesen, dann muss die Abfrage zum nächsten Datensatz springen. Dies kostet Zeit. Ein wirkliches Problem ist dies angesichts der immer besser gewordenen Zugriffsgeschwindigkeiten externer Speicher aber nur bei sehr großen Datenmengen.

Für solche Situationen wurden die spaltenorientierten Datenbanksysteme und Datenbankengeschaffen. Hier werden die Attributsausprägungen eines Attributs mehrerer Tupel (sozusagen) hintereinander geschrieben. Jede Spalte kann dabei in einer eigenen Datei liegen. Die Ausprägungen eines Attributs liegen hier also hintereinander, über die Tupel hinweg.

Spaltenorientierung

Ein Beispiel: Es soll eine Datenbank mit Kundendaten angelegt werden. Die Attribute sind KuNr (Kundenummer), KuName (Kundenname), Ort und Umsatz. Das führt zur folgenden konzeptionellen Tabellendarstellung:

KUNDEN

#KuNr

KuName

Ort

Umsatz

1001

Schmidt

Berlin

5000

1002

Koch

Stuttgart

3000

1003

Widmer

Köln

7000

...

 

 

 


In einer zeilenorientierten Datenbank werden bei der physischen Speicherung alle Datenwerte einer Zeile aneinander "angehängt" und anschließend folgt die nächste Zeile. Somit würde eine "Tupelfolge" mit folgendem Aufbau entstehen:

1001, Schmidt, Berlin, 5000; 1002, Koch, Stuttgart, 3000; 1003, Widmer, Köln, 7000; ...

Zeilen hintereinander

Eine spaltenorientierte Datenbank hingegen legt die Ausprägungen eines Attributs über alle Tupel hinweg hintereinander. Mit dem obigen Beispiel:

1001,1002,1003; Schmidt, Koch, Widmer; Berlin, Stuttgart, Köln; 5000, 3000, 7000; ...

Spalten hintereinander

Die Menge der Ausprägungen eines Attributs wird hier als Spalte bezeichnet. Die konzeptionelle Vorstellung ist die einer Zerlegung der Relation:

KUNDEN-Name

#KuNr

KuName

1001

Schmidt

1002

Koch

1003

Widmer

...

 


KUNDEN-Ort

#KuNr

Ort

1001

Berlin

1002

Stuttgart

1003

Köln

...

 


KUNDEN-Umsatz

#KuNr

Umsatz

1001

5000

1002

3000

1003

7000

...

 


Entscheidend ist aber nicht diese, sondern die damit einhergehende veränderte physische Struktur, wie oben ausgeführt.

Hat man Auswertungen, die zahlreiche Attributsausprägungen eines Attributs verarbeiten (hier z.B. der Durchschnittsumsatz aller Kunden; eine Auszählung, wieviele Kunden in den einzelnen Städten sind), müssen nicht alle Zeilen, sondern nur die Spalten, welche für die Auswertung relevant sind, durchsucht werden. Von dieser spaltenorientierten Speicherung erhofft man sich vor allem folgende Vorteile:

Vorteile der spaltenorientierten Speicherung

  • Die für Auswertungen in einem Data Warehouse benötigten Auswahlprozesse können, wenn sie auf einem einzelnen Attribut basieren, schneller realisiert werden.
  • Aggregate (gespeicherte aggregierte Werte: z.B., ausgehend von Tagesdaten, die von Wochen, Monaten, Jahren) können eingespart werden, da die aggregierten Werte bei Bedarf berechnet werden.
  • Bessere Komprimierbarkeit, da die Spalten homogenere Daten als Tupeldaten haben (Ausprägungen eines Attributs).
  • Evtl. Verzicht auf Indexierung, da diese Speicherungstechnik die Effizienz der Abfragen steigert.

Diesen Vorteilen steht der Nachteil gegenüber, dass das Einfügen von Tupeln aufwändiger ist. Ebenso die Durchführung bestimmter Abfragen, z.B. wenn viele oder alle Attribute der Tupel benötigt werden. Dann muss bei dieser Speicherungsform deutlich mehr „gesprungen“ werden als in der zeilenorientierten.

Nachteil

Neben dem schnelleren Zugriff ist der Wunsch nach effizienterer Komprimierung ein Motiv, denn die spaltenorientierte Speicherung eignet sich besonders gut für Komprimierungstechniken. Der Grund liegt darin, dass Daten desselben Typs (Attributsausprägungen eines Attributs) auf dem Speichermedium in aufeinander folgenden Abschnitten gespeichert werden. Wenn es sich beim jeweiligen Attribut nicht um einen Schlüssel handelt, liegen sogar viele gleiche Attributsausprägungen vor.

Hauptmotiv: große Datenmengen

Als Komprimierungsmethode nennen [Plattner und Zeier 2011] die Light-Weight-Compression. Die Vorgehensweise ist recht einfach, so können mehrfach vorkommende Werte durch Variablen ersetzt werden, die in einem Wörterbuch gepflegt werden. Mithilfe dieses Wörterbuches können sie wieder in ihre ursprünglichen Werte übersetzt werden. Bei identischen Werten, die direkt aufeinander folgen, können diese als Sequenzlauflängen codiert abgelegt werden.

Ein weiteres Entwurfsziel spaltenorientierter Datenbanken ist die Erleichterung der horizontalen Skalierbarkeit. Damit ist die Möglichkeit gemeint, den Datenbestand und seine Verarbeitung auf eine große Anzahl von Clustern zu verteilen.

Horizontale Skalierbarkeit

Zusammengefasst kann mit [Plattner und Zeiher 2011] festgehalten werden, dass spaltenorientierte Datenbanken für analytische Systeme mit sehr vielen Lesevorgängen optimiert sind, während zeilenorientierte Datenbanken für operative Systeme mit sehr vielen Schreibvorgängen entwickelt wurden.

Zu den Begriffen analytische und operative Datenbanken vgl. Abschnitt 24.1 in [Staud 2021].

[Plattner und Zeiher 2011] empfehlen für moderne Datenbanksysteme beides, Zeilen- und Spaltenorientierung (hybride Technik). Durch eine solche optimale Mischform sehen sie Performanceverbesserungen von bis zu 400% gegenüber einer reinen Zeilen- oder Spaltenorientierung.

Hybride Technik

Perkins et al. fassen wie folgt zusammen:

“… By contrast, a row-oriented database (like an RDBMS) keeps information about a row together. The difference may seem inconsequential, but the impact of this design decision runs deep. In column-oriented databases, adding columns is quite inexpensive and is done on a row-by-row basis. Each row can have a different set of columns, or none at all, allowing tables to remain sparse without incurring a storage cost for null values.” [Perkins, Redmond und Wilson 2018, Pos. 259-266]

Beispiele

HBase, Cassandra

 

4 Literatur

Codd et al. 1993
Codd, E. F.; Codd, S. B.; Salley, C. T.: Providing OLAP (On-Line Analytical Processing) to User Analysts: An IT Mandate. White Paper, Arbor Software Cooperation. 1993

Connolly, Begg und Stachan 2002
Connolly, Thomas; Begg, Carolyn und Strachan, Anne: Datenbanksysteme. Eine praktische Anleitung zu Design, Implementierung und Management. München u.a. 2002 (Gebundene Ausgabe)

Date 1990
Date, C.J.: An Introduction to Database Systems. Volume I (5. Auflage), Reading u.a. 1990

Date, Kannan und Swamynathan 2006
Date, C.J; Kannan, A. und Swamynathan, S.: An Introduction to Database Systems. (8. Auflage), New Delhi 2006

Edlich, Friedland, Hampe u.a. 2011
Edlich, Stefan; Friedland, Achim; Hampe, Jens; Brauer, Benjamin und Brückner, Markus: NoSQL. Einstieg in die Welt nichtrelationaler Web 2.0 Datenbanken (2. Auflage). München 2011 (Hanser)

Elmasri und Navathe 1989
Elmasri, Ramez; Navathe, Shamkant B.: Fundamentals of Database Systems Datenbanksystemen. Redwood City 1998

Elmasri und Navathe 2002
Elmasri, Ramez; Navathe, Shamkant B.: Grundlagen von Datenbanksystemen (3. Auflage), München 2002 (Pearson Studium)

Fondermann, Spichale und George 2014
Fondermann, Bernd; Spichale, Kai und George, Lars: BigData. Apache Hadoop. E-Book 2014 (entwickler.press)

Gull 2011
Gull, Clemens: Web-Applikationen entwickeln mit NoSQL. Haar 2011 (Franzis)

Gumm und Sommer 2011
Gumm, Heinz-Peter; Sommer, Manfred: Einführung in die Informatik (9. Auflage). München und Wien 2011

Harrison 2015
Harrison, Guy: Next Generation Databases. NoSQL, NewSQL, and BigData, New York 2016 (E-Book)

Herden 2007
Herden, Olaf: Data Warehouse. In: [Kudraß 2007], S. 427 - 455

Herold, Lutz und Wohlrab 2012
Herold, Helmut; Lurz, Bruno; Wohlrab, Jürgen: Grundlagen der Informatik (2. Auflage). München u.a. 2012 (Pearson)

Ingallali, Ienco und Poncelet 2018
Ingallali, Vijay; Ienco, Dino und Poncelet, Pascal: Querying RDF Data: a Multigraph-based Approach. In: [Pivert (Hrsg.) 2018, S. 135 - 165]

Inmon 2005
Inmon, William H.: Building the Data Warehouse, 4. ed., Indianapolis.

Kastens und Büning 2008
Kastens, Uwe und Büning, Hans Kleine Büning: Modellierung. Grundlagen und formale Methoden (2. Auflage). Bonn 2008 (Hanser)

Kemper und Eickler 2011
Kemper, A.; Eickler, A.: Datenbanksysteme. Eine Einführung. München und Wien 2011

Köppen, Saake und Sattler 2012
Köppen, Veit; Saake, Gunter und Sattler, Kai-Uwe: Data Warehouse Technologien. Heidelberg 2012 (mitp)

Köppen, Saake und Sattler 2012
Köppen, Veit; Saake, Gunter und Sattler, Kai-Uwe: Data Warehouse Technologien. Heidelberg 2012 (mitp)

Kudraß 2007
Kudraß, Thomas (Hrsg.): Taschenbuch Datenbanken. Leipzig 2007

Kurowski 2012
Kurowski, Oliver: NoSQL Einführung. CouchDB, MongoDB und Redis. E-Book 2012 (entwickler.press)

Lang und Lockemann 1995
Lang, Stefan M.; Lockemann, Peter C.: Datenbankeinsatz. Berlin, Heidelberg 1995

Lange 2013
Lange, Barbara: Alles autonom. Die Produktion steuert sich selbst. In: iX Heft 7/2013, S. 108 – 114

Lausen 2005,
Lausen, Georg: Datenbanken. Grndlagen und XML-Technologien (1. Auflage). München 2005

Lockemann und Schmidt (Hrsg.) 1987
Lockemann, P.C. und Schmidt, J.W. (Hrsg.): Datenbank-Handbuch. Berlin und Heidelberg 1987 (Springer)

Mertens 2013
Mertens, Peter: Integrierte Informationsverarbeitung 1. Operative Systeme in der Industrie (18. Auflage), Wiesbaden 2013 (Springer Gabler)

MySQL 2014
MySQL 5.1 Referenzhandbuch. Oracle 2014

MySQL 2017
MySQL 5.7 Reference Manual (dev.mysql.com/doc/). Oracle 2017

Nguyen 2018
Nguyen, Kim: NoSQL Languages and Systems. In: [Pivert (Hrsg.) 2018, S. 1 - 20]

Oehler 2000
Oehler, Karsten: OLAP. Grundlagen, Modellierung und betriebswirtschaftliche Lösungen. München und Wien 2000

Ollmert 1992
Ollmert, Hans J.: Datenstrukturen und Datenorganisationen. Oldenbourg Verlag, München, 1992.

Oracle Corp. 2002
Oracle Corp.: Oracle9i. SQL Reference. Release 2 (9.2). Part No. A96540-02. Primary Author: Diana Lorentz. October 2002

Oracle SQL 2013
Oracle SQL Database SQL Language Reference 11g Release 2 (11.2), E41084-02, July 2013

Perkins, Redmond und Wilson 2018 (Buch)
Perkins, Luc; Redmond, Eric; Wilson, Jim R.: Seven Databases in Seven Weeks. A Guide to Modern Databases and the NoSQL Movement (2. Auflage). Raleigh 2018

Perkins, Redmond und Wilson 2018 (E-Book)
Perkins, Luc; Redmond, Eric; Wilson, Jim R.: Seven Databases in Seven Weeks. A Guide to Modern Databases and the NoSQL Movement (2. Auflage). E-Book 2018

Piepmeyer 2011
Piepmeyer, Lothar: Grundkurs Datenbanksysteme. Von den Konzepten bis zur Anwendungsentwicklung. München 2011 (Hanser)

Pivert 2018
Pivert, Olivier (Hrsg.): NoSQL Data Models. Trends and Challenges. London und Hoboken 2018

Plattner und Zeier 2011
Plattner, Hasso und Zeier, Alexander: In-Memory Data Management. An Inflection Point for Enterprise Applications. Berlin, Heidelberg 2011

Saake und Sattler 2014
Saake, Gunter; Sattler, Kai-Uwe: Algorithmen und Datenstrukturen. Eine Einführung mit Java. Heidelberg 2014

Scheer 1997
Scheer, August-Wilhelm: Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse (7. Auflage), Berlin u.a. 1997

Schrempp 2012
Schremp, Mirko (Hrsg.): BigData - Technologiegrundlagen. E-Book 2012 (entwickler.press)

Sellami und Defude 2018
Sellami, Rami und Defude, Bruno: Big Data Integration in Cloud Environments: Requirements, Solutions and Challenges. In: [Pivert (Hrsg.) 2018, S. 93 - 134]

Singh und Ahmad 2021
Singh, Ajit und Ahmad, Sultan: Data Modeling with NoSQL Database (2nd Edition) [E-Book]. Amazon 2021

Staud

Staud 1983
Staud, Josef L.: Internationale Arbeitsteilung und Nationales Lohnniveau. Bedeutung und Rolle entwickelter Ökonomien im Geflecht der Welthandelsbeziehungen. Band I. Frankfurt u.a. 1983 (Peter Lang, 446 Seiten). (Dissertation)

Staud 1985
Staud, Josef L.: Statistische Datenbanken: Beschreibung, Retrieval, Benutzerschnittstellen; in: Deutsche Gesellschaft für Dokumentation (Hrsg.), Deutscher Dokumentartag 1984, München u.a. 1985

Staud 1986a
Staud, Josef L.: Die Welt der Online-Datenbanken. Modellierung, Datenstruktur und Retrievalprozeß; in: Nachrichten für Dokumentation 37. 1986. Nr. 3, S. 139 - 150.

Staud 1986b
Staud, Josef L.: The Universe of Online Databases. Reality and Model(s). Universität Konstanz, Informationswissenschaft, Bericht 4/86, Juli 1986

Staud 1986c
Staud, Josef L.: Typen von Wirtschaftsdatenbanken und Retrievalprozeß; in (Tagungsband): Deutsche Gesellschaft für Dokumentation (Hrsg.), Fachinformation: Methodik - Management - Markt. Neue Entwicklungen, Berufe, Produkte (bearbeitet von Hilde Strohl-Goebel), (Deutscher Dokumentartag 1985, Nürnberg, 1. - 4. 10. 1985), 1986

Staud 1987a
Staud, Josef L.: Factual-Type Online Databases for Humanities and Social Sciences: a Survey, in (Tagungsband): Moberg, Thomas F. (Hrsg.), Databases in the Humanities and Social Sciences 1985, Osprey (Florida) (Paradigm Press), S. 470 - 501. [Tagungsband der "Fifth International Conference on Data Bases in the Humanities and Social Sciences", Grinnel College, Grinell, Iowa, 22. - 24. Juni 1985] 1987

Staud 1987b
Staud, Josef L.: Factual-Type Online-Databases. Downloading and Local Processing of Statistical Data with AREMOS. In: Lehmann, Klaus-Dieter; Strohl-Goebel, Hilde (Hrsg.), "The Application of Microcomputers in Information, Documentation and Libraries", Amsterdam, New York, Oxford et al. 1987 (Proc. of the Second International Conference on the Application of Micro-Computers in Information, Documentation and Libraries, Baden-Baden, 17. - 21. März 1986)

Staud 1987c
Staud, Josef L.: Online Wirtschaftsdatenbanken 1987. Mit einem Verzeichnis von Datenbanken, Anbietern und Produzenten / Online Business Databases 1987. With a Directory of Databases, Hosts and Producers. Bilingual - Zweisprachig. Band I. Frankfurt u.a. 1987 (Verlag Peter Lang, 713 Seiten)

Staud 1987d
Staud, Josef L.: Online Wirtschaftsdatenbanken 1987. Mit einem Verzeichnis von Datenbanken, Anbietern und Produzenten / Online Business Databases 1987. With a Directory of Databases, Hosts and Producers. Bilingual - Zweisprachig. Band II. Frankfurt u.a. 1987 (Verlag Peter Lang, 230 Seiten)

Staud 1987e
Staud, Josef L.: Wirtschaftsdatenbanken 1987. Typen und Themen. in: Deutsche Gesellschaft für Dokumentation e.V. (Hrsg.), 9. Frühjahrstagung der Online-Benutzergruppe der DGD in Frankfurt am Main vom 12. - 14. Mai 1987, Frankfurt 1987

Staud 1989
Staud, Josef L.: Fakten in Öffentlichen Datenbanken: Informationstypen und Strukturmerkmale. in: Nachrichten für Dokumentation 40, Nr. 1, Februar 1989, S. 7 - 14

Staud 1990
Staud, Josef L.: Kapitel D 104 Wirtschaftsinformation. in: Buder, Marianne; Rehfeld, Werner; Seeger, Thomas (Hrsg.), Grundlagen der praktischen Information und Dokumentation. Ein Handbuch zur Einführung in die fachliche Informationsarbeit (zwei Bände), München et al. 1990

Staud 1991a
Staud, Josef L.: Online Datenbanken. Aufbau, Struktur, Abfragen. Bonn u.a. 1991 (Addison-Wesley Publishing Company, 415 Seiten)

Staud 1991b
Staud, Josef L.: Statistische Datenbanken, ihre Anbieter und Produzenten. Ein umfassendes Verzeichnis aller statistischen Daten zu Wirtschaft, Finanzen, Energie, Demographie und vielen anderen Themenbereich in Online-Datenbanken, auf Cd-ROMs, Disketten, usw. Frankfurt u.a. 1991 (Verlag Peter Lang, 594 Seiten)

Staud 1993
Staud, Josef L.: Fachinformation Online. Ein Überblick über Online-Datenbanken unter besonderer Berücksichtigung von Wirtschaftsinformationen. Berlin u.a. 1993 (Springer-Verlag, 550 Seiten)

Staud 2010a
Staud, Josef: Unternehmensmodellierung - Objektorientierte Theorie und Praxis mit UML 2.0. Berlin u.a. 2010 (Springer-Verlag)

Staud 2019
Staud, Josef: Unternehmensmodellierung – Objektorientierte Theorie und Praxis mit UML 2.5. (2. Auflage). Berlin u.a. 2019 (Springer Gabler)

Staud 2021
Staud, Josef Ludwig: Relationale Datenbanken. Grundlagen, Modellierung, Speicherung, Alternativen. 2. Auflage 2021. Verlag tredition GmbH,
Paperback: 978-3-347-35883-6
Hardcover: 978-3-347-35884-3
E-Book: 978-3-347-35885-0

Theis 2014
Theis, Thomas: Einstieg in PHP 5.6 und MySQL 5.6 (10. Auflage). Bonn 2014 (Galileo Press)

Trelle 2014
Trelle, Tobias: MongoDB. Der praktische Einstieg. Heidelberg 2014

Wartala 2012
Wartala, Ramon: Hadoop. Zuverlässige, verteilte und skalierbare Big-Data-Anwendungen. München 2012 (Open Source Press)

Welkenbach und Schmutz 2012
Welkenbach, Peter und Schmutz, Guido: Relationale, NoSQL- und NewSQL-Datenbanken. In [Schrempp 2012 (E-Book)]

Wiederhold 1980
Wiederhold, Gio: Datenbanken. Analyse - Design - Erfahrungen. Band 1 Dateisysteme. München und Wien 1980

Wolff, Hunger, Spichale und George 2013
Wolff, Eberhard; Hunger, Michael; Sichale, Kai und George, Lars : NoSQL-Überblick. Neo4j, Apache Cassandra und HBase. E-Book 2013 (entwickler.press)

Wolff, Nitschinger und Trelle 2014
Wolff, Eberhard; Nitschinger, Michael und Trelle, Tobias: NoSQL-Überblick. Couchbase, Riak, MongoDB E-Book 2014 (entwickler.press)