Big Data Technologien – ein Überblick für Einsteiger

(Last Updated On: 24. Mai 2018)

Big Data bietet Chancen für Unternehmen, so viel ist bekannt. Unternehmen haben ein großes Interesse daran, neue wirtschaftliche und gesellschaftliche Trends zeitnah vorher sagen können. Dies dient nicht nur zur Ergreifung von Chancen, sondern auch zur Behandlung von Risiken. Um die dazu notwendigen Analysen fahren zu können, bedarf es einer großen Menge an Informationen. Dazu werden Daten aus verschiedenen Quellen analysiert, die einen Indikator dafür bieten könnten, welche Waren und Dienstleistungen die Kunden in Zukunft erwarten, und welche Markteinstellung (kauffreudig oder kaufscheu) sie in nächster Zeit einnehmen werden.

Die Daten werden häufig von den potentiellen Kunden selbst bereit gestellt. Häufig findet man interessante zu analysierende Daten in Social Media Netzwerken, über Support Anfragen im lokalen Ticket System des Unternehmens,  E-Mails, oder aber auch digitalisierte Briefpost. Neben diesen Daten sind beispielsweise aktuelle Nachrichtenmeldungen, Veröffentlichungen von Marktforschungsinstituten, aber auch Live-Daten von den Sensoren von Maschinen, Smart Devices und IoT Things heran zu ziehen. Vergessen Sie außerdem nicht Daten, die sich bei Ihnen bereits in Archiven befinden. Diese können für Analysen noch einmal wertvoll sein.

In diesem Beitrag schildere ich kurz die Kernherausforderungen von Big Data Szenarien und biete im Anschluss einen Deep Dive in die wichtigsten Technologien und Denkansätze in der Architektur von Big Data Landschaften.

Contents

Die Herausforderungen von Big Data

Grundsätzlich muss man bei der Gestaltung einer Big Data Architektur zwischen fünf großen Herausforderungen unterscheiden, die als die 5 V’s beschrieben werden

  • Volume. Referenziert auf die schiere Menge an Daten, die heutzutage anfallen. Wir haben weiter oben schon zahlreiche Quellen für solche Daten aufgezählt. Heute erzeugen wir jede Minute so viele Daten, wie in den Jahren bis 2000 insgesamt erzeugt wurden. Das Hauptproblem hierbei ist die Skalierbarkeit der Lösung. Ich als Unternehmer möchte wissen, dass ich jederzeit dazu in der Lage bin, alle anfallenden Daten zu speichern und zu verarbeiten. Das heißt, meine Infrastruktur muss mit meinem Datenaufkommen mit wachsen. Problematisch wird das, wenn dieser Bedarf über nacht auf kommt, weil beispielsweise eine Produkt-Werbung viral geht oder einem Startup ein Durchbruch gelingt.
  • Velocity. Verweist auf die Geschwindigkeit, mit der neue Daten generiert werden und mit der sich Daten bewegen können. So werden beispielsweise viele Suchmaschinenanfragen innerhalb kurzer Zeit gestellt. Diese müssen alle bedient werden. Zahlreiche Daten sollen außerdem in Echtzeit analysiert werden, da sie ansonsten ihre Relevanz verlieren. Flaschenhälse können verschiedener Art sein. Allein die Lesegeschwindigkeit von Daten stellt ein Problem dar. Denn die Menge an Daten steigt in einem Enterprise exponentiell, während die Lesegeschwindigkeit der Datenträger nur einen linearen Anstieg verzeichnen kann. Je größer also ihre Datenmenge, desto mehr Probleme bekommen Sie beim Versuch, all diese Daten, oder einen relativen Wert davon, zu lesen.
  • Variety. Adressiert die unterschiedlichen Formen, in denen Daten heute vorliegen. Volltextdateien wie Dokumente oder Logs, unstrukturierte Binärdateien wie Video, Audio und Bild, semi-strukturierte Daten in Form von bspw. Key/Value-Paaren, JSON- oder XML-Dokumenten oder klassische relationale SQL-Datenbanken. Alles kommt zusammen in einem großen Big Data Szenario.
  • Veracity. Fokussiert den Blick auf die „Unreinheit“ von Daten. Dies kann aus zwei Gründen der Fall sein. Zum einen werden heutzutage durch Botnetze und Hoax-Meldungen die Vertrauenswürdigkeit von Social Media Postings und Hashtags in Frage gestellt. Stammen die Inhalte aus Social Media wirklich generisch aus den Händen zahlreicher Menschen, oder steckt ein großes Botnetz dahinter? Zum Anderen führen statistische Ausreißer dazu, dass bei der Analyse von Daten falsche Annahmen getroffen werden. Ein einfaches Beispiel: Sie möchten analysieren, wie viel Umsatz Sie im Durchschnitt pro Monat machen. Je nach Branche wäre es äußerst unklug, einfach so einen Durchschnitt über 12 Monate zu bilden, da das Weihnachtsgeschäft ein krasser Ausreißer ist. Wenn Sie nun beispielsweise auf Basis dieses Durchschnittswertes festlegen würden, wie viele Waren Sie im Monat vor halten müssen, endet das damit, dass Sie 11 Monate im Jahr viel zu viel im Lager haben, was gebundenes Kapital und somit verpasste Marktchancen bedeutet. Sie müssen Daten vor der Analyse also mitunter „vor-analysieren“ und Segmente bilden. Daten müssen also vor einer eigentlichen Analyse gereinigt werden (Data Cleansing). Firmen, die früher nur Software einem Qualitäts-Test unterzogen haben, führen nun auch immer mehr QA-Tests auf ihren Datenbestand durch.
  • Value. Zeigt das Problem auf, dass Daten möglichst schnell in Wert transformiert werden müssen. Daten, die gespeichert werden, ohne dass man einen Wert aus ihnen gewinnt, verursachen unnötige Kosten. Das Problem dabei ist jedoch auch, dass Sie heute nicht sagen können, was Daten, die Ihnen heute als unnütz erscheinen, in 5 Jahren vielleicht wert sein können. Eine gängige Aussage in Zusammenhang mit Big Data ist auch: „es ist günstiger, alles zu behalten, als mühsam zu entscheiden, was davon man weg werfen kann.“

Wie speichere ich meine Daten in den Quellsystemen?

Bevor ich mir die Frage stellen kann, wie ich an die Daten, die ich analysieren will, heran komme, muss man sich als IT-Architekt die Frage stellen, wie die Daten in den Quellsystemen gespeichert werden sollen. Denn die Daten müssen zur Analyse zugreifbar sein. Die beiden wichtigsten Kriterien hierbei sind die Verfügbarkeit und die Performance. Doch können weitere Anforderungen wie beispielsweise die Revisionssicherheit der Daten wichtig sein.

Anreicherung der Daten

Bei der Anreicherung der Daten in den Quellsystemen versucht man bereits hier, die Auffindbarkeit und den Wert der Daten zu erhöhen. Ein typisches Beispiel ist die Anreicherung der Daten mit Tag Clouds und

Wie komme ich an die Daten?

der Herausforderung, an die Daten zu kommen und Datenquellen anzuzapfen. So werden beispielsweise Veröffentlichungen von Marktforschungsinstitution oder Online-Nachrichtenmeldungen über REST-APIs oder Webcrawler abgetastet. Social Media Daten lassen sich durch WebCrawler oder durch abtasten von RSS-Feeds abtasten. Daten aus dem Support Portal des Unternehmens lassen sich oft direkt aus der darunter liegenden SQL-Datenbank entnehmen. Enterprises haben häufig auch ein verteiltes Unternehmensnetz. Die Daten müssen also aus unterschiedlichen Standorten abgeholt werden.

E-Mails müssen häufig aus Datenbanken, Archiven oder Dateisystemen entnommen werden. Noch schwieriger wird es bei Briefpost, da diese zuvor digitalisiert werden muss. Wenn das Dokument auch noch durchsuchbar sein soll, mittels OCR. Weitere interessante Text-Dokumente sind beispielsweise Logs, SMS/MMS oder Text, der in Blockchains oder auf Dateisystemen gespeichert ist. Auch dieser Text muss geparst und analysiert werden.

Damit hört es aber noch nicht auf. Unter Umständen ist es für ein Unternehmen etwa interessant, die Sprache in der Audiospur von Videos als Untertitel in Textform zu extrahieren, und anschließend Analysen auf diese Daten auszuführen. Somit ließe sich beispielsweise analysieren, wie oft ein bestimmtes Buzzword in letzter Zeit auf einem Video-Portal genannt wird. Eine entsprechende Einwilligung der Gegenpartei vorausgesetzt, könnten Sie dieses Szenario sogar auf aufgenommene Anrufe in einem Call Center oder auf Text To Speech Suchanfragen ausweiten. Sie merken ja, auch ich als Blogger komme ohne Buzzwords nicht aus, denn ich will ja gefunden werden. Ich würde dann klassischerweise SEO-Tools über eine API und Suchmaschinen wie Google anzapfen.

Aber auch von Barcode-Scannern, Magnetlesern oder RFID-Empfängern kommen Daten herein beispielsweise im Lager oder bei der Zeiterfassung. Zu guter letzt hätten wir dann noch die Datenentnahme aus Sensoren von Things in verteilten Netzen bzw. in der Cloud. Das wichtigste Buzzword in diesem Bereich ist das der Source Data Automation. Dahinter verbirgt sich die Digitalisierung und die möglichst automatische Verarbeitung von Daten am Punkt ihrer Entstehung. Auf keinen Fall sollte es notwendig sein, Daten einzugeben, die bereits an anderer Stelle erhoben worden sind. Ein typisches Beispiel ist das Abschreiben von Daten, die bereits ausgedruckt auf einem Blatt Papier stehen. Analoge Datenformen, wie beispielsweise ein Blatt Papier, sollten immer eine schnelle und günstige Möglichkeit bieten, die Daten an anderer Stelle wieder zu digitalisieren, beispielsweise über einen Barcode.

Wie verarbeite ich die Daten vor der Speicherung?

Grundsätzlich unterscheidet man in einem Big Data Szenario zwischen

  • ruhenden Daten, die auf Vorrat in einem persistenten Datenspeicher hinterlegt werden. Die hier vorliegenden Daten werden häufig in einer Stapelverarbeitung (Batch) in regelmäßigen Abständen aggregiert, verarbeitet und am Zielort zur Analyse abgelegt.
  • beweglichen Daten, die in einem konstanten Datenstrom, meist in Echtzeit, analysiert werden. Natürlich kann der Datenstrom zur historischen Betrachtung zusätzlich dauerhaft in einen ruhenden Speicher persistiert werden. Man spricht in diesem Zusammenhang häufig von einer Streamerfassung bzw. Streamverarbeitung von Daten.

Wie speichere ich die Daten vor der Analyse

Gleich vorweg: Nicht alle Daten müssen unbedingt vor der eigentlichen Analyse in einem neuen Zielformat abgespeichert werden. Einige Daten können beispielsweise direkt aus dem Quellsystem entnommen und danach direkt einer Berechnung zugeführt werden. Eine erneute Speicherung von ohnehin schon vorhandenen Daten in einem zentralen analytischen Speicher verursacht schließlich Kosten. Dennoch gibt es Gründe, die für eine entsprechende Speicherung von Daten sprechen, beispielsweise

  • die Performance beim Laden der Daten ist nicht gut genug. Es dauert zu lange, an die Daten zu kommen, oder es ist zu teuer
  • Die Daten aus den Quellsystemen sind nicht verfügbar genug gehalten. Deswegen werden die Daten in eine Lösung überführt, die hochverfügbar und verteilt ist
  • Die Daten aus den Quellsystemen dürfen aus datenschutzrechtlichen Gründen nicht im Original verwendet werden. Die Daten müssen stattdessen pseudonymisiert oder anonymisiert werden, da sie personenbezogenen Daten beinhalten.
  • Die Daten liegen im Quellsystem nicht in einem Format vor, welches sich für die Analyse eignet. Deswegen müssen die Daten in ein geeigneteres Zielformat überführt werden. Wenn beispielsweise das Quellsystem auf einem Event Log wie Apache Kafka beruht, möchten Sie die Daten vorher mitunter in SQL überführen.
  • Es ist bequemer, Daten für eine Analyse von einer zentralen Quelle zu beziehen. Vorsicht: Eine zentrale Quelle heißt nicht, dass die Quelle geografisch nur an einem einzigen Ort existiert. Zenral bedeutet an dieser Stelle nur, dass es „einen Ansprechpartner“ gibt. Die Daten kommen also sozusagen „alle aus ein und dem selben Topf“. In der Praxis nennt man dies häufig einen Data Lake, oder ein Data Warehouse. Den Unterschied zwischen den beiden Begriffen werden wir im Laufe des Beitrages noch deutlich machen. Der Data Lake oder das Data Warehouse kann jedoch de fakto über mehrere Standorte hinweg verteilt sein. Das macht auch Sinn, damit die Daten von überall auf der Welt schnell verfügbar und außerdem ausfallsicher abgelegt sind. Und: Obwohl es nur einen einzigen Ansprechpartner für die Daten gibt, können die Daten trotzdem über mehrere verschiedene Speicher-Technologien verteilt sein. So kann ein Teil der Daten beispielsweise in einer in-Memoery Datenbank abgelegt sein, ein anderer Teil in einer Graph-Datenbank wie Neo4j, ein anderer wiederum in Apache Hadoop und ein anderer in einer spaltenorientierten Datenbank, die als Near-Line-Storage fungiert.

Wie lese und verarbeite ich die Daten vor der Analyse?

Die Daten, welche nun an einem zentralen Data Warehouse oder Data Lake abgelegt werden, müssen nun analysiert werden, um Business Insights und damit Mehrwerte aus diesen Daten zu gewinnen. Hierfür gibt es unterschiedliche Techniken. Die berühmtesten darunter sind Data Mining und Machine Learning, jedoch können beispielsweise auch andere Techniken wie das Natural Language Processing (NLP) für beispielsweise Video-Untertitel verwendet werden.

Wie analysiere ich die Daten

Die Art und Weise, wie Daten heutzutage analysiert werden, hat sich im Vergleich zu damals verändert. Heute geht es nicht mehr darum, die Antwort auf eine gegebene Frage zu finden. Das ist mit den heute verfügbaren Tools relativ einfach.  Viel wichtiger ist es, die richtigen Fragen zu stellen. Um herauszufinden, welche Fragen ich stellen muss, muss ich mein Konzept, wie ich mit Daten jongliere und sie analysiere, ändern.

Die Analyse der Daten hat aber auch einen naturwissenschaftlichen Charakter. Typischerweise sind die folgenden Fachbereiche der Analyse von Big Data Stämmen involviert

  • Decision Science
  • Pattern Recognition und Machine Learning
  • Natural Language Processing

Man unterscheidet zwischen

  • Descriptive Analytics. „Was ist passiert?“
  • Diagnostic Analytics. „Warum ist es passiert?“
  • Predictive Analytics. „Was wird passieren?“
  • Prescriptive Analytics. „Wie machen wir, dass es passiert?“

 

 

Die wichtigsten Technologien im Zusammenhang mit Big Data

klassische relationale Datenbanken

Damit meine ich die klassischen relatioanlen Datenbanken, wie sie seit Jahrzehnten auf dem Markt sind. Die bekanntesten Vertreter dieser Marke sind beispielsweise MySQL, Oracle, Sybase ASE und Sybase iQ, MS SQL Server, SAP MaxDB u. v. m. Die klasssichen Datenbanken haben auf gar keinen Fall ausgedient. Traditionelle Datenbanken funktionieren nach dem Relationenmodell. Man kann sie klassischerweise in Form von miteinander in Beziehung stehenden Tabellen darstellen. Grundsätzlich unterscheidet man zwei Arten von relationalen Datenbanken

 

Zeilenorientierte und spaltenorientierte Datenbanken – der Unterschied

Zeilenorientierte Datenbanken sind die am häufigsten verbreitete Gattung der relationalen Datenbanken. Legen wir beispielsweise die folgende Tabelle „Mitarbeiter“ zu Grunde

PersonalnummerNameVornameGeburtsdatumFamilienstand
1034691LoiblAndreas21.08.89ledig
1034692MüllerMax01.04.76verheiratet

Eine zeilenorientierte Dateenabnk speichert die Einträge so, wie man sie hier auch sieht

1034691;Loibl;Andreas;21.08.89;ledig

1034692;Müller;Max;01.04.76;verheiratet

Warum das wichtig ist, erfahren wir, wenn wir uns im Vergleich jetzt die spaltenorientierten  Datenbanken ansehen

Eine spaltenorientierte Datenabnk würde diese beiden Datensätze folgendermaßen abspeichern

1034691;1034692;

Loibl;Müller

Andreas;Max

21.08.89;01.04.76

ledig;verheiratet

Erkennen Sie den Unterschied? Bei der zeilenorientierten Datenbank ist eine Zeile in der Tabelle auch eine Zeile in der Speicherstruktur. Bei einer spaltenroeintierten Datenabnk entspricht eine Spalte der Tabelle  einer Zeile in der Speicherstruktur.

Wie viele Zeilen in der Speicherstruktur müssen gelesen werden, wenn wir den gesamten Datensatz für den Mitarbeiter Andreas Loibl ausgeben wollen? Bei der zeilenorientierten Datenbank muss nur eine Zeile gelesen werden, bei der spaltenorientierten Datenbank hingegen sämtliche Zeilen. Sie können sich also vorstellen, dass die Abfrage

„SELECT * FROM mitarbeiter WHERE name=’loibl'“

Auf der zeilenorientierten Datenbank wesentlich schneller von statten geht

Wie sieht es nun aus, wenn wir alle Nachnamen ausgeben wollen? auf der zeilenorientierten Datenbank müssen in diesem Fall alle Zeilen gelesen werden, bei der spaltenorientierten Datenbank hingegen nur eine. Die Abfrage

„SELECT name FROM mitarbeiter“

ist also auf einer spaltenorientierten Datenbank wesentlich schneller.

Wie sieht es nun mit der Komprimierung aus? Nun, nehmen wir mal an, in der Tabelle mitarbeiter gibt es 10 Mitarbeiter mit em Familientsand ledig und 20 Mitarbeiter mit dem Familienstand verheiratet. Sagen wir mal, die Speihcerstruktur sieht so aus

Andreas;Martin;Mario;MAx;Robert;Axel;Alex;Oliver;Jan;Sascha

….

ledig;ledig;verheiratet;verheiratet;verheiratet;ledig;verheiratet;verheiratet;ledig

 

dann könnte ich die letzte Zeile vereinfachen durch

ledigx2;verheiratetx3;ledig;verheiratetx2;ledig

Und das ist nur ein sehr simples Beispiel dafür, dass spaltenorientierte Datenbanken in der Regel einfacher zu komprimieren sind. Das heißt, in der Regel bekomme ich in eine spaltenorientierte Datenbank bei gleichem Speicherplatz mehr Daten unter.

Einen Nachteil hat die Starke Kompression jedoch. Jedes mal, wenn ich in die Tabelle einen neuen Datensatz einfügen oder einen bestehenden Datensatz ändern möchte, muss ich die Tabelle erst dekomprimieren, die Änderung vornehmen, und dann neu komprimieren.

