#22 NoSQL: ACID, BASE, Ende einer Ära Teil 2

Neben relationalen Datenbanken gibt es noch eine ganz andere Welt: NoSQL.

Doch wofür steht eigentlich NoSQL? Kein SQL? Not Only SQL? Was ist eigentlich die Geschichte hinter dem Hype? Warum wurde diese Art von Datenbanken erfunden? Wofür sind diese gut? Folgen NoSQL Datenbank auch dem ACID-Concept? Was ist Eventual Consistency? Und was sind Neo4J, M3, Cassandra, und Memcached für Datenbanken? Eine Episode voller Buzzwords … Hoffen wir auf ein Bingo.

Bonus: Warum Wolfgang keinen Manta fährt und ob Andy bald mit einem Ferrari zum einkaufen fährt.

Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Sprungmarken

(00:00:00) Intro

(00:00:53) Wolfgangs Auto, Entlastungspaket in Deutschland

(00:03:23) Heutiges Thema: NoSQL Datenbanken und CO2-Einsparung durch Datenbank-Optimierungen

(00:07:20) Was ist anders zur Episode 19 (Datenbanken) und ist NoSQL überhaupt noch ein Thema?

(00:08:39) Was verstehen wir unter dem Begriff NoSQL und woher kommt es eigentlich?

(00:15:58) Tip: Für Side Projects besser vertikal anstatt horizontal skalieren

(00:16:50) NoSQL: Speziellere Lösungen mit Fokus auf Einfachheit und Benutzerfreundlichkeit

(00:18:38) Braucht man heute noch Datenbank-Administratoren (DBA)?

(00:21:13) Der Job des klassischen System-Administrator ist weiterhin relevant

(00:23:15) Gibt es wirklich keine Datenbank-Schemas in der NoSQL-Welt?

(00:27:23) Schema-Lose Möglichkeit in relationalen Datenbanken und Arbeit in die Datenbank oder Software auslagern

(00:30:53) NoSQL hat die ACID-Properties aufgeweicht und warum ACID nachteilig für die Skalierung ist

(00:33:28) Das NoSQL BASE Akronym

(00:36:15) Der Client muss die Datenbank ordentlich nuzten um ACID-Garantien zu bekommen

(00:41:35) Was bedeutet eigentlich NoSQL? Kein SQL? Not Only SQL?

(00:43:38) Haupt-Speicher Datenbanken und was SAP damit zu tun hat

(00:48:02) Was ist Neo4J für eine Datenbank und welcher Use-Case kann damit abgedeckt werden?

(00:50:49) Was ist M3 für eine Datenbank und welcher Use-Case kann damit abgedeckt werden?

(00:53:06) Was ist Cassandra für eine Datenbank und welcher Use-Case kann damit abgedeckt werden?

(00:54:20) Was ist Memcached für eine Datenbank und welcher Use-Case kann damit abgedeckt werden?

(00:58:44) Outro

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:00 - 00:00:55)

Ni Na No Angels. Nee, das war falsch. Die deutsche Girlgroup, die im Jahr 2000 aus der ersten deutschen Staffel der Castingshow Popstars hervorging, ist auch super, aber um die geht's heute nicht. Heute geht's um Ni Na No SQL. Und das Jahr 2000 stimmt auch. Zumindestens circa, wenn es um die Geburtsstunde des Begriffs NoSQL geht. In dieser Episode ist Wolfgang wieder voll in seinem Element, Dozent für Datenbanken. Und dabei fallen so viele Buzzwords, dass wir eine hohe Chance auf ein Bingo haben. ACID, BASE, EVENTUAL CONSISTENCY, FACEBOOK, FLICKR, SAP, COMMODITY HARDWARE, REDDIS, NEO4J, KASSANDRA, MEMCASH, WHITE COLUMN STORE und und und. Haltet die Bingo-Karten bereit, wir legen los. Und zwar mit einer der schlechtesten Themenüberleitungen, die ihr je gehört habt. Viel Spaß! Wolfgang, du hast kein Auto, oder?

Wolfi Gassler (00:00:55 - 00:00:57)

Aus Überzeugung nicht mehr.

Andy Grunwald (00:00:57 - 00:00:58)

Hattest du mal ein Auto?

Wolfi Gassler (00:00:58 - 00:00:59)

Natürlich.

Andy Grunwald (00:00:59 - 00:01:00)

So ein Manta?

Wolfi Gassler (00:01:00 - 00:01:05)

Nein, es war ein Nissan Sunny. Sunny wie mein Gemüt, hat immer gut gepasst.

Andy Grunwald (00:01:05 - 00:01:10)

Du hast aber sehr wahrscheinlich da nicht dran rumgetunt oder ähnliches, oder? Der hat dich nur von A nach B gebracht.

Wolfi Gassler (00:01:11 - 00:01:22)

Genau, vor allem während dem Zivildienst. Ziemlich viele Kilometer und nach diesem Winter mit dem vielen Salz in Österreich ist er dann dem Rost zum Opfer gefallen, nach einem Jahr Zivildienst jeden Tag bändeln.

Andy Grunwald (00:01:22 - 00:01:27)

Und zwar habe ich ein Auto, weil ich wohne ja auf dem Land. Ohne Auto ist man hier nix. Man kann natürlich auch Fahrrad fahren.

Wolfi Gassler (00:01:27 - 00:01:33)

Ich habe gedacht, man ist nur nix, wenn man einen richtigen Traktor hat, so wie du einen Ferrari Traktor.

Andy Grunwald (00:01:33 - 00:01:45)

Das Problem ist mit einem Traktor auf einem eleganten Parkplatz zu kriegen, ist halt relativ schwierig. Also der Vorteil mit einem Traktor ist, du kannst halt auch im Beet parken, du brauchst keinen richtigen Parkplatz, das ist super, aber der hat halt nicht so eine Ladefläche oder Kofferraum, wo man mit Einkäufe tragen kann.

Wolfi Gassler (00:01:45 - 00:01:52)

Du hast ja wohl einen Anhänger dann, wobei mit einem Ferrari Traktor hast du überall Platz oder? Der geht mit bis zur Hüfte oder so oder wie hoch ist der?

Andy Grunwald (00:01:53 - 00:02:03)

Ja, das ist so ein kleiner Querlenker, ja das stimmt schon, so ein Suppelachser, aber da ist halt nicht viel Platz, sondern ich kriege vielleicht einen Kasten Wasser oder einen Kasten Bier zwischen meine Beine und das badet dann auch schon.

Wolfi Gassler (00:02:04 - 00:02:05)

Der ist ja ausreichend oft.

Andy Grunwald (00:02:05 - 00:02:48)

Der Grund, warum ich frage, wir schreiben den 1. Juni 2022, heute geht das sogenannte Entlastungspaket in Deutschland an den Start. Das Entlastungspaket soll unter anderem die Spritpreise bei uns reduzieren. Habe ich auch morgen im Radio gehört, Diesel soll um 17 Cent Steuern runtergehen und Benzin um 34 oder 31. Und jetzt kommt der Clou, dieses ganze Entlastungspaket, geht für drei monate ach so das 9 euro ticket das populäre 9 euro ticket wonach jetzt alle nach sylt fahren gehört als würde ich auch dazu, aber dann habe ich gehört die mineralöl konzerne sind gar nicht verpflichtet uns uns uns deutschen diese einsparung durchzureichen ist das nicht faszinierend.

Wolfi Gassler (00:02:49 - 00:02:53)

Also die firmen können noch mehr verdienen es ist eigentlich sehr gut.

Andy Grunwald (00:02:53 - 00:03:56)

Die im radio sagten auf jeden fall dass in den letzten wochen die spritpreise noch mal hochgeklettert sind und die mineralölkonzerne argumentieren dass sie den sprit den sie jetzt verkaufen, ja schon teurer eingekauft haben. Das bedeutet eigentlich, wenn das Entlastungspaket jetzt am 1. Juni in Kraft tritt, also heute, dass erst bis zum nächsten Nachschub der Tankstelle erst der günstige Sprit von den Mineralölkonzernen ankommt. Und da frage ich mich, ist das nicht irgendwie so eine Art falsches Versprechen? Und was hat das falsche Versprechen jetzt mit dem heutigen Podcast-Thema zu tun? Wir sind bei Datenbanken. Und nicht bei SQL-Datenbanken, weil SQL-Datenbanken halten ihre Versprechen. Wir sind bei NoSQL-Datenbanken. Und NoSQL-Datenbanken, da ist das mit der Persistenz. Die nehmen das nicht immer ganz so genau. Liebe Hörer und Hörerinnen, der Wolfgang schmunzelt gerade im Videocall. Mit hoher Wahrscheinlichkeit war das der Dad-Joke des Tages und die Dad-Überleitung. Ich glaube, er kommt nicht mehr raus.

Wolfi Gassler (00:03:56 - 00:04:33)

Du bekommst jetzt wirklich einen Eintrag in deinem Mitteilungsheft, falls das bei euch auch gegeben hat, in der Grundschule mit Sternchen für diese Überleitung, wie du Themen aus dem Nichts miteinander verbinden kannst. Zwei Themen, die null miteinander zu tun haben. Wobei, ich hätte auch eine Verbindung gehabt vom Benzin weg, wenn du nämlich weniger Benzin verwendest und CO2 damit einsparen willst. Wenn du auch CO2 einsparen willst, Und du hast eine große Anwendung, optimiere deine Datenbank und du sparst automatisch viel CO2 ein. Mit jeder Anfrage kannst du CO2 einsparen, wenn du eine optimierte Query hast und natürlich auch noch Serverkosten.

Andy Grunwald (00:04:33 - 00:04:35)

Du meinst also weniger CPU Cycles und so weiter.

Wolfi Gassler (00:04:36 - 00:04:36)

Genau.

Andy Grunwald (00:04:36 - 00:06:32)

