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" xxx(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 xxx(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.

Leidensdruckxxx

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 2³² (etwas über vier Milliarden) IP-Adressen, das neue IPv6 erlaubt 2¹²⁸ (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 xxxausgebaut 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.

xxxERP-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: xxx

• 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. xxx
• Faktendaten aus dem Social Web. Die hier entstehenden Informationen beruhen auf Dokumenten. xxx
• Andere sog. unstrukturierte Daten.

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

2 NoSQL - 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]

xxxBedeutung 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 xxx 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 (vgl. Abschnitt xxx) .

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].xxx
• 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 et al. 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.xxx

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.xxx
• 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. Xxx
• 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.xxx

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.xxx

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ändexxx) 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

xxxNguyen 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. 8xxx]

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[3] (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 xxx[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 [xxxWartala 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 [xxxWartala 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 (vgl. xxx) 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 Programmierungxxx 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 et al. 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.

xxxAuch 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.