Um es kurz zu sagen:

  • zeilenorientierte Datenbanken sind schneller beim Einfügen neuer Datensätze in eine Tabelle und bei allen Arten von SELECT *  Statements
  • spaltenorientierte Datenbanken sind schneller bei SELECT <spalte>-Statements
  • spaltenorientierte Datenbanken benötigen in der Regel weniger Speicherplatz als zeilenorientierte datenbanken, da sie besser komprimiert werden können

Aus diesem Grund verwendet man zeilenorientierte datenbanken bevorzugt für Anwendungen, die bei denen viele neue Daten eingepflegt werden und bei denen häufig ganze Datensätze angezeigt werden. Um es einfacher zu sagen: Zeilenorieniterte Datenbanken eignen sich besser für Systeme, in denen Dinge verwaltet werden, die einen physikalischen oder geldbezogenen Wert haben. Diese Systeme werden gruppiert als Online Tranasctional Processing (OLTP)-Systeme bezeichnet. Datenbanken, welche für diese Art von Daten genutzt werden, nennt man acuh Operational Data Store (ODS). Darunter fallen beispielsweise ERP-Systeme, CRM-Systeme, und die meisten typischen Desktop-Softwaresysteme.

Spaltenorientierte Datenbanken verwendet man hingegen gerne bei analytischen Anwendungen, wie etwa Business Intelligence Software. Um es einfacher zu sagen: Spaltenorientierte Datenbanken eignen sich besser zur Verwaltung von Dingen, die einen intellektuellen Wert haben – also Analysen, Statistiken, wissenschaftliche Texte usw. Denn diese setzen sehr häufig gefilterte Abfragen ein, bei denen nur bestimmte Spalten eines Datensatzes abgefragt werden.

NoSQL Datenbanken

NoSQL steht für Not Only SQL. DAvon gibt es verschiedene Arten. Gemeinsam haben sie erst einmal alle, dass sie in der Regel keine festen Strukturen mehr benötigen. Das heißt sie wenden keine Constraints auf die Daten an, die in diese Datenbanken geschrieben werden. Das Konzept habe ich auch schon einmal in diesem Beitrag beschrieben. Somit ist es einfacher, die Daten zu speichern, weil sie keine constraints erüfllen, sondern die Daten nur in eine gorbe Struktur wie etwa JSON bringen müssen.

NoSQL-Datenbanken speichern Daten also semistrukturiert. Die Art und Weise, wie diese Datenbanken das tun, entscheidet über die Art der noSQL-Datenbank. Die verschiedenen Arten werden wir später noch kennn lernen. Die meisten NoSQL-DAtenabnken sind außerdem gleichzeitig MPP-Datenbanken. Der Hauptvorteil von NoSQL-Datenbanken ist, dass sie super skalieren. Das bedeutet, mit einer NoSQL-Datenbank is tes sehr einfach, Scale-Out zu betreiben.

NoSQL-DAtenbanekn werden gegenüber traditionellen SQL-Datenbanken gerne eingesetzt, wenn man große Datenmengen aprallel schreiben und lesen möchte. Traditionelle SQl-DAtenabnken können immer entweder das eine oder das andere gut (siehe den Vergleich von OLTP gegen OLAP-Datenbanken weiter oben), aber nicht beides.

Welche Art von Daten sind für noSQL-Datenbanken geeignet? Genrell kann man sagen:

  • statische transaktionale Daten, nur einmal geschrieben werden und sich nicht häufig ändern. NoSQL-Datenbanken sind, bis auf einige Ausnahmen, nicht wirklich dafür geeignet, Daten immer wieder zu ändern, da sie meistens nicht ACID-compliant sind. es gibt Ausnahmen so ist beispielsweise die Graphen-Datenbank neo4j auch für sich häufig ändernde Daten geeignet.
  • Datensätze die in großen Mengen geschrieben werden (nicht aggregierte Daten). Da noSQL-Datenbanken keine Datenbanksperren (zumindest die meisten) haben und keine Constraints auf Daten anwenden müssen, schreiben sie neue DAtensätze wesentlich schneller als klassische SQL-Datenabnken. Zudem müssen viele noSQL-Datenbanken nicht jedes mal den Index komplett umschreiben und neu aufbauen, wenn neue Datensätze eingefügt werden.
  • Es gibt Ausnahmen. So eignen sich beispielsweise spaltenorientierte NoSQL-Datenabnken wie HBase weniger für transaktionale DAten, dafür eher für vordefinierte Abfragen auf analytische Daten.
  • in Umgebungen, in denen sich das Schema von Daten ändern kann. wenn Sie in der klassischen SQL-Welt für eine Tabelle ein Attribut hinzufügen wollen und Ihre Tabelle hat 1 Millionen Einträge, wird es zu einer Behemoth-aufgabe. Denn die Datenbank muss durch jeden einzelnen DAtensatz der Tabelle durchgehen, an diesen die neue Spalte anhängen, und am Schluss evtl. die Datenbankstatistiken und die Indizes umschreiben. in noSQL gibt es kein Schema, das heißt ein neues Attribut hinzuzufügen ist sehr einfach und Sie können die Arbeit aufteilen – Sie müssen nicht wie bei SQL ein riesen großes ALTER TABLE-Statement auf einmal ausführen. Sie können gleich afnangen, neue Datensätze mit dem neuen Attribut zu schreiben, und die alten Datensätze Schritt für Schritt umziehen, indem Sie denen einfach das Attribut verpassen. Sie können das Attribut aber auch ganz weg lassen, wenn Sie es bei den alten DAtensätzen nicht brauchen. Nichts hindert Sie daran, da keine Constraints angewendet werden.
  • noSQL Datenbanken sind einfacher zu skaliren als klassische SQL-Datenabanken.

Wenn man von einer traditionellen SQL-Datenbanke auf eine noSQL-Datenbank wechselt, gibt man in der Regel folgende Dinge auf

  • Datenintegrität. DA nun keine Constraints mehr auf die zu speichernden Daten angewendet werden, ist die Struktur der Daten nicht mehr garantiert. Jeder Datensatz kann eine andere Struktur haben.
  • Datenkonsistenz. noSQL-Datenbanken sind in der Regel nicht ACID-, sondern BASE-complaint. Was das heißt, lernen wir weiter unten. Es gibt natürlich Ausnahmen. so ist beispielsweise die Graph-DAtenbank neo4j ACID-compliant und damit beispielsweise auch für sich häufig ändernde Daten geeignet, die hohe Anforderungen an die Datenkonsistenz stellen.

Das CAP-Theorem

Die Einführung von NoSQL-Datenbanken ist perfekt, um das CAP-Theorem anzusprechen. Das CAP-Theorem besagt, dass ebei einer Datenbank die folgenden drei Features wichtig sind,

  • Consistency
  • Availability
  • Partition Tolerance

jedoch immer nur zwei dieser Features mit einer Datenbank erreicht werden können. Wir können also niemals alle drei Features mit einem mal haben. Das heißt, es gibt drei Arten von Datenbanken nach dem CAP-Theorem

  • CA (availability + Consistency). Dies sind traditionelle RDBMS wie beispielsweise Oracle, SAP Sybase ASE usw. Aber auch einige Graph-Datenbanken wie Neo4j sowie der in-memory key/value store redis zählen in diese Kategorie. CA-Systeme sind Single-Site-Cluster, d. h. alle Knoten in einem Scale-Out Cluster müssen immer miteinander in Verbindung stehen. Wenn die Verbindung zwischen den Scale-Out-Knoten abbricht, blockiert das System. CA-Systeme sind in der regel ACID-compliant
  • AP (Availability + Partition Tolerance). Beispielsweise CouchDb, Cassandra, DynamoDB, Riak. Im Gegensatz zu CA-Systemen steht das System auch dann noch zur Verfügung, wenn einige Shards down gehen. Nachteil: einige der daten, die zurückgeliefert werden, sind mitunter nicht richtig / konsistent. AP-Systeme sind in der regel BASE-compliant.
  • CP (Consistency + Partition Tolerance). Hierunter fallen beipsielswiese MongoDB, HBase . CP heißt, einige daten sind eventuell aktuell nicht erreichbar, aber die anderen Daten sind konsistent und auf diese können auch Transaktionen und Lesezugriffe erfolgen.

Um nun zu verstehen, wann  welche Art von Datenbank in Ordnung ist, müssen wir erst die drei Features verstehen.

Consistency

ACID-consistency

Das Non-Plus-Ultra an Consistency wird erreicht, wenn eine Datenabnk ACID-Compliant ist.

Eine wesentliche Schwäceh der meisten NoSQL-DAtenabnekn ist, dass sie nicht ACID-Compliant sind. Sie basieren auf dem Prinzip der „eventual Consistency“ oder BASE-compliant. Das bedeutet einfach gesagt, dass merhere Leute, welche die selben Daten abrufen, mitunter verschiedene Ergebnisse sehen können. Was heißt das?

Eine ACID-kompatible Datenbank verfügt über verschiedene Funktioanlitäten, die die Konsistenz der in ihr gehaltenen Daten sicher stellen.

  1. Atomicity

Wir nehmen als Beispiel eine Tabelle mitarbeiter, eine Tabelle abteilung und eine tabelle kostenstellen

mitarbeiter
PersonalnummerNameVornameAbteilungs-ID

 

Abteilungen
Abteliungs-IDAbteilungs-Name

 

kostenstellen
Kostenstellen-IDNameAbteilungs-ID

Ein mitarbeiter wird also in unserem modell einer abteilung zugeweisen, und diese Abteilung ist mit einer lkostnestelle verbunden.

Nehmen wir an, sie nehmen nun eine Änderung vor, in welcher sie beispielsweise die ID einer Abteilung verändern. Dies erfordert, dass Sie die zugehörige abteilungs-ID in allen drei Tabellen ändern. technisch sind dies drei UPDATE-Statements. Diese drei Vorgänge werden nun in eine Transaktion gekapselt. Atomicity bezeichnet das Konzept, dass eine Transkation erst dann konsistent abgeschlossen ist, wenn alle drei Transaktionen abgeschlossen sind. Gelingt es biepsielsweise nur, zwei der drei Transkationen auszuführen, weil beispielsweise unterwegs ein Stromausfall die Datenbank lahm legt, wirdbeim Neustart der Datenbank die Transaktion zurückgerollt. Dadurch hat die Datnebank wieder den Ausgangszustand. Sie können sich nämlich vorstellen, dass es für verwirrung sorgen würde, wenn Sie di eabteilungs-ID in der tabelle mitarbeiter und abteilungen ändern würden, die Kostenstelle aber noch auf die alte Abteilungs-ID verweist.

2. Consistency

Consistency steht für das Prinzip, dass die Datenbank beschränkungen auf die Ablage von Daten anwendet, die ein Programmierer durfch seinen Anwendungs-code ncht brechen kann. so ist es beispielsweise einer Anwendung in einer ACId-Datenbank nicht möglich, einen Text in eine Tabellen-Spalte einzufügen, die den Datentyp „Integer“ hat. Einer Anwendung ist es auch nicht möglich, die Rollback-funktoinakität einer datenbank auszuhelben (die wir unter Punkt 1 angesprochen haben).

3. Isolation

das prinzip der isolation behandlt das folgende Problem: Nehmen wir an, zwei mitarbetier arbeiten in der Verkaufs-Abteilung eines Unternehmens. ein Kunde schreibt eine E-Mail und gibt über diesen kommunikationskanal eine Änderung an einem bestehenden Auftrag bekannt. die E-mail wird an eine gemeinsame Adresse geschickt: bestellung@unternehmen.de. Nun passier tes zufälligerwiese, dass beide Mitarbeiter gleichzeitig die Bestellugn des Kunden im Mail-postfach lesen, aber nicht wissen, dass sie gegenseitig die selbe Bestellung bearbeiten wollen. also beginnen nun beide mitarbeiter gleichzeitig, an ein und der selben Bestellung rum zu hantieren. eine Bestellung sieht auf Datenbank-Ebene so aus

Bestellungen
bestellungs-IDKunden-IDArtikel-IDMenge
11110
11220
1135

Wir haben also in dieser tabelle derzeit eine einzige Bestellung vom Kundne mi tder ID 1, die drei Artikel mit unterschiedlichen Mengen umfasst. Der Kunde möchte in seiner E-mail „Die menge von Artikel 2 um 5 reduzieren und die Menge von Artikel 3 um 2“.

welche Probleme können nun auftreten, wenn beide Mitarbeiter gleichzeitig an der selben Bestellung arbeiten?

Dirty read: Der Kunde möchte in seiner E-mail „Die menge von Artikel 2 um 5 reduzieren und die Menge von Artikel 3 um 2„.Mitarbeiter 1 sieht die Bestellung so, wie sie aktuell ist: Mengen 10, 20 und 5. Er gveränder tide Bestellung auf die mengen 10, 15 und 3, wie vom Kunden gewünscht, und schickt ide transaktion ab. Mitarbeiter 2 liest dne aktuellen Stand der bestellung ein, während die Änderungen durchgeführt wrden. Zum Zeitpunkt, wo mitarbeiter 2 die Bestellung an sieht, wurde die erste Änderung von 20 auf 15 bereits durchgeführt, jedoch noch nicht ide zweite Änderung von 5 auf 3. Mitarbeiter 2 bearbeitet die Bestellung jetzt noch einmal, und reduziert die Menge von Artikel 2 von 15 auf 10 und Artikel 3 von 5 auf 3. die Änderung von Mitarbeiter 2 ist also jetzt falsch, weil er „gemischte daten“ vorgefunden hat. Der Datensäatz für Artikel 2 war bereits geändert, der für Artikel 3 jedoh noch nicht. Das problem, welches zu diesem Misstand geführt hat, nennt sich Dirty Read: Mitarbeiter 2 hat Daten glesen, die noch nicht sauber abgeändert wurden. Hätte mitarbeiter 2  den sleben Datenstand gesehen wie Mitarbeiter 1, so lange die Transkation nicht abgeschlossen war, hätte er die selben Schritte durchgeführt wie Mitarbetier 1. Man löst dieses Prolbem auf Datenbank-ebene, indem man  Mitarbeiter 2 erst erlaubt, deie Datensätze zu lesen, bevor oder nachdem die Schreibtransaktion von Mitarbetier 1 abgeschlossen ist, aber nicht während dessen. Das heißt mitarbeiter 2 hätte entweder ddie Mengen 10, 20 und 5 oder 10, 15 und 3 sehen können, aber keine Mischung. das löst immer noch nicht das Problem, dass die beidne mitarbeiter noch nicht wissen, dass sie gegenseitig an der selben Bestellung dran sind, und Mitarbeiter 2 theoretisch die betellung von 10, 15 und 3 auf 10, 10 und 1 herab setzen könnte. Das ist aber Aufgabe der Anwendung. die anwendung müsste mitarbeiter 2 davor warnen, dass die bestellung kurz zuvor von mitarbeiter 1 bereits bearbeitet wurde.

Lost Updates: für dieses Problem müssen wir ein anderes Beispiel nehmen. Wir haben ein Lagerverwaltungssystem, in welchem fest gehalten wird, welches Produkt in welcher Stückzahl sich aktuell im Lager befindet

Artikel-IDNameItemsInStock
1Computermaus50

Nun werden zwei Transaktionen parallel ausgeführt. Hierbei handelt es sich um zwei Verkaufsvorgänge. Zu verschiedenen Zeitpunkten passiert in den transaktionen folgendes

Transaktion 1Transaktion 2
Lese aus, wie viele Stück verüfgbar sind
50
Lese aus, wie viele Stück verfügbar sind
50
Schreibe: Schreibe: Verkaufe 2 Einheiten.
ItemsInstock=ItemInStock-2
Verkaufe 3 Einheiten
ItemsInStock=ItemsInStock-3
Commit: Computermäuse noch verfügbar: 47
Commit: Computermäuse noch verfügbar:48

Erkennen Sie das Problem? Obwohl insgesamt 5 Einheiten verkauft werden, also nur noch 45 Einheiten verfügbar sind, steht nun in der Datenbank drin, dass noch 48 Einheiten verfügbar sind, Die Verkäufe von Transaktion 2 gehen also verloren. Wie würde man dieses Problem lösen? Indem die transkationen nicht prallel ausgeführt werden, sondern hintereinander. Dann liest nämlich Transaktion 2, dass anstatt 50 Stück nur noch 48 verfügbar sind, und zieht die drei verkauften Einheiten von 48 ab.

Non-repeatable reads: Wir bleiben bei unserer Lagerverwaltung mit 50 Computermäusen. diesmal haen wir zwei Transaktionwe.n Eine macht einen ganz einfachen Verkauf von 5 Einheitne und entfernt daher diese fünf einheiten aus der tabelle. Eine andere Transaktion führt eenfalls einen Verkauf durch, jedoch in Form einer Berechnung. diese besagt, dass der Kunde zum Zeitpunkt X das Recht hat, die Hälfte des Bestands aufzukaufen. In den Transaktionen sieht alles so aus.

Transaktion 1Transaktion 2
lese ItemsInStock

50

Lese ItemsInStock

50

schreibe: Verkaufe 5 Einheitne

ItemsInStock=ItemsInStock-5

Commit
schriebe: Verkaufe 50 % des Bestands

ItemsInStock=45 * 0,5

Commit

das Problem ist an dieser Stelle en anderes als ein beispiel zuvor. Hier geht keine der beiden Updates verloren, wie beim Lost Update Prolbem. Anber eines der beiden Updates liefert ein falches Resultat, weil sich ide Daten während der Transaktionsberechnung ändern. Anstatt dass der Kunde von transaktion 1 25 Artikel bekommt, bekommt er jetzt nur noch  23 Artikel. Auch dieses Problem ließe sich lösen, wenn die bieden Transaktionen nicht parallel, sondern sequentiell nacheinander laufen.

Phantom Reads

Um Phantom Reads zu erklären, bedienen wir uns einem nueen Beispiel. Wir haben eine Tabelle, in welchen mitarbeiter-Datensätze gespeichert sind.

IDNameVornme
1LoiblAndreas
3DellerMichael

Was wir jetzt mahen ist Folgendes.  wir lassen wieder zwei Transaktionen parallel laufen. Transkation 1 führt einmla am Anfang und einmal am Ende der Transaktionen einen Leseprozess aus. Zwischen den zwei Lesevorgängen, die beispielsweise 10 Sekunden auseinander liegen, fügen wir einen neuen Datensatz ein.

Transaktion 1Transaktion 2
Lies die Datenstze in der tabelle
2 Mitarbeiter werden zurückgegeben
Füge ienen mitarbeiter mit der ID 2 hinzu
Commit
Lies die datensätze in der tabelle
3 Mitabreiter werden zurückgegeben