Da frage ich mich aber mal, bei Optimierungen ist es ja auch so oft so, nur weil man denkt, man optimiert, heißt das nicht, dass das in jedem Use Case dann schneller ist oder besser ist, sondern du kannst ja auf der einen Seite optimieren, und dann fällt die Optimierung auf der anderen Seite wieder schlecht aus. Und speziell wenn du von CO2 und Environmental Changes und so weiter und dann mit Compute Power und Datenbanken und Servern und so weiter sprichst, da frage ich mich ganz einfach, Gibt es eigentlich schon ein Data Center oder ein Server Provider oder ein Co-Location Provider, der dir solche Zahlen dann auch mal wirklich rausgibt? Das ist die erste Frage, ja? Also, wie deine Applikation läuft, wie viel Kilowatt oder Watt dein Server eigentlich zieht. Und jetzt kommt's, weil wir in der Cloud ja oft mit virtuellen Maschinen arbeiten, kann man so was eigentlich auf virtuelle Maschinen umrechnen? Stell dir vor, du hast einen Server in irgendeinem Rack, Und der Datacenter oder Co-Location-Provider hat dann da ganz viele Sensoren und schießt mich tot und so weiter. Und der kann dir sagen, pass mal auf, deine virtuelle Maschine auf Server XY zieht so und so viel Kilowatt pro Zeitrahmen. So, und auf diesem Server laufen jetzt vier virtuelle Maschinen und virtuelle Maschine eins. Also in der Regel sagt man natürlich, okay, wir haben keine noisy-neighbor-Probleme mehr. Somit sagen wir einfach mal, jeder Server hat 25 Prozent Auslastung oder konsumiert 25 Prozent. Was natürlich eigentlich ja nicht wahr ist, weil angenommen du hast vier Maschinen, vier virtuelle Maschinen auf einem physikalischen Server. Die eine Maschine ist mein Digital Ocean Server, der idelt halt rum. Und die andere ist dein F-Online, ja, der auf voll, voll Power läuft. dann konsumiert ja der Server eigentlich mehr Energie, weil deine virtuelle Maschine ja wirklich Gas gibt. Und meine Frage ist, kann man, geht sowas überhaupt, den Verbrauch auf pro virtuelle Maschine runterzurechnen?

Wolfi Gassler (00:06:32 - 00:07:04)

Es ist natürlich mit Virtualisierung wahrscheinlich umso schwieriger. Ich kenne jetzt auch keine Clouds, die dir das ermöglichen grundsätzlich, da mehr Informationen zu bekommen. Aber ich glaube ganz allgemein, wenn du es schaffst irgendwie einen Index anzulegen in deiner Datenbank und 50 Prozent einzusparen, dann brauchst du einfach weniger Server im Endeffekt. Und wenn du eine sehr große Applikation hast, überleg mal, wenn Google oder Facebook irgendwo in einer Query, die überall abgefeuert wird, 50 Prozent einsparen kann, dann sind das schon ziemliche Wellen, die du dann da schlagen kannst damit.

Andy Grunwald (00:07:05 - 00:07:22)

Sehen wir mal ein bisschen spezifischer, weil wenn du ein Index anlegst und das eine Tabelle ist, wo du mehr schreibst anstatt liest, wird der Index ja mehr neu geschrieben und dann hast du zwar ein optimiertes Lesequery, das bringt aber nichts, weil die komplette, die Disk, ich nenne es mal, rotiert, was sie natürlich bei SSD nicht mehr tut, aber dann ist das auch schon wieder für die Cuts, wa?

Wolfi Gassler (00:07:22 - 00:07:27)

Du hast sehr gut aufgepasst, in unserer letzten Episode 19 war es, glaube ich, über Datenbanken.

Andy Grunwald (00:07:27 - 00:07:39)

Wenn wir heute schon wieder über Datenbanken sprechen. Was ist heute anders? Worüber sprechen wir heute, Wolfgang? Oder wiederholen wir einfach die Episode 19? Nehmen wir die ganze Sache einfach nochmal auf, weil du nicht zufrieden warst als alter Akademiker?

Wolfi Gassler (00:07:39 - 00:08:11)

Wir haben in der Episode 19 über verschiedene Datenbankmodelle gesprochen und was es so früher gegeben hat, so auf den ganz ersten bandbasierten Systemen, was danach gekommen ist und haben dann so bei den Mainframes, die du eingeworfen hast, so aufgehört. Und was wir eigentlich nur ganz leicht gestreift haben, ist der ganze NoSQL-Trend, der danach gekommen ist. Du bist ja alt genug, du kennst den wahrscheinlich noch, oder? Ist NoSQL immer noch ein Thema, deiner Meinung nach? Hört man das Wort an sich, NoSQL?

Andy Grunwald (00:08:11 - 00:08:48)

Das Wort an sich höre ich jetzt so im Alltag jetzt eher weniger, weil ich denke, die Datenbanken, die unter dieses Wort fallen würden, sind schon im Standard-Tech-Stack, glaube ich, angekommen. Also man redet nicht mehr, wenn wir uns über Architekturen im Team unterhalten, wir reden nicht mehr darüber, ob wir die Entscheidung treffen, ob wir eine SQL- oder NoSQL-Datenbank sprechen, sondern wir sprechen dann direkt schon, welche Garantien brauchen wir, welche Arten von Daten speichern wir, wie lesen wir die. Und ab da schauen wir dann natürlich auch, welche Garantien brauchen wir, wie viel Daten handeln wir.

Wolfi Gassler (00:08:49 - 00:09:03)

Jetzt bist du ja auch so eine Koryphäe in deinem Bereich, und ganz viele Leute sprechen ja dann mit dir. Wenn sie dann NoSQL so in den Raum werfen, was verstehst du unter NoSQL? Oder was bedeutet überhaupt NoSQL? Ohne jetzt danach zu googeln.

Andy Grunwald (00:09:03 - 00:10:27)

Das ist eine sehr, sehr, sehr gute Frage. Ich glaub, ich frag in der Regel, was sie eigentlich meinen, und frag noch mehr Kontext. Weil NoSQL, find ich, ist so ein Buzzword, genauso wie DevOps. Jeder benutzt es, aber keiner weiß wirklich, was es heißt. Meine erste Intuition war, wenn man keine SQL-Abfragesprache hat, was natürlich auch Blödsinn ist, aber eine SQL-Datenbank bringt natürlich dann gewisse Garantien mit. Transactions, ACID und so weiter und so fort, die natürlich beim Schreiben und Lesen von Datensätzen erfüllt werden, wohingegen NoSQL-Datenbanken dann vielleicht auch in dem Bereich vom CAP-Theorem die Prioritäten anders legen. Consistency, Availability und Partitioning, wo dann eher die Priorität auf zum Beispiel Availability liegt oder ähnliches. Das bedeutet, Datenbanken, die andere Kriterien höher priorisieren. Nehmen wir mal Performance, nehmen wir mal, ja, Datensicherheit oder Datenverteilung vielleicht sogar. Nehmen wir mal eine Postgre oder ein MySQL oder ähnliches. Da gibt's ja, die meisten Setups werden da mit Single Primary gefahren. Wohingegen, wenn man jetzt mal, ich nenne es mal eine NoSQL-Datenbank, nimmt eine verteilte Datenbank, nehmen wir mal eine Cassandra oder so, jetzt ist die gute Frage, ist Cassandra eine NoSQL-Datenbank? Ist ja, in der Regel fährt man ja als Multinode-Cluster.

Wolfi Gassler (00:10:27 - 00:10:43)

Jetzt warte mal kurz, ich schaue doch mal grad auf meinen Zettel, auf meinen, Datenbank, Bullshit, Bingo. Ich glaub, du hast Bingo, Andi. Du hast jetzt so viele Wörter in den Raum geworfen aus der Datenbank-Welt, du hast eindeutig Bullshit-Bingo gewonnen.

Andy Grunwald (00:10:43 - 00:10:52)

Aber das ist jetzt so aus dem Bauch heraus. Und jetzt will ich nur sagen, okay, wo sind wir denn bei der Realität? Was versteht man denn akademisch unter dem Begriff NoSQL? War das jetzt kompletter Blödsinn, was ich erzählt hab?

Wolfi Gassler (00:10:52 - 00:12:53)

Ich hab eine eigentlich sehr ähnliche Einschätzung zu dem Ganzen. Akademisch ist sowieso immer die große Frage, vor allem bei solchen Passwort-Terms, ob's da eine sinnvolle Definition überhaupt gibt. Vielleicht ganz allgemein, NoSQL, ich habe gerade nochmal nachgecheckt, wann das erfunden worden ist, und zwar 1998 ist der Terms erst einmal aufgekommen, also so um die 2000-Wende, beziehungsweise dann später so richtig groß geworden in Richtung 2000 bis 2010, ich glaube, das war so die Hype-Zeit dann, wo das Ganze auch mit Bigtable, MapReduce, DynamoDB und so weiter dann aufgekommen ist von den Cloud-Providern. Aber wenn man sich nochmal zurück überlegt, ganz ursprünglich war das ja wirklich gedacht, okay, wir wollen weg von den klassischen relationalen Datenbanken, no SQL, das war irgendwie so das Schlagwort, wir brauchen kein SQL mehr, wir brauchen neue Datenbanken fürs Web. Und ich habe ja in Episode 19 schon kurz erzählt von diesem Paper, wenn wir jetzt wieder von der akademischen Seite kommen, von Michael Stonebreaker, der auch Postgres erfunden hat und viele andere Datenbanken. auch den Turing Award gewonnen hat, also diesen Nobelpreis der Informatik, und der hat ein Paper eben geschrieben, Ende einer Ära, dass wir so wirklich neue Datenbankmodelle brauchen, weil es gibt eben nicht mehr diese eine Datenbank oder das eine Datenbankmodell, was wir einfach verwenden können, um alles zu erschlagen. Und er hat da ein paar Unterbereiche aufgeteilt, warum eigentlich die alten Datenbanksysteme nicht mehr funktionieren. Und er hat es halt mehr von der akademischen Seite betrachtet und der ganze NoSQL-Hype, der so parallel gelaufen ist. Und ich habe es ja schon einmal erzählt, die akademische Welt war nicht sehr happy über den NoSQL-Trend, aber im Prinzip haben sie eigentlich genau das gleiche probiert zu erreichen. Der NoSQL-Trend war halt einfach, wir haben die coolen, neuen, hippen Datenbanken, wir machen das nicht akademisch und dieses Paper ist halt von der akademischen Seite gekommen und hat gesagt, okay, warum gibt es eben diese One-Size-Fits-All-Datenbank nicht mehr und warum haben wir die Probleme?

