Datenbanken sollen große Datenmengen permanent und möglichst effizient verwalten. Was vorgestern mit hierarchischen und relationalen Datenbanken begann, ist heute längst in verteilte Datenbankkonzepte, Big-Data-Ansätze und In-Memory-Technologien eingeflossen.
Mit meinem Kollegen Gottfried Vossen spreche ich im ersten Teil über die historischen Herausforderungen und den aktuellen State of the Art.
Im zweiten Teil diskutieren mein Kollege Gottfried Vossen und ich neue Ansätze, aber auch das Potential für Handy-Datenbanken, Künstliche Intelligenz und Datenmarktplätze.
Viel Vergnügen!
Literaturempfehlung:
- Lemahieu, W., vanden Broucke, S. & Baesens, B.: Principles of Database Management. 2018
https://www.amazon.de/Principles-Database-Management-Practical-Analyzing/dp/1107186129 - Elmasri, R. & Navathe, S. B.: Database Systems. 2016
https://www.amazon.de/Database-Systems-Ramez-Elmasri/dp/1292097612/ref=sr_1_1?qid=1559588206&refinements=p_27%3AShamkant+B.+Navathe&s=books&sr=1-1&text=Shamkant+B.+Navathe - Chen P.P.: The Entity-Relationship Model. 1976
http://bit.csc.lsu.edu/~chen/pdf/erd-5-pages.pdf - Codd E.F.: A Relational Model of Data for Large Shared Data Banks. 1970
https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
————————–
Wenn Ihnen unsere Folgen gefallen, dann freuen wir uns über eine 5-Sterne-Bewertung auf Ihrer Wunschplattform, damit auch andere auf diesen Podcast aufmerksam werden und wir das Angebot weiter verbessern können. Zeitaufwand: 1-2 Minuten.
In diesem Sinne: keep connected.
Herzlichst
Ihr
Axel Winkelmann
Transcript:
ERP-Podcast, Folge 98. Eine kurze Geschichte der Datenbank. Ein Interview mit Professor Doktor Gottfried Vossen, zweiter Teil.
Datenbanken sollen große Datenmengen permanent und möglichst effizient verwalten. Was vorgestern mit hierarchischen und relationalen Datenbanken begann, ist heute längst in verteilten Datenbankkonzepte, Big Data Ansätze und In-Memory-Technologien eingeflossen. Im zweiten Teil diskutieren mein Kollege Gottfried Vossen und ich neue Ansätze, aber auch das Potenzial für Handy- Datenbanken, künstliche Intelligenz und Datenmarktplätze.
Viel Vergnügen. Herzlich willkommen zum ERP-Podcast, dem Podcast für alle, die sich aktiv mit dem Einsatz und der Gestaltung von Unternehmenssoftware und den daraus entstehenden Veränderungen und Potenzialen in Unternehmen auseinandersetzen wollen. Mit diesem Podcast möchte ich Sie mit eigenen Gedanken und Interviews bei der Gestaltung moderner IT-Konzepte nebenbei, also zum Beispiel beim Spazierengehen oder Autofahren begleiten.
Damit möchte ich Ihnen in dieser von technologischen Veränderungen geprägten Zeit Informationen anbieten, die sich in Zeitschriften, Fachbüchern und wissenschaftlichen Artikeln in dieser Form nicht darlegen lassen und für die sich im hektischen Alltag ohnehin nicht die Zeit findet. Mein Name ist Axel Winkelmann. Ich bin Professor für Betriebswirtschaftslehre und Wirtschaftsinformatik an der Universität Würzburg.
Liebe Hörer des ERP-Podcast, herzlich willkommen zurück zu einer neuen Woche. Dieses Mal sprechen wir ein bisschen über die Geschichte der Datenbanken. Wir haben das letzte Woche schon angefangen.
Ich habe hier im Studio zu Gast Gottfried Vossen. Er ist Professor an der Universität Münster in der Wirtschaftsinformatik, ist selber Informatiker und wir haben festgestellt, er hat über 40 Jahre lang Datenbankerfahrung. Vielleicht kann er sich selber noch mal ein bisschen vorstellen und dann gehen wir wieder in Medias Reis.
Ja, ich bin Gottfried Vossen. Ich bin seit 1993 Professor für Informatik am Institut für Wirtschaftsinformatik in Münster. Ich habe es letzte Woche schon gesagt, ich habe 1979 in Aachen während meines Studiums, so im Hauptstudium, eine erste Datenbankvorlesung gehört.
Ja, und das ist der Grund, warum du, Axel, dann sagen kannst, ich mache das seit 40 Jahren. Das ist tatsächlich dieses Jahr 40 Jahre und ich beschäftige mich eigentlich immer noch mit Datenbanken, wenngleich man sagen muss, Datenbanken haben eine Entwicklung durchlaufen in dieser Zeit, die sie im Grunde zu einer unsichtbaren Technik gemacht haben. Früher, wenn man Datenbank gearbeitet hat, dann ging man mit SQL daran oder über irgendeine Schnittstelle.
Ich habe selber in meiner Aachener Assistentenzeit angefangen, SQL-Kurse auf dem SQL-Data-System der KFA Jülich zu machen und da war der typische, der Zugang war über irgendeine Form von SQL-Schnittstelle. Heutzutage redet man mit einer Datenbank, wenn überhaupt, über ganz andere, zum Beispiel über Apps. Datenbanken stecken heutzutage in fast allen Systemen drin, aber ganz tief unten, man sieht sie nicht mehr.
Also ich sage immer, Datenbanken sind aus der Sichtbarkeit verschwunden, in dem Sinne, dass man sie typischerweise als Endbenutzer nicht mehr direkt anspricht, sondern dass man nur noch über den Umweg über irgendwelche Anwendungen, Apps heutzutage auf dem Smartphone, auf jedem Smartphone ist eine Datenbank installiert. Interessanterweise, das wissen auch die Wenigsten. Soll ich dir sagen welchen? Ja, dann sag mal.
Das ist die am weitesten verbreitete Datenbank weltweit, die ist auf jedem Handy installiert. Das ist SQL-Lite. Das ist eine amerikanische Entwicklung von einem leichtgewichtigen Datenbanksystem mit ganz bestimmten Eigenschaften.
Also das ist keine vereinfachte Form von SQL, was der Name übernehmen könnte, sondern das ist ein abgesperrtes Datenbanksystem, was genau auf so Anwendungen wie in Handys und so weiter, wo man eben mit limitiertem Platz doch immer noch auskommen muss, weil die Datenbank eben nicht beliebig viel Platz bekommt, sondern man möchte eben den Benutzer möglichst viele Apps installieren lassen oder viele Bilder aufnehmen, viele Podcasts hören und darum braucht man in solchen Umgebungen, typischerweise in mobilen Anwendungen, auch in Autos und so, braucht man ein leichtgewichtiges System und SQL-Lite ist die weltweit mit Abstand am weitesten verbreitete Datenbank und ein typisches Beispiel für eine Datenbank, die kaum jemand kennt und die man nicht sieht von außen. Das ist die typische Situation heute. Wer hat die entwickelt? Oh, das müsste ich nachgucken.
Das war ein Amerikaner. Ich habe vor ein paar Jahren auf einer amerikanischen Konferenz einen Vortrag von dem gehört. Ich kann mich aber an den Namen leider nicht erinnern.
Starten wir noch mal ein bisschen früher. Also wir haben letztes Mal sozusagen als Reprise jetzt gesagt, ursprünglich Datenbanken als Teil der Anwendungssoftware zunächst mal gar nicht so losgelöst, sehr stark an den physischen Strukturen orientiert, hierarchische Datenbank, netzwerkartige Datenbanken. Je mehr man die Daten eigentlich gelöst hat von der Anwendung, desto weniger war diese physische Orientierung eigentlich sinnvoll.
Man hat dann in den 70er, 80er Jahren mit relationalen Gedanken angefangen, hat die ersten relationalen Datenbanken entwickelt. Wir sind bis hin zur Objektorientierung, die wir am Ende der letzten Folge uns ein bisschen angeschaut haben. Wir sind aber eigentlich immer noch sehr stark innerhalb der Organisation, sprich aus meiner Sicht innerhalb des Unternehmens, also innerhalb der Unternehmensanwendung, richtig? Ja, im Prinzip sind wir das.
Es gab natürlich immer schon viele andere Anwendungen für Datenbanken, also insbesondere zum Beispiel im naturwissenschaftlichen Bereich. Andererseits muss man sagen, es gibt auch viele Bereiche, wo seit jeher so große Datenmengen entstanden sind, dass man sich gar nicht erst die Mühe gemacht hat, die in der Datenbank zu speichern. Also das typische Beispiel ist die Weltraumforschung.
Wenn man sich ansieht, was so die Weltraumsonden, die so zum Mond oder zum, was weiß ich wohin, zum Mars fliegen, oder so ein Hubble- Teleskop, was die an Datenmengen zur Erde schicken, dann muss man sagen, so schnell wie die das schicken und in den Massen, wie die es schicken, können das typische Datensysteme gar nicht aufnehmen. Also diese Daten hat man immer in Filesystemen abgespeichert, schon seit jeher. Das ist für betriebliche Anwendungen, für Unternehmensanwendungen ist das eher neu, dass man jetzt wieder auf Filesysteme zurückgeht und sich überlegt, muss es eigentlich immer eine Datenbank sein? Das wäre jetzt genau mein Plädoyer, also jetzt ist ERP natürlich sehr weit weg von Weltraumforschung, aber wir haben irgendwann sozusagen das Internet bekommen, in Anführungszeichen.
Die Welt hat sich geöffnet, man hat festgestellt, dass Integration von Daten eben nicht an den Anwendungen des Unternehmens halt macht, sondern das richtige Potenzial kann man erst ziehen, wenn man seine Wertschöpfungskette, seine Lieferanten, seine Kunden mit einbezieht in das Ganze. Man hat heute große Kundenshops im Internet und so weiter und so fort. Irgendwo kommt da die relationale Technologie spätestens dann, wenn wir über soziale Netzwerke und ähnliches reden, doch sehr stark an ihre Grenzen, oder? Ja, man stellt sich halt die Frage, ist so die tabellarische Darstellung von all diesen Zusammenhängen, ist das noch die angemessene? Und das hat wesentlich, wie du schon sagtest, mit den Entwicklungen im Internet zu tun.
Ein typisches Beispiel ist das, was Google relativ schnell festgestellt hat. Die Google Gründer wurden im Page, die ihre Suchmaschine entwickelt haben. Da war ja die wesentliche Idee, die des PageRank.
Also jede Seite wird sozusagen irgendwie mit einer Bewertung versehen und wenn der Benutzer irgendwas fragt, dann werden die Seiten zurückgegeben mit der höchsten Bewertung. Das ist jetzt stark vereinfacht, aber das ist so im Wesentlichen die Idee. Die Bewertungen von Webseiten, die werden halt berechnet, unabhängig davon, ob jemand nach der Seite fragt oder nicht.
Ich kann nicht in dem Moment, wo eine Suchanfrage auf die Suchmaschine trifft, dann durchs Web loslaufen und gucken, ob ich irgendwelche relevanten Seiten finde, sondern das muss ich unabhängig von Suchanfragen machen. Und das war bei Google relativ schnell die große Anforderung, einen Index aufzubauen, der mir einerseits sagt, wenn ich einen bestimmten Suchbegriff vorgebe, welche Dokumente, welche Webseiten könnten dazu relevante Inhalte enthalten und wie kann ich das möglichst schnell feststellen. Und das hat dazu geführt, dass man sich bei Google gar nicht erst mit relationaler Technik abgegeben hat, sondern man hat relativ schnell seine eigenen Strukturen entwickelt.
Das war unter anderem die System Bigtable, was heute immer noch vielen Entwicklungen zugrunde liegt. Und in Bigtable hat man gesagt, wir brauchen eine etwas einfachere Struktur als mit den Tabellen, die ich aber besser skalieren kann und die ich insbesondere schneller durchsuchen kann. Und eine Antwort auf diese Fragen, die sich dann in dem Zusammenhang gestellt haben, waren die sogenannten Key-Value-Stores.
Ein Key-Value-Store ist im Prinzip, kann man sich vorstellen, wie eine binäre Tabelle mit zwei Spalten. Die eine ist der Key und die andere ist der Value. Und der Key kann irgendetwas sein.
Der Key kann ein Schlüssel im klassischen Sinne sein, muss es aber nicht. Der Key kann auch ein Wort aus einem Text sein und der Value ist die Anzahl der Vorkommen dieses Wortes in dem Text. Der Key kann aber auch eine Personalnummer sein und der Value ist alles, was ein Unternehmen über diese Person weiß, in irgendeiner strukturellen oder auch unstrukturellen Form.
Und mit solchen Key-Value-Stores hat man zum Beispiel die Möglichkeit, ganz selbstständig festzulegen, was ich eigentlich als mein Suchkriterium vorgeben will und was ich als Information da dran hängen will. Und das muss ich nicht mehr jetzt so streng strukturieren, wie ich das in einem klassischen Datenbanksystem tun muss. Und das hat dazu geführt, dass man gesagt hat, für viele Anwendungen, und diese Indexberechnung in Suchmaschinen war eine davon, für viele Anwendungen wäre es ganz nett, wenn ich eine andere Form der Strukturierung hätte.
Für manche Anwendungen wäre es sogar schön, wenn ich mich nicht von vornherein, bevor ich die Datenbank benutzen kann, um ein Schema kümmern muss. Sondern wenn ich mich gar nicht erst mit Entwurfsfragen abgeben muss, sondern einfach Objekte speichern kann. Und das war so ein Antrieb für die sogenannten NoSQL-Systeme, wobei das No eben nicht für nicht steht, das muss man immer betonen, sondern das steht für Not Only.
Not Only SQL, also nicht nur SQL. Diese Systeme zeichnen sich dadurch aus, dass sie weitestgehend schemafrei sind. Das heißt, ich muss nicht, bevor ich so ein System benutzen kann, einen Entwurfsprozess durchlaufen, sondern ich kann mehr oder weniger direkt loslegen und dann eben Objekte in unterschiedlicher Form speichern.
Zum Beispiel als Key-Value-Paare, zum Beispiel als grafische Strukturen, zum Beispiel als spaltenorientierte Speicherung und so. Kann man damit sagen, das, was Google angestoßen hat damals, ist so der Beginn dieser ganzen Umwälzung, dieser Verteilung dieser riesigen Datenbanken, die wir heute im Netz sehen? Das war sicherlich ein wesentlicher Anschluss dazu. Es gibt natürlich noch viele andere Entwicklungen, wo man eben gesagt hat, Mensch, wir haben plötzlich große Datenmengen, wir machen aber nichts damit.
Im Grunde hat das so Mitte der 90er Jahre angefangen mit dem Stichwort Data Warehouse. Mitte der 90er Jahre haben die Unternehmen zum ersten Mal gesagt, wir haben jetzt durch den aufkommenden E-Commerce und nochmal das Stichwort Digitalisierung in dem Zusammenhang, wir haben jetzt so viele Daten, wir wissen viel über unsere Kunden, über die Produkte, über die Kaufvorgänge. Wir wissen, was die Kunden so suchen.
Wir haben so eine gewisse Kaufhistorie. Was können wir daraus eigentlich an neuem Wissen generieren? Das war so die ursprüngliche Frage und das hat dann dazu geführt, dass man sich, das hat diesen Bereich BI, Business Intelligence, angestoßen, dass man gesagt hat, Mensch, wir brauchen eigentlich mal irgendwas, irgendeine Plattform, unabhängig von unseren operativen Systemen, auf dem man so alle möglichen Analysen und Reports und so fahren kann. Das war die Idee des Data Warehouse oder wie wir im Deutschen sagen, des Datenlagers, wo man eben gesagt hat, wir integrieren mal aus operativen Systemen, möglicherweise auch aus externen Systemen die Daten in einem System, konsolidieren sie auf bestimmte Weise.
Die Schemaform in dem Data Warehouse ist typischerweise eine etwas andere als in den operativen Systemen und dann können wir aber auf dem Datenlager, auf dem Warehouse, können wir dann alle möglichen Auswertungen fahren, die auch rechenintensiv sein dürfen und weil es eben ein separater Datenbestand ist, wird sozusagen die Performance unserer operativen Systeme davon nicht beeinflusst. Das war so der Stand vor 20 Jahren. Im Laufe der Zeit hat man das natürlich immer weiter vereint.
Heute muss man für eine BI-Anwendung nicht mehr unbedingt ein separates Datenlager aufbauen. Heute kann man viele der Funktionen, die man so gerne zur Verfügung hätte, unmittelbar auf dem operativen Datenbestand oder auf einer Zwischenschicht machen. Zwei Stichworte, die ich gerne einwerfen würde an der Stelle.
Das eine ist Hadoop als Datenbank, die sicherlich in aller Munde ist. Hatspace oder Hadoop, Distributed File Systems und auf der anderen Seite das Thema In-Memory, aber vielleicht fangen wir erst mal mit der spaltenorientierten Datenbank an. Ja, also die spaltenorientierte Datenbank ist, das hat man sich Column Stores oder Columnar Databases, das hat man sich im Zusammenhang mit Data Warehouses überlegt, weil man in einem Data Warehouse hat man letztlich eine tabellenartige Struktur, die aber abweicht von der klassischen Organisation, wie man sie im operativen System hat.
Also man spricht hier von sogenannten Sternschemata oder auch von Schemata, wo ich so Fakten-Tabellen in der Mitte habe und drumherum gewisse Dimensions-Tabellen und man hat dann festgestellt, häufig habe ich in den Dimensions- oder auch in den Fakten-Tabellen viele Nullwerte, weil ich etliche Werte, die ich da gerne zusammenziehen würde, noch nicht kenne oder nicht im Zugriff habe und dann hat man sich überlegt, anstatt zeilenweise, spaltenweise zu speichern und zwar nur die Spalten, wo ich wirklich genügend Werte zur Verfügung habe und wenn ich das mache, dann kann ich ganz raffinierte Techniken anwenden, wie zum Beispiel Bitmap-Indexe oder so, die mir dann extrem schnellen Zugriff auf diese Tabellen erlauben und das war so die Idee der spaltenorientierten Speicherung, die stammt im Übrigen wieder mal von Stormbreaker. Mike Stormbreaker hat ja ganz viele solche Entwicklungen angestoßen im Laufe der Jahre, wofür er inzwischen auch den ACM Turing Award bekommen hat. Also die Spalten, die Spaltenorientierte Speicherung, die ist eigentlich noch nicht so eine richtige NoSQL-Entwicklung, die ist noch ein bisschen älter, aber sie wird heute natürlich in diese Entwicklungskategorie gerne eingeordnet.
Das ist auch nicht so ganz falsch. Es ist immer die Frage, wie kann ich die Performance erzielen, die ich von meinen relationalen Systemen gewöhnt bin. Das ist bei allen Neuentwicklungen immer wieder die Frage gewesen und je nachdem, wie ich das mache, ist das nicht so leicht zu beantworten.
Bei In-Memory-Systemen macht man sich zum Nutzen, dass heutzutage die Computertechnik einfach viel zuverlässiger geworden ist. Ausfälle sind wesentlich seltener, Totalabstürze kommen nur noch ganz selten vor. Das war vor 30 Jahren bei der Einführung von relationalen Systemen völlig anders.
Da hat man eine Transaktionskomponente, ich habe das ja in der letzten Woche gesagt, eine Transaktionskomponente musste immer auf Ausfälle vorbereitet sein und immer dafür sorgen können, dass ich geeignete Recovery-Maßnahmen nach einem Systemabsturz durchführen kann. Und Recovery-Algorithmen, die man dazu entwickelt hat, die sind eben schon sehr ausgefuchst, nur mittlerweile ist die Technik so, ich vergleiche das immer mit Flugzeugen, heutzutage fliegt man ja weite Strecken über Ozeane, also Long-Distance-Flights, typischerweise nur noch mit Zweimotorienmaschinen, auch das war vor 30 Jahren undenkbar. Also da in den Pazifik von San Francisco nach Auckland zum Beispiel 12 Stunden Flug mit einer Zweimotorienmaschine zu absolvieren, das war vor 30 Jahren undenkbar.
Da war man froh, dass man den Jumbo hatte und er hatte vier Triebwerke und das war eben zuverlässiger. Heutzutage ist die Rechentechnik so ähnlich. Die Rechentechnik ist viel ausfallsicherer als früher, die Idee, Datenbankfunktionen in den Hauptspeicher zu verlagern, die stammt auch so aus Mitte der 80er Jahre.
Es gab damals, ich glaube an der University of Texas, eine Dissertation von Margaret Eich, die hat sich zum ersten Mal intensiver mit der Frage der In-Memory-Datenbanken auseinandergesetzt. Aber die Idee ist damals nicht geflogen, man konnte es nicht realisieren, weil einfach die Technik zu unzuverlässig war. Man hat immer gesagt, wenn ich Transaktionen im Hauptspeicher ausführe, ich brauche den Backup auf einem nicht-flüchtigen Speicher, also damals Platenspeicher, ich brauche den Backup da, sonst kann ich das nicht machen.
Natürlich werden Transaktionen im Hauptspeicher ausgeführt, aber die Logs zum Beispiel, die ich führe, die Log-Dateien, die mir nachher bei der Recovery helfen, die müssen in einem sicheren Speicher liegen. Darum hat man das damals verworfen. Inzwischen ist die Technik so, dass ich das machen kann.
Das macht sich jetzt SAP mit HANA und vielen anderen auch. IBM, Oracle haben alle Hauptspeicher-Datenbanken inzwischen entweder selber gebaut oder zugekauft. Jeder große Hersteller, Microsoft, jeder große Hersteller hat inzwischen eine Hauptspeicher-Datenbank im Angebot.
Ich glaube SAP war einer der ersten, der das großflächig propagiert hat, aber ist längst nicht mehr der Einzige, der das macht. Da sind die Techniken jetzt andere. Auch da muss ich noch mal darauf vorbereitet sein, dass mir das System abstürzt.
Aber die Vorbereitungen, die ich dazu treffen muss, sind längst nicht mehr so aufwendig, wie ich das vor Jahren noch hätte tun müssen. Kannst du uns mal ein Gefühl davon geben, wie groß heute solche Datenbanken sind? Also N-Memory-Datenbanken, das ist sicherlich was, was man braucht In Anführungszeichen der überschaubaren Größe eines Unternehmens hat NoSQL-Datenbanken natürlich viel in verteilten Web-Anwendungen verwendet. Entsprechend sicherlich nochmal sehr viel größer. Vielleicht, dass wir einfach mal so ein Gefühl haben, wie groß sind die? Also grundsätzlich ist es immer so, dass ich bei einem Rechner habe ich eine bestimmte Hauptspeichergröße und wenn ich ein Datenbanksystem auf dem Rechner betreiben will, dann kriege ich das Datenbanksystem einen Teil des Hauptspeichers als sogenannten Datenbankpuffer zur Verfügung gestellt.
Und in diesem Datenbankpuffer spielt sich alles ab. Also alles, was ich mit der Datenbank mache, spielt sich im Puffer ab. Wenn der Puffer nicht groß genug ist, habe ich Pech gehabt, dann kann ich das Betriebssystem anfragen, ob es mit dem Puffer ein bisschen vergrößert.
Aber normalerweise ist das ein Bereich, der ist eben fest zugeteilt. Das ist heute, wenn ich mir die heutigen Hauptspeichergrößen angucke, im Großrechnerbereich sind das natürlich viele Terabyte. Also ich kann heute gigantische Datenmengen auch im Hauptspeicher halten.
Also sowohl der Hauptspeicher insgesamt wie auch der Datenbankpuffer, das sind heute locker Größen im Terabyte-Bereich. Und da kann ich natürlich schon einiges unterbringen. Das wächst so vor sich hin.
Da gilt immer noch das Moschee-Gesetz. Der Speicher wird immer noch preiswerter und immer noch größer. Und das ist im Moment noch nicht so richtig absehbar, wann das enden wird.
Man sagt zwar seit vielen Jahren das Ende des Moschee-Gesetzes voraus. Und man ist jetzt kurz davor, dass es mal endet. Jetzt produzieren die ersten Chip-Hersteller in 5-Nanometer-Technik.
Damit ist natürlich dann langsam die Null erreicht. Aber im Moment geht das noch immer weiter. Also das sind derzeit im Terabyte-Bereich.
Das wird sicherlich irgendwann auch noch im Petabyte-Bereich gehen und möglicherweise darüber hinaus. Also zum Verständnis Mega, tausendfach Giga, tausendfach Terabyte, tausendfach Petabyte. Genau.
Immer mal 1003. Also unverstellbar eigentlich. Das ist das, was wir heute mit N-Memory nur limitiert durch die Hardware, also durch den RAM, durch den Hauptspeicher leisten können.
Diese NoSQL-Datenbanken, diese verteilten Datenbanken im Netz. Was ist da als Größenordnung? Was weißt du, was hört man? Da gibt es im Grunde keine Beschränkungen. Du sprachst eben Hadoop an.
Hadoop ist ja an sich kein Datenbanksystem. Also es gibt Datenbanksysteme wie HBase auf der Basis von Hadoop. Aber Hadoop kommt generisch eben mit dem sogenannten Hadoop-Distributed-File-System, HDFS.
Und das ist natürlich heute eine große Konkurrenz. Vieles macht man eben heute ganz offen auf Dateisystemen. Weil man sagt, Dateisysteme reichen mir.
Ich muss nicht mit der Kanone eines Datenbanksystems auf eine bestimmte Anwendung schießen. Ein Datenbanksystem, das ist immer eine Frage, wann brauche ich ein Datenbanksystem? Und ein Datenbanksystem brauche ich dann, wenn ich mich auf einen Anfrageoptimierer verlassen will, wenn ich eine effiziente Implementierung haben will, wenn ich mich auf transaktionale Garantien verlassen können will, wenn ich das nicht mehr machen will. Es gibt aber eben viele Anwendungen heutzutage, da spielt das keine Rolle mehr.
Wenn ich in Facebook ein Update poste und ich habe 500 Follower, ich habe 500 Freunde bei Facebook und den Post sehen nur 498 anstatt alle 500, das ist jetzt längst nicht so tragisch, wie wenn eine Banküberweisung nicht durchläuft. Und darum sagt man, in so Anwendungen wie Facebook oder auch bei Twitter sind diese harten Anforderungen an transaktionale Garantien zum Beispiel irrelevant. Darum reichen mir weichere.
Und irgendwann sagt man, das, was ein Dateisystem heutzutage kann, das reicht mir für meine Anwendung völlig aus. Also man geht heute hin und gleicht sehr genau ab, was sind die Anforderungen meiner Anwendung, was sollte die Anwendung leisten, worauf will ich mich verlassen können und ausgehend davon, worauf ich mich verlassen können will, was ist ein System, was das in idealer Weise unterstützt und häufig reichen Dateisysteme aus. Auch das ist eine Anwendung, die haben natürlich hier die Großen wie Twitter, Google, Facebook, Amazon, die waren da Vorreiter in vielen Dingen, setzen für viele Dinge eben Dateisysteme ein.
In einem HDFS habe ich typischerweise eine Replikation, meistens so eine Dreifachreplikation, das heißt, ich habe die Daten verteilt gespeichert, ich habe sie an mindestens drei Stellen identisch gespeichert. Wenn mir ein Knoten ausfällt, habe ich immer noch zwei, auf die ich zugreifen kann. Das macht das Updaten, das Aktualisieren ein klein bisschen aufwendiger.
Ich muss natürlich dafür sorgen, dass alle drei Repliken immer gleich aussehen und alle Updates, die an einer erfolgen, müssen auf die anderen nachgezogen werden, auch im Kontext von Netzausfällen. Es gibt da in dem Zusammenhang das berühmte CAP-Theorem. Das ist von Eric Breuer mal aufgestellt worden.
Eric Breuer hat eben mal diese Hauptanforderungen untersucht. Also CAP, C-A-P, das C steht für Consistency, das A steht für Availability. Also Consistency heißt Konsistenten Datenzustand.
Also alle Integritätsbedingungen eingehalten. Availability heißt Hochverfügbarkeit. Also Verfügbarkeit gemeint ist Hochverfügbarkeit.
Und das P steht für Partition Tolerance. Das heißt, wenn Netzwerkausfälle auftreten, dann werden die toleriert in dem Sinne, dass der Datenbestand nach endlicher Zeit wieder in einem konsistenten Zustand sein wird. Und Eric Breuer, das CAP-Theorem, das besagt, diese drei Eigenschaften kann ich nicht gleichzeitig haben.
Ich muss mich in heutigen Anwendungen entscheiden für zwei davon. Und die dritte muss ich dann selber bauen. Also es gibt Systeme.
Und ich kann die NoSQL-Systeme eigentlich sehr schön danach einteilen, wer welche Eigenschaften besitzt, welches System was kann. Viele können C-A, also Consistency und Availability. Manche können AP, also Availability und Partition Tolerance.
Und wenn ich weiß, mein System kann eben bestimmte zwei, dann muss ich als Anwender dafür sorgen, dass eben die dritte Eigenschaft durch meine Programmierung dann gewährleistet wird. Ich habe noch ein Thema hier stehen, was nicht direkt Datenbank ist, aber sehr viel mit verteilten Daten zu tun hat, nämlich das Thema Blockchain. Ja.
Was hat es damit auf sich aus deiner Sicht? In welchem Zusammenhang steht das auch mit Datenbanken, mit der Weiterentwicklung von Datenbanken? Ja, bei der Blockchain ist das eben so, dass was ich einem Block zuordne, das steht im Prinzip in der Datenbank. Die Datenbank wird sozusagen unter allen Teilnehmern repliziert. Also alle Teilnehmer besitzen eher Blockchain.
Ich bleibe mal bei den sogenannten Permissioned Blockchains, also quasi die privaten, wo die Teilnehmer bekannt sind. Bei den Public Blockchains ist das alles ein bisschen komplizierter, weil die Teilnehmer halt nicht bekannt sind. Wenn die Teilnehmer bekannt sind, dann ist klar, wer alles mit Kopie der Datenbank einer Blockchain bekommt und eines jeden Blocks.
Und das große Problem darin ist, die Transaktionen zu verarbeiten, weil ich das ja sozusagen verifizieren muss in sämtlichen Repliken. Ich muss damit rechnen, dass bestimmte Teilnehmer der Blockchain im Moment nicht erreichbar sind, weil die Netzverbindung nicht existiert und so weiter. Das große Problem hier ist einfach die Geschwindigkeit im Moment.
Ich sagte letzte Woche mal, Visa verarbeitet bis zu 50.000 Transaktionen pro Sekunde. Bei einer Blockchain-Datenbank, da kommt man mit viel Glück vielleicht auf 1.000 bis 2.000. Das heißt, die sind von der Leistungsfähigkeit klassischer Transaktionsverarbeitungssysteme weit entfernt. Das ist im Moment ein deutlicher Hemmschuh.
Das liegt eben daran, dass ich es aufwändig replizieren muss und das liegt auch daran, dass ich eben alles verifizieren muss. Wenn jemand sagt, ich will einen neuen Block kreieren, ich will den als letzten anhängen, dann müssen eben alle, die an der Blockchain teilnehmen, müssen das verifizieren. Es könnte ja sein, dass sich sozusagen ein Hacker eingeschleust hat, ein schwarzes Schaf, und jetzt die Blockchain kompromittieren will.
Das ist im Moment das große Problem. Die Teilnehmer müssen einen sogenannten Konsensus, also die müssen Übereinstimmung erzielen. Dazu gibt es natürlich viele Protokolle.
Man beschäftigt sich ja in der Datenbankwelt nicht erst seit gestern mit verteilten Systemen und der Frage, wie kann ich Übereinstimmung in verteilten Systemen erzielen, das ist im Grunde alter Hund. Da gibt es viele Protokolle für, die sich auch in verteilten Umgebungen bewährt haben, die aber in der Blockchain vor völlig neuen Herausforderungen stehen. Es gibt da viele Aktivitäten, die sich damit beschäftigen, viele Forscher weltweit.
Das ist relativ am Anfang. Ich würde sagen, das Gebiet steht im Moment so da, wo die früheren relationalen Datenbanken Mitte der 70er Jahre standen. Also viel Forschungsarbeit in dem Bereich, was noch vor uns liegt.
Absolut. Vielleicht eine abschließende Frage. Das Thema künstliche Intelligenz hat logischerweise auch immer mit Daten zu tun.
Ja. Welche Bedeutung kommt dabei der Datenbank zugute beziehungsweise wie müssen sich Datenbanken vielleicht an der Stelle auch verändern, um Zugriffe von lernenden Algorithmen entsprechend verarbeiten zu können? Zunächst mal ist es ja grundsätzlich so, je größer die Datenbasis ist, desto besser wird das Lernen. Das zeigen ja viele Anwendungen.
Das sehe ich ja an beispielsweise Recommender-Systemen. Man fasst ja heute Recommender-Systeme auch als lernende Systeme auf. In meiner Gruppe arbeitet ein Doktorand an der Frage, wie kann ich Anfrageformulierung als lernendes System auffassen und mit technischer oder künstlicher Intelligenz bearbeiten und beantworten.
Man hat im Grunde diesen Trade-off. Wenn ich wenig Daten habe zum Lernen, dann kann ich keine guten Antworten, kann ich keine gute Intelligenz erwarten. Je mehr ich habe, desto besser.
Aber es gibt einen großen Haken bei der Geschichte, womit sich auch immer mehr Leute beschäftigen. Das ist der Bias. Ich kann in die Daten natürlich Dinge einstreuen, die meinem lernenden Algorithmus eine ganz bestimmte Zielrichtung geben.
Beispielsweise Gesundheitsversorgung. Wenn ich ein KI-System baue, was mir für Schnupfen bestimmte Medikamente empfiehlt, dann ist es leicht, die Trainingsdaten so zu bauen, dass nur Medikamente eines bestimmten Herstellers empfohlen werden. Das ist Bias.
Das ist kein offenes, kein unabhängiges, neutrales System mehr, sondern das ist gezielt gerichtet auf einen bestimmten Hersteller. Das kann ich natürlich jederzeit machen. Das wird auch heute vielfach praktiziert.
Das kann ich in Empfehlungssystemen machen. Ich kann die Automobile eines bestimmten Herstellers gegenüber einem anderen bevorzugen, damit man die Produkte ganz allgemein … Das geht bis hin zu Fake News, wo ich die Daten in irgendeiner Weise kontrollieren können muss. Auch durch mehr oder weniger unabhängige Stellen.
Durch eine Art Datentypf müsste man Daten beurteilen, bevor man sie einem Algorithmus als Lernmittel zur Verfügung stellt, um Dinge wie Bias auszuschließen. Auch da stehen wir ganz am Anfang. Das wird uns erst so langsam klar, was da alles möglich ist.
Also Riesenaufgaben, die auch vor der Datenbank-Community der nächsten Jahrzehnte stehen. Definitiv. Lieber Gottfried, wir haben in einem sehr breiten Strauß eine sehr lange Geschichte dieser Technologie besprochen.
Gibt es Bereiche, die wir nicht touchiert haben, die noch besonders erwähnenswert sind? Beispielsweise Datenmarktplätze. Auch das ist seit vielen Jahren ein latentes Problem. Aber das ist auch eine interessante Herausforderung.
Es wird seit jeher mit Daten gehandelt. Das war früher schon so, als Firma kann man Adressdaten kaufen, die in irgendeiner Weise konsolidiert sind, die vielleicht integriert aus unterschiedlichen Systemen sind. Heutzutage findet das im großen Stile statt.
Das betrifft Werbung im Internet, auf den insozialen Netzwerken. Wo kommt die Werbung her? An wen werden die Profildaten verkauft? Das Ganze spielt sich ab auf Datenmarktplätzen. Auch das ist ein großer Bereich, wo man forschungsmäßig langsam versteht, was da passiert.
Wer kann Daten verkaufen? Was kann ich verkaufen? Sind das nur Daten? Kann ich auch Algorithmen verkaufen, die auf den Daten arbeiten? Was kann ich da machen? Wie sollte das reguliert werden? Welche Voraussetzungen müssen die Teilnehmer mitbringen? Datenmarktplätze ist ein Gebiet, mit dem ich mich forschungsmäßig beschäftige. Das ist von zunehmendem Interesse. Technik, Syntaktik und Semantik verschwimmen da immer mehr zueinander, richtig? Richtig.
Es bleibt spannend. Gibt es ein Buch oder Quellen, die du unseren Zuhörern empfehlen kannst, um sich auch in diesem Bereich weiterzubilden? Eigene Bücher auch gerne erlaubt? Nein, die eigenen Bücher. Wenn man bei Amazon nach Forsten googelt, dann findet man die schon.
Es gibt ein ganz neues Lehrbuch im Datenmarktbereich von holländischen Kollegen und anderen. Das heißt, die haben eine Webseite, Praktical Database. Ich müsste sie nachgucken.
Moment, das habe ich gleich. Es gibt viele Klassiker in dem Bereich. Zum Beispiel die Bücher von Mastrio Navarte, mittlerweile in der siebten Auflage erschienen.
Die sind auch regelmäßig aktualisiert worden und haben dadurch nie an Aktualität verloren. Ich gucke gerade mal nach, ich sehe gerade hier das Buch von Limahoy, Vandenburg, Seppl und anderen Principles of Database Management. Das ist gerade im letzten Jahr erschienen.
Das ist eine sehr moderne Darstellung. Die geht von den Anfängen bis hin zu NoSQL und Hadoop und In-Memory-Systemen. Sie kommt interessanterweise auch mit einem umfangreichen Web-Angebot.
Die Kollegen haben sich die Mühe gemacht, erstens mal ihre ganzen Unterlagen bereitzustellen auf ihrer Webseite und sie haben die gesamten Kapitel vertont. Man kann also praktischen Datenbankkurshalter aufziehen, indem man nur noch deren Folien abspielt. Das ist ein sehr schönes Buch, das ist auch so der aktuelle Stand der Dinge.
Das bringt uns zum Thema E-Learning in Universitäten. Gut. Wenn du dir das Ganze jetzt anschaust, die Entwicklung aus der wir kommen, was das Thema Datenbanken angeht, bis heute bzw.
wir schauen ja auch noch ein bisschen weiter in die Zukunft, als das vielleicht unser normaler Hörer hier macht. Was wird sich verändern? Wie wird sich da auch die Berufswelt in diesem Umfeld von Datenbanken in den nächsten Jahren stark verändern? Also ich glaube, Datenbankkenntnisse werden nach wie vor wichtig sein. Es hängt ein bisschen davon ab, welche Art von Beruf man hat.
Also man wird vermutlich nicht mehr so sehr viele Implementiere brauchen. Auf der anderen Seite, Leute, die sich mit Datenverwaltungssystemen welcher Art auch immer auskennen, ich glaube, das wird eine ganz wichtige Kompetenz sein, dass man in der Lage ist zu entscheiden, brauche ich ein Datenbanksystem? Wenn ja, welchen Typ? Reicht mir ein Dateisystem? Ist ein Dateisystem vielleicht vorteilhaft? Und wenn ich mich für eine der beiden Richtungen entschieden habe, dass ich in der Lage bin zu beurteilen, wie sieht der Markt aus? Mache ich das in der Cloud? Mache ich das On-Premise? Das sind alles so Entscheidungen, wo man als ITler in der Lage sein sollte, diese Entscheidungen zu fällen. Jetzt kommen wir in diesem Podcast sehr stark von der Unternehmenssoftware und damit natürlich auch die Frage, wenn du dir heutige Unternehmenssoftware, vielleicht auch zukünftige Unternehmenssoftware, insbesondere natürlich ERP, anschaust und reflektierst aus deiner Sicht als Datenbank-Experte, welche Herausforderungen siehst du da ganz besonders? Ja, immer stärkere Integration, dass Systeme immer stärker ineinandergreifen, immer stärker aufeinander aufbauen, Daten austauschbar sind, Daten angemessen integriert werden zwischen den unterschiedlichen Systemen.
Das ist, glaube ich, eine Entwicklung, die wir in den letzten Jahren schon massiv erlebt haben. Ich habe in dem Zusammenhang seit mehreren Jahren in Münster eine Vorlesung Datenintegration, wo wir uns mit diesen Fragestellungen natürlich überwiegend aus technischer Sicht beschäftigen. Aber ich glaube, dass so eine Datenschicht, so eine Datenverwaltungsschicht, die sehr heterogen, sehr hybrid aufgebaut ist mit unterschiedlichen Datenbanksystemen, manche, die klassische Eigenschaften haben, manche, die die Eigenschaften ein bisschen aufgelockert haben, manche, die gar keine Datenbank sind.
Ich glaube, dass man so eine Datenverwaltungsschicht, was man ja heute manchmal auch als Data Lake bezeichnet, dass man so eine Schicht in Zukunft wird haben müssen und dass die Systeme einfach so darauf zugreifen können, wie sie das gerade benötigen. Das war ein wunderschönes Schlusspedoyer, lieber Gottfried. Ich danke dir ganz, ganz herzlich.
Data Lake, ich nenne es Unternehmensdatenfundament, vielleicht noch ein wenig weniger technisch, als das die Informatik Community macht. Wie immer, die letzten Worte sind natürlich die meines Studiogastes. Ich möchte mich ganz, ganz herzlich bedanken.
Ich glaube, das war ein Abriss über die Datenbankgeschichte, wie sie nur jemand mit so viel Leidenschaft machen kann, der tatsächlich 40 Jahre diese Thematik auch gelebt, gehört und selber auch weiterentwickelt hat. Vielen Dank. Ja, vielen Dank.
Hat Spaß gemacht. Ihnen hat der ERP-Podcast gefallen und Sie konnten wertvolle Erkenntnisse gewinnen? Dann würde ich mich über eine Bewertung auf iTunes freuen, damit auch andere von diesem Podcast erfahren können. Eine Anleitung für die Bewertung finden Sie auf www.erp-podcast.de Dort finden Sie auch weitere Hinweise, Links und Aktualisierungen zu dieser Folge.
Das war der ERP-Podcast für alle, die sich aktiv mit dem Einsatz und der Gestaltung von Unternehmenssoftware und den daraus entstehenden Veränderungen und Potenzialen in Unternehmen losgelöst von Fachzeitschriften, Büchern und wissenschaftlichen Veröffentlichungen zum Beispiel beim Spazierengehen oder Autofahren auseinandersetzen wollen. Mein Name ist Axel Winkelmann. Ich bin Professor für Betriebswirtschaftslehre und Wirtschaftsinformatik an der Universität Würzburg.