wichitg ist, an dieser Stelle zu verstehen, dass nichts verkehrt daran ist, dass der neu hinzugefügte mitarbeiter angezeigt wird, sobald Transaktion 2 abgeschlossen ist. Wenn Sie ienen neuen Datensatz in eine Datenbank einfügen, soll dieser auch angezeigt werden, richtig? Das Problem ist hier, dass Transaktion 1 davon ausgeht, dass es zum Zeitpunkt der Ausführung die einzige transaktion auf der datenbank ist. Wenn nun zwei Lese-Zugriffe auf ein und die selbe Datenbasis inerhalb einer transktion unterschiedliche Werte zurückgeben werden, das ist das Problem. Denn wie soll Transaktion 1 irgend etwas mit den Daten, die sie liest, anfangen, wenn sie den Daten nicht trauen kann?

Isolation Levels

Die Isolation-Komponente von ACID kümmert sich also um vier-Kernprobleme. Es gibt verschiedne isolationslevels, di eauf eine Transaktion angewandt werden können. Je höher das Isolationslevel, desto weniger dieser vier bekannten PRobleme treten auf. Die einfachste lösung – und gleichzeitig das höchste Isolation Level – ist es, die parallele Ausführung von Transaktionen gänzlich zu verieten. Das heißt, solange eine Transaktionauf einen Datenbestand läuft-  egal ob lesend oder schreibend – ist dieser Datenbestand für andere Transaktionen gesperrt. Eine Datenbank setzt diese Sperren technisch durch sogenannte Datenbank-Locks. Wichtig hierbei ist zu verstehen, dass nur der Datenbestand, auf welchen eine Transaktion angewendet wird, gesperrt wird. Von der Transaktion nicht beienflusster Datenbestand kann weiterhin durhc andere Trnasaktionen beeinflusst werde n. Serializable erlaubt auf dem selben Datenbestand keine parallelen Transaktionen. Dies hat einen negativen Einfluss auf die Performance. Denn damit eine neue Transaktion auf einen Datenbestand ausgeführt werdne kann, muss der Vorgänger erst abgeschlossen sein. Je höher der Isolation Level einer Datenbank, desto geringer ist die Möglichkeit der Parallelisierung von Transaktionen, und desto geringer ist die Performance der Transaktions-Ausführung, desto niedrigerjedoch das Risiko auf inkonsistente Daten. Je niedriger der Isolation Level, desto höher der Grad der Ausführung und desto besser somit die Performance, aber desto höher ist auch die Chance auf Inkonisstenzen in den Daten.

Isolation levelDirty readsLost UpdatesNon-repeatable readsPhantoms
Read Uncommittedmay occurYesmay occurmay occur
Read Committeddon’t occurYesmay occurmay occur
Repeatable Readdon’t occurNodon’t occurmay occur
Serializabledon’t occurNodon’t occurdon’t occur

 

4. Durability

Die letzte Komponente von ACId, Durability, sagt aus, dass Transaktione, wleche manipulationen auf Daten ausführen, erst dann abgeschlosen sind, wenn die daten nachweisbar und kosnistent auf einem nichtvolatigen speicher abgelegt sind. Das bedeutet im klartext, dass wenn daten beispielsweise nur im Arbeitsspeicher vorhanden sind und noch nicht auf eine  festplatte geschrieben wurden, alle anderen datenmanipulationen dieser transaktion zurückgerollt werden, wenn es zum stromausfall kommt und die datenbanklösung neu gestartet wird. Denn die Transaktion ist erst dann vollständig, wenn alle Datenmanipulationsvorgänge einer Transaktion den Weg auf einen festen Datenträger gefunden haben.

BASE-Consistency

Jetzt, da wir über acid-consistency gesprochen haben, widmen wir uns als nächstes der BASe-consistency. die BASE-Consistency ist gegenüber der Acid consitency eine abgespeckte Variante der garantierten Datenkonsistenz. Base-consistency heißt in der Regel ,dass man eine „eventuelle Consistency“ der Daten erhält. Das heißt, wenn alles gut läuft, sind die daten konsistent, und wenn nicht, hat man eben leichte schiefstände, ide man on-the-fly korrigieren muss. base-consitency ist ein „optimistischer Ansatz“, während acid-consistency ein „pessimistischer Ansatz“ ist. Dafür ist eine anwendung, die „nur“ auf dem Dogma der Base-consistency arbeite,t in der Regel dazu in der Lage, performanter zu arbeiten, da parallel mehrere anfragen bearbeitet werden können. Base consistency wird gerne bei domains verwendet, in denen die Last auf der Datenbanklösung hoch ist, die Wichtigkeit der 100%igen Korrekthiet der Daten aber nachrangig. ES ist z. B. nicht wichtig, ob die Likes zu einem Facebook-Post jetzt 100% richtig sind, oder ob beispielsweise die Likes der letzten 5 Minuten bei einem Read-statement nicht berücksichtigt werden. Base-consistency heißt nicht, dass man nicht irgendwann eine Konsistenz der daten erreicht. Bei Base wird die Konsistenz jedoch nicht gleich beim Schreibvorgang der daten hergestellt. Dies ermöglicht jedoch ein Performance-optimiertes Schreiben der Daten über Queues. Anbei dazu ein gutes Video zur Erklärung

In diesem Beispiel bedeutet Eventual consistency, dass eventually die Facebook Likes, die aktuell in der queue sind, irgendwann in die Datenbank geschrieben werden. Dadurch werden die daten irgendwann konsistent. Das heißt aber auch, dass in dem Zeitfenster, in welchem die Daten noch nicht in der Datenbank sind und noch nicht repliziert wurden, Lese-Abfragen den nicht exakt korrekten wert iweder geben werden. Ein SELECT-Statement auf di Likes eines Facebook-posts würde in diesem Beispiel 4 Likes weniger anzeigen, als tatsächlich abgegeben wurden, weil 4 Likes noch in der warteschlnge stecken und daruaf warten repliziert zu werden. An dem Beispiel wird auch deutlich, dass es in einer BASE-Datenbank keine Datenbank-sperren gibt. Im Gegensatz zu einer ACID-Datenbank mit Isolation-Level „serializable“ können sie also in einer BASE-Datenbank Schreib- und Lesetransaktionen beliebig parallelisieren. Die damit einher gehenden 4 Grundprobleme (Dirty reads, Lost Updates, Non-repeatable reads und Phantom Reads) auf Datenbankebene können Sie auf Anwendungsebene auch teilweise abfangen, so dass sie weniger gewicht haben.

am wichtigsten wird BASE, wenn wir mehrere Datenbanken in einem Failover-szenario arbeiten lassen. Das heißt wird haben einen Primary-Knoten, welcher für Lese- und Schreib-Aktionen genutzt wird, nud wir haben einen Secondary-Knoten, der zwar auch die Daten des Primarys speicher,t aber erst dann einspringt, wenn der Primary ausfällt. in einer klassischen Datenbank, die nach dem ACID-Konzept arbeitet, ist eine Transaktion erst abgeschlossen, wenn der Schreibvorgang nicht nur auf dem Master, sondern auch auf dem Slave abgeschlossen ist, welcher die Daten für den Fall vor hält, dass der Master ausfällt. Das heißt die dauer einer Datenbank-sperre verlängert sich nun zusätzlich um die Zeit, die es braucht, die daten von Datenban-Knoten A nach Datenbank-Knoten B zu replizieren. Für einige Einsatzgebiete nimmt man diese zusätzliche Wartezeit in kauf, weil man lieber sicher geht, dass die Daten auf jeden fall siche rauf beiden Knoten sind. Bei anderen hingegen kann man mit „eventual Consistency“ leben und verringert diese Wartezeit durch das BASE-Konzept. In unserem Beispiel würde es heißen, dass wenn der Primary ausfällt, alle Facebook-Likes verloren gehen, die noch nicht vom Primary an den Secondary übertragen wurden. Ihr könnt euch aber vorstellen, dass der Benefit, den man durch die schnellere Verarbeitung der Likes erhält, wichtiger ist, als das risiko, einmla ein paar hundert Likes zu verlieren.

BASE steht für

1. Basically Available

die Datenbank ist meistens funktional, und wenn mal ein teil nicht da ist, funktioniert immer noch der Großteil der Datenbank. die Daten in der Datenbank sind immer redundant auf mehrere Knoten verteilt. Sind einige Knoten down, sind die  Daten auf den anderen Knoten immer noch verfügbar.

2. Soft State

Jedoch kann es sein, dass einige der Daten die verfügbar sind, einen veralteten und daher inkonisstenten Stand haben. Es kann nämlich sein, dass auf einem ausgefallenen Knoten eine katuellere Version der Daten (z. b. Anzahl der facebook-Likes für ein Posting hat) gespeichert ist, also auf dem Knoten, der noch verfügbar ist. Das ist der unterschied zu aCID. Sie können sich sicher vorstellen, dass dies für facebook-Likes OK ist, aber für Ihren Kontostand auf der Bank asolut inakzeptaele.

Wenn eine ACID-kompatible Datenbank hochverfügbar gehalten wird, gibt es immer einen Master und einen Slave Knoten. Eine Schriebaktion auf der datenbank ist erst dann abgeschlossen, wenn die daten sowohl auf dem Master, als auch auf dem Slave persistiert wurden. das heißt wenn einer der beiden Knoten ausfällt, hat der andere Knoten den exakt selben Datenstand, was die Daten konistent macht. Genau so ist es bei BASE nicht, hier kann es sein, dass der slave sich seit längerer Zeit kein Update mehr vom Master geholt hat. Dafür ist aber eben die Verarbeitungsgeschwindigkeit der Schreib-Aktionen schneller.

3. Eventual Consistency

Eventual Consistency bedeutet jetzt, dass die Datenbanklösung eine Logik implementiert hat, um verschiedene datenstände, ide aufgrund der soft State Eigenschaft von BASE auseinander laufen, sich selbst „reparieren“. Das heißt, früher oder später, irgendwann, sind die daten in einer BASE-compliant Datenbank konsistent. Wir bleiben bei unserem Beispiel mit den Facebook-Likes. Ein Knoten, der aktuell 500 Likes misst, ist ausgefallen. Die 500 Likes wurden noch nicht auf die anderen Knoten repliziert. Sie gehen noch von 400 Likes aus. Wenn jetzt Knoten mit den 500 Likes iweder online kommt, kann die Datenbank eine Logik implementiert haben, dass neuere Datensätze die älteren automatisch überschreiben.

 

was ist jetzt, wenn in der Zwischenzeit wieder neue Likes dazu gekommen sind? sagen wir einmal, dass in der Zeit, in welcher der Knoten mit 500 Likes nicht vergfügbar war, neue Likes dazu gekommen sind, so dass die anderen Knoten jetzt 450 Likes verzeichnen. Nun, in dem Fall würden, wenn einfach die Anzahl der Likes vom alten Knoten übernommen werden, 500 Knoten übernommen werden, was de fakto dazu führt, dass 50 Likes verloren gehen. Denn 500 Likes waren ja davor schon im System persistiert, und die 50 die dazu gekommen sind, werdne jetzt nicht mehr berücksichtigt. Deswegen heißt es auch Eventual consistency. Das System erreicht irgendwann einen technisch konsistenten Zustand, aber ob dieser in der Realität wirklich jede Transaktion konsistent wieder gibt, ist nicht garantiert.

Man könnt dieses Prolbem übrigens lösen, indem man die Anzalh der Likes nicht als dumme Zahl speichert ,sondern wirklich anhand von Verbindungen. Das heißt, wenn ein User auf Like klickt, wird tatsächlich zu diesem User eine Verbindung hergestellt. In diesem Fall würden die Knoten, wenn sie sich später wieder gegenseitig sehen, einfach sämtliche Verbindungen ggenseitig untereinander austauschen, und ie Datenbank wäre wieder konsistent.

Unit of Work Pattern im anwendungscode

Wenn Sie Anwendungsentwickler sind, kommen Sie vielleicht auf die Idee, zu sagen: „Wer braucht denn schon ACID-Compliance?“ Ich kann doch eine BASE-compliant Datenbank nehmen und mich auf Anwendungsebene darum kümmern, dass Transaktionen immer schön hintereinander ausgeführt werden. Noch besser: Auf Anwendungsebene kann ich beispielsweise einen Nutzer daran hindern, eine Bestellung zu bearbeiten, an der gerade ein anderer Mitarbeiter arbeitet. Somit verhindere ich, dass sich die Mitarbeiter unerkannt gegenseitig die Änderungen überschreiben.  Die Umsetzung dieses Design Patterns ist also in Umgebungen mit hohen Anforderungen an die Datenkonsistenz nicht nur sinnvoll, sondern in vielen Fällen sogar notwendig.

Grundsätzlich wäre dies eine Idee, jedoch haben Sie an dieser Stelle drei Probleme, das letzte davon ist das alles entscheidende:

  • Eine LUW auf Anwendungsebene besteht in der Regel aus mehreren LUWs auf Datenbankebene. Diese LUWs auf Datenbankebene können parallel ausgeführt und daher nicht ausreichend isoliert werden, wenn Sie die entsprechende Logik nicht implementieren. Anbei habe ich hier ein Diagramm aus dem SAP Help Portal aufgezeichnet, welches ich nach dem Fair Use Prinzip hier einmal einfüge. Dementsprechend besteht eine SAP LUW aus drei Datenbank-LUWs, die in drei aufeinander folgenden Eingabemasken erzeugt werden. Am Ende der SAP-LUW werden die drei Datenbank-LUWs freigegeben. Die drei freigegebenen Datenbank-LUWs könnten nun nach ihrer Freigabe parallel ausgeführt werden und daher auf Datenbank-Ebene auf Probleme stößen.

  • Neben der Anwendung, für die Sie selber den Quellcode schreiben, wird auf die Datenbank ja auch noch durch andere Client-Software zugegriffen, beispielsweise durch Kommandozeilen-Clients oder Excel-Makros. Dieses Problem hätten Sie damit nicht abgedeckt
  • Das Herstellen einer Konsistenz auf Anwendungsebene erfordert eine ständige Kommunikation der einzelnen Server-Instanzen untereinander. Das ganze führt im Endeffekt dazu, dass sie, obwohl Sie eine BASE-Datenbank haben, die selben Nachteile haben, als würden Sie eine ACID-Datenbank einsetzen. Denn Sie müssen ja jetzt trotzdem darauf warten, dass Transaktion 1 abgeschlossen ist, bevor Sie Transaktion 2 anstarten können. Sie können also in diesem Fall gleich eine ACID-Datenbank verwenden. Sie haben also die Vorteile einer BASE-Datenbank nicht mehr, wenn Sie dieses Design Pattern implementieren.

Verschiedene Arten von NoSQL-Datenbanken

Es gibt verschiedene arten von noSQL-Datenbanken. Sie unterscheiden sich zu aller erst in der Art und Weise, wie sie Daten speichern. In der unten stehenden Abbildung sind die vier Kategorien von NoSQL-Datenbanken abgebildet. In Orange immer die Kategorie, in Blau einige Beispiele, in Grün die Vorteile der Datenbank und in Rot die Schwächen

Würde man diese vier Formen in eine Rangfolge schieben, welche der NoSQL-Datenbanken bei tapischen klassischen SELECT- und INSERT-Statements ohne Tabellen-Joins am schnellsten sind (read/write-Speed), würde man die Reihenfolge folgendermaßen festlegen

  1. Columnar NoSQL
  2. Document Oriented
  3. Key Value atabase
  4. Graph DAtabase

Jedoch ist z. B. eine Graph-Datenbank bei weitem schneller, wenn es um typische Graph-Algorithmen oder um JOINs geht. Dazu kommen wir weiter unten.

Key-Value Datenbanken

Key-Value Datenbanken bestehen aus einem Schlüssel-Feld und einem BLOB-Feld. IN diesem BLOB-Feld kann alles mögliche drin stehen, von einem Video, über ein Bild, über Text, usw. Die Datenbank interessiert sich nicht für den Inhalt. Das heißt aber auch, dass ich in dem Inhalt eines BLOB-Feldes mehrere Informationen rein schreiben kann. Als Vergleich habe ich hier mal eine klassische SQL-TAeblle für „user“-Konten und darunter eine Key-Value Tabelle für User-Konten erzeugt.

klassische SQL-Userdtabelle
User-IDUsernameGeburtsdatumE-MailTelefonWohnort

Key-Value Tabelle
KeyValue
1Username: dafrk

Geburtsdatum: 21.08.1989

E-Mail: info@dafrk-blog.com

Telefon: +49 1511 103 6804

Wohnort: München

Der Vorteil von Key-value-Datenbanken wirdklar, wenn ihr euch vor Augen haltet, was jetzt passiert, wenn wir dem User-Konto noch andere Inforamtionen wie beispielsweise „Bestellungen“, „Adressen“, usw. hinzufügen. In einer klassischen SQL-Datenbank hättet ihr an dieser Stelle mehrere tabellen. Ihr hättet eine Tabelle User, eine Tabelle Bestellungen und eine Tabelle Adressen. Wenn ihr nun nach allen Informationen zu einem bestimmten Benutzer sucht, müsst ihr entweder eine Join-Query machen oder drei verschiedene einfache Select-Queries und die Inforamtionen dieser drei Queries am Ende zusammenführen. Das ist aufwendig. Im Vergleich dazu: Bei einer Key-Value-Datembank fragt ihr einfach nach dem Key (1), und erhaltet auf einen Schlag alle Informationen.

Damit werden aber auch die Nachteile klar: Die Datenhaltung ist nicht normalisiert, das heißt wir haben unter Umständen viele Redundanzen, es gibt keine Constraints auf die Daten, die Datenbank ist nicht ACID-compliant und die Suche nach einzelnen Teilinfomrationen kann sehr aufwendig sein, wenn ich den Schlüssel-Wert (Key: 1 in unserem Beispeil) nicht kenne, weil dann alle User-Einträge durchforstet werden müssen. Selbst wenn ich den Schlüsselwert des Benutzers weiß, aber nur einige Teilinformationen haben möchte, beispielsweise die E-Mail, muss innerhalb des BLOBs eine Volltextsuche statt finden. Das heißt das gesamte Blob muss nach dem STring „E-MAil“ durchsucht werden, um ie E-Mail des Benutzers zurückzugeben. Key-Value-DAtenbanken sind also in der Regel schneller, wenn ich alle oder viele Informationen zu einer Entität anzeigen lassen möchte, aber langsam, wenn ich nur einige teilinformationen hbaen will. Außerdem: Wenn Sie einen Datensatz updaten wollen, müssen Sie den gesamten Inhalt des „value“-Feldes neu schreiben. Bei einer klassischen relationalen Datenbank müssen Sie unter Umständen nur den Wert einer einzelnen Spalte ändern, also nicht den gesamten Inhalt neu schreiben. Erfahrungsgemäß ist das Schreiben neuer Zeilen trotzdem schneller als bei einer klassischen SQL-Datenbank, weil wir eine NoSQL-datenbank den ganzen Overhead mit Datenbanksperren, Daten neu sortieren und Index neu schreiben nicht hat. Wir werden später aber noch eine ARt von NoSQL-Datenbank kennen lernen, die neue Datensätze noch schneller schreibt als eine Key-Value NoSQL-Datenbank.