Andy Grunwald (00:12:53 - 00:13:55)

Ist das also dann richtig, dass der Root der NoSQL-Datenbanken dann wirklich aus dem Bedarf von Webscale-Plattformen kommt? Weil zum Beispiel so um die Geburtsstunde von Facebook herum, als die richtig steil gegangen sind in Amerika, da kamen ja auch Services wie Flickr hoch und wie sie alle heißen. also da gab es ja da gab es ja so eine handvoll oder zwei hände voll von ich nenne es mal web scale companies der wirklich große adaptionen und große user zahlen hatten und in dieser zeit ist natürlich web scale technisch enorm viel passiert ja also also ein root war natürlich die velocity konferenz die immer noch top notch ist, Aber da kommen natürlich super viele dieser heute, ich nenne es mal Standard-Practices wie Continuous Deployment, Continuous Delivery und so weiter her. Ist das wirklich der Root von NoSQL? Weil die sagten, hey, klassische Datenbanken lassen sich gar nicht so weltweit skalieren, also klassische SQL-Datenbanken.

Wolfi Gassler (00:13:55 - 00:15:30)

Das war zumindest einer der Claims, die sie gesetzt haben und einer der Gründe, warum NoSQL eigentlich so stark wurde. Ob das wirklich im Detail immer der Hauptgrund war, ich wage das mal zu bezweifeln. Wenn man sich auf jeden Fall das Ecosystem von damals anschaut, dann hat es halt da die großen Datenbanksysteme gegeben, Oracle, DB2, das hat sich natürlich auch niemand im Web leisten können, es hat MySQL gegeben und Postgres, klar, aber die waren auch nicht so groß und im professionellen Umfeld auch weniger verbreitet, als sie jetzt heute sind, zum Beispiel. Und auch die haben damals durchaus Probleme gehabt mit der Skalierung oder es war nicht so einfach, die ganzen klassischen Datenbanken zu skalieren, vor allem wegen dem ACID-Konzept, wenn du einfach harte Konsistenzkriterien erfüllen willst, dann ist es einfach extrem schwierig, etwas zu verteilen. Und in der Google-Zeit hat es ja auch angefangen, dass man eigentlich immer mehr in Richtung horizontale Skalierung geht und weniger die vertikale Skalierung macht. Also früher bei der vertikalen Skalierung hat man halt einfach mehr RAM reingeworfen und noch eine größere Maschine gekauft und hat einfach viel Geld investiert in eine größere Maschine. Das war ja dann wirklich, wirklich teuer früher. Und Google hat ja so im großen Stile wirklich angefangen, billige Rechner, da gibt es ja diese klassischen alten Bilder von diesen Motherboards ohne Gehäuse, die Google einfach mehr oder weniger zusammengesteckt hat zu einer riesen Maschinerie und hat horizontal skaliert mit billiger Hardware und die Datenbanken waren für so eine Skalierung einfach überhaupt nicht ausgelegt.

Andy Grunwald (00:15:30 - 00:16:54)

Bei der billigen Hardware redet man im Fachjargon von Commodity-Hardware. Commodity-Hardware ist also eigentlich das, was du gegebenenfalls im Desktop-Gehäuse vielleicht noch unterm Schreibtisch stehen hast. Das ist der Rechner, der bei eBay-Kleinanzeigen nicht mehr weggeht. Und zwar, Commodity-Hardware wird eigentlich das bezeichnet, das was man da hat, das was gerade günstig auf dem Markt ist, einfach rein und Software optimieren, dass das dann in die Breite skaliert werden kann und über verschiedene Maschinen und nicht in die Höhe mit mehr RAM, mehr CPUs und so weiter. Aber, wenn wir mal ganz kurz für die ganzen Leute, die vielleicht nicht so im großen Webscale unterwegs sind, sondern ihr Sideprojekt machen, Kleiner Tipp, ihr könnt eine ganze Menge vertikal skalieren. Das bedeutet, wenn ihr Serverprobleme habt, kleiner Tipp, nehmt ihr bitte 5 Dollar mehr pro Monat in die Hand und upgradet mal eben eure Maschine, anstatt dass ihr da Effort reinpackt und horizontal skaliert, um die ganze Sache auf mehreren Datenbanken und auf mehreren Servern zu verteilen. Mit vertikaler Skalierung kommt ihr ganz, ganz weit mit recht wenig Geld. Würde ich euch eher empfehlen für eure Side-Projects, für eure Firma. Also ich weiß zum Beispiel, dass ein paar größere Webfirmen immer noch auf einem Server laufen und das machen die seit Jahren und die machen da auch Millionen mit. Also das geht locker. Ich weiß, euer Engineering-Herz blutet gerade, weil ihr würdet natürlich gerne horizontal skalieren und sagen, hey, wir sind auf fünf Servern. Kleiner Tipp, das bringt euch mehr Schmerzen, als ihr eigentlich wollt.

Wolfi Gassler (00:16:55 - 00:18:43)

Ein anderer Punkt, den NoSQL probieren wollte zu beheben und der auch in diesem Paper End of an Era drinsteht, Stonebreaker hat es damals als no knobs bezeichnet, also keine Stellschrauben, keine Drehknöpfe sozusagen an der Datenbank. Und wenn man sich das mal betrachtet, wie früher Datenbanken aufgebaut waren, so eine Oracle, so eine DB2, diese One-Size-Fits-All-Lösungen, die haben sehr viel abdecken können, aber waren auch super kompliziert in der Maintenance. Sind sie teilweise immer noch. Du hast 100.000 Konfigurationsmöglichkeiten und früher war das eigentlich noch viel schlimmer. So schnell mal eine Oracle installieren, irgendwie runterladen, install und dann verwenden, wie du das mit einer MySQL konntest damals eigentlich auch schon und heutzutage eigentlich fast mit jeder Datenbank. Das war früher einfach nicht möglich. Früher hast du mal da zwei, drei Datenbank-Administratoren gebraucht, die dir irgendwie die Config-Werte eingestellt haben, damit du überhaupt so eine Datenbank zum Laufen gebracht hast. Und das war halt auch nicht sehr benutzerfreundlich. Und für Normalsterbliche, die da irgendwie neue Web-Anwendungen schrauben und kein Geld haben und dann womöglich irgendwie Webscale erreicht haben. Für die war das natürlich unmöglich sowas zu machen. Und da hat Stonebrain Cam schon gesagt, okay, es wird speziellere Lösungen geben, die auch einfach weniger Maintenance brauchen. Und MongoDB zum Beispiel hat da ja auch in diese Richtung ein großes Versprechen damals abgegeben. Wir können skalieren, ohne dass du da viel konfigurieren musst. Du installierst es einfach auf mehreren Servern, horizontale Skalierung und es funktioniert out of the box. Und es funktioniert auch noch gut und du verlierst keine Daten, in der Theorie zumindest. Jeder, der vor Jahren mal MongoDB verwendet hat, weiß, dass es nicht so einfach ist, wie damals versprochen worden ist.

Andy Grunwald (00:18:43 - 00:19:27)

Thema Datenbankadministratoren, sogenannte DBAs, Database Administrators, gefühlt ist ja heute jeder ein DBA, weil Datenbanken sind ja wie Commodity Hardware. Keine Applikation läuft ja mehr ohne Datenbank. Ab welchem Level würdest du sagen, man braucht DBAs? Oder würdest du sagen, DBAs braucht man immer? Oder sagst du, nee, mit Standard-Tutorials kommt man ... mit Standard-Medium-Artikels kommt man schon relativ weit? Wo nennst du da den krassen Unterschied? Oder kann man das überhaupt so generalisieren? Und an alle DBAs, ich möchte euren Job jetzt nicht kleinreden, ganz und gar nicht. Ich denke, ihr macht unglaublich gute Arbeit. Mit jedem DBA, mit dem ich schon mal gearbeitet hab, der hat mir immer die Schuhe ausgezogen mit den Tricks, die da aus dem Hut gezaubert wurden. Doch vielleicht nur mal ein bisschen als Guidance.

Wolfi Gassler (00:19:28 - 00:21:18)

Ich sehe das so ähnlich wie die klassischen Systemadministratoren. Da hat sich das Jobbild, glaube ich, auch stark gewandelt, dass es viel mehr in Richtung geht, dass diese Leute, die vielleicht Spezialisten sind in ihrem Bereich, in der Systemadministration, im Betrieb von Infrastruktur, dass die einfach viel näher mit dem Team zusammenarbeiten oder vielleicht dem Team mehr Möglichkeiten geben, selbstständig damit zu arbeiten und ich glaube mit den neueren datenbank modellen ist es so ähnlich klar wenn du ein datenbank system extrem ausreizen willst brauchst du wahrscheinlich irgendwen die zum beispiel extrem viel erfahrung hat im datenbankbetrieb eben optimieren von datenbanken oder solche geschichten die dem team dann helfen kann. Aber dass das so stark getrennt wird, glaube ich, gibt es heutzutage immer weniger. Also, dass du wirklich ein DBA-Team hast, und die kümmern sich nur um die Datenbank und nur um die Optimierung der Queries. Und dann gibt es das Entwicklerteam, und dieses Entwicklerteam kümmert sich nur um die Software. Also, ich glaube, es wächst schon immer mehr zusammen. Und für kleinere Projekte braucht man wahrscheinlich immer weniger DBAs, weil das Team im Großen und Ganzen so klassisch eine Datenbank sehr wohl selber am Leben erhalten kann. Der Schein trügt natürlich auch teilweise. Da kann natürlich auch viel passieren, wenn man zu wenig versteht von den Details, die im Hintergrund passieren. Aber ich glaube, es kann viel, viel länger gut gehen als wie früher, wo du halt einfach wirklich super Spezialisten gebraucht hast, die alles organisiert haben, deine Schema überprüft haben und abgesegnet haben. Und das waren so richtige, diese Root Admins sozusagen für die Datenbank. wo du wirklich immer die Leute anbetteln hast müssen, wenn du eine neue Spalte willst, wenn du irgendwas verändern willst. Und du hattest diese Gatekeeper-Rolle auf der Datenbankseite. Also das wird wahrscheinlich immer, immer weniger, hoffe ich zumindest.

Andy Grunwald (00:21:18 - 00:23:20)

