Zeitgemäße Produktkommunikation im heutigen Internet Wir leben in exponentiellen Zeiten. Cisco prognostiziert für 2016 einen Anstieg des weltweiten Internetverkehrs auf 1,3 Zettabyte. Zur kurzen Erklärung: Ein Zettabyte sind 1000 Exabytes und ein Exabyte (1018) sind eine Milliarde Gigabytes. 2006 lag die Menge der weltweit gespeicherten Daten noch bei 161 Exabytes – 2010 waren es schon 988 Exabytes. Die zunehmende Abhängigkeit der Daten durch Vernetzung und die steigende Komplexität geht einher mit der exponentiellen Zunahme der zu verwaltenden Datenmengen. Beim Thema Produktkommunikation bedeutet dies konkret, dass aufgrund der steigenden Anforderungen der Kunden, weltweitem Konkurrenzdruck und der immer kürzer werdenden Produkt-Lifecycles umfangreicher und zugleich schneller kommuniziert werden muss, um über die eigenen Mehrwerte zu informieren. Parallel dazu haben sich die Marketing-Channels, die konsistent bedient werden müssen, erweitert.
Sollen nun mit differenzierten Produkt-Portfolios länder- sowie marktspezifisch Kunden zielgruppengerecht und in der jeweils gesprochenen Sprache erreichet werden, wird schnell klar, warum die Datenmengen in einer Kettenreaktion exorbitant zunehmen. Durch Trends und Entwicklungen, soziale Netzwerke, das semantische Web (Web 3.0) und die dafür nötigen offenen und standardisierten Schnittstellen für verschiedenste Systeme, entstehen zudem stetig wechselnde Anforderungen – sowohl an die Skalierbarkeit der Datenmodelle, als auch an deren Leistungsfähigkeit. Gerade in den letzten Jahren hat sich viel im Internet verändert. Mit den steigenden Anforderungen erkennen wir nun, dass die ausschließliche Verwendung von relationalen Datenbanken weitreichende Probleme verursachen und trotz gewisser vorteilhafter Eigenschaften in bestimmten Bereichen einen „Flaschenhals“ darstellen sowie Erweiterungsmöglichkeiten technisch begrenzen. Seit ca. 2007 hört man genau aus diesen Gründen immer wieder ein Schlagwort: NoSQL. Sie als Leser schreiben garantiert jeden Tag Daten in NoSQL-Datenbanken oder lesen Daten aus diesen Datenbanken – Google, Facebook, Amazon, LinkedIn, twitter und sones sind – zumindest für Nichtprogrammierer – die bekanntesten Entwickler und Förderer im Bereich NoSQL. Aber wie ist NoSQL zu verstehen und was ist der Vorteil und der Nutzen im Vergleich zu relationalen Datenbanken?
Relationales und die Theorie komplexer Systeme: Relational bedeutet in der Theorie von komplexen Systemen eine Mehrzahl miteinander vernetzter und interagierender Entitäten. Diese Geflechte bilden dann Muster, Strukturen und Funktionen nach einem fixen Schema. Genauso funktionieren relationale Datenbanken, welche seit den 80er Jahren von den meisten Applikationen benutzt werden. Werden nun Daten hinzu geschrieben, Daten entfernt oder verbunden, verändern sich viele Informationen und Gegebenheiten an vielen Stellen innerhalb dieser Geflechte. Dies passiert nach dem fixen Schema der grundsätzlich definierten Tabellen und Strukturen. Dadurch wird z.B. die Konsistenz der Daten permanent gesichert und alles funktioniert in diesem festgelegten Rahmen stets der Reihe nach. Die Daten werden normalisiert. Aber auch wenn Daten abgerufen werden, sind dies Zugriffe, die stets einer definierten Logik und Indexierung folgen. Transienz vs. Persistenz: Persistente Daten-Verwaltungsstrukturen sind zwar sehr konsistent, behindern aber – aufgrund der für die Konsistenz erforderliche strikte Struktur und Normalisierung – eine einfache Skalierbarkeit der Daten über mehrere Maschinen. Diese Strukturen können nicht „mal eben“ erweitert und verändert werden, ohne dass dies wiederum Einfluss auf die Such-, Lese- und Schreibzugriffe hätte – oder sogar auf die gesamte Datenstruktur. Die logischen Joint-Operations und Abfragen (Queries) über diese strikten Tabellenvorgaben, welche vorgeben, wie die Daten abgelegt, verändert und gesucht werden müssen, beeinträchtigen wiederum die Performance – besonders bei vielen kleineren Operationen in sehr kurzen Zeiträumen. Sind zum Beispiel schwach modellierte Daten mit stark modellierten Daten in relationalen Datenbankmodellen gleichermaßen vorhanden, ist der Aufwand diese zu suchen, zu lesen und zu schreiben stets gleich groß. Aber auch lückenhafte Informationen werden in relationalen Datenbanken umständlich abgefragt. Diese ergeben dann zum Beispiel Nullergebnisse. Das ist allerdings erst zu erkennen, nachdem über alle Datenbankstrukturen und Tabellen aufwändig gesucht wurde. Diesen Effekt hat garantiert jeder schon erlebt, wenn eine Applikation mitunter minutenlang über Datensätze sucht, um dann letztendlich festzustellen, dass nichts an gesuchter Information vorhanden ist. Gerade bei der Produktrecherche wird dies für den potentiellen Kunden im Online–Katalog eines Herstellers schnell zu einem Geduld-Spiel. Es besteht also das Problem, die Konsistenz, die Verfügbarkeit und die Skalierbarkeit gleichzeitig zu vereinen: das sogenannte CAP-Theorem. Dieses besagt, dass man jeweils nur zwei der drei gegensätzlichen Anforderungen erreichen kann. Das alles bedeutet natürlich nicht, dass relationale Datenbankmodelle ihre Daseinsberechtigung verlieren. Vielmehr geht es darum, die verschiedenen Modelle den Anforderungen entsprechend einzusetzen und zu verbinden. Dies gilt auch bei NoSQL-Datenbank-Modellen. NoSQL ist kein Begriff für ein einziges Datenbankmodell, sondern ein Begriff für eine ganze Modell-Gruppe. Voraussetzung ist jedoch immer, dass keine SQL-basierte Abfragesprache benutzt wird, weil es eben nicht durch die Art der Datenstruktur erforderlich ist. Keine „Bürokratie“ beim Datenmanagement: Es gibt bei NoSQL keine „bürokratische“ Indexierung, keine Tabellen mit Zeilen und Spalten, abhängige Strukturen und langwierige, strikte Verfahren zur Sortierung und Kategorisierung. Die Informationen werden – wenn man so will – nicht fein säuberlich, sondern völlig frei und lose abgelegt – dafür aber vielfach und an verschiedenen Orten. Diese halten sich gegenseitig selbst auf den neuesten Stand, wenn sich an anderer Stelle etwas geändert hat. NoSQL bedeutet immer hochspezialisierte Lösungen – speziell zugeschnitten auf das jeweilige Anforderungsgebiet. Vergleichbar ist dies vielleicht mit einem unaufgeräumten „Schreibtisch-Chaos“, in dem sich nur der jeweilige Besitzer auskennt. Dafür findet der Benutzer sofort die entsprechenden Informationen – und der Griff erfolgt stets in die Richtung, wo die jeweilige Information am nächsten liegt und am unkompliziertesten zu erreichen ist. Würde jemand anderes diesen Schreibtisch aufräumen oder in eine strikte Ablage-Struktur zwängen, würde nichts mehr funktionieren. Ein weiteres Beispiel ist eine schnell angelegte Mindmap-Zeichnung, die nur der Besitzer versteht, der sie selbst angelegt hat. Während andere Gesprächsteilnehmer ganze Abhandlungen als Gesprächsprotokolle schreiben müssen und das Notizpapier knapp wird, entsteht diese Mindmap in wenigen Sekunden. Der Verfasser des Gesprächsprotokolls muss meist sein gesamtes Gesprächsprotokoll durchlesen, um eine einzige wichtige Information im ganzen Text wieder zu finden. Der Mindmap-Verfasser benötigt jedoch nur einen Blick auf seine Mindmap, um selbst komplizierteste Notizen, Vorgänge und Abhängigkeiten schnell wieder abzurufen. Not only SQL: Die Mischung macht´s: Für die Produktkommunikation bedeutet dies, dass Zentralität, Transaktionssicherheit, Persistenz, Konsistenz und Medienneutralität der Informationen beim Produkt-Informations-Management durch PIM-Systeme gewährleistet wird, welche für diese Aufgabe per Definition prädestiniert sind. Um die Hauptanforderung der Daten-Persistenz zu gewährleisten, basieren diese Systeme daher auf relationalen Datenbankmodellen. Bei der Kommunikation dieser Daten im Internet liegt der Fokus jedoch auf der Hochverfügbarkeit der Daten und nicht hauptsächlich auf Persistenz. Auch unter der Last von vielen kleinen Lese- und Schreibzugriffen müssen die Informationen agil und hochverfügbar kommuniziert werden. Dies wird zum einen durch die schnelleren, unkomplizierteren Abfragen erzielt und zum anderen durch die einfache Skalierbarkeit und der gewollten Dezentralität der Informationen. Durch Dezentralität und Transienz wird dann der nötige Grad an Daten-Persistenz erreicht. NoSQL bedeutet also nicht die generelle Ablösung von relationalen Datenbankmodellen, sondern ist eine notwendige Entwicklungsstufe, um nicht nur heutige, sondern auch zukünftige Anforderungen proaktiv zu begegnen. Und auch bei dem Oberbegriff NoSQL verbergen sich unterschiedliche Submodelle. Oberbegriff NoSQL und die 4 Submodelle: – Key-Value stores: – Alle Informationen werden als „Schlüssel“ und „Wert“ Paare global gespeichert. Die Position eines Wertes wird über den Schlüssel gefunden. Die Ablage kann man sich als zweispaltige Tabelle vorstellen – in einer Spalte die Keys und in der anderen die passenden Werte. Informationen können so hochperformant abgelegt und wieder aufgerufen werden. Der Focus liegt auf hohe Performance, gute Skalierbarkeit und große Datenmengen. Gewisser Nachteil: Bei komplizierten Abfragen können die zusammengesetzten Abfrageschlüssel (Key-Arrays und Key-Sequenzen) zunehmend unübersichtlich werden. DB Beispiele: Voldemort, Dynomite, (basierend auf dynamo paper von Amazon) – Dokumentendatenbank – Kollektionen und Kombinationen aus Key-Value in Dokumenten. Die Datenbank selbst kennt die nötigen Keys. Keys und Key-Sequenzen bzw. Values wurden anfänglich in XML – später dann in JSON-Dokumenten gespeichert. DB Beispiel: Lotus Notes – BigTable Datenbank Klone – Basierend auf Google´s Hochleistungs-Datenbanksystem. Tabellen sind ähnlich, wie bei Kollumnen-orientierten relationalen Datenbanken. Beim mehrdimensionalem BigTable Konzept können Spalten und Zeilen in Tabellen jedoch unterschiedlich groß sein und dadurch theoretisch unendlich wachsen. Die Struktur bietet sich besonders an, wenn häufig Daten hinzukommen und selten geändert werden. DB Beispiele: cassandra, Hypertable oder HBase – Graphendatenbank – Basierend auf Facebook OpenGraph. Datenbankmodell als große, vernetzte Struktur bestehend aus Knotenpunkten und Verbindungen (Relationen) untereinander. Datenknoten, sowie die Verbindungen besitzen wiederum Key-Value Eigenschaften. Relationen zwischen zwei Daten-Knoten können sowohl nur in eine Richtung als auch in beide Richtungen verlaufen und Reflexionen beinhalten (Semantik). Knotenpunkt „A“ = Name: „Tom“ Beispiel Reflexion: „A“ lebt mit „B“ ( In diesem Fall ist es logisch, dass „B“ auch mit „A“ zusammen lebt) Beispiel Relation : „A“ liebt „B“, „B“ liebt „C“ ( von Knoten „B“ geht eine Verbindung in Richtung „C“ ) DB Beispiel: Facebook-Datenbank für Freunde und Timeline