Wenn Sie ein Softwareentwickler sind, fällt Ihnen vielleicht noch ein anderer Use Case für Key-Value-Datenbanken ein. Wo speihern Sie denn so eine Art von Wertezuwachs innerhalb Ihrer Anwendung? richtig, meistens in Arrays, und allgemein betrachtet in Variablen. Wenn Sie Werte jedoch immer nur auf dem Anwendungsserver in Form von Variablen speichern, haben Sie ein PRoblem, dass Sie die Verarbeitung der in den Variablen gespeicherten Werte nicht skalieren können. Denn die Variable ist ja im Arbeitsspeiher der Anwendung gespeichert. Wenn der Server, auf welhem die Variable gespeichert ist, ausgelastet ist oder osgar ausfällt, ist der Wert dieser Variable verloren und der Benutzer muss die gesamte Prozedur auf einem anderen Awnendungsserver wiederholen, die zur Zwischenspeicherung der Variable geführt hat.

Wenn Sie die Werte hingegen in einer Datenbank ablegen, beispielsweise Session-Informationen, die Sie in einer Session-ID hinterlegen, können Sie die Informationen zunächst in einer Datenbank speichern und dann über diese Datenbank in mehreren Anwendungsservern parallel in eine Variable einlesen. Die Variable ist nun also auf mehreren Anwendungsservern gleichzeitig im Arbeitsspeicher  gespeichert. Die Anfragen des Benutzers können nun auf mehrere Anwendungsserver verteilt haben, weil alle diese Server Zugriff auf die Daten haben. Einziges Problem hierbei ist: Sie müssen eine Logik entwerfen, die dafür sorgt, dass die Session-Informationen auf allen Awnendungsservern immer aktuell sind, wenn diese geändert werden.

Document-Oriented Datenbanken

Document-Oriented Datenbanken funktionieren genau so wie Key-Value-Datenbanken, nur dass hier im BLOB-Feld die Daten häufig in Form einer vordefinierten Struktur gespeichert sind. Hier werden häufig stnadardisierte Dokumentstrukturen wie XML, JSON oder BSON eingesetzt. Eine derartige Datenbank würde also beispielsweise so aussehen

KeyValue
1<User>

<username> dafrk</username>

<e-mail>info@dafrk-blog.com</e-mail>

</user>

Der Vorteil gegenüber relationalen Datenabnken sowie auch die Nachteile sind überwiegend gleich wie bei den Key-Value-DAtenbanken. Gegenüber den Key-Value-Datenabnken haben Document Oriented Datenbanken den Vorteil, dass die in ihnen gespeicherten Daten vorstrukturiert und daher einfacher zu analysieren sind. Sie haben gegenüber Key-Value-Datenabken den Nachteil, dass sie für die selbe Datenmenge in der Regel mehr Speicherplatz brauchen, weil der Overhead durch die Dokumentenstruktur mit gespeichert werden muss. Außerdem kann es bei dieser Art Datenbank zu PRoblemen mit Sonderzeichen, insbesondere bei der Speicherung von Binärdaten, geben. Denn die Dokuemntenstruktur, beispielsweise XML, nutzt ja selbst Sonderzeichen wie beispielswiese <>, um die Dokumentenstruktur herzustellen. Dazu kommt es hier in der Regel zu Problemen bei der Unterscheidung, welches Zeichen nun zur Dokumentenstruktur, und welches zu den eigentlichen Daten gehört. Dies müsste man durch eine Enkodierung der Sonderzeichen lösen, beispielsweise indem innerhalb des Textes <> mit &gt; sowie &lt; kodiert werden, wie man es aus der Webentwicklung kennt. Document-oriented Datenbanken eignen sich also in der Regel nicht für Binärdateien, sondern eher für Klartextinformationen.

Document-oriented Datenbanken werden gerne für das Event Logging genutzt, also als Ersatz für eine klassische Logdatei. Außerdem eignet sich die Datenbank wunderbar, um die Daten direkt an eine API zu übergeben. Aber auch beispielsweise für Text-Informationen, die keine ACID-Compliance benötigen, wie etwa Kommentare, eignet sich diese Art von Datenbank.

Wide-Column noSQL Datenabnken

Wide-Columns noSQL Datenabnken sind im Kern auch nur eine Key-Value-Datenbank. Mit dem Unterschied, dass ein Key nun mehrere Spalten an Daten tragen kann. Dabei ist die Anzahl der Spalten und somit der Anzahl der attribute nicht fix. Eine Zeile kann 4 Spalten haben, eine andere 20, eine andere 500, und die nächste Zeile 100 000 Spalten. Eine Wide-Volumn Datenbank sieht, grafisch dargestellt, ungefähr so aus

Column Family „User“
KeyValue
1
UsernameE-MailGeburtstagWohnort
dafrkinfo@dafrk-blog.com21.08.89München
2
UsernameHochschuleGeburtstagWohnortGeschlecht
mdellerLandshut01.04.21Landshutmännlich

Wie Sie sehen, enthält die Datenbank statt einer Spalte „Value“ also eine sogenannte Column Family. Für jede Zeile ist die Anzahl der Spalten und auch die Bezeichnung und reihenfolge dieser Spalten nicht vorgegeben. Eine Column Family ist bei einer Wide-Column Datenbank das äquivalent zu einer Tabelle in einer klassischen SQL-Datenbank.  Mehrere Column Families werden zusammen in einem sogenannten Keyspace gespeichert. Ein Keyspace wäre im Hinblick auf eine klassische SQL-Datenbank das Äquivalent zu einem Schema.

Wide-Column NoSQL-Datenbanken können ACID-compliant sein, müssen es aber nicht. ES hängt also sehr stark von der Art der Wide-Column-Datenbank ab, welche Nachteile im Vergleich zu einer relationalen Datenbank Sie haben. Haben Sie ACID-Compliance, haben Sie wieder Einbußen in der Datenkonsistenz. Dafür schreiben Sie neue Werte schneller als eine klassische SQL-Datenbank.

Eine Wide-Column NoSQL-Datenbank ist tricky. Erinnern Sie sich an unseren Vergleich von zeilenorientierten und spaltenorientierten SQL-Datenbanken? Wissen Sie noch, dass wir festgestellt haben, dass

  • zeilenorientierte Datenbanken schneller im Einfügen und Aktualisieren von Datensätzen und in der Abfrage von SELECT *-Statements oder Abfragen mit vielen Attributen sind?
  • spaltenorientierte Datenbanken besser in der Kompression und in der Abfrage von einzelnen Attributen sind?

Eine Wide-Column-Datenbank kombiniert die beiden Vorteile ein wenig. Zunächst einmal ist das Einfügen neuer Datensätze schnell, weil eine Wide-Column-Datenbank noSQL ist und daher nicht den ganzen OVerhead wie Constraints und Datenbank-Sperren mit sich bringt (es sei denn, sie haben eine ACID-compliant NoSQL-Datenbank gewählt, dann haben Sie Sperren). Und: im Gegensatz zu einer Key-Value-Datenbank müssen Sie bei der Änderung eines DAtensatzes nicht den gesamten Inhalt der Value-Spalte neu schreiben, sondern nur die jeweilige Spalte innerhalb der Column family, die sich wirklich geändert hat. Dadurch sparen Sie Schreib-Volumen. Wide-Column-Datenbanken sind also, wenn es um das Aktualisieren von Datensätzen geht, in der Regel schneller als Key-Value- und Document-Oriented Datenbanken. Wenn Sie alle Attribute eines Datensatzes wissen wollen, und Sie den Key des Datensatzes wissen, sind die Daten schneller da wie bei einer klassischen SQL-Datenbank, da Sie nicht mehrere Tabellen über JOINS oder mehrere SELECT-Statements abfragen müssen: Alle Daten sind in einer Column Family zusammen und sofort da. Dafür haben Sie wieder die damit einhergehenden Nachteile: Doppelte Datenhaltung (Redundanzen), evtl. keine Constraints und keine ACID-Compliance. Aber ein Nachteil von Key-Value-Datenbanken im Vergleich zu einer klassischen SQL-Datenbanken fällt weg: Die Suche nach Einzelinformationen ist jetzt beinahe genau so schnell wie bei einer spaltenorientierten SQL-Datenbank, da die Column Family einer Wide-Column-Datenbank ziemlich genau so aufgebaut ist wie eine spaltenorientierte Tabelle. SELECT-Statements nach einzelnen Attributen sind also jetzt ebenfalls schnell, jedoch mit einigen Einschränkungen, da die Spalten ja nicht vorgegeben sind. Weitere Einschränkung: Wide-Column-Datenbanken unterstützen keine Sekundär-Indizes. Wenn Sie also Ihre spaltenroientierten Abfragen durch Sekundär-Indizes optimieren wollen, sollten Sie lieber zu einer klassischen spaltenorientierten SQL-Datenbank tendieren als zu einem Wide-Column Store. Eine Wide-Column Datenbank ist in der Abfrage von Einzelinformationen also durchaus konkurrenzfähig zu einer spaltenorientierten SQL-Datenbank, jedoch nur, wenn das Datenmodell auf die Abfragen abgestimmt ist. Bei Abfragen, die on-the-fly generiert werden, ist die spaltenorientierte SQL-Datenbank schneller. Das Datenmodell einer Wide-Column Datenbank wird aus diesem Grund erst designt, wenn die Abfragen auf die Daten bekannt sind.

Wichtig in diesem Zusammenhang ist außerdem zu verstehen, dass der Sinn einer Wide-Column-Datenbank ist, dass sämtliche Daten in einer einzigen Column Family enthalten sind. Es macht keinen Sinn, Daten über mehrere Column Families hinweg zu joinen. Dann ist der Vorteil dahin.

Was sind nun die Nachteile einer Wide-Column-Datenbank gegenüber Key-Value und Document-Oriented Datenbanken? Nun, die Daten sind wieder in einem ähnlichen Format wie bei einer klassischen SQL-Datenbank, das heißt diese Art von Datenbanken eignet sich nicht so gut für das Speichern unstrukturierter und semi-strukturierter Daten. Sofern Sie eine ACID-kompatible Wide-Column-Datenbank gewählt haben, haben Sie an dieser Stelle auch wieder Datenbanksperren  und daher den Overhead einer klassischen SQL-Datenbank.

 

Columnar noSQL DAtenabnken werden also sehr gerne genutzt, wenn:

  • massiv viele Datensätze in einer Datenbank geschrieben oder aktualisiert werden sollen, ohne dass die Performance in die Knie geht.
  • die Abfragegeschwindigkeit aller Attribute und selektiver Attribute zusammen optimiert werden soll
  • Sie in dieser Datenbank unstrukturierte und semi-strukturierte Daten ohne die Anwendung von Constraints speichern wollen.

Columnar noSQL sollten Sie nicht verwenden wenn:

  • Ihre Applikation Sekundär-Indizes nutzt. Wide-Column-Datenbanken unterstützt keine Sekundär-Indizes
  • relationale oder tranaktionale Daten gespeichert werden, insbesondere finanzielle, personenbezogene, sensible und buchhalterische Daten. Warumm? Die mesiten Columnar noSQL Datenabnken sind AP-Datenbanken, das heißt sie sind gut im Hinblick auf die Verfügabrkeit und die Partition Tolerance, aber nicht im Hinblick auf die Konsistenz. Bei transaktionellen Daten ist Konsistenz und damit auch die Datensicherheit allerdings in der Regel sehr wichtig.
  • Dynamische Abfragen auf die Daten in den Spalten. Dynamische Abfragen sind Abfragen, die on-the-fly generiert werden, die also im Vornherein nicht bekannt sind. In diesem FAll ist das Datenmodell nicht auf die Abfragen optimiert, und eine Datenbank wie Cassandra verliert ihren Benefit. Wide-Column Stores sind insbesondere nicht für das Aggregieren von Daten gemacht, beispielsweise über eine SUM() oder AVG()-Funktion. Die Daten, die im Wide-Column Store gespeichert werden, sollten vor-aggregiert werden, bevor sie dort abgelegt werden.

Graphen-Datenbanken

Um Graph-Datenbanken zu verstehen, müssen wir erst wieder ein wenig in die Welt der relationalen Datenbanken abtauchen. Wie wir wissen, werden Beziehungen zwischen einzelnen TAbellen in einer relationalen Datenbank anhand von Fremdschlüsseln hergestellt.  Das folgende Beispiel würde qetwa abbilden, dass jeder Mitarbeiter immer nur in einer Abteilung sein kann, eine Abteilung allerdings mehrere Mitarbeiter haben kann (1:n)

IDNameabteilungsID
1Alice2
Abteilungen
IDName
1Buchhaltung
2Einkauf

Was ist nun, wenn wir uns im Klartext anzeigen lassen wollen, in welcher Abteilung Alice ist,? Nun, dann rbauchen wri die Spalte Name aus der tabelle mtiarbeiter und die Spalte Name aus der Tabelle Buchhaltung. Und damit wir die Verbindung herstellen, müssen wir einen Join machen. DAs SQL Statement würde etwa so aussehen.

SELECT  Mitarbeiter.Name, Abteilungen.Name
FROM Mitarbeiter
INNER JOIN Mitarbeiter ON Mitarbeiter.abteilungsID=Abteilungen.ID;

Joins wollen wir vermeiden, denn sie sind sehr teure SQL-Statements, die hohe Ansprüche an CPU und Arbeitsspeicher stellen und lange Antwortzeiten haben und es schwieirg ist, Indizes für Join-Abfragen zu erstellen.  Eine erste Lösung für dieses Problem gibt es auf Anwendungsebene. Durch objektrelationales Mapping (ORM) im Programmcode erstellen wir kein Join SQL-Satetement mehr. Statt dessen haben wir einen Programmcode, der einfach gesagt so aussehen kann

$mitarbeiter = getMitarbeiterByID(1);
$abteilung = getAbteilungFromMitarbeiter($mitarbeiter->getID());

Dieser Code führt dann nacheinander die folgenden SQL-Satatements aus

SELECT * from mitarbeiter WHERE id = 1; // Programm kriegt die Daten für Alice
SELECT abteilungsID from mitarbeiter WHERE id = 1; // Programm merkt sich 2
SELECT * from abteilungen WHERE id = 2; // die 2 hat das Programm sich von vorhin gemerkt

In diesem Beispiel ist kein Join mehr nötig. Das Programm hat am Ende alle Daten, die es braucht, in zwei Variablen gespeichert. Zudem werden diese beiden Variablen nun im Arbeitsspeicher der Anwendung gecached, das heißt die Daten werden nur einmal abgefragt und befinden sich danach im Arbeitsspeicher der Anwendung.

Etwas komplizierter wird es nun, wenn ein Mitarbeiter in mehreren Abteilungen sein kann. Dann haben wir eine m:n-Beziehung. Bei einer m:n-Beziehung brauchen wir in einer relationalen Datenbank eine sogenannte JOIN-Tabelle, welche die Verbindungen herstellt. In unserem neuen Beispiel ist Alice soowhl Mitglied der Abteilung Buchhaltung als auch der Abteilung Einkauf

Abteilungen
IDName
1Buchhaltung
2Einkauf

Mitarbeiter
IDName
1Alice
2Bob
joinMitarbeiterAbteilungen
mitarbeiterIDabteilungsID
11
12

Auch hier lässt sich ein Join über drei Tabellen vermeiden, indem man objektrelationales MApping nutzt. Joins sind bei 1:1-Beziehungen und wenigen DAtensätzen noch schneller als mehrere SELECT-STatements. Sobald wir aber 1:n oder m:n-Beziehungen haben, sind mehrere SELECt-Statements in der Regel aus Sicht der Antwortzeit und des Arbeitsspeicherverbrauchs effizienter. Eine interessante Diskussion hierzu gibt es auf Stackoverflow. Durch objektrelationales Mapping erreicht ein Entwickler, dass Joins vermieden werden, und der Code stattdessen mehrere SELECT-STatements nutzt.

Auch wenn wir jetzt durch ORM die nutzung von Joins verhindern könne, haben wir immer noch ein Problem: Wir müssen, trotz alledem, alle drei Tabellen durchscuhen. Und auch wenn alle drei Tabellen Indizes haben, ist das trotzdem noch einiges an Aufwand. Jetzt stellt euch vor, ein Mitarbeiter ist nicht nur Mitglied einer oder mehrerer Abteilungen, sondern

  • hat auch eine oder mehrere Staaatsangehörigkeiten
  • hat ienen oder mehrereVorgesetzte
  • bekleidet eine oder mehrere Rollen innerhalb des Unternehmens
  • hat einen oder meherere Pool-fahrzeuge gerade in Beschlag
  • hat eine oder mehrere Geräte aus dem Inventar empfangen

usw. Ihr merkt also, je mehr Beziehungen ein Mitarbeiter in unserem Beispiel hat, desto mehr Tabellen müssen wir durchsuchen. Genau in solchen Szenarien, in welchen komplexe Beziehungsgeflechte abgefragt werden, glänzen Graph-Datenbanken. Graph-Datenbanken speichern Daten nicht in Tabellenform, sondern in Pfadform. Anstatt mehrere Indizes oder mehrere Tabellen auf der Suche nach den zusammen passenden Werten durchlaufen zu müssen, muss auf der Suche nach einer Beziehung nur der Pfad einmal durchlaufen werden.

Graph-Datenbanken sind also gut, wenn es darum geht, einen einzelnen DAtensatz anzuziegen, der Beziehungen zu vielen verschiedenen TAbellen hat. Graph-DAtenbanken sind hingegen schlecht, wenn es darum geht, mehrere Datensätze anzuzeigen, die wenige Beziehungen haben. Denn in einer Graph-Datenbank müssen sie den ganzen Pfad einmal durchlaufen, bevor sie den nächsten Pfad einlesen können. Damit wird jetzt klar, was die Stärken und Schwächen einer Graph-Datenbank im Vergleich zu einer klassischen relationalen Datenbank sind.

Wir wissen nun, dass Graph Datenbanken gerne dort eingesetzt werden, wo viele Joins nötig werden. Wo werden Graph DAtenanken denn jetzt in der Praixs gerne genutzt?

  • Social Media, insbesondere Neo4j, weil Neo4j ACID-compliant ist und daher die transkationalen Daten des Social Media Netzwerkes konsistent gespeichert werden können. In der Graph-Datenbank gehen dann typische Querys wie beispielsweise „Sie sind über XX Personen mit Person Y verbunden“ wesentlich schneller als mit einer relationalen SQL-DAtenbank
  • Interconnected Data Szenarien wie beispielsweise öffentlicher Schienenverkehr oder GPS-Straßennavigationspunkte.

Full Text Databases

Wenn wir von Full Text DAtabases reden, sprechenwir von Lösungen wie Lucene, ElasticSearch (welche auf Lucene basiert) und SolR. Full Text Datenbanken bestehen im Kern aus drei großen Indizes.

Der Main Document Index enthält einen Index, also sozusagen eine Liste, auf alle Dokumente, die in der Datenbank hinterlegt sind. Hier ist es der Anwendung möglich, Meta-Daten abzuspeichern. Dadurch kann nach Dokumenten gesucht werden über Informationen, die im eigentlichen Dokumententext gar nicht vor kommen. So kann man etwa in einer Bibliothek ein Physik Buch bestimmten Kategorien zuordnen, oder das Veröffentlichungsjahr, die Auflage und den Autor hinterlegen. Da es sich um einen Index haben, gibt es einen Pointer, der auf den datenblock zeigt, in welchem das Dokument gespeichert ist. Dieser Pointer kann etwa auf ein BLOB in einer Datenbank zeigen, oder auf die in einem externen Dateisystem gespeicherte Datei.