Du hattest gerade die DBAs mit klassischen Systemadministratoren verglichen und da stimme ich dir auch zu. Nur weil es DevOps gibt, Side Reliability Engineers und so weiter, macht das nicht die klassischen Systemadministratoren obsolet. Warum? Auf der einen Seite haben sich natürlich ziemlich viele Leute im Systemadministratorenbereich einfach gerebrandet. Vor ein paar Jahren hießen die noch DevOps-Engineer. Wir gehen jetzt nicht in die Diskussion, ob das jetzt ein Jobtitle oder eine Kultur ist. Danach haben die sich selbst gerebrandet nach Site-Reliability-Engineers, weil man sonst ja keine Talente mehr findet. Und jetzt machen die eigentlich immer noch das Gleiche. Wohingegen natürlich Software-Engineers auch nicht die Expertise haben, die ein klassischer Systemadministrator über 10, 20 Jahre aufgebaut hat. Die nächste Baustelle ist, was ich immer wieder merke, dass die meisten Software-Engineers, Devs, Obst- und Reliability-Engineers, wie sie sich auch immer schimpfen, einfach ganz, ganz schwach sind im Bereich Netzwerk, Netzwerk-Design und so weiter und so fort. Und speziell auch mit der Arbeit von klassischen modernen Clouds, VPCs, Subnetzes et cetera. Besonders, wenn man größere Kubernetes-Cluster maintaint, mal eben so ein Subnet zu vergrößern und neu anzupassen und allem Drum und Dran. Richtig berechnen. Klar, hatten wir alle in der Ausbildung, hatten wir alle im Studium, ja? Aber wie viele Software-Indies können das denn wirklich, ja? Und richtige Port-Einstellungen und so weiter, da hört's halt ratzfatz auf. Und deswegen denke ich auch, ähnlich wie im modernen Devopsite-Reliability-Umfeld, da braucht man auch noch Leute mit klassischer System-Administrator-Experience. Und es gibt auch ganz einfach Sachen, da lohnt es sich finanziell und business-technisch einfach nicht, diese zu automatisieren. Bin ich auch ganz ehrlich. Mir blutet zwar das Herz, bin ich aber ehrlich. Und so sehe ich das dann mit DBAs auch. Ich denke, wenn sich jemand richtig gut auskennt, der kann mir dann auch sagen, okay, eine neue SQL-Datenbank, eine Graph-Datenbank, eine Time-Series-Datenbank, eine Denkumenten-basierte Datenbank ist hier der bessere Use-Case. Oder eine klassische SQL-Datenbank. Oder vielleicht reicht auch einfach eine SQLite. Oder vielleicht auch mal Textfile. Also dann auch mal sagen, du fragst hier nach einer Datenbank, aber du brauchst gar keine Datenbank. Ich glaube, das macht dann richtig gute Leute aus.

Wolfi Gassler (00:23:20 - 00:25:36)

Weil ihr auch gerade erwähnt habt, dieses Schema und diese Gatekeeper-Rolle auf der DBA-Seite, also auf den Datenbank-Administratoren, die eine Gatekeeper-Rolle im Schema-Bereich eingenommen haben. Das war ja auch sowas, wo NoSQL geglänzt hat, würde ich mal sagen, oder probiert hat zu glänzen, dass man kein Schema mehr benötigt. Man wird nicht mehr in ein Schema gepresst. Man kann diese klassischen Loads im Webscale-Bereich einfach ganz easy abbilden, weil man da einfach den gesamten JSON-Blob reinschmeißen kann und die Datenbank kümmert sich gar nicht darum, was für Columns du da hast, was für Spalten, garantiert dir natürlich auch nichts, checkt nicht, ob da wirklich ein Integer drinsteht, aber du kannst dann super flexibel damit arbeiten und für viele Web-Anwendungen war das schon eine gute Herangehensweise, weil du einfach ein Feld hinzufügen kannst als Entwickler und dir gar nicht darum kümmern musst, brauchst du da ein Integer, brauchst du da ein String, was verwendest du da überhaupt, musst du das Schema ändern, wie änderst du das Schema, weil es einfach kein Schema gibt. Das war, glaube ich, auch ein großer Punkt von den NoSQL-Datenbanken. Und es stimmt natürlich, die Schema sind weniger wichtig geworden im Web-Bereich. Aber meiner Meinung nach hast du immer ein Schema, weil du lagerst es dann vielleicht aus mehr in die Software-Seite. Aber die Software muss ja wissen, was du für Spalten da drin hast, was für Felder du in diesem JSON-Blob drinnen gespeichert hast. Du wirst ja mit dem arbeiten üblicherweise. Und wenn du eine gute Software schreibst, reichst du ja auch nicht blind irgendwelche Werte durch, vom JavaScript-Client zum Beispiel, sondern überprüfst, ist das Feld korrekt, ist der Datentyp korrekt von diesem Feld. Also du verlagerst eigentlich nur diese ganze Schemaüberprüfung mehr in Richtung Software, weil du das ja wahrscheinlich sowieso programmierst in der Software, obwohl auch vielleicht in der klassischen relationalen Datenbank das in der Datenbank überprüft würde, überprüfst du das in der Software sowieso. Und dann haben halt viele gesagt, okay, das macht das Leben einfach viel, viel einfacher. Man muss aber auch dazu sagen, dass es das Leben definitiv erschwert, weil man eben keine Überprüfung von der Datenbank bekommt, auch nicht so leicht Foreign Keys zum Beispiel machen kann, referenzielle Integrität und diese ganzen Dinge, die bei den relationalen Datenbanken normal mitkommen, diese Features bekommt man natürlich dann auch nicht und damit muss man halt auch leben.

Andy Grunwald (00:25:37 - 00:27:14)

Du hast schon recht, dass man das Schema dann eigentlich nur verlagert von der Datenbankseite in die Software. Aber was für mich als Softwareentwickler auch ganz wichtig ist, ist der Unterschied zwischen einem expliziten Schema und einem impliziten Schema. In der SQL-Datenbank hat man ein explizites Schema. Das ist vorgegeben. Das zwingt dich in einen Rahmen. Das ist positiv, weil jeder Softwareentwickler, der mit der Datenbank arbeitet, weiß sofort, in welchem Rahmen er sich befindet. Das ist negativ, weil die Erweiterung des Schemas teilweise recht aufwendig sein kann, je nach Datengröße, je nach wie man das Schema erweitern möchte oder vielleicht sogar ändern möchte. Wenn man natürlich jetzt eine schemalose Datenbank nimmt, dann hat man natürlich schon in irgendeiner Art und Weise auch ein Schema, genau so wie du sagtest, aber implizit. Und wenn man jetzt sogar noch gar nicht so eine gute Softwarearchitektur hat und vielleicht sogar noch mit einer dynamischen Sprache arbeitet, nehmen wir mal PHP oder Python, und wenn man in seiner Software gar nicht eine eine Data-Klasse hat oder ein Data-Struct oder ähnliches, ja? Also, was dann dieses Schema repräsentiert in Software-Form, sondern mit Array- oder Hash-Map-Indizes arbeitet. Also wirklich so mit Keys, die als Strings immer benutzt werden und nicht als Konstanten. Dann ist sein Schema natürlich relativ lost, relativ verteilt über dann komplette Software. Der Vorteil ist, man kann da einfach Daten reinschmeißen, alles super. Der Nachteil ist, du weißt halt nicht, welche Daten wie wo abgefragt werden. Es ist unglaublich schwierig, dann mal Daten zu entfernen. Nehmen wir mal DSGVO, je nach was für Daten das sind. Man hat halt ein Schema, aber es ist halt einfach implizit.

Wolfi Gassler (00:27:14 - 00:28:19)

Es gibt, glaube ich, heutzutage schon viele Anwendungsfelder, wo das praktisch ist. Und darum haben wir auch die klassischen Datenbanken. Also wenn ich von klassischen Datenbanken rede, ist es immer relationale Datenbanken. Und da haben ja mittlerweile alle nachgezogen. Das heißt, die bieten mittlerweile alle JSON-Felder an. Das heißt, du kannst einfach deinen JSON-Blob in eine Spalte schmeißen. Und die haben mittlerweile sogar Features, dass du zum Beispiel Felder in deinem JSON-Blob automatisch extrahieren kannst, einen Index drauflegen kannst, das was bei den klassischen dokumentbasierten Datenbanken oder Key-Value-Stores später auch noch dazu gekommen ist, weil am Anfang gab es da ja auch überhaupt keine Indizes, die du zum Beispiel auf einem Feld anlegen kannst in deinem JSON-Objekt, was ja dann auch ein Problem ist natürlich, wenn du irgendwie nach irgendwas suchst. Das war natürlich immer ein großes Problem und dann musst du irgendwie mit MapReduce in MongoDB zum Beispiel alle Daten durchgehen. Klar ist es dann verteilt, horizontal skaliert, aber trotzdem hat es natürlich nicht den gleichen Wert wie ein superschneller Indexzugriff, den du ja unter Umständen gerne haben wirst, auch im Web.

Andy Grunwald (00:28:20 - 00:29:17)

Ich hab aber auch schon Applikationen gesehen, da wo zum Beispiel von diesem JSON-Datatype in einer relationalen Datenbank Gebrauch gemacht wurde. Und dann auf Client-Seite hatte man dann eine Validation mit dem JSON-Schema. Also das gibt's halt auch, ja. Und da frage ich mich dann, okay, du hast auf der Client-Seite ein JSON-Schema, was validiert wird, dann über CI oder Ähnliches. Oder vielleicht sogar während der Runtime. Und dann auf der anderen Seite schmeißt du alles einfach in ein JSON-Blobfeld. denke ich mir so, okay, du hast jetzt hier eine Speicherung, nutzt aber irgendwie nicht die Power der Datenbank, weil ich hab zum Beispiel damals noch im Studium gelernt, lager so viel Arbeit wie möglich auf die Datenbank aus. Ja, mit Arbeit ist hier so was gemeint wie Berechnungen, Summenbildung, Joins, Gruppierungen und, und, und. Und das geht natürlich dann nicht mehr so gut. Das machen dann, glaub ich, ziemlich viele NoSQL-Datenbanken dann auf Client-Seite.

Wolfi Gassler (00:29:18 - 00:30:52)