Main document index
KeyTitelAutorErscheinungsjahr…Pointer

Der Main Word INdex hält fest, welche Wörter wie oft in welchem Dokument vor kommen. Dadurch ist es möglich, eine sortierte Liste auszugeben, welches Dokument am relevantesten für einen bestimmten Suchbegriff ist. Der Index zeigt auf die Dokumenten ID, die im Main document INdex hinterlegt ist.

Wort-Index
WortAnzahlDocument-ID

als dritten Index hat jeder Lösung, wie beispielsweise ElasticSearch, SolR oder Lucene, ihre eigenen hersteller-eigenen Indizes. Beispielsweise können die Hash-Werte verschiedener Revisionen eines Dokumentes indiziert werden usw.

Was ist nun der vorteil einer Full-TExt-Datenbank im Vergleich zu einer klassischen relationalen Datenbank? Nun, eine relationale Datenbank erstellt klassischerweise keine Indizes auf den Dokumentinhalt. Wenn Sie in einer Fulltext-Datenbank ein dokument referenzieren, geht die Datenbank her, durchsucht das Dokument und erstellt automatisch für dieses Dokument den Wort-Index. Mit Hilfe des wort-Index könnenn Sie nun Dokumente schnell anhand ihres konkreten Inahlets finden. IN einer klassischen relationalen Datenbank, in welcher sie den Dokumentinhalt nicht indiziert haben, müssen Sie entweder das gesamte Dokument, welches beispielsweise als BLOB oder LONGTEXT-Feld gespeichert ist, im Full Scan modus durchsuchen, oder Sie können das Dokument nur anhand von Metadaten suchen, die Sie zuvor manuell eingegeben haben – wie etwa den Titel, Autor, Textschnipsel usw.

Natürlich können Sie Ihre Webanwendung nun so schreiben, dass die Daten, die als text ine ienm LONGTEXT- oder BINARY-Feld stehen, durch die Webanwendung durchforstet und von dieser dann in einer Wort-Index-tabelle indiziert wird, keine Frage. Der Vorteil von ElasticSearch und Co. ist eben, dass diese Datenabnken diese Arbeiten schon selbständig erledigen – und dass die von den Datenabnken genutzten Algorithmen ständig von den Entwicklern weiterentwickelt werden, während der webentwickler einer Webanwndung die Logik vielleicht nur einmalig implemenitert und sie danach nicht mehr anrührt. Und: Wenn Sie keine NoSQL-Datenabnk verwenden, haben Sie natürlich die typischen Nachteile einer SQL-Datenbank: Constraints, schlechte Skalierbarkeit und alngsame Schreibvorgänge.

Weiterhin sind Full Text Datenbanken auf die Verarbeitung von Text-Queries optimiert. Typische Features, die ElasticSearch und Co. im Vergleich zu relationalen Datenbanken bieten, sind

  • Hybrid Queries. Innerhalb einer einzigen Query durchsucht die Datenbank nach passendenDokumente sowohl anhand des Wort INdexes als auch anhand der Metadaten in den Metadata-Attributen.
  • flexiblere Query-Operatoren. Text-Engines bieten speziell auf Text-Queries bezogene Operatoren. DArunter fallen beispielsweise das Language Stemming, die automatische Suche nach statistisch wahrscheinlichen Synonymen, Suche anhand der Wortdichte in einem Dokument, Soundex-Suchen nanhand der phonetischen Aussprache von Wörtern usw.
  • Relevancy Weighing. Die Suchergebnisse werden anhand von definieren PArametern wie etwa der Wortdichte gewogen, so dass die Suchergebnisse ganz oben stehen, die die beste Relevanz im Hinblick auf die Suchkriterien haben.

Full Text Datenbanken sind, rein technisch gesehen, ganz einfach Document oriented NoSQL-Datenbanken, mit dem einzigen Unterschied, dass sieihre STärke nicht darin sehen, nach einem Schlüssel zu suchen (beispielsweise nach einer Dokumenten-ID oder nach einem Pointer), sondern die Stärke liegt darin, ein ERgebnis nach Werten (de fakto nach Wörtern, die sich im Dokument befinden sollen) zu finden.

Log Management

In einem Big Data Szenario gehört es auch dazu, Logdateien von Maschinen, SPSen, IT-Systemen, Netzwerkgeräten, Datenbanken und Anwendungsservern auszuwerten. In der Regel beginnen Unternehmen damit, die Logdateien all dieser Kompoennten an einem zentralen Logging-Server zu sammeln. Häufig ist dies einfach nur ein ganz normaler syslog-Server, es können jedoch auch Enterprise-Lösungen wie ArcSight  dahinter stecken.

Die an zentraler Stelle aggregierten Logs können Sie dann mit einem Log Management Tool parsen und analysieren. Das auf dem MArkt bekannteste Tool zum Log Management ist Splunk. Das Problem bei Splunk ist, dass nur das erste Gigabyte, welches am TAg genutzt wird, kostenlos ist. Danach wird splunk ziemlich teuer. Viele Unternehmen gehen daher dazu über, den sogenannten ELK-Stack zu implementieren. ELK steht für ElasticSearch (richtig, unsere Volltext-Datenbank, die wir weiter oben schon kennengelernt habe), Logstash und Kibana.

Eine typische Logstash-Architektur sieht wie folgt aus.

  • Shipper sind die Komponenten, welche die Logdateien erzeugen, also beispielsweise Datenbank- und Web-SErver, Firewalls, SPSen usw.
  • Logstash ist der Broker in diesem Konzept. Logstash besteht aus einer Reihe von Plugins, welche den Input von Logs und deren Output managen. Über Logstash ist es beispielsweise möglich, die Logs an ein Monitoring-Tool wie Nagios, Icinga oder Cabbix weiterzuleiten. In unserem Beispiel wird er Output an ElasticSearch weitergeleitet. In Logstassh können Sie auch filter definieren, so das nicht der gesamte Inhalt von Logs, sondern nur die relevanten Seiten weitergeleitet werden. Das beliebteste Plugin für Logstash zum Filtern ist das Regex-Plugin grok. grok nimmt den Inhalt der Datei und extrahiert diesen anhand von REgular Expressions. Dieser Inhalt wird dann durch die definierten Filterregeln in ein semi-strukturiertes Format wie etwa JSON geschrieben.
  • Einige Kunden installieren zwischen Logstash und ElasticSearch nochmal einen dedizierten MessageBroker, wie beispielsweise RAbbitMQ. RAbbitMQ hat zwei Vorteile: Es sendet die Nachrichten an unterschiedliche Empfänger über das AMQP-Protokoll, das heißt die Nachrichten, die es ausgibt, haben einen einheitlichen Standard. Und RabbitMQ kann über Routing-Regeln festlegen, welche Komponenten wann welche Nachrichten über welchen Weg bekommen sollen.
  • die JSON-Daten können jetzt beispielsweise an ElasticSearch weitergereicht werden.

 

in-Memory Datenbanken (IMDBs)

in-Memory Datenbanken (IMDBs) wurden früher auch NewSQL-Datenbanken genannt. Es handelt sich in erster Linie um klassische relationale Datenbanken. Sie sind also ACID-Compliant und Schreiben Daten auf eine Festplatte. Jedoch lesen in-Memory Datenbank die Daten, welche sich auf der Festplatte befinden, kontinuierlich in den Arbeitsspeicher. Das heißt sämtliche Daten wrden in den Arbeitsspeicher vor geladen, und müssen daher in der Regel nur beim aller ersten Aufruf einer Tabelle initial von den Datenträgern gelesen werden. Dieser Ansatz unterscheidet sich von klassischen dAtenabnekn enorm. Denn während sie bei klassischen Datenbanken nur die zuletzt abgefragten Tabellenblöcke (also nicht einmal ganze Tabellen, den Prozess habe ich hier einmal beschrieben) im Arbeitsspeicher vorhalten, befindet sich in einer IMDB mitunter die gesamte Datenbank im Arbeitsspeicher. DAnach befinden sie sich im Arbeitsspeicher und können von dort sehr schnell abgefragt werden. In-memory Datenbanken bieten eine tolle Möglichkeit, um die Stärken von zeilenorientierten und spaltenorientierten Datenabnekn zu verbinden. Während die Daten auf den Datenträgern häufig spaltenorientiert abgelegt sind, kann die Datenbank die Tabellen im Arbeitsspeicher ablegen, wie sie lustig ist. Das beduetet Sie können beispielsweise eine Tabelle sowohl zeilen- als auch spaltenorientiert im Arbeitsspeicher ablegen, was die Abfragegeschwndigkeit für beide Formen von SQL-Statements (SELECT * und SELECT-Statements mit Filter) verringert.

Der nachteil von in-Memory Datenbank ist, dass sie in der Regel nicht so viele Daten speichern können, da Arbeitsspeicher wesentlich teurer ist als gewöhnlciher storage-Platz. Hersteller von IMDBs lösen dies häufig, indem Sie entscheiden können, welche Daten ibzw. Tabellen im Arbeitsspeicher geladen werden sollen, und welche beispielsweise auf den Datenträgern verbleiben sollen (Warm Storage) und welche auf einen Near-Line-Storage ausgelagert werden sollen (Cold Storage).

Die Ansätze der Datenbankhersteller unterscheiden sich. Unter Oracle 12c werden beispielsweise zunächst alle Tabellen im klassischen Sinne vom Datenträger gelesen und nur die zuletzt abgefragten Tabellenblöcke im Arbeitsspeicher gecached. Sie können jedoch Tabellen für den Arbeitsspeicher fixieren, so dass diese fixierte Tabelle komplett in den Arbeitsspeicher geladen wird. SAP HANA hingegen lädt stnadardmäßig die gesamte Datenbank in den Arbeitsspeicher und Sie müssen explizit wählen, welche Tabellen Sie davon ausschließen wollen. Oracle 12c verfolgt also einen Whitelisting-Ansatz für die in-Memory Speicherung von Tabellen, SAP HANA einen Blacklisting-Ansatz.

Viele verwechseln außerdem den Unterschied zwischen Oracle 12c und Oracle TimesTen. TimesTen ist ebenfalls eine in-Memory-Datenbank, die beiden Produkte sind jedoch auf unterschiedliche Query-Größen optimiert. Oracle TimesTen ist bis zu 9x schneller als Oracle 12c bei kleinen und mittelgroßen Query-Volumina. Sobald die Querys ein bestimmtes Volumen erreichen, holt die Oracle Datenbank den kleinen Bruder wieder ein. Hierbei gehen wir davon aus, dass bei beiden Datenbanken die jeweiligen Tabellen in-Memory liegen.

Scale-Up Parallelisierung in IMDBs

CPUs mit hohem Parallelisierungsgrad können besser ausgenutzt werden. Beispiel. Sie haben einen Korb voll mit Spielkarten und müssen diese nach Farbe sortieren. Dies entspricht in der Datenbank-Welt einem GROUP BY Statement. Alleine brauchen Sie für das Sortieren der Karten eine volle Stunde. Sie nehmen nun die Karten und verteilen diese gleichmäßig auf vier Leute. Jetzt brauchen Sie nur noch 16 Minuten – 15 Minuten bis der langsamste Mithelfer seinen Stapel sortiert hat, und eine Minute zum Zusammenstellen der Ergebnisse. Diese Parallelisierungentspricht in der Technik-Welt die Aufteilung eines Verarbeitungsprozesses auf mehrere CPU-Kerne und -Threads. Je mehr CPU-Kerne eine Prozessorienheit bietet, und je mehr Threads ein einzelner Kern verarbeiten kann (Hyperthreading), desto höher ist der Grad der PArallelität.

Gewöhnliche Datenbanken haben häufig ein Problem, bei der Auslastung einer CPU, weil sie die Daten, die für die Verarbeitung notwendig sind, nicht so schnell lesen können, wie die CPU sie abarbeiten könnte. Der Flaschenhals ist also an dieser Stelle nicht die CPU, sondern die Lesegeschwindigkeit des Storage-Datenträgers bzw. die Zulieferung des SAN-Netzwerkes. Dieses Problem haben sie bei in-Memory Datenbanken nicht mehr, da die Daten im Arbeitsspeicher liegen und daher für die CPU Gewehr bei Fuß liegen.

Kombinierte spalten- und zeilen-orientierte Ablage der Daten im RAM

Erinnern Sie sich daran, dass ich versucht habe, Ihnen Wide-Column noSQL-Datenbanken schmackhaft zu machen, weil sie die Geschwindigkeitsvorteile von zeilenorientierten- und spaltenorientierten Datenbanken miteinander kombinieren? Nun, IMDBs sind nochmal eine Stufe weiter als Wide-Column Stores. Warum, fragen Sie? Nun, da die Daten komplett im Arbeitsspeicher liegen, können die Daten einmal zeilenorientiert und einmal spaltenorientiert in diesem organisiert werden. Das heißt, Sie können innerhalb einer IMDB sowohl zeilenoptimierte Queries als auch spaltenorientierte Queries zusammen optimieren. Auf Storage-Ebene, also auf der Festplatte, sind die Daten bei IMDBs eigentlich immer spaltenorientiert abgelegt, wie bei einer klassischen spaltenorientierten SQL-Datenbanken (a la SAP Sybase iQ beispielsweise). Jedoch können die Daten nach dem initialen Lazy Loading, wenn Sie also im Arbeitsspeicher sind, so organisiert werden, wie es der Datenbank beliebt. Und während Sie bei einem Wide-Column Store keine Sekundär-Indizes auf die Daten setzen können, ist dies bei einer in-Memory Datenbank hingegen wieder möglich. Des Weiteren sind IMDBs eigentlich immer ACID-compliant.

Warum gibt es dann überhaupt noch Wide-Column Stores, fragen Sie? Die in-Memory Datenbanken scheinen die Wide-Column Stores in jeder Hinsicht zu schlagen. Nun, ganz so ist es freilich nicht. Auch IMDBs unterliegen dem CAP-Theorem und sind meistens zwar Consistent und Available (CA), aber nicht Partition Tolerant. Des Weiteren basiert ihre Geschwindigkeit ja auf massiver Arbeitsspeicherkapazität, und Arbeitsspeicher ist zwar heutzutage verhältnismäßig günstig, aber immer noch teurer als klassischer Storage. Weiterhin können IMDBS häufig nicht auf Commodity Hardware installiert werden, sondern müssen auf extra zertifizierten Appliances installiert werden. IMDBS sind außerdem häufig lizenzpflichtig. Wide-Column Stores haben also bis zu einem gewissen Grad ein besseres Preis-/Leistungsverhältnis, da Sie weniger Arbeitspeicher benötigen, auf Commodity Hardware installiert werden können und häufig lizenzkostenfrei sind.

Multi Temperature Data Mangement

Spaltenorientierte Datenbanken als Near-Line-Storage

 

Massively Parallel Processing (MPP)

Massively Parallel Processing steht für die parallel Verarbeitung eines Algorithmus bzw. Programms durch mehrere komplette Recheneinheiten (also Rechner mit eigenem Betriebssystem und eigner Hardware inklusive CPU Arbeitsspeicher und Netzwerkanbindung). Damit MPP funktioniert, muss auch das darunter liegende Dateisysteme für MPP geeignet sein. Dies geschieht häufig durch das Slicing von Datenblöcken. Die verschiedenen „Streifen“ an Daten werden dann von jeweils parallel von unterschiedlichen Recheneinheiten verarbeitet.

MPP basiert immer auf der folgenden Systemarchitektur

  • Ein Control bzw. Master Node führt einen Index. In diesem Index steht drin, wo sich welche Streifen der verschiedenen Daten befinden. Die Daten sind bei den Storage-Knoten als verschiedenfarbige Streifen symbolisiert. Der Master Node ist dadurch auch dazu in der Lage, Streifen zwischen den einzelnen Knoten zu verschieben und zu verteilen. Der gleiche Datenstreifen ist immer auf mehreren Storage-Knoten vorhanden, damit eine Ausfallsicherheit gegeben ist. Deswegen gibt es Streifen mit der selben Farbe auf mehreren Storage-Knoten. Wenn der Master Knoten eine Anfrage bekommt, etwas mit den Daten anzufangen, also beispielsweise Berechnungen auf Basis dieser Daten durchzuführen, teilt er den Computing Knoten Streifen zu, die diese abarbeiten sollen
  • Die Processing bzw. Computing Knoten bekommen vom Master Knoten zugeteilt, welche Berechnung sie auf welchem Datenstreifen durchführen sollen. Sie holen sich den Datenstreifen von einem der Storage Knoten ab (in Apache Hadoop sind Processing Node und Storage Node ein und der selbe Host, so dass keine Datenübertragung über Kabel o. Ä. statt findet), führen auf diesem Streifen die Algorithmik durch, die sie vom Master Knoten bekommen, und übermitteln das Teil-Ergebnis der Verarbeitungsschritte an den Master Node.
  • Der Master Node nimmt die Teil-Ergebnisse der einzelnen Prozess Nodes und fügt diese zusammen. Das finale End-Ergebnis wird dann an den Benutzer der Anwendung ausgegeben.

 

Massively Parallel Processing wird notwendig, weil:

  • die Taktfrequenzen der Prozessoren an ihre Grenzen gelangen und nur stetig ansteigen. Man kann also die zunehmende Arbeitslast nicht mehr durch Up-Scaling bewältigen, also indem man einfach eine immer stärkere Recheneinheit kauft und die Daten auf diese migriert. Um also immer mehr Daten, deren Volumen exponentiell zunimmt, in annehmbarer Zeit verarbeiten zu können, müssen mehrere Prozessoren parallel geschaltet werden.
  • Die Lesegeschwindigkeiten der Datenträger  kommt ebenfalls an ihre Grenzen und steigt nur linear an. Um diesem Problem Herr zu werden, müssen die Daten in Streifen zerlegt werden, damit sie parallel von meheren Datenträgern für die Verarbeitung gelesen werden können.