Ich glaube, das war eigentlich der allgemeine Trend, dass einfach viel mehr in Richtung Software geht und du dich weniger um die Datenbank kümmern musst. Und umso flexibler die Datenbank ist, umso weniger Probleme hast du natürlich. Und wenn dahinter womöglich sogar noch ein Administrator steht, der den Zugang blockiert zur Datenbank, dann war das natürlich immer ein Problem. Und da ist es halt oft auch einfacher, das in der Software zu machen. Es ist auch, muss ich ganz ehrlich sagen, dieses, was du jetzt erwähnt hast, dass man alles in der Datenbank machen sollte oder möglichst viel in der Datenbank machen soll, weil die einfach schneller ist und vielleicht das Performante direkt auf den Daten abarbeiten kann. Das stimmt natürlich schon in vielen Fällen, aber man muss auch dazu sagen, du hast halt dann wieder zwei Orte, wo dein Code läuft und du hast halt dann vielleicht sogar Procedures in der Datenbank oder so, die irgendwelche Dinge machen. Das kann zwar super schnell sein, aber du hast halt dann wieder Teile in deinem klassischen Code, dann wieder Logik in der Datenbank und so trennt sich das halt alles und macht auch alles viel, viel komplizierter. Und wenn du alles in deiner Software hast und auch dein JSON-Schema in der Software hast, dann ist die Datenbank halt nur mehr ein dummer Storage, der am Ende deinen JSON-Blob annimmt und irgendwo abspeichert und halt möglichst verteilt, weil du hast eine große Web-Applikation und das horizontal skaliert. Und das war halt so die Idee, in die Richtung NoSQL gegangen ist. Und NoSQL hat ja auch stark die ganzen ACID-Properties aufgeweicht. Also ACID, nochmal zur Wiederholung, was heißt ACID, Andi, kommst du es hin? Ich kann es derweil in Wikipedia nachschlagen.

Andy Grunwald (00:30:52 - 00:30:57)

Atomicity, Consistency, Isolation and Durability.

Wolfi Gassler (00:30:57 - 00:31:00)

Ja, du hast das jetzt sicher nachgeschaut, du hast es nicht aus dem Kopf gewusst, oder?

Andy Grunwald (00:31:00 - 00:31:10)

Ne. Also ich muss auch zugeben, diese englischen Wörter, Atomicity, da kannst du mich jagen, das ist genau wie Message Uchits. Kannst du den englischen Start aussprechen? Message Uchits?

Wolfi Gassler (00:31:10 - 00:31:12)

Message Uchits.

Andy Grunwald (00:31:12 - 00:31:12)

Ja.

Wolfi Gassler (00:31:12 - 00:33:14)

Du kannst es auch auf Deutsch sagen, Atomarität, Konsistenz, gut ist ein K statt ein C, aber close enough, Isolation und Dauerhaftigkeit. Also Atomarität in einem Satz ist so, entweder es werden alle deine Updates geschrieben oder keines. Konsistenzerhaltung, klassisches Beispiel, du hast Kunden und Rechnungen und wenn du eine Rechnung hast, dann gibt es auch immer den Kunden dazu und wenn du den Kunden löscht, dann kann die Rechnung nicht mehr existieren ohne Kunden. Hast du eine Konsistenzgarantie, die da zum Beispiel gegeben wird. Isolation ergibt sich eigentlich aus Atomarität und Konsistenz, dass wenn eben noch nicht alle Updates geschrieben sind, dass andere Leute auch nicht Updates, die schon zwischendrin gemacht worden sind, sehen können. Also erst, wenn alles abgeschlossen worden ist. Und die Dauerhaftigkeit heißt eigentlich nichts anderes, als dass alles sicher auf deine Platte zum Beispiel geschrieben ist oder ganz allgemein, wenn die Datenbank sagt, es ist geschrieben worden. alles ist okay, dass du die Daten eigentlich nicht mehr verlieren kannst. Wenn es einen Stromausfall gibt, wenn es irgendwo einen Crash gibt, verlierst du die Daten nicht. Das ist im Großen und Ganzen ACID zusammengefasst. Und bei NoSQL Datenbanken Die haben natürlich schon gemerkt, wenn wir da ein Versprechen geben, das soll skalieren auf vielen Servern, dann kannst du zum Beispiel Atomarität nicht mehr so einfach garantieren, weil du auf ganz vielen Servern arbeitest, das verteilen musst, womöglich auf hunderte Server in unterschiedlichen Data Centers. Da ist es nicht mehr so einfach ACID zu garantieren und darum hat man das auch aufgeweicht, weil man auch gesagt hat, okay im Web-Bereich ist es nicht so wichtig, dass zum Beispiel die Isolation garantiert ist. Wenn da ein User irgendeinen alten Wert liest und erst zwei Minuten später den neuen und ein anderer User, der auf die Webseite kommt, aber schon den neuen Wert bekommt, ist das vollkommen in Ordnung, weil es nicht so schlimm ist, weil das ja nur ein Blogartikel ist, wo der Artikel zum Beispiel abgedatet worden ist. Also das ist nicht so schlimm.

Andy Grunwald (00:33:14 - 00:33:17)

Da reden wir dann über Eventual Consistency.

Wolfi Gassler (00:33:17 - 00:33:36)

Genau, das ist dann auf der NoSQL Seite, da hat sich ein Akronym auch entwickelt, ich glaube das ist erst später gekommen, weil man halt irgendwie probiert hat sowas wie ACID zu kreieren und weil man halt so lustig ist, hat man sich gedacht, okay zu ACID passt gut BASE, also BASIC zu Jetzt kommst du.

Andy Grunwald (00:33:36 - 00:33:38)

Aus der Chemie oder aus der Chemie?

Wolfi Gassler (00:33:38 - 00:33:48)

Aus der Chemie natürlich. Und drum war eben die logische Folgerung aus von Acid, von, das heißt nicht Acid, wie heißt denn das, das Gegenteil von Basis ist?

Andy Grunwald (00:33:48 - 00:33:53)

Also in der Weiterführendenschule war ich in Chemie recht gut, aber danach habe ich das Thema auch aufgegeben.

Wolfi Gassler (00:33:53 - 00:36:05)

Säure. Sauer. Säure. Okay, also Säure. Und als Gegenstück Basisch Base. Das heißt, es hat sich dieses Akronym Base gebildet. Ich glaube, man ist einfach später dann mit dem Begriff um die Ecke gekommen und hat sich da irgendwas ausgedacht, weil es cool klingt. Und das heißt basically available, soft state and eventually consistent. Auch wieder ganz kurz erklärt was heißt es eigentlich eben es ist nicht mehr acid im großen und ganzen basically available heißt bin möglichst verfügbar das heißt ich kann Daten immer lesen ich komme nicht in so einen zustand wo ich irgendwie daten noch mal nicht lesen kann weil irgendwie eine transaktion noch läuft weil ein anderer serverknoten weggebrochen ist sogar in einem split brain Situation wenn mein halber cluster weg bricht kann ich trotzdem noch daten lesen das heißt ich bin grundsätzlich immer Available, aber unter Umständen sind die Daten gar nicht mehr korrekt, die ich lese. Vielleicht veraltet schon, weil dieses Update eben noch nicht auf allen Servern durchgegangen ist. Soft State bedeutet genau das Gegenteil von den Konsistenzkriterien oder von den Konsistenzgarantien, die ich bei ACID habe. Ich bin in einem Soft State und kann eben nicht wirklich sagen, ob der aktuelle State konsistent ist und mir wird auch keine Konsistenz garantiert. in der Datenbank, aber was garantiert wird ist, ist es eventually consistent, das heißt, wenn ich lang genug warte, dann sind meine Knoten alle up to date und dann habe ich so eine Art konsistenten Zustand in der Theorie zumindestens, wenn ich lang genug warte und alle sich beruhigt hat, sozusagen in meinem Cluster, alle Konflikte aufgelöst worden sind, dann bin ich schlussendlich, also eventually in einem konsistenten Zustand. Das ist diese Base-Semantik, die sich da im Gegensatz zu ACID gebildet hat und die weicht einfach alles auf und damit ist es überhaupt erst möglich, dass man zum Beispiel so stark in die horizontale Skalierung geht, weil ich eben kein Asset mehr garantieren muss und dann ist es super einfach, oder nicht super einfach, aber viel viel einfacher, irgendwas zu verteilen in meinem Cluster zum Beispiel.

Andy Grunwald (00:36:05 - 00:36:26)

Wobei man doch sagen muss, und das ist jetzt eher eine Frage, bei klassischen SQL-Datenbanken, wenn wir uns jetzt an Asset orientieren, an den ersten beiden Wörtern, Atomar und Konsistenz. Bei Atomar hat es so das Beispiel gebracht, wenn ein Update fehlschlägt, gehen die anderen auch nicht durch, sondern werden dann abgebrochen.

Wolfi Gassler (00:36:26 - 00:36:33)

Beziehungsweise sogar zurückgerollt. Wenn du davor schon ein Update hast, was Teil einer Transaktion ist, dann wird es sogar wieder zurückgerollt.

Andy Grunwald (00:36:33 - 00:36:59)

Und genau darauf möchte ich ja hinaus, dass der Client, um die Asset-Garantien ja auch zu nutzen, entsprechend programmiert werden muss. Nehmen wir mal ein Beispiel. Nehmen wir mal eine Web-Applikation. Die führt jetzt zehn Updates hintereinander aus. Wenn diese zehn Updates hintereinander einfach ausgeführt werden, die ersten drei gehen durch, das vierte schlägt fehl, dann werden die ersten drei ja nicht gerollbacked, sofern man nur die Updates ausführt, sondern diese Updates muss man dann natürlich schon in einer Transaktion rappen.

Wolfi Gassler (00:37:00 - 00:38:17)