Wichtig in diesem Zusammenhang, ist zu verstehen, dass:

  • MPP nicht mit Scale-Out, auch bekannt als symmetrical Processing (SMP), zu verwechseln ist. Scale-Out, oder Sharding, ist ein sehr simples Verfahren, bei welchem mehrere Instanzen einer Anwendung oder Datenbank in einem Aktiv/Aktiv-Cluster zusammen arbeiten. Nehmen wir als Beispiel eine Datenbank. Wird eine Datenbank in einem Scale-Out Cluster betrieben, befinden sich nicht alle Daten auf einem einzigen Server. Statt dessen werden die Daten auf mehrere Server verteilt. Das ist jedoch NICHT MPP, da die Daten nicht gesliced werden. Das heißt beispielsweise, dass wenn es in der Datenbank nur zwei Tabellen gibt, sich die eine Tabele auf dem einen Server befindet und die andere auf dem anderen SErver, oder dass die Datensätze 1-200 von Tabelle 3 auf Server 1 sind und die Datensätze 200-500 von tabelle 3 auf Server 2. Wenn wir Daten aus Tabelle 1  oder die Datensätze 1-200 von TAbelle 3 abfragen, reden wir mit Server 1, fragen wir Daten aus Tabelle 2 oder die Datensätze 200-500 von Tabelle 3 ab, reden wir mit Server 2.  Bei MPP hingegen sind die Datenstreifen viel feiner, so dass unsere beiden Server immer husammen arbeiten würden. Somit ist es nicht möglich, dass beide Server gleichzeitig an der selben Datenabfrage arbeiten. Deshalb ist ein klassischer scale-Out Knoten über Sharding kein MPP
  • Auch ein Striping der Daten auf Storage-Ebene ist nicht mit MPP zu verwechseln. Hierzu zähle ich sowohl das Striping auf Hardware-Ebene, welches beispielsweise durch ein RAID 0 hergestellt werden kann, als auch auf Software-Ebene, welches beispielsweise durch den Logical Volume Manager (LVM) oder durch ein Software-Raid (durch mdadm) unter Linux hergestellt werden kann. Hierbei werden die Daten zwar über mehrere Datenträger gestriped, jedoch ergeben sich im Vergleich zu MPP noch folgendes Einschränkungen:
    • In der Regel befinden sich alle Datenträger, über die per RAID gestriped wird, in lediglich einem einzigen Storage-System.  Denn der RAID-Controller, welcher das RAID herstellt, ist innerhalb des Storage-Systems verbaut. Bei MPP können die Daten über mehrere Storage-Systeme hinweg gestriped werden.
    • Beim Software-Striping wäre es möglich, Datenträger von verschiedenen Storage-Systemen in ein Software-RAID zusammen zu fassen, jedoch haben wir dann das Problem, dass die Storage-Systeme in der Regel nur von einer einzigen Recheneinheit gemountet werden können, und für alle anderen Recheneinheiten gesperrt werden. Das heißt beim Software-RAID kann immer nur  eine CPU an den Daten arbeiten. Eine Verteilung der Rechenschritte an mehrere CPUs erfolgt nicht.

Jetzt fragen Sie sich zu guter Recht: Sind in-Memory Datenbanken (IMDBs) gleichzeitig MPP-Datenbanken? Schließlich müssen bei einer in-Memory Datenbank die Daten nicht gesliced werden, da die Daten vollständig im Arbeitsspeicher liegen. Hat man also zwei oder mehr in-Memory Datenbanken mit den selben Daten am laufen, können beide Datenbanken mit den Daten im Arbeitsspeicher rechnen. Trotzdem sind in-Memory Datenbanken per se nicht MPP-fähig. Es ist dann in so fern möglich, parallele Verarbeitung von Datenbeständen anzustoßen,als dass man eine Verarbeitung durch entsprechende SQL-STatements aufteilen kann. Wenn wir eine Tabelle haben mit 100 Datensätzen, können Sie auf Server 1 die berechnungen auf die Datensätze 1-50 und auf Server 2 die Berechnungen auf die Datensätze 51-100 anwenden. Das ist per se kein Problem, so lassen sich die CPUs der beiden IMDBs gemeinsam auslasten. Jedoch ist eine in-Memory Datenbank per se noch lange nicht MPP-fähig. Warum?

  • Nehmen wir an, die Tabelle enthält eine Spalte vom Datentyp LONGTEXT. Die Datensätze 1-50 machen 80% des Speicherplatzes der Tabelle aus. Die Datensätze 51-100 nur noch 20%. Teilen sich Server 1 und Server 2 also die Last gleichmäßig untereinander auf? Die Antwort ist nein
  • In heutigen relationalen Datenbanken gibt es nicht nur einen klassischen Storage, in welchem sie nur klassische Datensätze vearbeiten können, sondern bieten beispielsweise auch die Möglichkeit, unstrukturierte Daten in Form von Key/Value-Dokumenten oder JSON-Strings abzulegen. Hier fällt es Ihnen schwer, anhand von SQL-Statements die Berechnungsleistung aufzuteilen.

Sie fragen jetzt zurecht: Aber wenn in-Memory Datenbanken per se kein MPP betreiben, wann sind sie derzeit dann das Maß aller Dinge? Die Antwort ist, weil derzeit die Verarbeitung über Scale-Up, also einfach das Nachkaufen einer Appliance mit mehr CPU-Kernen, noch möglich ist. Aktuell gibt es z. B. zertifizierte SAP HANA Appliances mit 120 CPU-Kernen und Intel Hyperthreading. Das führt dazu, dass Sie einen Parallelisierungsgrad von 240 haben. Das ist genug für die meisten DAX-Unternehmen. Diese Entwicklung wird sich jedoch mit der Zeit ändern, da das Datenwachstum rapider voran schreitet als die Entwicklung der CPU-Technik nach dem Moore’schen Gesetz . An dieser Stelle muss ich jedoch fairerweise sagen, dass   ich an dieser Stelle die mögliche Marktreife der Memristor- oder Quantencomputer-Technik nicht mit einbezogen habe. Kommt es an dieser Stelle zu einem Durchbruch, ist die Nachhaltigkeit des Scale-Up-Faktors wieder gegeben.

Viele im Big Data Segment wichtige Technologien verwenden das MPP-Prinzip. Die wichtigsten darunter sind Apache Hadoop und MPP-Datenbanksysteme. Letztere fungieren häufig als verteiltes Data Warehouse System.

MPP Datenbanken

MPP Datenbanken verwenden die Architektur  und das Konzept von MPP, um klassische traditionelle relationale Datenbanken über hunderte oder tausende von Knoten für parallelisierte Datenverarbetiung zu skalieren. MPP-Datenbanken gibt es sowohl zeilen- als auch spaltenorientiert. Vertica Database, Actian Matrix, Greenplum und Sybase iQ sind beispielse für spaltenorientierte MPP-Datenbanken.

Das Problem bei MPP-Datenbanken ist, dass die Daten zunächst für die Verarbeitung vorbereitet werden müssen. Denn die Daten sitzen innerhalb einer Datenbank. Das bedeutet, die Daten müssen Constraints erfüllen, damit sie in die Datenstruktur der Datenbank passen. Das ist ein Problem, welches sie bei anderen MPP-Technologien wie beispielsweise Apache Hadoop nicht haben.

in-Memory  Datenbanken kombiniert mit MPP

Der neueste Schrei der Technik ist die Kombination der in-Memory Technik mit MPP. Hierbei werden die Daten, welche sich im Arbeitsspeicher der in-Memory Datenbank befinden, über mehrere Knoten hinweg gesliced. Bevor Sie jetzt aufschreien, dass dieses Szenario ja das unschlagbare Nonplus-Ultra wäre, Vorsicht.

In allen Scale-Up Szenarien, in denen die CPU nicht der Flaschenhals ist, sondern die Zulieferung der Daten an die CPU einer einzelnen Recheneinheit über die Datenträger oder das Netzwerk, sind sie mit einer Standalone in-Memory Datenbank selbstverständlich schneller, als bei einer in-Memory MPP Datenbanken. Denn bei der in-Memory MPP Datenbank müssen sie schließlich die Ergebnisse der Datenverarbeitung zusammen führen. Sie müssen also Daten über das Netzwerk übertragen. Dieser Effekt entfällt selbstverständlich bei einem in-Memory Scale-Up Szenario. Da wir gelernt haben, dass aktuelle Appliances bis zu 120 CPU-Kerne anbieten, tritt dieser Effekt erst sehr spät ein.

in-Memory MPP rentiert sich erst dann, wenn Sie kein Scale-Up mehr betreiben können, sondern auf Scale-Out angewiesen wären. Man muss aus meiner Sicht schon zu den Fortune 500 Unternehmens gehören und Big Data seit mehreren Jahren betreiben, um so weit zu kommen.

Es gibt diverse in-Memory Datenbanken, die MPP-fähig sind, darunter Oracle Exadata, EXASOL und SAP HANA.

Apache Hadoop erklärt – simple und einfach

Apache Hadoop ist eine MPP-fähige Technologie, die jedoch nicht auf einer Datenbank basiert. Stattdessen arbeitet Apache Hadoop auf Basis eines Dateisystems, welches beliebige Daten speichern kann, also keine Constraints auf diese Daten anwendet (es sei denn sie programmieren speziellen Code dazu). Der Vorteil hierbei ist, dass sie die Daten vor der parallelen Verarbetiugn nicht vorbereiten, sondern sie einfach im Rohdatenformat abspeichern können. Außerdem läuft Apache Hadoop im Gegensatz zu den meisten MPP-Datenbanken auf einfacher Commodity x86-Hardware, wohingegen bei den Datenbank-Pendants häufig dedizierte Appliances oder Enterprise-level Hardware gekauft werden muss. Apahce Hadoop begnügt sich also mit geringeren Anschaffungskosten.

Jedoch gibt es auch Nachteile gegenüber MPP-Datenbanken. Im Gegensatz zu MPP-DAtenbanken eignet sich Apache Hadoop im Basisumfang nicht für Echtzeitanalysen, da die Funktiosnweise von MapReduce und dem Dateisystem HDFS batch-basiert ist. Dieses Problem wurde jedoch gewissermaßen durch die in-Memory Funktioanlität von Apache Spark behoben, wobei MPP-Datenbanek  jedoch basolut gesehen immer noch leistungsfähiger sind

Apache Hadoop eignet sich auch nicht zur Transkationsverarbeitung, unter Anderem weil Hadoop nicht ACID-compliant ist. Sie sollten also  nicht auf die Idee kommen, beispielsweise ein ERP-System auf Basis von Hadoop zu betreiben.

Hadoop eignet sich am besten für das parallele Lesen und Verarbeiten großer Datenmengen. Das zeigt bereits die Standard-Blockgröße von 64 MB im Hadoop File Systems HDFS. Die zwei wichtigsten Konzepte von Apache Hadoop sind Map und Recude. Das technische Prinzip hinter MapReduce lässt sich anhand einer Küche erklären.

Map: Wenn es für einen Koch zu schwierig wird für alle Besucher eines Restaurants zu kochen, weil so viele Kunden gleichzeitig bestellen, stellt man mehrere Köche ein. Dabei zeigt es sich, dass es besser ist, jeden Koch einen bestimmten Teil der Gerichte kochen zu lassen, als jeden Koch eine vollwertige Mahlzeit zubereiten zu lassen. So gibt es einen Sauciere, der sich nur um die Soßen kümmert, einen Koch, der für das Fleisch zuständig ist, usw. Warum das so ist, ist logisch. Wenn sich jeder Koch nur um eine Zutat kümmert, kann man ihm einen eigenen Schrank zur Verfügung stellen, in welchem sich  nur seine Zutaten und das Geschirr befinden, welches er braucht. DAdurch verhindert man, dass alle Köche gleichzeitig zum Schrank rennen, in dem das Gemüse gelagert ist, und sich dadurch ein Stau bildet. Außerdem kochen dann nicht zwei Köche die gleiche Sauce, sondern nur ein Koch bereitet die Sauce für beide Gerichte zu. Das verhindert als Redundanz und Overhead.

Reduce: Am Ende, wenn alle Zwischenergebnisse für ein Gericht erstellt wurden, geht der chef hin und erstellt aus den Teilerzeugnissen das Gericht, welches an den Kunden ausgeliefert wird. Den Köchen ist es egal, ob bereits ealle Teilerzeugnisse für ein Gericht fertig sind – sie arbeiten bereits am Teilerzeugnis für das nächste Gericht. So kommt es bei den anderen teilprozesen nicht zum Stau, wenn es mal irgendwo hängt.

Apache Hadoop funktioniert genau nach diesem Konzept. Der Chef-Koch, der am Ende alle Teilergebnisse zu einem Gesamtergebnis zusammen fügt, ist der sogenannte Master Node. Wir kennen desn Master Node bereits aus der Abbildung weiter oben, wo ich die Architektur von MPP erklärt habe. Die Data nodes sind die einzelnen Köche, die sich auf einen Teilbereich spezialisiert haben, auch diese sind uns bekannt. Jeder Data Node in Apache Hadoop hat Datenstereifen von verschiedenen Dateien im dateisystem inne. Das heißt ein Data Node hat Zeile 100-300 von Dokument 1, und gleichzeitig Zeile 200-500 von Dokument 2, und ein anderer Data Node hat Zeile 0-100 on Dokument 1 und 0-200 von Dokument 2. Jeder Data Node arbeitet nur mit den Datenstreifen, also mit den Zutaten, die ihm zur Verfügung stehen. Kochen steht an dieser Stelle für das Durchführen von Berechnungsschritten. Die Teilergebnisse leiten die Data Nodes am Schluss an den Master Node weiter. Dieser stellt die Teilergebnisse zu einem Endergebnis zusammen und liefert sie aus.

Hadoop ist ein quellofenes Projekt, ähnlich wie Linux. wie auch bei Linux gibt es verschiedene Distributoren, die Hadoop in einem vorgefertigten Paket ausliefern. Die bekanntesten Hadoop-Distributoren für eine on-Premise Installation sind Cloudera, MapR, IBM und Pivotal,. Amazon und Microsoft bieten des Weiteren eine Hadoop-Cloud. Im Gegensatz zu Linux jedoch, wo jeder Distributor seine eigene Admin-Verwaltungsoberfläche hat (z. B. YaST unter SuSe Linux und die OpenShift-Adminkonsole unter Red Hat), nutzen die Hadoop-Distributoren überall möglichst einheitliche Administrationstools, um die Verwaltung von Hadoop zu vereinheitlichen.

Hadoop unterstützt im Auslieferungsumfang keine SQL-ähnlcihe Abfragesprache. Diese Funktionalität wurde jedoch initial mit Apache Hive und später mit den leistungsfähigeren Pendanten Cloudera Impala, Pivotal HAWQ und Apache Spark umgesetzt. Unter Apache Spark wird Hadoop in-Memory fähig. Das heißt, die Daten werden zwar noch durch MapRecude von den DAtenträgern gelesen und geschrieben, jedoch werden die Daten im Arbeitsspeicher nach einem initialen Lazy Loading vorgehalten und können dort dann schnell verarbeitet werden.

Hadoop muss seine Daten nicht zwingend im Dateisystem HDFS halten, sondern kann auch mit HBase, Amazon S3 oder Apache Cassandra zusammen arbeiten.

Data Warehouses

Data Warehouses bestehen aus einer verteilten Datenbank im Zentrum und einer Anwendung zur Analyse der in dieser verteilten Datenbank gespeicherten Daten. Data Warehouses gibt es nun schon seit annähernd 40 Jahren. Data Warehouses bestanden früher aus einfachen, spaltenorientierten Datenbanken, die in einem Scale-Up oder Scale-Out Szenario betrieben wurden, also nicht auf MPP, sondern auf SMP-Verarbeitung basieren. In diesem Zusammenhang wurden diese Lösungen vor allem für das finanzielle und operationale Reporting verwendet. Dazu wurden Daten von den umliegenden Quellsystemen aggregiert und die Daten verschiedener Entitäten (Kunden, Bestellungen, produkte, Lieferanten, …) in einer Faktentabelle verbunden, um auf dieser Analysen durchzuführen. Größtenteils handelt es sich hierbei um operationale Analysen, also beispielsweise: Wie viele Bestellungen fallen im  Monat X auf welche Kunden, wie viele Produkte werden in den einzelnen Regionen im Jahr verkauft, usw. Datenbanken für Data Warehouses sind häufig spaltenorientiert, weil sich diese besser für Analysezwekce eignen, wie weiter oben schon einmal erörtert.

Data Warehouses haben also das Problem, dass immer dieser ETL-Prozess notwendig ist. ETL steht für Extract, Transfer and Load. Die Daten werden aus den Quellsystemen extrahiert, in das notwendige Zielschema transformiert und im Zielformat (beispielsweise als Faktentabelle) in das Data Warehouse geladen.

Dieser klassische ETL-Prozess ist jedoch für heutige Anwendungsszenarien nicht immer geeignet. Sie können sich beispielsweise gut vorstellen, dass mit diesem ETL-Prozess schlecht eine Echtzeit-Analyse von Daten für Predictive Analysis möglich ist. Deswegen wird in modernen Data Warehouses ein neue rAnsatz gefahren.

Heutzutage bestehen Data Warehouses meistens entweder aus in-Memory Datenbanekn (IMDBs) oder aus einer Massively Parallel Processing Datenbank (MPP).  Man unterscheidet zwischen den folgenden Szenarien.

Analysen werden auf dem Quellsystem selbst durchgeführt

Quell- und Zielsystem sind die selben Systeme. Man hat also beispielsweise nicht mehr ein ERP System, auf welchem beispeilsweise Buchhaltung, Lagerverwaltung, Controlling und Vertrieb durchgeführt wird, und ein Data Warehouse, auf welchem Aanlysen durchgeführt werden, sondern man vereint beides in einem System. Dieses Szenario eignet sich vor allem dann, wenn man anstatt mehrerer kleiner Quell-Systeme ein großes zentrales System hat, welches die transaktionalen Daten erzeugt, die analysiert werden sollen, und das System durch Scale-Up- oder Scale-Out-Sizing dazu in der Lage ist, sowohl die Last durch die transaktionale Nutzung als auch durch die analytische Nutzung zu bewältigen.

eliminiert man einige Flaschenhälse

  • es müssen keine Daten mehr über das Netzwerk übertragen werden. Das Netzwerk als Flaschenhals entfällt also
  • Der Mehr-Aufwand für die Extraktion und das Laden der Daten entfällt. Im klassischen ETL-Prozess müssen die Daten aus dem Quellsystem einmal von den Datenträgern gelesen, dann von der CPU transformiert, und im Zielschema von den Datenträgern des Zielsystems geschrieben werden. Dieser Aufwand entfällt nun. Das bedeutet, man spart sich jeweils einen Schreib- und Lesevorgang auf Storage-Ebene und einen großen Verarbeitungsschritt auf der CPU
  • Sie sparen damit auch Speicherkapazität, weil sie die für die Analyse relevanten Daten nicht mehr doppelt speichern müssen.