Genau, also klassisch, man startet mit einer Transaktion, sagt Start Transaction und hat dann mehrere Updates hintereinander, die können ruhig irgendwo in unterschiedlichen Teilen vom Code sein und ganz am Ende schickt man dann ein Commit, das heißt man ist am Ende der Transaktion und dann übernimmt die Datenbank. Und wenn irgendwo was fehlschlägt oder kein Commit kommt, dann wird es einfach nach einem Timeout wieder zurückgerollt und man kann sich sicher sein, dass alles am Ende konsistent ist. Das ist natürlich extrem wichtig, wenn du zum Beispiel eine Bank bist, wo du irgendwie Geld von einem Konto auf das andere transferierst, wo du ein Update am ersten Konto machen musst und ein Update am zweiten Konto. Und da darf natürlich kein Geld verloren gehen am Weg, wenn da zum Beispiel das zweite Update dann fehlschlägt oder wenn da eine andere Transaktion von einem anderen User zum Beispiel dazwischen ausgeführt wird, dann darf da natürlich nicht irgendwie ein falscher Kontostand oder so entstehen oder mehr Geld plötzlich entstehen oder weniger Geld, was auch immer. Und da sind natürlich solche ACID-Garantien unbedingt nötig, sonst kannst du sowas nicht bauen. Aber im Web hat man halt ganz oft viel einfachere Use Cases und daher hat eben NoScale gesagt, wir sind fürs Web da, für WebScale, wir skalieren gut, dafür haben wir weniger Garantien zum Beispiel, wenn es um Transaktionen geht.

Andy Grunwald (00:38:17 - 00:38:36)

Aber das ist ja ein ganz wichtiger Punkt, wenn du sagst, okay, du hast eine MySQL und eine PostgreDatenbank, Ja, die kann ACID, aber der Client muss es halt auch nutzen, ja? Also nicht, dass du sagst, ah, ich hab nur MySQL, ich hab hier automatisch ACID, ich bin whatever-compliant mit schieß-mich-tot. Ja? Also der Client muss es natürlich schon nutzen, dasselbe.

Wolfi Gassler (00:38:36 - 00:38:45)

Der Programmierer oder die Programmiererin muss es nutzen. Also die muss das Wissen haben und dann dementsprechend die nötigen Kommandos verwenden, klarerweise.

Andy Grunwald (00:38:45 - 00:38:51)

Alles richtig und der zweite Kommentar ist ja und zwar eigentlich genau dasselbe Pattern bei der Konsistenz.

Wolfi Gassler (00:38:51 - 00:38:52)

Du hattest glaube ich gerade das Beispiel.

Andy Grunwald (00:38:52 - 00:40:03)

Gebracht mit, du hast Kunden in der einen Tabelle und Rechnungen in der anderen Tabelle und wenn der Kunde gelöscht wird, sollen auch die Rechnungen gelöscht werden. Ja, ob das jetzt businesstechnisch Sinn macht, das entscheidet ihr mal bitte, aber nehmen wir mal diesen Use Case an. Das bedeutet natürlich auch, dass du so Sachen machen, so Features nutzen solltest, wie referenzielle Integrität. Das bedeutet auf der User Tabelle sollst du sagen, okay User Record, Und delete, bitte delete dann da drüben auch. Natürlich kannst du es auch applikationsseitig abbilden in deiner Applikation, dass du da die Logik programmierst. Oder du nutzt halt so was wie referenzielle Integrität und diese Features von der Datenbank, um da halt wirklich die Relation darzustellen. Und da ist die nächste Frage, wie viele Leute machen das wirklich, damit die halt das Feature der Konsistenz aus dem Asset Term mitnehmen. Also nehmen wir mal klassisches Web, Wordpress, Drupal, Typo3 und so weiter und so fort. Ganz selten. Und speziell wenn wir unten drunter nochmal ein ORM haben. Oder ein Database Expression Layer. Huiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiuiui Und genau das war eigentlich die Idee von NoSQL.

Wolfi Gassler (00:40:03 - 00:40:12)

Es wird sowieso wenig verwendet. Es ist zu komplex. Man braucht es meistens nicht. Das heißt, wir brauchen eine neue Datenbank, die das einfach vereinfacht.

Andy Grunwald (00:40:12 - 00:40:32)

Eine Frage. Du hast gesagt, braucht man das nicht oder wissen einfach unglaublich viele Leute nicht, dass das existiert? Oder wissen Leute, dass das existiert mit Asset, wissen aber nicht, dass man es explizit anwenden muss, clientseitig und programmierseitig? Das war eine interessante Frage meines Erachtens.

Wolfi Gassler (00:40:32 - 00:40:42)

Wo ist der Unterschied? Am Ende, wenn es Leute nicht wissen, dann brauchen die Leute das auch nicht. Und damit hat sich das erledigt. Und ich glaube, darum sind auch so viele aufgesprungen auf diesen No-School-Trend.

Andy Grunwald (00:40:42 - 00:40:54)

Wenn bei meinem Auto die Bremsen runtergefahren sind, dann weiß ich das gegebenenfalls nicht, brauche es aber. Nur weil ich etwas ja nicht weiß, heißt das ja nicht, dass ich das nicht brauche, sondern ich weiß es ja einfach nur nicht.

Wolfi Gassler (00:40:54 - 00:41:10)

Naja, ohne Bremsen kannst du nicht Auto fahren, aber ohne referenzielle Integrität kannst du einen Block bauen. Insofern für das Blockbeispiel ist es komplett ausreichend. Klar könnte man vielleicht ein paar Sachen drüberlegen, die ganz praktisch sind, referenzielle Integrität, aber ob das jetzt wirklich nötig ist.

Andy Grunwald (00:41:10 - 00:41:30)

Ich glaube, das Beispiel mit den Bremsen, ich glaube, ich merke das erst zu spät. Und ich glaube, so ist das dann auch bei referenzieller Integrität oder Konsistenz. Weil erst, wenn das Kind in den Brunnen gefallen ist, erst, wenn meine Daten komplett inkonsistent sind oder erst, wenn nur die Hälfte der Updates und der Insights durchgelangen sind, dann merke ich ja, dass ich das brauche.

Wolfi Gassler (00:41:30 - 00:43:29)

Ganz guter Punkt, der auch auf das NoSQL an sich zutrifft. Also NoSQL hat er gestartet mit kein SQL. Eigentlich, die Datenbank braucht kein SQL. Dann hat man aber gemerkt, so ideal ist es doch nicht und SQL funktioniert ganz gut. Wir haben aber dieses coole NoSQL-Wort. Wir ändern es jetzt einfach um auf Not Only SQL. Also NoSQL steht für Not Only SQL. Damit sind die ganzen Datenbanken, die auch SQL anbieten, weil man eben drauf gekommen ist, SQL ist vielleicht doch nicht so schlecht, SQL zu haben und nicht alles mit irgendwie MapReduce in JavaScript zu machen. wie am Anfang bei MongoDB oder mit einer eigenen Query-Sprache, die man wieder extra lernen muss. SQL kennt halt jeder und ist ganz praktisch, sehr weit verbreitet. Und dann hat man halt SQL doch wieder eingeführt. Und wenn man sich das heutzutage anschaut, dann ist der, drum ist glaube ich vielleicht dieses Wort NoSQL auch wieder mehr in den Hintergrund gerückt, weil SQL wieder mehr in den Vordergrund gerückt ist. Also wenn man sich so neue Systeme anschaut wie Presto zum Beispiel. Es wurde ursprünglich von Facebook entwickelt und ermöglicht den Zugriff auf ganz unterschiedliche Datenquellen. Und was verwendet es? SQL am Ende wieder. Also SQL ist eine sehr gute Anfragesprache, weil sie super verbreitet ist, super einfach zu lernen ist. allgemein gültig ist und sie hat sich eigentlich jetzt wieder durchgesetzt, also man ist komplett weggegangen von diesem not SQL Trend und hat jetzt eigentlich viel viel mehr SQL bei ganz neuen Datenbanken oder Datenbank ähnlichen Systemen oder wenn man mit Datenbanken einfach arbeitet, auch im ganzen Data Science Bereich ist glaube ich SQL immer noch der absolute Standard und wenn man Spark, Hive oder sonstige Dinge verwendet, die haben alle irgendwo ein SQL Dialekt zumindestens, weil der einfach allgemein gültig ist und ich glaube Datenbanken ohne SQL werden eigentlich wieder weniger, außer man geht jetzt wirklich auf Key-Value-Stores, wo man sehr tief unten integriert irgendwie Key-Value-Anwendungsfälle hätte oder hat.

Andy Grunwald (00:43:29 - 00:44:03)

Ich fühle mich gerade so ein bisschen wie in so einer Vorlesung an der Uni. Wir sprechen hier gerade sehr viel über Theorie, Acid, NoSQL, Base, die Historie, wo das eigentlich herkommt. Lass uns doch mal wieder ein bisschen praktisch werden. Lass uns doch mal bitte ein bisschen Name-Dropping betreiben. Und zwar nennen wir doch mal ein paar Datenbanken, in welches Datenbankmodell diese fallen würden und vielleicht mal Beispiel-Use-Cases, damit wir mal ein bisschen praktisch werden und auch mal was zum Googeln haben, wenn ich mal was ausprobieren möchte.

Wolfi Gassler (00:44:04 - 00:45:52)

Da bin ich jetzt ganz geschickt und nenne eine Datenbank und zwar die HANA-Datenbank von SAP, Hasso Plattner, weil dann kann ich kurz zurückspringen zum akademischen Teil, weil der Hasso Plattner ja auch eigenes Institut hat und in dem Bereich auch einiges gemacht hat und HANA ist ja eine Hauptspeicherdatenbank. Das heißt, die behält eigentlich die meisten Daten im Hauptspeicher. Und das war auch ein Punkt, der noch in diesem Paper von Stormbreaker erwähnt worden ist, der, glaube ich, extrem wichtig ist, dass man eigentlich weggegangen ist von den klassischen Festplatten, die sich drehen, zu Hauptspeicher, weil heutzutage eigentlich ganz viel im Hauptspeicher Platz hat und es gibt wenig Systeme, die nicht im Hauptspeicher Platz haben, wenn es darum geht, die Daten, die man so im täglichen Gebrauch hat oder von einem System, das ständig abgefragt wird. Und Hasso Plattner hat da mal, ich habe das selber auch mal gehört, ich glaube das war schon vor über zehn Jahren, hat da mal erwähnt, lang bevor HANA wirklich bei SAP dann im Einsatz war, hat er schon erwähnt, bei SAP gibt es eigentlich keinen Kunden, dessen Daten nicht komplett im Hauptspeicher Platz haben, also zumindest was er täglich braucht, also keine extrem historischen Daten klarerweise, aber die, die man im täglichen Leben braucht, um den Firmenablauf zu garantieren, Die haben immer im Hauptspeicherplatz, sogar vor zehn Jahren schon. Und er meinte, manchmal ist es teuer, da muss man wirklich Terabyte RAM oder so reinstecken in so eine Maschine. Aber es hat im Hauptspeicherplatz. Und darum hat man auch dann neue Datenbanken entwickelt. die einfach viel optimierter waren im Hauptspeicherbereich und nicht mehr auf die sich drehenden Festplatten optimiert waren und mit dieser Technologie probiert haben, eine bessere Performance zu bekommen. Im Main-Memory gibt es da natürlich ganz andere Herangehensweisen.

Andy Grunwald (00:45:52 - 00:46:27)

Und zum Beispiel so ein Key-Value-Store wie Redis macht sich das ja auch zunutze, hält primär alles im Hauptspeicher, im RAM und ist natürlich dadurch ratenschnell. Klar hat Redis zum Beispiel auch ein paar Persistenzfeatures, aber die Hauptoperationen finden alle im Rahmen statt. Und da muss ich sagen, bin ich ein mega Fan von. Natürlich muss man da ein bisschen mit der Speicherung der Daten aufpassen. Und welche Daten speichert man da? Und wann wird das persistiert auf Festplatte? Und wie groß ist der Timeframe für einen potenziellen Datenloss? Aber ich bin da ein großer Fan von zum Beispiel.

Wolfi Gassler (00:46:27 - 00:48:03)

Man hat da auch dann auf eine ganz einfache Technologie gesetzt. Früher hatte man da ja bei den Datenbanksystemen extrem viele Layer von der Festplatte bis zum Speicher und was man nicht alles am Weg optimiert hat. Und dann hat man eigentlich gemerkt, okay, das Betriebssystem, MongoDB hat das ja auch am Anfang gemacht zum Beispiel, die haben einfach Memory Mapped Files verwendet. Das heißt, du hast definiert, okay, du hast da ein File auf der Festplatte, und es soll direkt in den Memory gemappt werden. Das ist komplett vom Betriebssystem übernommen worden und das Betriebssystem hat sich um alles gekümmert. Und du hast in der Datenbank eigentlich komplett diesen Layer vergessen können und hast einfach direkt im Memory gearbeitet. Das wurde hinten weg abstrahiert, wurde für ein Betriebssystem schön gemappt, dass das auch immer wieder in die FALS zurückgeschrieben wird. Und so war es überhaupt möglich, dass man Datenbanken programmieren kann, ohne dass man da 20 Jahre Erfahrung hat und sich um diesen ganzen Stack da im Hintergrund gekümmert hat, wie kann man denn da optimiert überhaupt auf eine Festplatte schreiben. Und das war halt auch eine Entwicklung von den Server-Systemen, die immer stärker geworden sind, großen Memory gehabt haben und dann hat man einfach das auf das Betriebssystem ausgelagert und im schlimmsten Fall ist da sogar irgendwas in den Swap ausgelagert worden. Das hat aber alles das Betriebssystem gemacht und man hat sich selber gar nicht drum kümmern müssen, und hat so auch wieder schlussendlich eine Optimierung gemacht, indem er nicht das Rad neuer gefunden hat, sondern eben verlassen hat auf etwas, was das Betriebssystem schon zur Verfügung stellt. Aber um nochmal zurückzukommen auf deine Frage, Name Dropping, was für Names hättest du denn gern gedroppt? Wirf mal rein.

Andy Grunwald (00:48:03 - 00:48:21)

Okay, damit wir die Folge jetzt nicht hier sprengen und keine zwei bis drei Stunden Folge machen, limitiere ich mich einfach mal auf vier datenbank typen oder vier datenbanken die mir jetzt gerade so einfallen bezüglich name dropping und du nennst mal was ist das für eine datenbank und was wäre so ein klassischer use case.

Wolfi Gassler (00:48:21 - 00:48:25)

Dafür darf ich danach google nach oder muss ich das jetzt on the fly beantworten können wie ich die antwort kriege.

Andy Grunwald (00:48:26 - 00:48:30)

Dass mir egal das Ergebnis zählt. Also ich bin ja ein Fan davon, du musst nicht alles im Kopf haben, du musst nur wissen, wo es steht.

Wolfi Gassler (00:48:31 - 00:48:34)

Okay, bin gespannt, bin bereit fürs Quiz.

Andy Grunwald (00:48:34 - 00:48:35)

Neo4j.

Wolfi Gassler (00:48:35 - 00:49:50)

Neo4j, alter Klassiker, Graf-Datenbank. Ist einer der ersten großen Graf-Datenbanken, würde ich sagen. Also man geht jetzt wirklich zurück ins historische Zeitalter. ist in Java programmiert und ermöglicht eben, dass man die Daten in dem Graph ablegt, was jetzt noch nichts weltbewegendes ist, kann in einer relationalen Datenbank natürlich auch machen, aber die bietet natürlich spezielle Graph-Operationen, dass ich zum Beispiel den kürzesten Weg zwischen zwei Knoten finde oder solche Dinge. Da ist es dann auch schwieriger mit SQL, da braucht man dann wirklich eigene Anfragesprachen, ist schon hoch spezialisiert, aber wenn man wirklich so eine Graf-Datenbank braucht für einen Graf-Anwendungsfall, den man eben nicht mit der relationalen Datenbank abbilden kann, wenn man spezielle Graf-Algorithmen braucht, dann würde ich auf so eine Graf-Datenbank setzen. Sonst gibt es da wirklich andere Konzepte, wie dass man nur den Graf mappt auf eine relationale Datenbank oder auf so Mischformen wie ArangoDB zum Beispiel, Damit kann man dann mehr abdecken, aber sonst würde ich aufpassen, dass man auf eine Kraftdatenbank setzt, weil man einfach den klassischen Use Case, wenn man den vielleicht noch braucht, dann verkompliziert, wenn man eine Kraftdatenbank verwendet. Aber sonst ist natürlich eine sehr starke Kraftdatenbank Neo4j.

Andy Grunwald (00:49:51 - 00:50:12)

Use-Case spezifisch fällt mir bei der Graf-Datenbank immer dieses Facebook-Feature oder Link-In-Feature ein, Freunde von Freunde. Wie viele Connections hast du denn mit dieser Person? Das ist, glaube ich, so ein ganz klassischer Use-Case, der in der Graf-Datenbank sehr, sehr effizient gemacht werden kann, was bei Relational dann gegebenenfalls schon in rekursive Queries enden kann, was dann sehr teuer sein kann.

Wolfi Gassler (00:50:13 - 00:50:29)

Das stimmt, das ist ein bisschen leichter umzusetzen. Man darf aber nicht vergessen, dass es trotzdem extrem aufwendig ist, diese Berechnung. Also nur weil ich eine Kraftdatenbank habe, werden die Berechnungen nicht automatisch irgendwie ganz billig oder so. Man kann sie ein bisschen optimieren, aber sie sind noch nicht gratis sozusagen. Also das darf man auch nicht vergessen.

Andy Grunwald (00:50:30 - 00:50:37)

Und Neo4j ist mir auch im Kopf geblieben, weil die die Query-Sprache, die Graph-Query-Sprache Cypher recht populär gemacht haben.

Wolfi Gassler (00:50:37 - 00:50:41)

Genau, also da ist es einfach nicht mehr möglich mit SQL zu arbeiten, ganz klar.

Andy Grunwald (00:50:41 - 00:50:43)

Kommen wir zum nächsten Kandidaten, M3.

Wolfi Gassler (00:50:44 - 00:52:04)

M3 bin ich erst kürzlich selber aufmerksam drauf geworden, ist eine Time-Series-Datenbank, Also wird vor allem in dem Umfeld von Metriken zum Beispiel, jetzt wenn man irgendwelche Servermetriken oder so abspeichern will und dann mit Grafana zum Beispiel anzeigen, dann ist M3 eines der möglichen Backends, das man verwenden kann. Und Timeseries Datenbanken sind halt wirklich optimiert auf sehr viele Daten, die reinkommen, sehr strukturiert sind und die dann halt optimiert abfragen kann, um zum Beispiel eben einen Graphen zu bauen, die Average Latency der letzten Monate oder solche Abfragen zum Beispiel. Also die sind halt dann einfach speziell auf diesen Use-Case optimiert. Mit denen hat man aber normalerweise wenig Kontakt, weil wenn man so Metric-Software verwendet, dann ist da meistens die Datenbank mit dabei im Hintergrund und man braucht da gar nicht so viel Wissen und das sind ja meistens auch nicht Systeme, die jetzt extrem konsistent sein müssen, wenn da mal irgendwo eine Metric verschwindet oder ein paar Minuten fehlen, dann ist das ja auch nicht so schlimm. Also die haben dann andere Anforderungen, auch bezüglich auf Durability und Konsistenz, weichen die natürlich üblicherweise Sachen auf, damit das möglichst optimiert ist für den Time Series Use Case.

Andy Grunwald (00:52:04 - 00:52:07)

M3 ist eine Cloud-Native-Datenbank und... Du hast.

Wolfi Gassler (00:52:07 - 00:52:12)

Jetzt in der Zwischenzeit wieder Zeit gehabt, um zu googlen und kannst jetzt einen raushängen lassen, aber mach mal.

Andy Grunwald (00:52:12 - 00:52:40)

Nee, in der Zeit, ich muss zugeben, M3 nutzen wir als Influx-DB-Emplacement. Weil speziell, wenn es an einen größeren Matrix-Storage geht, haben wir das Gefühl, dass M3 deutlich besser skaliert als eine Influx. Zumindest mit der Open-Source-Variante. Und M3 ist eine superpopuläre Datenbank, wenn es auch an Prometheus-Storages geht. Ähnlich wie Victoria Matrix oder Ähnliches. Aber, genau, zeitbasierte Datenbanken.

Wolfi Gassler (00:52:40 - 00:53:00)