Jedoch schafft man sich durch diese Architektur auch einige Flaschenhälse. Da nun sowohl die Business User als auch die Analysen auf dem System laufen, ist auf dem System ständig was los. Damit die Performance des Systems nicht in den Keller geht, müssen die Daten für beide Analyseprozesse schnell zur Verfügung stehen. Pobleme sind dabei häufig

  • Die Lesegeschwindigkeit der Datenträger. Dies löst man häufig, indem die zentrale Datenbank der Anwendung als eine in-Memory Datenbank realisiert. Somit werden die Daten nach einem initialen Lazy Loading aus dem Arbeitsspeicher gelesen.
  • Die Schreibgeschwindigkeit der Datenträger. Ergebnisdaten für die Analysen und transaktionale Daten im Tagesgeschäfts müssen nun zeitgleich geschrieben werden. Dies löst man durch das Striping der Daten durch typische Skalierungslösungen wie Hardware- und Software-RAIDs. Verwechseln Sie dieses Striping jedoch nicht mit dem Striping, welches wir bei MPP besprochen haben. Der Unterschied sollte jetzt klar sein.
  • Im klassischen ETL-Prozess ist die Datenbank des transaktionalen Quellsystems zeilenorientiert (OLTP-Datenbank), um das Schreiben von Daten (INSERT, UPDATE und DELETE Statements) sowie SELECT * Abfragen mit LIMITs zu beschleunigen. Die Datenbank des Data Warehouses ist spaltenorientiert (OLAP-Datenbank), um analytische Abfragen zu beschleunigen. Da sie jetzt allerdings beide Use Cases  in einem System haben, haben Sie mit einer klassischen relationalen Datenbank ein Problem. Entweder leidet die Performance ihrer Schreibprozesse, oder die Performance der analytischen Leseprozesse. Dieses Problem löst man mit dem INSERT Only Prinzip.Dementsprechend werden UPDATE und DELETE STatements per se nicht mehr durchgeführt. Statt dessen wird ein neues INSERT-STatement durchgeführt, welches einen aktuelleren Datensatz enthält. Das ganze funktioniert technisch so. Der Column Store der Datenbank hat einen MAIN und einen DELTA Part. Die alten Datensätze für unseren Mitarbeiter, unsere Abteilung und unsere Kostenstelle liegen im MAIN Part der Datenbank.  Der Main Store ist spaltenorientiert und komprimiert, um die Leseperformance zu optimieren. Jedes mal den Main Store zu dekomprimieren, die Änderungen rein zu schreiben und ihn wieder neu zu komprimieren, wäre sehr ressourcenintensiv. Die Performance würde in den Keller gehen, weil nachfolgende Schreibvorgänge immer sehr lange warten müssten, bis ihre Vorgänger fertig und abgeschlossen sind. Der Delta-Store ist aber unkomprimiert, um die Schreib-Performance zu optimieren.  Dies würde zu sehr langen Datenbank-Sperren auf dem System führen. Im Insert Only Prinzip werden neue Datensätze aber zunächst in den sogenannten Delta-Store eingefügt, was wesentlich schneller geht. In regelmäßigen Abständen erfolgt ein Merge, der die Datensätze vom Delta in den Main Store schreibt. Es wird also nur noch einmal für einen ganzen Stapel von Änderungen, statt jedes mal, der Main Store angepackt.Zum Löschen von Datensätzen gibt es eine dritte Tabelle. Wenn Sie ein DELETE-Statement ausführen, wir in diese Delete-Tabelle einfach nur die ID des Datensatzes und ein Delete-Flag gesetzt. In regelmäßigen Abständen werden die Einträge der Tabelle genommen und aus dem Main Store tatsächlich gelöscht. Ist der Datensatz aus dem Main Store gelöscht, kann der Eintrag in der DELETE-Tabelle ebenfalls entfernt werden.Wenn ein Benutzer ein SELECT Statement absetzt, frägt die Datenbank erst den Main Store, und danach den Delta Store ab. Wenn es im Delta Store einen neueren Eintrag für einen Datensatz im Main Store gibt, wird der Datensatz im Main Store ignoriert, und der Datensatz im Delta Store berücksichtigt.  Zu guter letzt wird in der DELETE-Tabelle geguckt, für welche der selektierten Datensätze ein Delete Flag gesetzt wurde, und ignoriert diese. Damit ist sicher gestellt, dass der Benutzer trotz INSERT Only Prinzip immer den aktuellen Stand der Daten sieht.
  • Da Sie nur noch ein System statt zwei Systeme haben, verringert sich die Anzahl ihrer CPU-Kerne. Das heißt die CPU kann in diesem Szenario zum Flaschenhals werden, da diese nun für analytische und transaktionale Berechnugnen zuständig ist. Bis zu einem gewissen Grad kriegen Sie dieses Szenario durch Scale-Up in den Griff. Reicht die CPU auf einem Datenbank-Knoten nicht mehr aus, können Sie  durch Scale-Out zumindest einzelne Datenbankobjekte wie etwa Tabellen auf verschiedene Knoten verteilen. Damit sind nicht mehr alle Tabellen auf einem Knoten, sondern diese sind nun verteilt, was sich wieder positiv auf die CPU-Auslastung auswirkt. Problemtaisch wird es dann, wenn ihre Datenbank irgendwann so groß wird, dass die CPU-Kerne eines einzelnen Knotens nicht mehr mit dem REchenaufwand der ihnen zugewiesenen Datenbankobjeke fertig werden. Dieses Problem löst man mit Massively Parallel Processing (MPP).

Das Data Warehouse bleibt zentral

In diesem Szenario haben Sie immer noch ein zentrales Data Warehouse. Alle Quellsysteme liefern ihre Daten an das Data Warehouse aus. Dieses Szenario wird im Vergleich zum obigen System meist gewählt, wenn

  • Sie eine verteilte  Systemlandschaft haben und daher nicht einfach die Analysen auf dem Quellsystem selbst durchführen können, weil es mehrere Quellsysteme gibt.
  • Die CPU bei Ihnen zum Flaschenhals wird, w,eil Sie für Ihre Analysen sehr komplexe Berechnungen oder Transformationen durchführen müssen  und die Datenbank des Data Warehouses nicht MPP-fähig ist. Häufig muss man sich bei der Auswahl einer Datenbanklösung beispielsweise noch entscheiden, ob man eine in-Memory Datenbank oder eine MPP-Datenbank möchte.
  • Aus Lizenzgründen, weil das Quellsystem ein Lizenzmodell pflegt, welches nach verbauten Chipsätzen abrechnet. Da Sie jedoch im Quellsystem nicht so viele CPUs brauchen, sondern diesen Bedarf eher im Data Warehouse sehen,trennen Sie das Data Warehouse vom Quellsystem, um an dieser Stelle Lizenzkosten einzusparen.

Bei einem zentralen Data Warehouse laufen Sie Gefahr, dass bei Ihnen die Datenübertragung, also das Netzwerk selbst, zum Flaschenhals wird.

Data Lakes

ein Data Lake ist, wie ein Data Warehouse, ein zentrales Ablage-Repository für Daten. Ein Data Lake führt ebenfalls Daten von verschiedenen Quellen zusammen und erleichtert dadurch das Reporting. Ein wesentlicher Unterschied des Data Lakes im Vergleich zum Data Warehouse ist, dass er die Daten in ihrer Rohform speichert. DAs heißt, der data Lake speichert die Daten so, wie sie von der Quelle geliefert werden. Das Ziel des Data Lakes ist nämlich, möglichst wenig Daten zu verlieren, frei nach dem Motto: „Es ist günstigert, einfach alles zu speichern, als zu entscheiden, was man davon weg werfen kann“. Das bedeutet aber gleichzeitig, dass sie für die Analysen die Rohdaten nehmen und immer wieder aufs neue Transformieren müssen. Es erfolgt also auch keine umstrukturierte speicherung, beispielsweise in einem Star- oder Snowflake-Schema, wie in einem klassischen Data Warehouse. Man macht sich beim Data Lake im Vornherein keine Gedanken darüber, welche Analysen man auf den Daten fahren will.

Das heißt, ein Data Lake stellt hohe Anforderungen an die Performance der Datenverarbeitung, insbesondere im Hinblick auf die CPU. Ein Data Lake macht daher in der Regel nur in Verbindung mit Passive Parallel Processing (MPP) Sinn. Bei einem dAta Lake gibt es also überhaupt keinen ETL-Prozess. Transofmrationen von Daten, die für eine Analyse notwendig sind, werden on-the-fly von er Recheneinheit durchgeführt. Dieses Prinzip wird als Schema on Read bezeichnet. Man bring diee Daten erst beim LEsen in das erforderliche Schema, wo hingegen das klassische Schema on Write ddes Data WArehousings die Daten schon in das gegebene Analyseformat schreibt.

Aufgrund der Tatsache, dass die Daten in Data Lakes im Rohdatenformat vorliegen, ist es sehr einfach, mit einem Data LAke als Basis eine neue Analyseprozedur zu implementieren. Ein Data Lake ist also sehr agil. Sie können sofort die Daten nehmen und einen neuen Report schreiben.

In einem Data Warehouse hingegen ist die Datenstruktur schon vorgegeben. Entscheiden Sie sich heute, einen neuen Report zu generieren, welcher die Daten in einer anderen Basis-Struktur benötigt, müssen Sie die Daten umformen. Das ist nicht sehr flexibel.

genau so wie man ein Data Warehouse in der selben Datenbank betreiben kann, in der auch die Quelldaten entstehen (die richtigen Vorbereitungen voraus gesetzt), liefert auch ein Data Lake Daten für transaktionale Prozesse.

Der Prozess der Zusammenführung Daten unterschiedlicher Quellen und Ursprungsformate an einen zentralen Ort wird übrigens Data Blending genannt.

Die Kombination von Data Lakes und Data Warehouses

Obwohl sich das Konzept des Data Lakes so neu und ofrtschrittlich anhört, sollte man nicht daran denken, Data Warehouses komplett als obsolet anzusehen. DAta Warehoueses haben nach vie vor eine Daseinsberechtigung. So ist beispielsweise die klassische Datenmodellierung von Data Warehouses anhand von Dimensionen notwendig, um ein Drill-Down bzw. Drill-Up-Verfahren anbieten zu können. Gerade für die interaktive Analyse, wo ein Business Analyst oder ein Controller sich beispielsweise über ein Excel-Frontend on-the-fly eine Analyse anhand von Filtern zusammen klickt, hat man die Daten lieber in einer vor-modellierten Form vorliegen, als in Rohform anhand eines JSON-Strings oder in einem Key-Value-Pair.  Die Datenmodellierung in einem Data Warehouse macht also für viele Einsatzgebiete der Business Intelligence weiterhin Sinn. Wenn Sie nur einen Data Lake haben, erhöht sich die Zeit die ihre Mitarbeiter brauchen, um ein BI-Deliverable wie etwa einen Monatsbericht der Hauswartungen bei einem Waschmaschinenhersteller zu generieren, enorm. Sie wollen aber durch die Einführung eines Data Lakes die Leistungsfähigkeit der Business Intelligence nicht schwächen, sondern stärken. Anstatt also der Vorstellung aufzusitzen, Data Lakes würden Data Warehouses ersetzen, sollte man den Data Lake als neue Komponente in der Datenlandschaft wahr nehmen. Die folgende Abbildung verdeutlicht das.

Ganz links sind beispielhaft einige Quellen für Daten bezeichnet, die in den DAta Lake geschrieben werden. Rechts davon befindet sich unter Data Lake. Dieser stellt die Daten an andere Analyse-Tools, Geschäfts-Systeme und an unser Data Warehouse bereit (gelbe Pfeile). Gleichzeitig schreiben die Geschäfts-Systeme und das Data Warehouse Daten in den Data Lake zurück (grüne Pfeile). Die Daten sind beispielsweise als historsiche Daten weiterhin wertvoll und dienen für künftige Analysen. Über den klassischen ETL-Prozess liefern außerdem die klassischen Geschäfts-Systeme Daten an das Data Warehouse (blauer Pfeil)

Near Real-Time Data Replication

Informatica

Event Stream Processing (ESP) bzw. Complex Event Processing (CEP)

Die Idee hinter Event Stream Processing ist die Vearrbeitung von Events, also Ereignissen jeder Art, die Business-relevant sind. Event Stream Processing bezeichent die Idee, Ereignisse kontinuierlich zu verfolgen und zu verarbeitung von Events kann automatisiert auf diese reagiert werden.

Beispiel. Über einen Webcrawler holt immer die aktuellsten Börsenkurse von einer Börsen-Seite ab. Und das in einem ziemlich kurzen Intervall, sagen wir alle 5 Sekunden. Sie wollen auf Basis des aktuellen Kurse automatisiert auf Kursschwankungen reagieren. Nehmen wir jetzt mal an, Sie würden diese Daten in einer klassischen relationalen Datenbank speichern. Das wäre äußerst umständlich. Denn zuerst müssen die Daten, die der Webcrawler aus der Börsen-Seite zieht, in eine Form gebracht werden, die in der Datenbank speicherbar ist. Das heißt die gecrawlten Daten müssen in ein SQL-STatement transformiert werden. Danach wird das SQL INsert Statement ausgeführt und der Datensatz in die Datenbank geschrieben. Um alle 5 Sekunden  den aktuell aus dem Web gecrawlten Datensatz in die Datenbank zu schreiben, üssen alle 5 Sekunden eine neue SQL-Query an die Datenebank geschickt werden.  Erst nachdem der DAtensatz in der Datenbank gespeichert ist, kann auf diesen Datensatz eine SQL-Query abgesetzt werden.  Um die Datenbank alle 5 Sekunden abzufragen, muss die SQL-Query alle 5 Sekunden immer wieder neu an die Datenbank gesendet werden. Um die Daten abfragen zu können, müssen sie als Datensatz gespeichert werden – entweder wir die Datenbank also sehr schnell voll, oder wir müssen alle Stunde die Datenbank durch ein DELETE-STatement leeren. DAs bedeutet, alle 5 Sekunden betreiben wir einen riesen Aufwand, um Daten in eine Datenbank zu bekommen und sie anschließend zu lesen.

Event Stream Processing funktioniert anders und bewältigt diese Problematik besser. Beim Event Stream Processing werden die Daten aus der Börsen-Website gecrawlt und on-the-fly gefiltert und über die Event Streaming software verarbeitet. Der Event Stream Processor liefert dann direkt den Output, den wir wollen. Ein Event Stream Processor ist stateless. Das bedeutet, der Event Stream processor speichert die Daten, die er verarbeitet, nicht. Er verarbeitet sie noch im Arbeitsspeicher, liefert den Ausgabewert, und vergisst die Daten dann gleich wieder. Wenn Sie jetzt sagen: Ja, aber ich kann doch auch z. B. eine Python-Anwendung schreiben, welche die Daten aus dem Web crawlt, die Daten in ein Array speichert, das Array verarbeitet und dann direkt das Ergebnis ausspuckt. Das ist richtig. Der Mehrwert eines modernen Event Stream Processors liegt darin, dass er die selbe Logik wie eine SQL-Datenbank anbietet, ohne eine zu sein. Das bedeutet, wenn die Daten vom Webcrawler rein kommen, können sie im Event Stream Processor Filter festlegen. Sie können die Daten also noch einmal filtern, beispielsweise nach Aktien-Index, oder Daten nur verarbeiten, wenn sie einen gewissen Wert über- oder unterschreiten. Dazu können Sie im Event Stream Processor Queries definieren, die ähnlich aufgebaut sind wie bei SQL. Sie kombinieren nun also die on-the-fly Verarbeitung einer Stand-Alone-Anwendung mit den Filter- und Sortiermöglichkeiten einer SQL-Datenbank. Im Endeffekt sparen Sie also

  • IT-Ressourcen, da Sie keine SQL-Statements mehr über das Netzwerk schicken müssen und keine Daten mehr permanent speichern müssen
  • Zeit, weil Sie in Ihrer Anwendung keine eigene Logik programmieren müssen, um die eingehenden Daten zu filtern und zu sortieren

Zusätzlich bietet ein Event Stream Processor Logiken zur Erkennung von Mustern. Sie können also Pattern REcognition und MAchine LEarning Szenarien auf die Daten on-the-fly anwenden, ohne diese vorher umständlich auf Vorrat in einer Datenbank speichern zu müssen. Dadurch ist die Geschwindigkeit, in der Sie ihre Analyseergebnisse heraus bekommen, schneller.

Ein weiterer Mehrwert von event Stream prozessoren im Vergleich zur eigenen Anwendung ist, dass sie, ähnlich wie MPP-Datenabnken und Hadoop, die Events in mehrere Streams zerlegen können. Die Daten, die über die verschiedenen Streams herein kommen, werden auf verschiedene Knoten aufgeteilt und von diesen dann parallel verarbeitet. Das heißt die Event Stream prozessoren sind gut skalierbar.

Wenn Sie jetzt sagen: „Was ist denn, wenn ich einen Teil der Börsenkurse nun tatsächlich speichern möchte, beispielsweise die Börsendaten der letzten 4 Stunden?“ Auch das ist mit einem klassischen Event Stream processor möglich. Dieser ist dazu in der Lage, anhand von Filtern zu entscheiden, welche Daten stateless durch den Stream Processor geschrieben werden, und welche zusätzlich in einem sogenannten „Time Window“ gepseichert werden. Sie können beispielsweise festlegen, dass in dem Window alle Daten der letzten 4 Stunden gespeichert werden, bis das Window geschlossen und ein neues geöffnet wird. Das Window können Sie vor der Schließung selbstverständlich in einen permanenten Speicher wegsichern, um historische Daten aufzubewahren.

In der frühen Zeit der Event Stream Processing engines hatte man zwischen zwei Arten von Stream Processing Ansätzen unterschieden.

  • Event Stream Processing bietet klassischerweise den Vorteil der Parallelisierung und Skalierung. Das hießt wie eine MPP Datenbank oder Apache Hadoop werden Streams zerlegt und von mehereren Knoten parallel verarbeitet. Dafür bieteten ESP-Engines der alten Generation keine Filter und SQL-ähnliche Query Logik, was bedeutet, dass Entwickler ihren eigenen Code schreiben mussten, um diese Logik zu implementieren.
  • Complex Event Processing Engines waren in der Regel nicht skalierbar. Es gab nur einen oder zwei zentrale Knoten, welche alle Streams entgegen nahmen und verarbeiteten. DAfür bieten CEP-Engines der alten Generation eine SQL-ähnliche Abfragesprache.

Heutzutage verschwimmt dieser Unterschied zwischen den beiden Arten. Moderne Streaming Engines wie etwa der SAP Event Stream Processor verbinden die Vorteile der beiden technologien.

Neue Dateisysteme

Wir haben uns bisher immer auf einer sehr hohen technischen Ebene – meist auf Ebene der Datenbanken – unterhalten. JEtzt wollen wir mal eine Ebene tiefer tauchen und uns auf der Ebene der Dateisysteme bewegen. Sie kennen vielleicht einige Dateisysteme aus der Praxis, darunter die Windows-Standard-Dateisysteme NTFS, FAT32 und exFAT, oder Linux/Unix-Dateisysteme wie ext4. Während dies größtenteils lokale Dateisysteme sind, können Sie diese oft in verteilte Dateisysteme wie NFS koppeln und sie somit mehreren Knoten zur Verfügung stellen. Das Problem: diese verteilten Dateisysteme sind nicht parallelisierbar. In der Regel kann immer nur ein Knoten gleichzeitig mit einer Datei umgehen. Es können also nicht mehrere Recheneinheiten parallel an verschiedenen Stellen einer Datei rechnen. Dadurch sind diese Dateisysteme nicht skalierbar.

In der Welt von Big Data brauchen wir, um Massively Parallel Processing (MPP) zu ermöglichen Dateisysteme, die dazu in der Lage sind, Daten in Streifen zu schneiden, auf verschiedene Knoten zu verteilen und den Zugriff auf diese Datenstreifen durch mehrere CPUs möglich zu machen. Diese Dateisysteme nennt man distributed and parallel File Systems. Derzeit gibt es zwei große Player auf dem Feld der verteilten Dateisysteme – GPFS und HDFS. Es gibt allerdings auch noch andere Vertreter, wie beispielsweise Lustre oder PanFS.