Ich würde sogar eher so ein Storage Backend fast sehen. Ich meine, ist natürlich eine Datenbank, aber ist eigentlich so ein Storage Backend, was man dann eben bei, oder was man eben statt InfluxDB zum Beispiel einsetzen kann. Und üblicherweise ist es nicht so, dass man jetzt eine Software schreibt und direkt auf M3 zugreift, sondern da ist meistens irgendwas dazwischen, üblicherweise.

Andy Grunwald (00:53:01 - 00:53:03)

Nimm mal den vorletzten Kandidaten, Cassandra?

Wolfi Gassler (00:53:03 - 00:54:12)

Cassandra ist ein Wide Column Store, nennt sich das. Also das ist so ein spaltenorientierter Ansatz, wo man auch innerhalb einer Spalte nochmal so Unterstrukturen machen kann, also so verschachtelt sozusagen. Und war eben auch dafür gedacht auf Commodity, Hardware, zu operieren, daher stark verteilt, ist glaube ich damals von Facebook sogar entwickelt worden oder zumindest verwendet worden für die Inbox, also für das Messaging-System bei Facebook, für eine Zeit zumindest, und war eben optimiert in einem Cluster zu laufen und das Ganze zu verteilen, möglichst schnell, möglichst große Datenmengen verwalten zu können. Und war mal extrem gehypt, in letzter Zeit habe ich ehrlich gesagt sehr wenig davon gehört. Es wird schon noch aktiv eingesetzt, meines Wissens, aber ich würde sagen der Hype ist vorbei, habe wenig gehört in letzter Zeit, dass das irgendwo noch als Datenbank sehr stark empfohlen wird. Ich glaube das ist schon spezieller Nischenbereich, wenn man sehr viele Daten hat und spezielle Anforderungen hat.

Andy Grunwald (00:54:12 - 00:54:15)

Falls ihr Cassandra im Einsatz habt, lasst uns das mal wissen.

Wolfi Gassler (00:54:15 - 00:54:19)

So, und jetzt die letzte große Datenbank, die du wissen willst.

Andy Grunwald (00:54:19 - 00:54:25)

Und da bin ich mir gar nicht sicher, ob mein letzter Kandidat wirklich eine richtige Datenbank ist, aber das ist jetzt mal die Frage an dich, Memcash.

Wolfi Gassler (00:54:25 - 00:54:36)

Memcache, eieiei, das ist ja eine gute Frage, ob das eine Datenbank ist. Ich glaube, Memcache kann mittlerweile persistent Sachen abspeichern, schätze ich mal, oder?

Andy Grunwald (00:54:36 - 00:54:37)

So viel ich weiß nicht.

Wolfi Gassler (00:54:37 - 00:55:13)

Ah, kann immer noch nicht, okay. Ich habe das eigentlich nur so im Kopf immer. Wir haben jetzt Memcache endlich durch Redis ersetzt. Also ich hab das irgendwie so als Vorgänger fast im Kopf für eine verteilte In-Memory-Speicher-Engine, die, glaube ich, aus klassischen Caching-Strukturen, darum auch der Name, hervorgegangen ist. Ich glaube, bei Trivago haben wir sie am Anfang noch verwendet, oder? Um Sessions zu speichern, wenn du PHP auf mehreren Servern verwendet hast und dann hast du irgendwo die Sessions speichern müssen, damit du round robin auf alle Server zugreifen kannst.

Andy Grunwald (00:55:14 - 00:56:22)

Gevago hat sehr, sehr stark am Anfang auf Memcache gesetzt. Später haben wir mehr und mehr davon auf Redis umgezogen. Der Grund war einfach, dass wir festgestellt haben, dass bei unterschiedlichen Cache-Itemgrößen Memcache intern ziemlich viele Evictions getriggert hat. Das hängt damit zusammen durch die Slap Allocation. Das geht natürlich jetzt sehr tief in Memcache rein. Aber wenn du einen Cache-Eintrag hast, der z.B. 2 Byte groß sein kann oder 10 Byte, dann ist das natürlich schon ein Problem für Memcache intern, wie der den Memory handelt und wie sogenannte Slabs allokiert werden. kriegst du ziemlich viele Cache Evictions. Das bedeutet, Memcache kümmert sich darum, die jeweiligen Speicherbereiche ordentlich aufzuräumen. Wo Redis die ganze Sache, ich nenne es mal, anders handelt und mit unterschiedlichen Cache-Größen besser klarkommt. Und speziell, wenn es an Session-Handling geht, speziell im PHP-Bereich, wenn man da ziemlich viele Daten in der Session speichert, dann kann eine Session natürlich unterschiedliche Art von Größen erreichen, je nach User Behavior.

Wolfi Gassler (00:56:22 - 00:56:25)

Weißt du, ob das noch viel eingesetzt wird?

Andy Grunwald (00:56:25 - 00:56:55)

Memcache wird einfach noch immer sehr sehr viel eingesetzt, aber ich glaube, ich habe auch schon gehört, dass ziemlich viele Firmen dann eher auf Redis gehen, allein weil Memcache natürlich primär klassisch Set und Get ist und Increment und allem drum und dran und du mit Redis schon nativere Unterstützung von Datentypen wie Hashmaps, Listen, Sets und ähnliches hast und du natürlich dann ziemlich viele Operationen auf Datenbankseite, nein auf Datenbank oder Key-Value-Seite, ob jetzt Memcache eine Datenbank ist oder Redis eine Datenbank, weiß ich grad nicht.

Wolfi Gassler (00:56:55 - 00:58:03)

Aber wenn du wirklich eine ordentliche Datenbank haben willst und bisher Memcache verwendet hast, fällt mir nämlich gerade ein, MySQL hat glaube ich seit der 6. Version Memcache Support. Das heißt, du kannst mit dem Memcache-Protokoll direkt auf MySQL zugreifen und kannst MySQL mit SetGet ganz normal ansprechen und kannst aber trotzdem referenzielle Integrität zum Beispiel sogar auf den Daten haben und auf dieselben Daten mit SQL zugreifen. Ich glaube, Oracle hat dann später auch sowas gebaut. Also das ist eigentlich ziemlich cool, weil halt dieses Protokoll super einfach ist, weit verbreitet ist und du kannst da einfach eine MySQL zum Beispiel dazwischen hängen. Wobei man natürlich dazu sagen muss, du bekommst jetzt nicht die gleiche Performance aus einer MySQL, wie du wahrscheinlich aus einer Memcache oder aus einem Memcache rausbekommst, wenn der wirklich sauber aufgesetzt ist und verteilt, weil das einfach natürlich, wenn MySQL da im Hintergrund irgendwelche referenziellen Integritäten checkt, dann ist das natürlich schwierig, das in demselben Speed zu machen. Zu deiner ursprünglichen Frage, ob das eine Datenbank ist, ich würde sagen nein, aber es ist ein Storage-Backend, vielleicht ein Main-Memory-Storage-Backend.

Andy Grunwald (00:58:03 - 00:58:14)

Das Memcache-Plugin von MySQL war mal drin, muss explizit aktiviert werden und ist jetzt in Version 8.0.20 oder so entfernt worden. Also das ist nicht mehr dabei.

Wolfi Gassler (00:58:14 - 00:58:32)

Okay, das zeigt vielleicht auch schon, dass die Verbreitung dann eher geringer wird mit der Zeit, weil es einfach viele Alternativen gibt. Und sogar klassische Datenbanksysteme, glaube ich, mittlerweile performance-technisch einiges liefern können. Und du gar nicht mehr so spezielle, einfache Systeme wie Memcache brauchst, die halt nur auf diesen einen Use-Case optimiert sind.

Andy Grunwald (00:58:32 - 00:59:28)

Ich hab mal versucht herauszufinden, warum das Memcache-Plugin jetzt entfernt wurde. Im Git-Commit steht nur Remove Memcache-Plugin. Im Public-Bug-Tracker findet man nix. Das wird anscheinend irgendwas Oracle-intern sein. Na ja, mal wieder eine Datenbank-Folge. Ziemlich viel Theorie. Am Ende haben wir doch noch die Kurve, wir haben ein bisschen Praxis bekommen. Liebe Hörerinnen und Hörer, checkt doch mal eure Applikation, ob ihr wirklich die volle Funktionalität von ACID wirklich nutzt oder vielleicht sogar von BASE. Wo befindet ihr euch? Wie nutzt ihr die Datenbank? Und lasst uns doch mal hören, ob ihr wirklich noch Cassandra im Einsatz habt und zu welchem Use Case. Wir hoffen, ihr habt ein bisschen was mitgenommen. Vielleicht habt ihr euch auch an eure Uni-Zeit oder Informatikerausbildung oder vielleicht euer Coding-Bootcamp zurückerinnert und sagt, ah, vielleicht sollte ich da doch nochmal in das Datenbank-Skript eingucken. Lasst uns doch mal wissen, wie euch diese Theoriestunde mit Dozent Wolfgang gefallen hat.

Wolfi Gassler (00:59:28 - 01:00:11)

Und man hat ja auch schon gemerkt, dass es ein Riesenthema ist, vor allem wenn man dann so Produkte in den Raum geworfen bekommt von Andi, da richtig zu antworten. Das sind alles hochkomplexe Systeme und man müsste sich wahrscheinlich sehr, sehr tief einlesen in das jeweilige Datenbanksystem, um da eine ordentliche Antwort zu geben, wie die wirklich aufgebaut sind, was sie garantieren. Und das muss man wahrscheinlich auch machen, wenn man wirklich auswählt, was man für Datenbank verwendet und verwenden will. Und das lässt sich halt nicht in drei einfachen Fragen abdecken. Aber als kleine Empfehlung, MySQL, Postgres oder SQLite ist definitiv ein guter Anfang für fast jedes Projekt. Und wie Andi schon gesagt hat, wir freuen uns auf euer Feedback und vor allem eure Erfahrungsberichte.

Andy Grunwald (01:00:11 - 01:00:25)

Feedback, wie immer, via E-Mail stetisch at engineeringkiosk.dev oder via Twitter an at engkiosk. Das war es heute von unserer Seite. Wir wünschen euch einen schönen Tag.

Wolfi Gassler (01:00:25 - 01:00:28)

Ciao.

Andy Grunwald (01:00:28 - 01:00:35)

Hör mal rein, ob die jetzt was geworden ist. Nicht, dass wir diese Folge das dritte Mal aufnehmen müssen, weil dann sage ich, Thema wechseln.