Parallele Dateisysteme speichern keine Dateien, sondern sie speichern Objekte. Ein Objekt enthält „Streifen“ von Daten, die zu einer oder mehreren klassischen Dateien gehören. Das heißt in einem Objekt können die Zeilen 1-200 von Textdokument 1 und die Zeilen 100-300 von Textdokument 2 drin sein, und in einem anderen die Zeilen 200-400 von Textdokument 1 und die Zeilen 0-100 von Textdokument 2.

Dateisyteme werden in der Regel nach folgenden Qualitätskriterien bewertet

  • Performance bzw. Schreib./Lesegeschwindigkeit auf einem einzelnen Knoten, aber auch die Geschwindigkeit von Suchen
  • Speicherplatz (also wie viel Nettospeicher steht mir bei diesem Dateisystem im Vergleich zu meinem Bruttospeicher zur Verfügung)
  • Kosten (bspw. für Lizenzen oder besondere Hardware, die dieses Dateisystem unterstützen)
  • Skalierbarkeit
  • Administrative Last (Benötigtes Wissen, Wartungsaufwand)
  • Überwachbarkeit
  • Ausfallsicherheit bzw. Zuverlässigkeit
  • Features (IndexAufbau für Suchen z. B., Images und Snapshots anfertigen, Revisionssicherheit)
  • Herstellersupport

Die Dateisysteme sind durch die Art und Weise, wie sie diese Objekte verarbeiten, auf eine gewisse Objektgröße optimiert. Das heißt die Leistungsfähigkeit eines Dateisystems ist abhängig von der Größe der Daten, die auf diesem gespeichert werden.

GPFS ist, im Gegensatz zu HDFS, ein POSIX-kompatibles Dateisystem. Das heißt auf GPFS können Sie typische Linux-Kommandozeilenbefehle wie scp oder cp nutzen, um Dateien auf dem Dateisystem zu verwalten. Mit HDFS brauchen Sie immer eine spezielle Anwendung, die eine eigene Syntax zur Verlwatung von Daten auf dem HDFS-Dateisystem verwendet. Das GPFS-Dateisystem ist damit beispielsweise auch kompatibel mit NFS ACLs oder mit SELinux, was die Integration von Informationssicherheit unter GPFS erleichtert.

 

Webcrawler

Zum einen können Log Management Tools wie Logstash dazu genutzt werden, um beispielsweise einem Twitter-Feed zu folgen. So kann beispielsweise das Aufkommen eines bestimmten Keywords naalysiert und an ElasticSearch weitergeleitet werden.

Scrapy

Scrapy works like a charm. Man gibt Scrapy eine Domain bzw. einen FQDN mit, und Scrapy crawlt automatisch sämtliche URLs unterhalb dieses FQDNs. Man gibt Scrapy nur noch Constraints mit, die ihm sagen, welche Daten er nicht crawlen bzw. nach welchen er explizit suchen soll.

BeautifulSoup

BeautifulSoup ist wie Scrapy ein Web Scraping Framework auf der Basis von Python. Im Gegensatz zu Scrapy crawlt BeautifulSoup jedoch nicht eine gesamte Domain, sondern immer nur die jeweilige URL, die man ihr zum Parsen mit gibt. Eine gesamte Domain kann nur über entsprechende Schleifen mit BeautifulSoup geparst werden, nativ wird diese Funktionalität nicht mitgeliefert.

cheerio

cheerio ist ein Webcrawler mit ähnlichem Funktionsumfang wie Scrapy. Nur basiert cheerio nicht auf Python, sondern auf NodeJS (und damit auf JavaScript). cheerio ist also eine gute Alternative für JavaScript-Entwickler.

BeamUsUp,  ScreamingFrog und WildShark

Die Lösungen sind sogenannte SEO-Spider. Sie werden genutztum beispielsweise Referal Links oder Duplicate Pages im Web zu finden. Sie werden daher eher nicht für die Extraktion von ifnromationen aus dem Web, sondern für Suchmaschinenoptimierung genutzt. Während  BeamUsUp und WildShark kostenlos sind, bietet ScreamingFrog für eine Lizenzgebühr zusätzliche Optionen wie beispielsweise eine komplette SEO-Analyse einer beliebigen URL.

Caching / Acceleration

Mobile Datenabnken

Visualisierungstechnologien – Tableau, Qlikview und Co

Tableau

Tableau ist neben QlikView das am meisten genutzte Business Intelligence Tool zur Visualisierung von Daten. Die Lösung überzeugt durch ihre Fähigkeit, große Datenmengen zu handlen, und durch ihre exzellenten Slicing/Dicing sowie Drill Down Fähigkeiten. Tableau ist im Verhältnis den anderen Lösungen sehr intuitiv und einfach zu bedienen. Nach der Installation von Tableau kann man unter der Voraussetzung, dass die Daten beispielsweise bereits per .csv-Datei strukturiert wurden, innerhalb von 5 Minuten einen gut aussehenden Report zusammen stellen.

Tableau schwächelt im Vergleich zu seinem größten Konkurrenten, Qlikview, in einigen fortgeschrittenen Ansätzen, z. B. bei der Datenintegration von meheren unterschiedlichen Quellen. In der Regel müssen die Daten in einer einzigen Quelle vorliegen, um Tableau vollumfänglich nutzen zu können. Tableau mag Daten auch nur in einem bestimmten Format, bietet aber nur sehr rudimentäre Werkzeuge zum umformen von Daten (genannt Data Shaping) an. Viele Tableau-Kunden wechseln häufig zwischen Tableau und Excel. In Excel werden die Daten so strukturiert, dass sie für ein Analyse-Szenario in Tableau geeignet sind. Dies hat sich jedoch mit der Einführung von Tableau Prep gebessert. Demnach bereiten Sie die Daten nun einfach in Tableau Prep vor.

SiSense

SiSense ist Tableau sehr ähnlich. SiSense hat ein sehr einfaches Look & Feel, bringt aber im Vergleich zu früheren Tabelau-Versionen von Anfang an sehr gute Funktionalitäten im Bereich der Datenintegration aus mehreren Quellen mit. Es ist sehr einfach per Maus Drag & Drop möglich, Daten aus unterschiedlichen Quellen über JOINs miteinander zu verknüpfen.

Der Fokus von SiSense liegt auf Predictive Analytics. Dazu hat SiSense integriertent Content bzw. integrierte Algorithmen bereit, die auf Basis von vergangenen und aktuellen Daten Vorhersagen machen.

Qlikview

Der Vorteil von Qlikview im Vergleich zu traditionellen BI Tools ist, dass das Tool bereits on-the-fly Beziehungen zwischen verschiedenen Entitäten herstellt. Um dies zu illustrieren, gehen wir mal ein Beispiel durch. Nehmen wir an, Sie arbeiten an einer Film-Datenbank. In dieser Datenbank sind die Filme, ihr Erscheinungsjahr, die involvierten Schauspieler und Regisseure sowie einige Daten wie etwa deren Gage hinterlegt.

Nehmen wir einmal an, wir wollen Informationen über einen Schauspieler analysieren, der im Film Goodfellas mitgearbeitet hat. In einer traditionellen OLAP-Anwendung ist der Pfad, mit dem Sie diese Analyse durch Filter-Regeln vorbereiten, vorgegeben. Sie filtern zuerst nach dem Regisseur und bekommen dann eine Liste aller Filme angezeigt, die Martin Scorcese dirigiert hat. Sie wählen Goodfellas aus und bekommen eine Liste mit allen Schauspielern angezeigt, die dort mit gespielt haben. Nun wählen Sie beispielsweise Robert de Niro aus. Nun können Sie Ihre eignetliche OLAP-Analyse fahren, z. B. an wie vielen Filmen hat Robert der Niro in seiner ganzen Karriere mitgespielt, wie viele Auszeichnungen er erhalten hat usw.

Bei QlikView ist Ihr Analysepfad nicht vorgegeben. Wenn Sie in Qlikview nach dem Regisseur filtern und Martin Scorcese auswählen, zeigt Ihnen Qlikview bereits beim Filtern, mit welchen Schauspielern Martin Scorcese während seiner Karriere zusammen gearbeitet und an welchen Filmen er beteiligt war. Sie bekommen also nicht nur eine Dimension, also seine Filme, angezeigt. Statt dessen präsentiert Ihnen Qlikview sofort alle Dimensionen, die mit der Entität „Regisseur“ verknüpft sind. Es liegt jetzt vollkommen an Ihnen, ob Sie jetzt einen Film oder einen Schauspieler anklicken wollen. QlikView zeigt Ihnen auch durch Graufärbung an, mit welchen Schauspielern und Filmen Martin Scorcese NICHT in Verbindung steht.

Um es kurz zu machen: Qlikview liefert ein besseres Look&Feel

Alteryx

die Idee hinter Alteryx ist, Daten, die aus einer Quelle kommen (beispielsweise von einer Datenbank, aber auch von einer .xml-, .json- oder .csv-Datei), ohne SQL- oder Excel-Kenntnisse in einer GUI per Maus für Analysen bereinigen und bearbeiten zu können. Sie können sozusagen per Drag and Drop Joins zwischen verschiedenen Tabellen oder Dateien vornehmen, Spalten umbenennen, die Datentypen von Spalten verändern, Berechnungen auf Zahlenwerte durchführen als wären Sie in Excel, Daten Sortieren und Duplikate entfernen u. v. m.

Der Hauptvorteil von Alteryx ist also seine Fähigkeit, verschiedene Quellen von Natur aus lesen zu können (das heißt Sie müssen Daten nicht erst für z. B. Excel „umformatieren“) und ohne Programmier- oder Skriptingkenntnisse komplizierte Datenoperationen für Analyseszenarien durchführen zu können.

Die per Alteryx für eine Analyse vorbereiteten Daten werden im Anschluss häufig mit anderen Tools wie Tableau kombiniert. Denn Alteryx ergänzt Tableau genau an den STellen, an denen Tableau schwach ist: Beim Data Shaping und bei der Datenintegration aus mehreren Quellen.

TIBCO Spotfire

TIBCO Spotfire ist sehr ähnlich aufgebaut wie Tableau und hat die selben Vor- und Nachteile. Was ich an Spotfire mag ist die Tatsache, dass es sehr einfach ist, mehrere Diagramme auf eine Seite zu packen. unter Tableau müsste man hierzu erst jedes Artefakt einmal erstellen und diese dann im Nachhinein in einem Dashboard zusammen stellen. Unter TIBCO ist das Hinzufügen eines neuen Diagramms zu einer Seite einfacher.

Kibana

Kibana ist eine Visualisierungs-Engine, die auf ElasticSearch aufbaut. Wir haben weiter oben schon erläutert, wie Volltext-Datenbanken wie ElasticSearch funktionieren. Kibana geht her und visualisiert den Inhalt der Indizes in ElasticSearch. Damit ist es möglich, auf einfache Art und Weise zu visualisieren, wie oft ein bestimmter Suchbegriff an bestimmten Stellen vor kommt. Am häufigsten wird Kibana bei der Analyse von Logs benutzt. Hierbei kombiniert man ElasticSearch, Logstash und Kibana zu einem sogenannten ELK-Stack. Auch dies haben wir weiter oben bereits vorgestellt. Dadurch ist es wiederum möglich, auf einfache Art und Weise darzustellen, wie viele Fehlermeldungen, Warnungen und dergleichen derzeit in der gesamten Systemlandschaft auftauchen, wenn man die Logs entsprechend analysiert.

Microsoft PowerBI

Microsoft PowerBI ist gerade deswegen interessant, weil es Bestandteil von Office365 ist. Das Tool wird aus diesem Grund von immer mehr Unternehmen adaptiert, die bisher noch keine Business Intelligence betrieben haben und damit starten. Gerade Startups und mittelständische Unternehmen adaptieren gerade sehr stark PowerBI. Was den Funktionsumfang betrifft, konkurriert PowerBI eher mit Tableau. Wie auch schon bei Tableau liegt der Haupt-Fokus von PowerBI auf der easy-to-use Experience. PowerBI funktioniert sehr gut in Zusammenarbeit mit Microsoft Technologien wie Excel und Sharepoint.

FusionCharts, HighCharts und d§

FusionCharts ist eine im Bereich der Webentwicklung sehr beliebte JavaScript-Bibliothek zur Generierung von Diagrammen und anderen Übersichten wie etwa räumliche Statistiken auf Basis von Landkarten (Spatial). Bis heute ist FusionCharts eine der am häufigsten genutzten JavaScript-Bibliotheken in diesem Bereich.

HighCharts ist ein direkter Konkurrent zu FusionCharts. Auch hier handelt es sich um eine JavaScript-Bibliothek, die gerne zur Generierung von visualisierten Statistiken und Diagrammen genutzt wird. Ich persönlich bevorzuge nach meinen aktuellen Erfahrungen HighCharts, habe jedoch mit beiden Technologien schon gearbeitet.

D3 ist die beliebteste JavaScript-Visualisierungsbibliothek im professionellen Bereich, weil sie sich so einfach selbst umgestalten lässt. Hier hat der Entwickler die größte Freiheit, wenn es um die Implementierung eigener Code-Fragmente geht.

DataWrapper

DataWrapper ist ebenfalls eine Lösung zur Erstellung interaktiver JavaScript-Diagramme, jedoch ist der Ansatz hier ein anderer. Die Bibliotheken werden nicht komplett eigenständig über JavaScript programmiert, sondern innerhalb der Plattform von DataWrapper erstellt und dann einfach in die entsprechende Seite eingebettet. Die Erstellung des Diagramms erledigt also die interne Logik von DataWrapper, man muss nur die Daten liefern und die Grundkonfiguration tätigen, und kann das Diagramm dann direkt einbinden.

Plotly

Plotly ist eine Bibliothek zur Erstellung von Diagrammen und Graphen. Sie basiert auf mehreren Programmiersprachen. Die beliebtesten Derivate sind die für Python und JavaScript. In der Python-Gemeinschaft ist sie die beliebteste Visualisierungsbibliothek. Plotly überzeugt insbesondere durch seine Interaktivität. So kann in einen mathematischen Graphen etwa herein und heraus gezoomt werden. Man erhält, wenn man in einem Diagramm oder graphen über eine Linie darüber fährt, immer sofort in einem Popup den Wert der Kurve an der jeweiligen Stelle angezeigt.

Plotly arbeitet gut mit anderen Python-Visualisierungsbibliotheken wie Seaborn, Bokeh und Holoviews.

SAP BusinessObjects Lumira

Lumira sollte nicht mit dem klassschen SAP BusinessObjects verwechselt werden. Während das klassische BusinessObjects ein mächtiges Reporting-Tool für Reports im Tabellenformat ist, zeichnet sich Lumira, ähnlich wie Tableau, als Datenvisualisierungstool aus.

Lumira glänzt durch die Bereitstellung von „Suggestions“. Wenn Sie beispielsweise ein Excel Spreadsheet mit Daten zur Analyse laden, schlägt Ihnen Lumira sofort verschiedene Analyseszenarien vor. Zudem bietet Lumira ein Excel-ähnliches Konzept für Arbeitsmappen. Es ist also sehr einfach, eine bestehende Analyse zu duplizieren und in einem neuen Reiter zu bearbeiten ohne die Quell-Analye zu verändern.

Ein weiterer wichtiger Vorteil von Lumira ist die Fähigkeit, sich direkt auf eine SAP HANA Datenbank zu verbinden. SAP BusinessObjects braucht zur Verbindung mit SAP HANA eine Universum, Lumira braucht diesen Zwischen-Layer nicht. Andere BI-Tools haben mitunter keine eingebaute Möglichkeit, um sich mit HANA zu verbinden.

Das Konzept der Polyglot Persistence

Jetzt, da wir so viele verschiedene Datebankarten kennen, ist die Zeit gekommen, sich über das Konzept der Polyglot Persistence zu unterhalten. WEnn Sie heute eine Anwendungssoftware schreiben, die Daten aus einer Datenbank abgreift, dann sollten Sie nicht mehr im klassischen modell denken, wo sie eine einzige Datenbank für die gesamten Anwendungsdaten haben. Statt dessen hat heutzutage eine Datenbank mehrere Datenbanken. Verschiedene Daten finden jeweils auf der Datenbank Platz, in der sie am besten aufgehoben sind. Die folgende Abbildung illustriert dies anhand eines Online-Shops. Im Beispiel fehlen nur noch aggregierte Daten für eine Analyse. Hierbei würden entweder spaltenorientierte SQL-Datenbanken, Wide-Column Stores oder in-Memory Datenbanken zur Auswahl stehen.

Meistens ist es hierbei so, dass die Daten immer nur in einer Datenbank stehen. Es kann jedoch auch manchmal Sinn machen, Daten redundant in mehereren Datenbanken zu halten. So können bestimmte Queries auf einen Datenbestand beispielsweise auf eine zeilenorientierte relationale DAtenbank und andere auf eine Graph-Datenbank mit dem selben Datenbestand durchgeführt werden. Hierbei müssen die Daten wiederum in Echtzeit zwischen den beiden Datenbanken repliziert werden, damit die ACID-Konsistenz gewährleistet wird.

Docker als wichtiger Virtualisierungs-Enabler in großen  Big data Szenarien

Sie fragen sich jetzt vielleicht als Administrator: Herr Loibl, Sie erzählen mir jetzt, dass ich beim Ansatz der Polyglot Persistence für eine einzige IT-Anwendung mehrere Datenbank-Server brauche, die jeweils einen Teilbereich meiner Daten verwalten. Statt also wie bisher eine Datenbank pro Anwendung zu haben und nur einen Server verwalten zu müssen, muss ich jetzt 10 Server verwalten. Das heißt ich brauche 10 Betriebssystemlizenzen und brauche, was die Grundressourcen des Betriebssystems der einzelnen SErver betrifft, zehn mal so viele virtuelle CPUs, Storage-Kapazitäten und Arbeitsspeihcerkapazitäten für die ganzen virtuellen Maschinen.

Nein, brauchen Sie nicht. Docker ist die Lösung dafür. Docker ermöglicht es Ihnen, auf einer einzigen virtuellen Maschine meherere „container“ zu erstellen. Das heißt, Sie erstellen voneiannder abgeschottete Container, die sich gegenseitig nach Updates nicht beeinflussen, haben aber gleichzeitig eine Ersparnis in der Vergabe von RAM, virtuellen CPUs und Speicher, weil alles auf einer einzigen virtuellen Maschine läuft. Sie brauchen also nicht 10 verschiedene klassische virtuelle Maschinen, sondern können die Teilkomponenten innerhalb einer einzigen VM kapseln, wenn Sie dies so wollen. Wenn Sie möchten, können Sie also weiterhin nur einen einzigen Datenbank-SErver im Sinne einer einzigen virtuellen Maschine haben.

 

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren...

Kommentar verfassen

This site uses Akismet to reduce spam. Learn how your comment data is processed.