#269 Performance-Basics: Indexstrukturen, Cache-Lokalität & Zugriffsmuster

0:03 [SPEAKER_01]: Willkommen zu einer neuen Episode von deinem Lieblingspodcast, dem Engineering-Kiospodcast. [SPEAKER_01]: Heute sprechen wir über Index-Shok-Tour. [SPEAKER_01]: Also über genau das Thema, das in Datenbank ständig mit läuft, oft super wichtig ist und trotzdem erstaunlich selten wirklich verstanden wird.

0:19 [SPEAKER_01]: Denn ein Index ist eben nicht einfach nur ein Haken für schneller. [SPEAKER_01]: dahinterstecken, Datenschuturen, Algorithmen, Hardware, Zugriffsmuster und eine ganze Menge Trader. [SPEAKER_01]: Wir schauen uns an, was ein Innex eigentlich ist. [SPEAKER_01]: Warum ein volltaimales Gen, manchmal trotzdem sinnvoller sein kann, was Selectivität und Cardinalität mit einer Creole Performance zu tun haben und warum ein Falscher Index nicht nur nichts bringt, sondern sogar Schaden kann.

0:45 [SPEAKER_01]: Außerdem sprechen wir über Read Heavy und Right Heavy workloads, über Right Implifikation, [SPEAKER_01]: Ob Serverability, SLOG für Reloks und darüber, wie der Optimizer in Datenbank überhaupt entscheidet, ob ein Index verwendet wird oder halt auch nicht. [SPEAKER_01]: Und danach wird's halt noch ein bisschen praktischer.

1:02 [SPEAKER_01]: Wir sprechen über Hauptspeicher, Versussekunderspeicher, B und B näherbäume und über unsichtbare Indizese in Meiskuell. [SPEAKER_01]: Ja, richtig gehört, unsichtbare Indizese. [SPEAKER_01]: Klingt irgendwie schräg, ist aber doch schon ziemlich nützlich. [SPEAKER_01]: Wer du also verstehen willst, warum Datenbank-Performen nicht mit Create Index erledigt ist, dann bleibt er.

1:22 [SPEAKER_01]: Die Episode ist für dich, los geht's. [SPEAKER_01]: The Engineering Keyers ist ja nicht nur ein Podcast. [SPEAKER_01]: The Engineering Keyers ist inzwischen eine ganze Entwickler Community mit echt über 500 Leuten im Discord. [SPEAKER_01]: Und wir haben sogar zwei Meetups 1 in Innsbruck.

1:40 [SPEAKER_01]: Das macht der Workgang mit einem ganzen Team, schon seit einer längeren Zeit. [SPEAKER_01]: in reiner Ruhe in Deutschland, in der reiner Ruhe-Region, haben wir jetzt auch mit dem. [SPEAKER_01]: Und das hatten wir die Tage. [SPEAKER_01]: Und dann hat der Chef Grüße gehen raus. [SPEAKER_01]: Auch so ein kleines Intro gemacht.

1:52 [SPEAKER_01]: Okay, was ist der Engineering Kiosk? [SPEAKER_01]: Und hat dann unter anderem auch das Bild des Podcasts gezeigt. [SPEAKER_01]: Und sagte, ja, wer irgendwie so auf Becken in Verschruktur steht, der sollte in diesem Podcasts mal reinhören. [SPEAKER_01]: Und hat danach auch seinen Podcasts vorgestellt, dem Wirkingraft Podcast Grüße gehen auch daraus.

2:07 [SPEAKER_01]: Und hat gesagt, wenn mehr auf Front entsteht. [SPEAKER_01]: So, Wolfgang. [SPEAKER_01]: In Verschruktur und Becken Podcasts. [SPEAKER_01]: Siehst du das auch so? [SPEAKER_00]: Und was hast du zu seiner Verteilung zu sagen? [SPEAKER_00]: Also ich bin schnell mal auf unsere Webseite gegangen und hab auf den Tag Kommunikation geklickt und das sind glaube ich über 30 Episodeen, wo es nur ums Thema Kommunikation geht, jahres Gespräch, Performance Reviews, Impostos Syndrome, Daten Journalismus, also...

2:33 [SPEAKER_00]: Die stimmt schon, wir kommen wahrscheinlich sehr aus der Beckhint world, aber wir machen schon sehr viel und das ist ja auch das Kredo, das ist von diesem Podcast, dass wir auch andere Sachen machen rund über den delarant rund umschlag in der IT, Sene und da wäre da so viel machen, ist es jetzt eigentlich schon wieder Zeit für eine unliche Beckhintvorge.

2:52 [SPEAKER_01]: Ich habe dieses Intro nicht einfach so gewählt, denn ja, jetzt befolgen wir die ganze Timatekmal wieder, denn für die Leute, die es nicht wussten. [SPEAKER_01]: Er Wolfgang hat einen Doktor Titel im Bereich Datenbanken und wir wären ja schön doof, das nicht auch mal ausschlachten würden.

3:10 [SPEAKER_01]: Im Produktivitätsbereich würde man sagen, wir nutzen mal ein paar Synergien, [SPEAKER_01]: denn solche Themen fallen in dem Wolfgang natürlich immer ganz locker von der Hand. [SPEAKER_01]: Und deswegen beschäftigen wir uns heute mal oder mal wieder, das weiß ich gerade gar nicht mehr, über Indekstrukturen.

3:27 [SPEAKER_01]: Indekstrukturen kommen bei den meisten Leuten im Kopf immer nur in Datenbanken vor, es wird aber nicht nur in Datenbank angewendet, in sehr vielen Compute, Lastigen, Applikationen gibt es ebenfalls Indekstrukturen, deswegen Wolfgang Indekstrukturen. [SPEAKER_00]: Was hast du dazu zu sagen?

3:43 [SPEAKER_00]: Also nun, dass gerade so oder klappt zu ziehen, wie du ja immer so schön sagst, war gerade am Tag Datenbanking bei uns auf der Webseite, da haben wir ungefähr 20 Äpfel suchen. [SPEAKER_00]: Also wir haben mehr Kommunikationsepisoden als Datenbankepisoden auf jeden Fall. [SPEAKER_00]: Und wir hatten...

3:59 [SPEAKER_00]: schon mal über indekstrukturen gesprochen, in einem sehr speziellen Bereich Geo, Indekstrukturen, also räumliche Indekstrukturen, wir hatten auch mal eine Episode, wo es um Gaming, Indekstrukturen sogar gegangen ist, dass es so sehr spezialisierte Episoden, aber wir hatten bisher eigentlich noch nie so eine [SPEAKER_00]: Grundlegende Episode, wo wir mal besprechen, was es eigentlich für Indigstruktur in dem Allgemeinen gibt, was vor Ort und nach Deile sind, hab Speicher, Sekundär, Speicher, also Festplatte, woher kommt das Ganze und genau darum soll es in dieser Episode mal gehen.

4:29 [SPEAKER_01]: Wie sagt man bei uns so offen darf, dann lassen uns nicht lang Schnacken, Kopf in Nacken, gilt eigentlich für Saufen, deswegen übertragen wir das jetzt noch das Thema. [SPEAKER_01]: Haume dreigt raus. [SPEAKER_01]: Was ist eigentlich ein Indigst? [SPEAKER_00]: Also wahrscheinlich haben wir alle von einem Index schon mal gehört, in der Schule oder wenn sie damals irgendwie so Alexa kommen.

4:45 [SPEAKER_00]: Also ich hoffe, es sind alles so alt, dass sie ein Lexikon kennen, also so ein Buch, wo man hinten so ein Index trennt hat, er hat schon Index geheißen. [SPEAKER_00]: Das ist so in die Grundform, aber wir in der Tech-Szene verstehen natürlich was anderes und haben Index und ich würde mal grundsätzlich das eine so definieren, dass ein Index, eine [SPEAKER_00]: eine gewisse Datenstruktur zu implementieren, die da einen optimieren oder Algorithmus hat, um mit dieser Datenstruktur zusammen zu arbeiten.

5:17 [SPEAKER_00]: Und das Ganze immer spezialisiert auf eine gewisse Hardware. [SPEAKER_00]: Also die Hardware spielte auch immer Rolle, wo wird das Ganze ausgeführt. [SPEAKER_00]: Auf einer Festplatte im Hauptspeicher, auf eine SSD-Platte, auf einen schnellen Rahmen, habe ich Cashless L1 Cash L2 L3 und wie ist der Workload?

5:34 [SPEAKER_00]: Also wie greifig auf diese Daten zu und meistens wird das ganze Jahr optimiert für einen speziellen Workload. [SPEAKER_00]: Also Facebook hat wahrscheinlich einen anderen Workload, also Wikipedia. [SPEAKER_00]: Weil Wikipedia hat ganz viele Rezugriffe, Facebook hat wahrscheinlich auch ganz viele Schreibzugriffe.

5:51 [SPEAKER_00]: oder eine andere Plattform wo es um Chets zum Beispiel geht, wo man einfach viele, viele Reiz, eben auch halt oder Änderungen in dem Sinne. [SPEAKER_00]: Und genau dafür optimiert man dann diese Datenstruktur, diesen Algorithmus, damit das Ganze dann am Ende schneller funktioniert und die Grundannahme ist eigentlich immer, ich probiere [SPEAKER_00]: Eigentlich meine Rechenzeit runter zu bekommen, in dem ich weniger Daten anfassen muss, oder wie in Österreich sagt man angreifen, da bist du ja immer verwirrt, wenn man Daten angreifen sagt oder dich angreifen, ist es schon nur mal Unterschied, aber wenn man wählen möglichst wenig Daten anfassen, berühren in irgendeiner Form, weil es ist meistens langsam.

6:28 [SPEAKER_00]: Wenn ihr natürlich jetzt 100 Gigabyte an Daten habt, aber 4 irgendeine Anfrage nur 10 Megabyte berühren muss oder irgendwie laden, muss bin ich am Ende schneller, das ist eigentlich so das Ziel von einem Index egal ob das im Hauptsprecher ist, auf der Festplatte auf einem Bandlaufwerk soll es ja auch noch geben kann man eigentlich überall abbilden.

6:46 [SPEAKER_01]: Wenn wir noch mal über die Verbindung zu der Hardware sprechen, dann sprechen wir nicht über Hardware Generationen wie zum Beispiel CPU, Achtektoren, ob das jetzt in X-68 oder ARM ist, sondern wir sprechen eigentlich darum, okay, CPU lasst dich, RAM lasst dich, disk lasst dich und nicht ob das jetzt ob die CPU eine 2-Giga-Herz-Taktung oder eine 3-Giga-Herz-Taktung hat.

7:07 [SPEAKER_01]: Bei Disk Marks vielleicht ein bisschen anders sein, bei SSDs, wer so es spinning ist, da ist es vielleicht ein bisschen anders, wegen der [SPEAKER_01]: Aufteilung, wie die Daten auf die Platte geschrieben werden, da hatten wir ja, glaube ich, da hatten wir auch mal eine Episode über OLAB-Wersus.

7:20 [SPEAKER_01]: OLTP und auch über Zeilen-Wersus-Spaltenorientierte Datenbanken, wo das Display-Autäre noch eine Rolle spielt. [SPEAKER_01]: Wenn wir uns jetzt noch von der Festbarte entkoppeln, dann sprechen wir jetzt nicht über die Taktung von Ramm oder die Taktung von CPUs und dann eher über CPU- und Cash-Größen-Wersus-Ramm-Wersus-Disk generell.

7:44 [SPEAKER_00]: Also wenn du jetzt alle Index strukturentwickler in einen beleidigen Wist, dann kremmer davon auskennen, aber die ganzen Leute, die sich die letzten 15 Jahre damit beschäftigt haben, die optimieren natürlich auf alles und alleine diese ganze Änderung in letzter Zeit [SPEAKER_00]: dass die L-1 bis L-3-Kässches größer geworden sind oder wie die CPU kommuniziert wie gelockt wird, was in einem geschärten Kässch auf der CPU passiert oder nicht besiert oder was geschärt werden kann zwischen Kerne, die spielt natürlich alles eine riesen Rolle.

8:18 [SPEAKER_00]: Also die reinen daktfrequenzen spielen jetzt vielleicht weniger die Rolle, aber [SPEAKER_00]: Alles andere, was an Architektur irgendwie möglich ist, Instructionsets, ob du auf der CBO irgendwas parallel abarbeiten kannst, ziem die, der spielt natürlich alle sind die Indekstruktur in rein und wenn du auf die großen Datenbank konferenzen blicks zu wie eine FileDB, very large database ist, ist eine der größten.

8:41 [SPEAKER_00]: Da findest du überall Papers, die da die letzten Prozent irgendwo noch mal rausholen, um für eine ganz spezielle Architektur noch mal irgendwie [SPEAKER_00]: In der Indekstruktur, mit einem Delta vom Delta vom Delta, also der 18. [SPEAKER_00]: Verbesserung von einer Indekstruktur, nochmal irgendwo ein bisschen rausholen und gerade die großen Kamponies wie Metta oder Google, bei denen bringt natürlich dieses 0,0,0,5% auch noch was natürlich bei ihren Indekstruktur.

9:07 [SPEAKER_01]: Und wenn du von Workload-spezifischen, Strukturen sprichst, dann kommt mir immer eine Sache in den Sinn, die ich in meiner Karriere super oft hatte und die vielleicht auch jeder hier schon kennt. [SPEAKER_01]: Der klassische Satz, das skaliert nicht. [SPEAKER_01]: Wenn ich eine Sache in meiner Karriere gelernt habe, dann ist das immer, wenn ich höre das skaliert nicht.

9:27 [SPEAKER_01]: Dann hat die Person wahrscheinlich am Vorabentecker News gelesen und da kam irgendein neuer Datenbank hoch. [SPEAKER_01]: die man dann eine Produktion schippen möchte? [SPEAKER_01]: Oder die Person hat den Satz einfach sehr schnell gesagt, weil es sehr einfach ist, diesen Satz zu sagen, um dann ein sehr spannendes Projekt zu launcheden.

9:42 [SPEAKER_01]: Ich habe aber auch gelernt und jetzt kommt die positive Seite, dass immer wenn man sagt, das geliert nicht, dass es sehr viel optimierungspotential in diesen Workloads gibt. [SPEAKER_01]: Das bedeutet, haben wir als Engineering Team eigentlich verstanden, welche Daten, welche Tabellen, [SPEAKER_01]: Wir in welchem Wuluben schreiben, wer so es lesen.

10:04 [SPEAKER_01]: Also haben wir einen Right Heavy Workload oder einen Red Heavy Workload. [SPEAKER_01]: Haben wir einen Traffic-Surfing Workload oder haben wir einen Batch Workload. [SPEAKER_01]: Der vielleicht nicht so Zeit intensiv ist, wo es keine Rolle spielt, ob das ist es 5 oder 15 Sekunden lang dauert, wo hingegen bei einem Traffic-Surfing Workload, also einem Live-Trafik, sei es mobile App, sei es irgendwas anders, auf Millisi-Kunden ankommen.

10:27 [SPEAKER_00]: Also du hast jetzt gerade OLTP und Olaf noch mal erklärt. [SPEAKER_00]: Also Olaf ist eine Lytik, da hat man Zeit, OLTP ist schon ein Exional, da hat man wenig Zeit. [SPEAKER_00]: Aber genau das ist im der Punkt, du hast im Prinzip diese vier Punkte, Datenstruktur, Algorithmus, Hardware und Workload und diese vier Sachen müssen zusammenpassen.

10:44 [SPEAKER_00]: Wenn man das jetzt ganz unten mal aufmachen, diese vierpunkte bei dem Index in der Volksschule, aber wir ist das bei euch Grundschule, Grundschule in einem Lexikon, wenn man das mal sieht, in einem Lexikon haben wir einen Workload, wo wir denken, okay, in einem Lexikon will ich vielleicht gewisse Begriffen oder allgemeine in einem Buch, will ich gewisse Begriffen schnell nach.

11:04 [SPEAKER_00]: Schauen können, dass sie schnell die Seitenzahl finden, das ist ein Read-Driven, würde ich mal sagen. [SPEAKER_00]: Dann habe ich eine Hardware, das ist mein Buch, meine Seiten in dem Fall, sind einfach klassische Seiten, die ich umblättern kann, ist im Speicher, aber eigentlich es sehr ähnlich, wenn man sich das anschaut.

11:20 [SPEAKER_00]: Dann habe ich eine Datenstruktur, ich habe einfach eine lange Liste, aber in dem Fall habe ich eine studierte Liste üblicherweise in dem Index hinten im Buch. [SPEAKER_00]: Das heißt, das ist schon mal studiert. [SPEAKER_00]: Ihr habt ja irgendeiner Struktur drin, eine studierte Liste. [SPEAKER_00]: Das wäre die Datenstruktur.

11:34 [SPEAKER_00]: Und dann hab ich den Optimizer oder den Algorithmus derde drauflauft. [SPEAKER_00]: Der lauft natürlich bei uns im Gehirn, bei einem klassischen Buch. [SPEAKER_00]: Irgendwannes Buch muss ich dir nicht erklären an. [SPEAKER_00]: Ich kann es so noch heute. [SPEAKER_00]: Kenn ich sogar sehr gut.

11:44 [SPEAKER_00]: Ich hab ein Hobby. [SPEAKER_01]: Ich kaufe Bücher. [SPEAKER_01]: Das heißt, nicht die Lese, sondern ich kaufe sie. [SPEAKER_01]: Aber ich habe hier einen großen Stapel links und rechts vor mir von Fachbüchern, die ich alle sehr gut finde und alle lesen möchte, doch sehr gut. [SPEAKER_00]: Ich kann so mal den Index hinten anschauen, vielleicht kannst du dann schon bei Inhalter rausziehen.

12:01 [SPEAKER_00]: Auf jeden Fall hat man dann die Studierte Liste und der Algorithmus läuft dann im Kopf ab. [SPEAKER_00]: Und das ist üblicherweise die Beiner Research, die wir im Kopf anwerfen, mehr oder weniger. [SPEAKER_00]: Das heißt, wenn wir wissen, wir suchen nach irgendetwas, was mit. [SPEAKER_00]: K-Anfangt, keine Ahnung, Konflikt, zum Beispiel als Wort, dann schauen wir natürlich schon, wo sind die Wörter mit K und dann machen wir so eine benäresuche, um das möglichst schnell einzugrenzen.

12:25 [SPEAKER_00]: Wir schauen mal bei alle K-S, wo es in die nächsten Buchstaben ist, es eher vorne in den K-Listen oder eher hinten. [SPEAKER_00]: Und so macht man dann Barchex und probiert sich anzunehren, ganz klassisch wie in einer Binären Suche, um das zu finden. [SPEAKER_00]: Also eigentlich haben wir das im echten Leben genauso diese Indexer und Indexerungen und Algorithmus im Kopf und das Ganze kann man eigentlich wirklich eins zu eins umsetzen, dann auf die Technik und auch da wieder egal ob im Hauptsprecher oder [SPEAKER_00]: festplatte oder wo wir auch immer umgehen oder bei uns in der Software, wenn wir es programmieren, ist eigentlich das immer deshalb, weil wir wollen, schnell auf Daten zugreifen können und Sachen schneller finden, ohne dass wir eben das ganze Lexicon durchsuchen oder den ganzen Index durchsuchen und dieses Vorgehen wird dann optimiert.

13:05 [SPEAKER_00]: Und das fällt eigentlich alles in Indekstrukturen. [SPEAKER_00]: Also man kann nicht nur wie du richtig sagst, desto nur auf einen Index an sich reduzieren. [SPEAKER_00]: Man muss immer alles rund herumwissen, um das dann am Ende optimieren zu können. [SPEAKER_00]: Und wenn man den falschen Index verwendet, vielen Workload, dann ist das ganz natürlich langsam.

13:20 [SPEAKER_00]: Und dann kommt das, eskaliert ja nicht. [SPEAKER_00]: Aber vielleicht hat man einfach den falschen Index gewählt. [SPEAKER_00]: Oder hat gar keinen Index gewählt. [SPEAKER_00]: Oder hat sich einfach gar nicht beschäftigt, damit wie man die Daten vielleicht ablegen kann, in einer besseren Datenstruktur um dann am Ende schneller zu sein.

13:33 [SPEAKER_01]: In der Episode 25, 60, wo wir über die One-Bill-Yen Road-Challenge gesprochen haben, haben wir auch über die Kritik von Data-Set-Over-Fitting gesprochen. [SPEAKER_01]: Das bedeutet, man optimiert seinen Algorithmus ganz genau auf die Daten, die man da hat. [SPEAKER_01]: Wenn ich das jetzt auf, das um Münze, was du jetzt gerade gesagt hast, dann ist ja Data-Set-Over-Fitting im Bezug auf Index Design sehr Vorteilhaft oder?

13:57 [SPEAKER_00]: Solange du garantieren kannst, dass dein Täter selbst gleich bleibt. [SPEAKER_00]: Das ist eigentlich das größte Problem in der Datenbank Welt, oder ganz allgemein natürlich du baustetst jetzt irgendein Index für einen ganz speziellen US-Case. [SPEAKER_00]: Das heißt, du machst eine Datenstruktur, wenn Algarit muss drauf, kannst du deine Hardware ganz gut und kannst auch den Workload.

14:15 [SPEAKER_00]: Du hast so ein zu viele Zugreffe, zum Beispiel 1000 User, man muss die Daten speichern von 1000 User, alles kein Problem funktioniert schnell. [SPEAKER_00]: Und über die Zeit kommen jetzt plötzlich ganz viele User dazu, oder du hast einen coolen Marketing Effekt und hast plötzlich 10.000 User, plötzlich ändert sich deine Workload, oder deine Daten ändert sich, weil plötzlich so viel geschrieben wird.

14:32 [SPEAKER_00]: Und dann stimmen diese Annahmen alle nicht mehr. [SPEAKER_00]: Das heißt, es kann natürlich über die Zeit passieren, dass diese Indexstrukturen nicht mehr geeignet sind oder nicht mehr die Richtigen sind. [SPEAKER_00]: Und das macht der bei so einem lebenden System eigentlich des Problemen aus und drum hat mehr früher auch diese DBAs, die Datenbankatmester Dorn gehabt, die sich immer des Angeschad haben, funktionieren, unsere Datenbankern auch ist alles noch schnell, mir gerade ein Freund erzählt, der es einen Datenbankatmester DFRMSSQL, die haben einfach einen Update eingespielt und plötzlich war alles langsam bei denen.

15:02 [SPEAKER_00]: Und sie haben wirklich eigentlich nie an dieses Update gedacht, weil es auch ein bisschen verzögert war und so weiter, so ist klassische Problem, aus dem Badag später. [SPEAKER_00]: Und am Ende sind sie aber darauf gekommen, ja, das Update hat halt irgendwas in den Algorithmen geändert und plötzlich war alles langsam bei denen.

15:16 [SPEAKER_00]: Das bringt mich aber zu den nächsten Frage. [SPEAKER_01]: Man kennt ja das gute Strichtwort, wenn ich mit der Zeit geht mit der Zeit und so mit ist der Strichtwort. [SPEAKER_01]: Das Strichtwort, das sozusagen ja, man wird dann auch gestrichen, das ist richtig. [SPEAKER_01]: Panentendertura bzw. nicht enthendelt?

15:30 [SPEAKER_01]: Wenn du nun sagst, wenn du einen Index einfühst, hast du gewisse Annahmen an die Daten. [SPEAKER_01]: Und diese Annahmen müssen weiterhin stimmen, damit der Index auch seinen soll erfüllt. [SPEAKER_01]: Jetzt wird aber jede Applikation konntionierlich geändert und dieselhtesten Daten setzen sind staatisch.

15:45 [SPEAKER_01]: Und wenn die startische sind, überlege ich gerade braucht man einen Innex oder kann man dann nicht ziemlich viel Pre-Computer, das ist eine andere thematik. [SPEAKER_00]: Nein, eine Innex ist hier nichts anderes als Pre-Computer, eigentlich. [SPEAKER_00]: Also, klar wird der verändert, aber eigentlich, wenn du ein statisches Datensätt hast und ein Innex machst, dann pre-Computerstuhl, eine andere Sicht auf die Daten und es genauso ein Innex.

16:08 [SPEAKER_01]: Ich glaube, meine Frage ist eigentlich, was in den Best Practices, um deinen Index kontinuierlich zu kontrollieren, ob die Initialen annahmen, in der Relation zu den Daten eigentlich noch stimmen. [SPEAKER_01]: Also eigentlich ist das ja so eine Art, wenn ich das im Infrastrukturbereich vergleiche, eine Art Kapästety-Planning für deine Daten nicht für Server, nicht für Speicherplatz, nicht für Ram, sondern für deinen Daten.

16:30 [SPEAKER_01]: Gibt's da Best Practices, die du aus dem Hut zur Bankanz und ich meines nicht heier einfach, [SPEAKER_00]: Ja, grundsätzlich gelten die gleichen Regeln, wie du jetzt gesagt hast, aus dem Infrastrukturbereich. [SPEAKER_00]: Du passt mal observabiliti und die hast du eigentlicherweise schon mal ganz, ganz oben auf der Application Seite.

16:49 [SPEAKER_00]: Und wenn dort was langsam wird, dann musst du rausfinden, liegt seiner Datenbank. [SPEAKER_00]: Das ganze gibt es natürlich auch auf der Datenbankseite, der du kannst die Datenbankmonitorn, du kannst rausfinden, welche Queries dauern, lang alle die in der Meiskelle, welt unterwegs waren, slow query lock ist oder das Schlagwort schlecht hin.

17:06 [SPEAKER_00]: Aber du kannst es natürlich grundsätzlich nicht verhindern, du kannst es probieren, vorher zu sehen und zu grob. [SPEAKER_00]: Einschätzen okay, was wir sein, wenn du viele Daten plötzlich reinbekommen, funktioniert es noch gut, aber [SPEAKER_00]: Im Endeffekt muss du es Monitoren und dann eben auch dem entsprechend agieren.

17:21 [SPEAKER_00]: Die Datenbanken sind natürlich schon einigermaßen schlau und die halten mit der Wein statistikinnen und probieren auch für den Interneten optimise den richtigen Indexraß zu suchen. [SPEAKER_00]: Also da gibt es natürlich schon viele Punkte, die die Datenbank versucht, automatisch zu machen und mittlerweile immer mehr automatisch zu machen und intelligent zu machen.

17:38 [SPEAKER_00]: Aber grundsätzlich ist die Datenbank so wie die Codebase an sich auch in irgendeiner Form im Leben des Systemen und kann über die Zeit die Gräden und Langsimmer werden und wird sie üblicherweise auch, weil du er dennendiell immer mehr Daten bekommst. [SPEAKER_01]: Über diesen Aspekt habe ich eigentlich so noch nie nachgedacht.

17:54 [SPEAKER_01]: Es gibt Firmen, die stellen Performance Engineers ein. [SPEAKER_01]: Zum Beispiel auf dem letzten Rhein-Ruh, ein Genericius-Mieterbar jemand, der hat mal bei Komot gearbeitet und hat die Frontend Performance optimiert. [SPEAKER_01]: Du was sie gemacht haben, die haben bei jedem Pullback Quest Frontend Test laufen, lassen und zu gucken, ob die Frontend Performance degradet wird durch den Pullback Quest.

18:16 [SPEAKER_01]: Was der sein kann? [SPEAKER_01]: Ich habe sowas eigentlich noch nie für Datenbank in die CS gesehen. [SPEAKER_00]: Die Datenbankhersteller haben sowas, also die haben riesige Testz von Kunden auch, weil die wollen ja üblicherweise nicht ihre Kunden langsamer machen. [SPEAKER_00]: Also es ist MSS-KoL und bei meinem Kollegen, der wirklich in dem Fall alles dann langsamer hatte, aber genau das wirst du eigentlich verhindern.

18:36 [SPEAKER_00]: Du hast riesige Testz, die dann durchlaufen, über Tage meistens, um zu checken, hat [SPEAKER_00]: den speziellen Data-Lode und Workload, meistens wie gesagt, große Kunden haben da noch eigene Testsetz und die Laffen dann wirklich da gelangt durch und checken, gibt es irgendwo Probleme oder können wir das neue Release wirklich rausbringen und ausrollen.

19:00 [SPEAKER_00]: Und das kannst du natürlich auf deiner Seite als Programmierer in natürlich genauso machen und haben. [SPEAKER_00]: Und manche Leute haben das natürlich auch, dass die in den Tests gewisse Workloads aberweiten um das dann wirklich zu testen. [SPEAKER_01]: Und wenn du das Wort Workloads wieder in Mundnipps fällt mir noch eine Frage ein, würde es zu sagen, ein Lexicon ist eher ein Read Heavy Workload und kein Right Heavy Workload.

19:23 [SPEAKER_01]: Du hast ja vorhin den Index anhand als Lexicon zu beschrieben. [SPEAKER_00]: Wo beinert durch das Lexikon an sich ganz praktisch ist, weil da kommt halt nichts dazu. [SPEAKER_00]: Das heißt, die braucht den Index nicht abdaten in der Datenbank, oder im Hauptspeicher, wie natürlich das Problem, dass sie ständig neue Daten reinbekommen und immer den Index auch abdaten muss.

19:48 [SPEAKER_00]: Und diese Wright amplifikation, wenn die ganz viele Indezesse [SPEAKER_00]: Mit Abdaten muss, das heißt, ich schreibe eigentlich nur eine Zeile, muss aber an 20 verschiedene anderen Stellen in Index abdaten. [SPEAKER_00]: Das heißt, das nennt sich dann Wright amplifikation, weil die eben statt einem Wright, dann im Ende 20 machen muss, dann wird halt alles langsam.

20:06 [SPEAKER_00]: So, dieses Abdaten, der Indezess, braucht natürlich auch Zeit. [SPEAKER_00]: Und wenn es dann um Transaktionen geht und das mit reinfließt, womöglich, dann wird eben alles, dementsprechend langsam haben, muss man natürlich auch immer mitbeachten. [SPEAKER_00]: Es umso mehr Parallel-Datenstrukturen, ich halte, umso mehr muss ich auch abdaten.

20:21 [SPEAKER_01]: Die Right-Emplifikation ist also eigentlich das, was so ein Fanaut von Microsoft's Requests macht, wenn du ein Microsoft's Anfrags und der 20 Fanaut machst, also eine Request von Stärkungen, wenn du so möchtest und hier eine Schreibvorstärkung, dass du dir selbst gegebenenfalls ins Knie schießt.

20:38 [SPEAKER_01]: Genau. [SPEAKER_01]: Okay, Basis geklärt, finde ich super, kommen wir zum zweiten Basis Thema. [SPEAKER_01]: Gib mir noch mal einen Rundown über die Kernkonzepte von Datenbangen. [SPEAKER_01]: Also, ich hab nicht habelle, nehme mal Kundendaten. [SPEAKER_01]: oder User, ganz klassisch. [SPEAKER_01]: Ich habe Primary Key, eine E-Mail, ein Land und vielleicht von der Record angelegt wurde.

20:57 [SPEAKER_00]: Der Fantasie Schommel an, Primary Key, Key ist eigentlich in der Datenbankwelt immer ein Wort für Index. [SPEAKER_00]: Es heißt, du hast mit dem Primary Key eigentlich schon Index auf deine Daten drauf. [SPEAKER_00]: Und üblicherweise ist der Primary Key zu meiste Primary Key, der Key, der bestimmt wie die Daten studiert sind.

21:13 [SPEAKER_00]: Es heißt üblicherweise sind die Daten nach dem Primary Key studiert, physikalisch, wirklich auf der Festplatte. [SPEAKER_00]: im Speicher. [SPEAKER_00]: Und wenn du jetzt nach irgendwas suchst, also wenn deine User-Hauszeleckstern vom User-Wair-Emmel ist an die Engineering-Kiosk.dev, da müsstest du durch deine ganzen User durchgehen und überall schauen, ist die E-Mail-Adresse irgendwo verhanden, das heißt du machst ein Full-Tablescan, das heißt du gehst doch alle Daten durch, lehst alle Daten durch die gesamte Speicher-Py-Plein, das heißt von der klassischen Festplatte egal ob es ist, die ihre sonst was in den Rahmen, in [SPEAKER_00]: Na, umgekehrt, L3-Kersch kommt zuerst, L2 und dann L1, dann die Register und dann kommt der eigentliche Vergleich.

21:52 [SPEAKER_00]: Ist das wirklich diese E-Mail-Adresse? [SPEAKER_00]: Wir hatten auch Kürzlich in der Episode von der One-Billion Road Challenge. [SPEAKER_00]: Dieses Trinkvergleich ist in sehr dauer. [SPEAKER_00]: Trink sind sehr lang. [SPEAKER_00]: Wir müssen alle noch mal durchgepäbt werden und das wäre natürlich super langsam, sogar bei kleinen Tabellen kann es unter Umständen schon sehr langsam sein und da würde sich natürlich ein Index anbieten, wenn ich auf diese E-Mailertresse suche, bauen einen eigenen Index auf, in diesem Index steht die E-Mailertresse von den einzelnen Jussern und dann steht irgendwo an die [SPEAKER_00]: Und dann suche in diesem studierten Index, der nach der E-Mail-Adresse studiert ist, bin ich sehr schnell an die, könnt die z.B. binäre Suche machen in meinem Index, finder an die sehr schnell, weistern, das ist die ID 18 und dann holt ihm ja die eigentlichen Daten aus der User-Tabelle mit der ID 18 vom Andio und habe nur einen Zugriff.

22:44 [SPEAKER_00]: Auf der Festplatte im Idealfall passt der Index vielleicht sogar in meinen Hauptspeicher. [SPEAKER_00]: Das heißt, ich kann dem Hauptspeicher super schnell nach an die Suchen, nach der imellertresse. [SPEAKER_00]: Und wenn ich seine Erdresse brauche, mache ich dann eine Punkt an Frage und hol mir genau die Erdresse von der Festplatte von der SSD, wo da an die gespeichert ist.

23:01 [SPEAKER_01]: Testfrage, Computer Science 101, das ist eine binieere Suche, wie funktioniert die? [SPEAKER_01]: Du hast das gerade zurück, das erlaubt gesagt als, müsste das jetzt hier jeder ohne AI locker programmieren können. [SPEAKER_00]: Ihr habt es schon erwähnt mit dem Lexicon und eigentlich machen wieder mehr oder weniger in den binäre Suche.

23:16 [SPEAKER_00]: Wenn nun eine lange Liste hast, die studiert ist, dann fängtst du üblicherweise mal in der Mitte an, checkst in der Mitte, was für ein Buchstamm hast du in der Mitte und dann entscheidest du, musst du weiter vorne nachschauen oder weiter hinten. [SPEAKER_00]: Das heißt, wenn ihr nach an die Sucha kommt, [SPEAKER_00]: Üblicherweise im Anfang könnt ihr in dem Fall schon wissen, aber wenn ich die klassische binäre Suche mache, schaue genau in der Mitte, wo Land wieder, wenn die da jetzt zum Beispiel M haben in der Mitte, dann weiß ich okay, muss noch links gehen, nimmt dort wieder die Mitte, komme irgendwo bei K an, weiß ich okay, muss wieder nach.

23:47 [SPEAKER_00]: umgehend Richtung A, den wieder die Mitte und so suchen wir immer wieder die Mitte heraus und prüfft so lang die Mitte und entscheide muss die links oder rechts gehen bis ich an die gefunden habe. [SPEAKER_00]: Und das nennt sich binäre Suche, weil sich der Suchraum immer halbiert. [SPEAKER_00]: Das heißt, ich mach die erste Hälfte, dann in der Linkinghälfte halbieren wieder.

24:07 [SPEAKER_00]: Es wird immer halbiert der Suchraum und darum komme ich dann relativ schnell, weil es locker rhythmisch ist zu meinem eigentlichen Ziel. [SPEAKER_00]: Und das ganz allgemein übliche Weise bei Baumstrukturen hat mal immer logarithmischen Zugreff, wer mehr schon mal eine Episode zu Ohnautation gehabt, also wie komplex.

24:23 [SPEAKER_00]: Ist so ein Algorithmus wie schnell komme ich an Steele, wie viel Daten muss ich verarbeiten und indekstrukturen. [SPEAKER_00]: Sind übliche Weise Bäume und Bäume sind immer logarithmisch. [SPEAKER_01]: Okay, ich suche es eine E-Mail, habt die E-Mail im Index gefunden, habt dann die ID, der Zeile gefunden und gilt, leset dann die ganze Zeile.

24:39 [SPEAKER_01]: Okay, dabei kommt die Frage auf, gibt es denn auch Situationen, wo ein Index langsamer sein kann, als ein komplette, sehr kränzillertabelskenn. [SPEAKER_00]: Das gibt's nicht nur, sondern es kommt sogar sehr oft vor. [SPEAKER_00]: Und es ist ein Grundsatzproblem, wenn man immer sagt, okay, irgendwas ist langsam, ich weilfe einen Index drauf.

24:58 [SPEAKER_00]: Weil das sind wir genau wieder bei dem Punkt, die muss wissen, was macht der Index, was für ein Workload habe ich und wie funktioniert das eigentlich im Hintergrund. [SPEAKER_00]: Und wenn man sich das an schaut, dann muss man so ein bisschen verstehen, wie Indezess eigentlich funktionieren.

25:11 [SPEAKER_00]: Und zwar wird es ja schon erwähnt, wenn wir jetzt einen Index haben, auf die E-Mail-Adressen, dann ist dieser Index nichts anderes, [SPEAKER_00]: Eigentlich die einzelnen User gespeichert sind. [SPEAKER_00]: Also, ich habe die E-Mail-Latresse zu dir nach der E-Mail-Latresse und dann steht da ID 18.

25:26 [SPEAKER_00]: Jetzt muss ich aber einen Sprung auf die ID 18 machen. [SPEAKER_00]: Diese Sprung der kostet mich natürlich auch was. [SPEAKER_00]: Das heißt, ich such jetzt alle E-Mails durch, finde der die E-Mail-Latresse, finde die ID und macht dann eine Sprung auf die Fesplatte. [SPEAKER_00]: Und dieser Sprung kostet mich Zeit, z.B. U.V.

25:43 [SPEAKER_00]: Kösse und so weiter. [SPEAKER_00]: Wenn ich jetzt annehmen, die der Beller hat, so wie so nur 100 Einträge. [SPEAKER_00]: Und die könnt die Sequenzial durchgehen. [SPEAKER_00]: Und hab dem Hauptspreche, dann kann der schneller sein, als sie macht einen extra Index, der auch abgedetet werden muss.

25:54 [SPEAKER_00]: Sie muss in dem Index nachschlagen. [SPEAKER_00]: Ihr muss dann springen auf die Festplatte. [SPEAKER_00]: Du musst mir die Daten holen. [SPEAKER_00]: Also dieser gesamte Ablauf von dem Index, von dem Lookup, kann und umständen langsamer sein. [SPEAKER_00]: Also, das kann ich immer sein, wenn die Daten klein sind.

26:07 [SPEAKER_00]: Eine andere Punkt, der in der Datenbank, weil es sehr wichtig ist, ist die Seliktivität von einem Index. [SPEAKER_00]: Das heißt, wie seliktiv ist, dass die E-Mailertresse ist natürlich super seliktiv, weil üblicherweise ist die sogar unique in meinem Data-Set. [SPEAKER_00]: Das heißt, die gibt es nur einmal, das heißt, ihr habt einen Treffer.

26:22 [SPEAKER_00]: Wenn ihr jetzt aber nen Index habe über zum Beispiel des Land, woher meine User kommen, also das wir im Land und die machen einen eigenen Index und bin jetzt auf dem Deutschbach in Raum unterwegs, dann werden 90 Prozent meiner User, die eh alles land haben. [SPEAKER_00]: Wenn ihr da jetzt ein Look habt, mache in meinem Index und der Index hat nur die Länderinformationen.

26:42 [SPEAKER_00]: Dann bekommen wir natürlich vor meinem Index 90% aller Idees zurück und muss dann erst wieder auf die Dabelle. [SPEAKER_00]: Das heißt mir bringt dieser Index überhaupt nichts, das ist absolut sinnlos. [SPEAKER_00]: Das heißt die Selikivität, also wie sehr filtert mein Index die Daten eigentlich, auf dieser Selikivität muss ja auch wirklich achten und nur eine hohe Selikivität macht eigentlich Sinn.

27:02 [SPEAKER_00]: Also niedrige Seliktivität, wenn meine Daten nicht ordentlich eingeschränkt werden, sobald ich den Index verwende, gibt es ein Problem. [SPEAKER_00]: Und da kommt da optimizer auch in Spiel wieder von Datenbanken, weil der schad sich natürlich an wie Seliktiv ist, ein Index verwende ich diesen überhaupt.

27:16 [SPEAKER_00]: Und eine schlaue Datenbank sagt dann, nup, hat eine niedrige Seliktivität, ich geh sofort auf die Daten und mach einen Fulltabels kennen, weil das Thema sprechen noch schneller ist. [SPEAKER_01]: Glas nicht interessant ein Punkt angesprochen, weil da sind wir ja schon wieder, hier kennen deine Daten, weil in deinem Beispiel gab es 80 oder 90 Prozent Deutsche, aber es ist nämlich jetzt auch Österreichfielternwürde, dann hätte ich ja nur noch 10 oder 15 Prozent oder 20 Prozent der Records und dann hätte ich ja wieder eine hohe Seliktivität oder?

27:41 [SPEAKER_00]: Genau die Selectivität hängt natürlich auch von der Query Grundsätzlich Abbeziehung ist die Verteilung in diesem Index oder Cardinalität. [SPEAKER_00]: Also wie viel unterschiedliche Werte habe ich dann darüber drinnen jetzt bei den Ländern hätte ich wahrscheinlich nur im Dachraum jetzt drei Werte, Deutschland Österreich, die Schweiz und die Verteilung ist wahrscheinlich ziemlich ungleichmäßig oder skewed auf Englisch, weil ihn natürlich sehr viel deutsche in meinem Index habe.

28:05 [SPEAKER_00]: Dies die Frage macht, dass der Index natürlich trotzdem Sinn, wenn ich zum Beispiel noch [SPEAKER_00]: Österreichische Personen suchen, dann habe ich vielleicht nur über 5% von meinem Index, das die Frage, aber genau da springt der optimise dann ein von der Datenbank, weil der sich hier ist so kramme und Statistiken auch von den Indizerspeichert und der weiß, okay, der Großteil ist DE für Deutschland und der kleiner Teil ist RT und wenn jetzt in der Query RT gefragt wird, dann wird der Index zum Beispiel verwendet.

28:32 [SPEAKER_00]: Also die Datenbank trackt das automatisch mit und billet sich im Hintergrund Statistiken, [SPEAKER_00]: Und entscheidet dann, ohne Fly bei jeder Query, soll ich den Index verwenden oder nicht. [SPEAKER_00]: Und im Idealfall, mit dem Land, wenn zum Österreich geht, würde wahrscheinlich das ganze verwenden, oder wenn man zum Beispiel ein Feld hat, der Status heißt aktiv, oder nicht aktiv, dann hast du wahrscheinlich ganz viele aktiv für User.

28:57 [SPEAKER_00]: und ganz wenige inaktive, das wäre auch so ein ganz unkleichverteilter Index, aber der macht natürlich auch Sinn, wenn du wirklich die nicht aktiv mit User-Rausfiltern wirst, dass du den Verwendest hingegen, wenn du in der Work-Lost drin hast, gi mir die aktiven, dann wirst du wahrscheinlich den Index gar nicht verwenden, weil einfach 99% der User-Service aktiv sind.

29:18 [SPEAKER_00]: Und das macht dann aber die Datenbank-Dementsprechend automatisch. [SPEAKER_01]: Okay, irgendwann irgendwie trifft die Datenmarkt die Entscheidung nicht nur zu diesen Innecks oder nicht anhand von ihren Statisten. [SPEAKER_01]: Jetzt können diese Statistiken ja auch auf Date sein und das abdecken, dieser Statistiken kostet ja auch Rechenpower und Zeit und Alentungen dann.

29:35 [SPEAKER_01]: Deswegen die Frage für mich, kann ich auch einen Index nicht nur auf die Spalte setzen, sondern auch auf Daten-Welduß. [SPEAKER_01]: Also, könnte ich jetzt zum Beispiel in unserem Länderbeispiell... [SPEAKER_01]: den Index nur auf RT setzen, weil ich meine da in so gut kenne und sage, wenn ich nach Deutschland Query, da wie so viel da in der Index sowieso nicht genutzt.

29:56 [SPEAKER_01]: Um diesen ganzen Look ab auf die Statistiken und das Risiko, dass die Länder-Schattesting oder auf Dätten zu vermeiden und mir das all das spare. [SPEAKER_00]: Also klassische Datenbanken kann es so nicht, es gibt natürlich spezielle Indekstrukturen, die das optimiert abspeichern. [SPEAKER_00]: Der Bitmap Index zum Beispiel ist halt genau für diesen USKs auch da, dass man zum Beispiel eben solche inaktiv aktiv, binäre Werte abspeichert, der würde das dann super optimiert abspeichern.

30:22 [SPEAKER_00]: Er macht das trotzdem über die gesamte Tabelle, aber er speichert das optimal ab, dass eben die 99% aktiv nicht wirklich zeile für zeile gespeichert werden, sondern das [SPEAKER_00]: Je nachdem, was du für Daten und Zugricks musst hast, musst du auch entscheiden, was für ein Typ von Index.

30:39 [SPEAKER_00]: Du hast gerade, wenn sie im Hauptsprecher basiert, da hast du mehr Flexibilitäten, was du für Indexstrukturen verwenden kannst. [SPEAKER_00]: In der Datenbankwält hast du meistens nicht so viel Möglichkeiten und die Datenbranke. [SPEAKER_00]: macht es schon einige Maßenrichtig, aber auch da kann man sich überlegen, kann den Hauptsprecher Index noch drüber selbst an speziellen Index-Herst und Beispiel in klassischen B3.

30:59 [SPEAKER_00]: Hab ich für Geostrukturen, z.B. natürlich eigene Indexstrukturen oder eben den Bitmap Index. [SPEAKER_00]: Also da gibt es schon Möglichkeiten, aber grundsätzlich wie du richtig sagst, dass die Kind können Outdated sein sind, eigentlich immer Outdated, weil Statistiken halt nicht immer automatisch [SPEAKER_00]: angebasst werden.

31:16 [SPEAKER_00]: Also, die sind nicht immer komplett live, weil das würde ja sonst zu viel Zeit benötigen und das sind nur Statistiken an sich. [SPEAKER_00]: Und wenn man sich diesen optimizer Anschaut in der Datenbank der arbeitet, so wie so grundsätzlich immer auf Statistiken und heuristiken. [SPEAKER_00]: Das heißt, der überlegt sich, okay, wie sieht meine Hardware aus?

31:33 [SPEAKER_00]: Was [SPEAKER_00]: Was haben wir da in meiner Query-Trennen für joins? [SPEAKER_00]: Muss ich irgendwas zu dienen? [SPEAKER_00]: Was für Daten haben wir, was wir in die Zeit haben zu Verfügung und versucht dann alles in den Dopf zu werfen, dann einmal umzurehen und dann die Ideale abfolge von Kommandos zu erstellen, die dann wirklich sagt, okay, probiert zuerst den Index, mit den Daten geht an der zweiten Index, dann fehlt den normal übern dritten Index, dann geht auf die eigentlichen Daten, dann mache ich die Studierungen.

32:01 [SPEAKER_00]: oder nämlich einen anderen Index, weil der sortiert mit der schon richtig, also jetzt da ganz, ganz viele abfolgen und die eigentliche Kunst von Datenpanken ist diese Optimizer. [SPEAKER_00]: Wie gut kann diese Optimizer automatisch erkennen, was er machen muss, mit was für ein kosten Modell funktioniert.

32:16 [SPEAKER_00]: Welche Informationen hat er überhaupt, das ist noch mal auch ein Problem, weil manche Optimizer nehmen vielleicht ganz klassische Festplatten an, du hast aber irgendwelche Hauptspeicher... [SPEAKER_00]: Einfach eh ist keine Ahnung, schlag mich dort irgendwas. [SPEAKER_00]: Das muss die Datenbanken durch auch wissen, weil es uns macht, sie falsche Optimierungen.

32:33 [SPEAKER_00]: Das ist eigentlich so ein Grundproblem, was es natürlich gibt. [SPEAKER_00]: Aber für die klassische Null auch 15 hat, wer funktioniert das eigentlich ganz gut. [SPEAKER_00]: Und wenn du dann alles mitberücksichtigt, als optimise, dasselbe Aktivität, Cardinalität, welche Daten überhaupt in meinem Index drinsteck hing, weil in Index hat er nicht nur eine Spalte der Kanal zähnstalten, haben der Rätisch.

32:52 [SPEAKER_00]: Dann kommst du um Schluss. [SPEAKER_00]: auf einen idealen Fahrt, den du abarbeiten kannst, als Datenbank. [SPEAKER_00]: Und da musst du natürlich dem Optimals ein bisschen helfen, weil der kann natürlich nur verwenden, was du auch erstellt hast, dann in den Extrukturen. [SPEAKER_01]: Welche Möglichkeiten habe ich denn dem Optimalser zu helfen?

33:07 [SPEAKER_01]: Also, im Bezug auf die Hardware zum Beispiel du hast gesagt, okay, wie teuer ist ein, wie teuer ist neue Aura-Poration, CPU und Piperpoh, und die nach Hardware-Estektur, ist das ja anders, vielleicht bin ich ja Hardware-Engineer. [SPEAKER_01]: Vielleicht möchte ich ja die Performance von anderen Datenbank auf meiner CPU testen.

33:23 [SPEAKER_01]: Vielleicht baue ich ja so eine CPU speziell für diese Datenbank wirklaut. [SPEAKER_01]: Also, ah, die erste Frage kann ich der Datenbank, kann ich dem Optimizer helfen, indem ich die Kostenparameter das Optimizer ist, das im Bezug auf die Hartwert. [SPEAKER_01]: Twiegen kann und B macht das überhaupt Sinn, sich diese Frage zu stellen.

33:44 [SPEAKER_01]: Also, hat die überhaupt eine relevanz im normalen Entwicklerumfeld. [SPEAKER_01]: oder trifft das nur auf hyperformen Sachen zu und co. [SPEAKER_00]: In erster Linie kann es mal darauf an, was du für Datenbank systemverwendest, manche erlauben mehr einkriefft, manche weniger. [SPEAKER_00]: MariaDB hat zum Beispiel ein wesentlich transparenteren Optimizer als zum Beispiel meist CoL, also da gehen sie zum Beispiel komplett auseinander, was du aber immer machen kannst.

34:08 [SPEAKER_00]: Und das ist eigentlich mal die Grundlage, du erstellst die Indexdruckduren. [SPEAKER_00]: Das heißt, du entscheidest welcher Index lebt und geabtet wird. [SPEAKER_00]: Und damit kannst du eigentlich dem Optimizer Meisten helfen. [SPEAKER_00]: Das heißt, du stellst mal die Indekstruktur und zur Verfügung.

34:21 [SPEAKER_00]: Der Optimizer entscheidet dann, verwendig die oder verwendig nicht. [SPEAKER_00]: Was mir das ins Konzept macht zum Beispiel das Ganze schneller oder nicht. [SPEAKER_00]: Also diese Entscheidung macht der Optimizer, aber du gibst dem schon mal das Futter überhaupt. [SPEAKER_00]: Weil ohne Index kann der Optimizer eigentlich wenig machen.

34:34 [SPEAKER_00]: Jetzt im Bezug auf IO und Hardware technische Sachen, wie gesagt man hier Datenbranken alle Augen, dass du da Informationen gibt, manche nicht, wie gesagt der normal sterbliche Entwickler, Entwicklerin, wird es nicht brauchen. [SPEAKER_00]: Was mir im Tagesgeschäft durchaus unterkommt, ist, dass man gewisse Hins gibt.

34:51 [SPEAKER_00]: Also gerade, wenn man sehr aufwendige Queries hat, dass man zum Beispiel irgendwelche Hins gibt, okay jetzt verwendet einen speziellen Index oder Materialisier zum Beispiel [SPEAKER_00]: komplexet, scheuen Reihenfolgen oder mehrere Tabellen hast mit Commentable Expressions. [SPEAKER_00]: Das du sagst, okay, jetzt baumall die erste Tabelle zu erst zusammen und dann mach erst den nächsten Schritt anstatt.

35:15 [SPEAKER_00]: Bauen Riesenplan zusammen, der die gesamte Querybe antwortet. [SPEAKER_00]: Das ist so schrittweise gelöst wird. [SPEAKER_00]: Das sind die Optimizer teilweise überfordert und da kannst du so ein paar Hins geben, mit so komandos, dass du eben sagst, okay. [SPEAKER_00]: Bauer dir mal diesen Zubteil zusammen von der Query und dann mach weiter.

35:32 [SPEAKER_00]: Und da kannst du gewisse Sachen optimieren und noch Performance rausholen. [SPEAKER_00]: Danach, da ist auch da wieder, es kommt neue Version raus von der Datenbank. [SPEAKER_00]: Du machst ein Update, plötzlich ist der Optimizer viel intelligenter und deine Hins machen eigentlich die ganze Sache schlechter.

35:47 [SPEAKER_00]: Als was der Optimizer das machen würde, der neue. [SPEAKER_00]: Also auch da ist wie das Problem, dass das halt gewisse Art von Black Box ist, zusätzlich die ganzen Statistiken ändern sich, erständigt eine Daten ändern sich. [SPEAKER_00]: Also auch da ist es schwierig, alles, was man dann zu hart koded, ist eher negativ für die Mal sagen.

36:02 [SPEAKER_00]: Also ihr wird den Optimizer schon einfach arbeiten lassen, weil die Sinn intelligent, da wird wirklich viel Zeit reingesteckt und die schauen sich dann wirklich die aktuellen Datenlage an und machen dann den Optimierten Ausführungsplan. [SPEAKER_01]: Ja, zusätzlich, wenn du dem Optimizer dann noch diese Hins gibt, oder ich kenn das ab und so von Eskellk流igst, den kannst du ja sogar vorpassen, nutze diesen Index.

36:21 [SPEAKER_01]: Wenn du jetzt wirklich weiß, was du da tust, dann kann sich die Implementierung des Optimizers ist ja auch in den nächsten Version ab, in den nächsten Versione da an bank ändern, und dann sind wir genau wieder bei dem Beispiel, was du von deinem Kollegen da erzählt hast, die Jagen irgendwelchen Performance, die Gradations hinterher wegen dem Datenbank abdät oder ähnliches, weil der Optimizer und Untergett hat.

36:39 [SPEAKER_01]: Also, generell ist ja die Frage. [SPEAKER_01]: Obtimierst du hier auf eine innere Implementierung oder Obtimierst du auf Basis des Optimizer Interfaces? [SPEAKER_01]: Es ist ähnlich wie in Juni Test, der Test ist, dass Exzene Interfaces oder Testes zu die innere Implementierung. [SPEAKER_00]: Und ach, da würde ich wieder sagen, wenn du keinen Einfluss drauf hast, auf diese Exzene Implementierung, dann lasst es einfach und nehmen die anders, die möglichst geschickt ist, ach ummachen.

37:04 [SPEAKER_00]: Also da die Trendlinie zu ziehen, wie bei allen anderen Ebentests oder so, genauso. [SPEAKER_00]: Also, was extern ist, was ich nicht beeinflussen kann, versucht, ich dann auch weniger zu beeinflussen, weil sonst hat man genau diese Seiteneffekte, wo man dann auch so mit Bugs ewig lang sucht.

37:19 [SPEAKER_00]: Oder hat man irgendwo einen hint trinnen und alles wird langsamer und dann viel Spaß beim suchen, weil der hint ist irgendwo vor fünf Jahren mal eingegeben wird. [SPEAKER_00]: Ich frage mich gerade, was ist der Hauptfokus von Indezees? [SPEAKER_01]: Was optimieren die, optimieren die, die Algorithmische Ausführung oder optimieren, die anhand von Trix wie die Hardware genutzt wird?

37:38 [SPEAKER_01]: Also I.O. [SPEAKER_01]: und Co. [SPEAKER_01]: Denn wir haben über beide Ariale bereits gesprochen. [SPEAKER_01]: Was würdest du sagen, ist der Hauptfokus eines Index zur Timierung? [SPEAKER_00]: Die Grund, die Idee, der wir ganz ganz am Anfang schon erwähnt ist, möglichst wenig Daten verarbeiten zu müssen.

37:53 [SPEAKER_00]: Weil es dauert grundsätzlich am längsten, wenn ich irgendwelche Daten laden muss, vergleichen muss, ist sie im CPU mal landen, durch die ganzen Cashierer hin, das braucht einfach. [SPEAKER_00]: Und das versucht ein Index in irgendeiner Form zu optimieren. [SPEAKER_00]: Aber wie auch am Anfang schon gesagt hat, bei Index ist immer die Datenstruktur selbst.

38:10 [SPEAKER_00]: Unter Algorithmus auf eine speziellen Hardware für eine spezielle Workload. [SPEAKER_00]: Und das muss alles mitdenken. [SPEAKER_00]: Also, man kann nicht sagen, es wird nur eine ... [SPEAKER_00]: Sache optimiert von den vier. [SPEAKER_00]: Du musst immer alles mitdenken. [SPEAKER_00]: Du kannst natürlich auch den Workload verändern und damit großen Impact auf die Gesamtzeit haben auf die Ausführungsteil.

38:27 [SPEAKER_00]: Also diese vier Punkte musst du immer gemeinsam betrachten, sonst funktioniert es nicht und da sind natürlich auch ein großer Unterschied, wenn wir jetzt von der Hardberg sprechen, sprechen wir von z.K. [SPEAKER_00]: der Speicher, Festplatte oder von Hauptspeicher. [SPEAKER_00]: Weil da unterscheiden sich die Strukturen natürlich extrem, wie abgerbeitet wird, was schnelles, da ist vielleicht ein Lukap, sehr schnell im Rahmen, auf der Festplatte ist es langsamer, da wie andere Cashierer hin, andere Geschwindigkeiten und dann muss in der Döchschung ganz anders arbeiten, mit meinem Algorithmus, ihr vielleicht dieselben Daten irgendwo liegen, aber der Algorithmus muss dann anders arbeiten oder der Optimiere,

39:00 [SPEAKER_00]: Weil du eine Operation vielleicht hast, die im Rahmen viel schneller ist, als auf der Festplatte und du dadurch den Ablauf ganz anders machen kannst, der rentiert sich es vielleicht, badaten mehr zu lesen, weil schneller ist dafür weniger abzusprechen. [SPEAKER_00]: Der klassische Trade-Off vom Speicherplatz um Geschwindigkeit zum Beispiel.

39:16 [SPEAKER_01]: Du wirst jetzt hier wieder mit Fachbegriffen um sich und erwartes von mir, dass ich hier im Vorlesungssal sitzen und wir haben Thomas Dark und du referenzierst hier gerade eine Vorlesung von Dienstag. [SPEAKER_01]: Hauptsprecher, Sekundarspeicher, Wolfgang. [SPEAKER_01]: Ich habe acht Stunden Arbeit hinter mir.

39:32 [SPEAKER_01]: Ich bin gerade auf dem Weg vom Büro nach Hause im Auto. [SPEAKER_01]: Mein Gehirn ist schon gebrutzelt, wenn mein Vorgesitzer wieder fünf reporting sagen wollte. [SPEAKER_01]: Also, explain me like I'm five. [SPEAKER_01]: Eine Einführungsspielvorlesung, über die Unterschiede, Hauptsprecher, sehkundeursprecher.

39:50 [SPEAKER_01]: Damit ich die auch mal folgen kann. [SPEAKER_00]: Was uns redes Speicher heißt, das mal... Oder heißt es so, vielleicht ist es so eine deutsche Österreichsische Sache. [SPEAKER_00]: Es ist eine Kondessekundehr. [SPEAKER_00]: Ja, egal. [SPEAKER_00]: Innenzmal Sekundeursprecher. [SPEAKER_00]: Also grundsätzlich fährst du mal nicht zur Arbeit, du bist fully remote an dir, aber gut.

40:05 [SPEAKER_00]: Es kann trotzdem anstrengend sein, weil eigentlich kommst du vielleicht gerade aus dem Garten vom Rasen nehmen oder so, aber ich lasst dir mal deine Anstrengende Arbeit. [SPEAKER_01]: Da packst du jetzt aber auch wirklich hier stelle Tüpen aus, wie Leute, Homeoffice beschreiben, die Nihomoffice machen durften.

40:23 [SPEAKER_01]: So nach dem Motor auch die Länge in nur im Garten. [SPEAKER_00]: Na ja, wenn ich gesagt liegen, du machst der Efehl im Gartenrasenmähn und so. [SPEAKER_00]: Aber gehen wir mal zurück auf den Habspeil. [SPEAKER_00]: Also grundsätzlich früher war das natürlich noch ein großer Unterschied mit dem Sekondärspeich mit der Festparte, mit der Spinning-Disk, weil die halt viel viel langsamer war.

40:39 [SPEAKER_00]: Also so eine Spinning-Disk hat der halt früher 300 Megabyte diese Kunde und halt bis du halt doch bei einigen Giga-Bit, die du vielleicht an Durchsatz erreichen kannst. [SPEAKER_00]: Also das hat sich ein bisschen geändert. [SPEAKER_00]: Nichtsdestotrot sind die Konzept, der eigentlich noch dieselben.

40:54 [SPEAKER_00]: Grundsätzlich überall, wo du auf Datenzugrefs, auf Speicherzugrefs, zeist jetzt auf der Festplatte oder im Rammen oder im L1 Cash, du hast immer eine gewisse Größe mit der du arbeitest. [SPEAKER_00]: Auf der Festplatte ist es die Seite Page, die sehr groß übliche Weise. [SPEAKER_00]: Und wenn du irgendwas lebst von dieser Festplatte, von deinem Sekunden der Speicher, dann musst du immer eine ganze Bedschladen.

41:19 [SPEAKER_00]: Das heißt, es sind, wenn du jetzt... [SPEAKER_00]: einen integer-ladend willst, dann sind das meistens wesentlich main-formationen, die du da immer mit lehtst automatisch, das heißt, du letzt an der Seite dann mit 4 Kilobweit oder vielleicht sogar noch mehr war 100 Kilobweit, wie das auch immer je nach speichertipfunktioniert, aber du lehst mehr als nur diesen einen integer-wert in du z.B. haben bis und [SPEAKER_00]: Das ist überall gleich auch beim L2, L3, Cash, du lebst nie nur den einzelnen Integer-Wert.

41:49 [SPEAKER_00]: Du lebst normal immer mehr mit Außenherum und mit dem musst du mal grundsätzlich arbeiten. [SPEAKER_00]: Also wie Lokal liegen deine Daten, weil du kannst wirklich nie nur einen Integer-Wert laden, du kannst in Deutschland, aber du musst alles andere wegwerfen. [SPEAKER_00]: Das heißt wie Lokal liegen deine Daten zusammen, die du gemeinsam brauchst.

42:05 [SPEAKER_00]: Das ist so die Grundannahme von Integer-Strukturen, dass du eigentlich diese Lokalität optimist. [SPEAKER_00]: Im Hauptspreche ist es halt eher die Cash-Lokalität, die größten von den Cash-S und auf der Festplatte sind diese ganzen Seiten, die du optimierst, das im meistens größere Blöcke, die du da unter einmal lebst.

42:24 [SPEAKER_00]: Was natürlich im Hauptspreche, schon noch mal eine andere Nummer ist, ist einfach die Geschwindigkeit. [SPEAKER_00]: auch jetzt im Vergleich zu SSDs oder modernen schnellen seconder Speichern. [SPEAKER_00]: Ich bin im Rahmen viel viel schneller. [SPEAKER_00]: Ich kann viel mehr springen, weil eben meine Cashlines oder Blöcke, die adressieren kann.

42:40 [SPEAKER_00]: Einfach viel kleiner sind, dadurch ist ein Sprung auch weniger Deuer, weil die nicht immer keine noch 4 Kilo beitladen muss, sondern nur 4 und 60. [SPEAKER_00]: Beit oder so in meinen Cash-Schradladen muss. [SPEAKER_00]: Also umso näher, ich an der CPU bin, umso billiger, sind meine Sprüge.

42:55 [SPEAKER_00]: Und umso mehr Pointer kann ich eigentlich verwenden. [SPEAKER_00]: Wenn jetzt meine Daten auf der SSD random ist hier irgendwo herumliegen, auch wenn man sagt, auf der SSD kann man ja trotzdem random springen, weil es ist ja keine spinning disk mehr wie früher, ist es trotzdem dauer zu springen.

43:09 [SPEAKER_00]: Und wenn ihr was zusammen habt und in einem Block hin einer Betsch lesen kann, bin ich trotzdem immer schneller. [SPEAKER_00]: Und genau da unterscheiden sich noch sehr kunderspeicher zu hab Speicher. [SPEAKER_00]: So wie sehr muss ich auf meine localität achten, dass meine Daten zusammenliegen.

43:24 [SPEAKER_00]: Und wenn man da wieder auf diese Benäre Suche geht, die man zum Beispiel schon gehabt haben, so die eine der einfachsten Indekstrukturen im Hauptspeich ist, jetzt da bin erbaum. [SPEAKER_00]: Das heißt, ihr habt nen Baum und bei jedem Knoten haben wir zwei Abzweigungen einmal nach links, einmal nach rechts bin er, Kleiner oder größer.

43:40 [SPEAKER_00]: Diese Struktur funktioniert natürlich nur im Hauptspeicher. [SPEAKER_00]: Das heißt, ich habe einen Knoten, mach einen Sprung, nach links oder nach rechts und springen zu einer anderen Adresse. [SPEAKER_00]: So ein Bienerbaum würde mich auf der Festplatte natürlich killen, weil dieser Sprung von einem Knoten zum nächsten Superdier ist.

43:57 [SPEAKER_00]: Und darum macht man zum Beispiel bei den Sekundär, Speicherindekstrukturen, einen viel größeren Fanaut auf so einem Knoten. [SPEAKER_00]: Das heißt, ihr braucht so einem Knoten nicht nur einen linken und rechten Knoten, Knoten, sondern ihr habt zum Beispiel 200 Knoten. [SPEAKER_00]: Das heißt, ihr kann unter einmal, wenn ihr bei einem Knoten eine Überbrüfung mache, wo hin soll die Sprengen, dann kann ich 200 Überbrüfungen machen und meinen Zuchraum in 200 Untersuchräume aufdeilen.

44:23 [SPEAKER_00]: Das ist der klassische B-Bahom, dann. [SPEAKER_00]: Also da bin erbaumteilt alles in zwei Supräume auf und der Bebau im üblicherweise in 200 in der Größenordnung. [SPEAKER_00]: Und dann laden die mal einmal so einen Knoten von der Festplatte mit den 200 Kriterien, wo hin soll ich jetzt springen.

44:39 [SPEAKER_00]: Kann die auf einmal bearbeiten in meiner... [SPEAKER_00]: CPU, idealerweise so lang wie die Cashline, ist, kann das hochoptimiert prüfen und daile dann meinen Zuchern in 200 auf. [SPEAKER_00]: Und das ist dann üblicherweise schneller, weil ihr natürlich einen Loginismus habe und dann schneller an mein Ziel komme.

44:57 [SPEAKER_00]: Beim B&R Baum ist es nicht so schlimm, weil da kann ich schnell springen im Speicher dafür ist, das ändern wesentlich schneller, weil die natürlich weniger Umstrukturieren muss, ab B-Bahn hat super komplexe Umstrukturierungsprozesse, wenn da irgendwas geändert wird, dann muss hier 18 Knoten umhängen und umbauen und unzuweiter.

45:13 [SPEAKER_00]: Also es ist wesentlich komplexe und das ist wieder da klassische Trade-Off zwischen Hauptspeicher und Sekundärspeicher. [SPEAKER_00]: Das Umbahn ist vielleicht deurer, dafür bin ich beim suchen schneller, beim Sekundärspeicher beim B-Bahn und beim B&R Baum ist es eben genau umgekehrt. [SPEAKER_01]: Bein ich als Zoffe ein Entwicklerin, die ganze Sache nutzen, dann sind ja so viel Sachen abstrahiert.

45:32 [SPEAKER_01]: Wie kann ich das überprüfen, was du jetzt gerade gesagt hast? [SPEAKER_01]: Mere ich immer zeitliche Messungen oder kann ich mir die Datenschruktur effektiv ansehen durchen? [SPEAKER_01]: Sie sind den UNIX-Komaan, oder ähnliches. [SPEAKER_00]: Du brauchst es hintergrund wissen. [SPEAKER_00]: Also du musst mal grundsätzlich verstehen, was bedeutet ein bener Baum, was bedeutet ein B Baum, welche Indikstruktur und verwendet meine Datenbank, welche Verwendig für mich im Hauptspreiche zum Beispiel wenn du eine Hashmap verwendes musst du ja auch verstehen, was macht diese Hashmap und eine Hashmap ist auch nichts anderes als eine Indikstruktur im Hauptspreiche.

46:02 [SPEAKER_00]: Die erlaubt mir einen schnellen Lockup ohne dass ich ganz viele Daten laden muss. [SPEAKER_01]: Also ich muss ja auch nicht verstehen, wie ein Benzinmotor funktioniert, um Auto zu fahren. [SPEAKER_00]: Ja, du kannst natürlich einfach sagen, okay, der AI agent meines Vertrauens hat mir gerade vorgeschlagene Hashmap zu verwenden, klar, kannst du verwenden, es wird schnell sein, ist vielleicht ausreichend.

46:25 [SPEAKER_00]: Wenn du Problem hast, wenn du in die Difekin willst, musst du natürlich verstehen, was ist eine Hashmap, wie funktionierten Hash, was sind die Nachdeile, kannst du natürlich auch Schmerzvoll einfach rausfinden, wenn du irgendwann mal dann gegen die Wand läuft und alles langsam wird und du musst dann mühsam rausfinden, okay, es ist die Hashmap und es gibt irgendwie Koalitionen in der Hashmap und darum wird alles langsam oder du verstehst [SPEAKER_00]: Grundsätzlich oder eigentlich ist ihr des Wissen an oder fachst mal deinen Agent Heyd los mit einer Hashme vorgeschlagen, warum, was ist eine Hashmeb und der Klemicoz vor und nach Deile unterließe diese drei Sätze und habt die Informationen.

46:57 [SPEAKER_00]: Das ist halt an der Unterschied, holig mir die Informationen, verstehe das einige Massen, was im Hintergrund basiert oder mache ihr einfach Weibkodi. [SPEAKER_00]: Leia. [SPEAKER_01]: Also, da beleid ich selbst aber sehr, sehr viele Leute, zwischen Weibkoding und ich weiß genau, wie unten drunter eine Herrschmöppt die Daten organisiert, da liegen halt schon noch ein paar Level.

47:15 [SPEAKER_00]: Ich sage nicht, dass man das bis hinstiefste Teil verstehen muss, aber eben diese Symplifrarge, etschend, erklären wir mal kurz vor und nach deine, wie das so grob funktioniert, ihr rede ja von diesem. [SPEAKER_00]: Verständnis und mehr brauchst du ja auch gar nicht verstehen. [SPEAKER_00]: Du musst denn jetzt nicht wissen, wie werden Koalitionen wirklich im Detail aufgelöst in dieser Hechmepp?

47:32 [SPEAKER_00]: Aber du musst wissen, wenn ich ganz viele Koalitionen habe, das das ganze Langsamer wird. [SPEAKER_00]: Also solche Grundinformationen habe in den Kie, wo ich viele Koalitionen habe, dann wird das ganze Langsamer üblicherweise. [SPEAKER_00]: Und solche Grundsatzinformationen und Verständnis von Indekstrukturen, das natürlich hilfreich, wenn man dir einfach hat, was das bedeutet.

47:50 [SPEAKER_00]: Ich verstehe jetzt auch nicht dem Detail wieder neu aus der Radix 3 irgendwie die L1 bis L3 Cash Optimierung macht und die wie lange die Zahlen im Detail sind. [SPEAKER_00]: Aber ich weiß grundsätzlich, dass es der Optimierung ergibt und man kann ja dann auf sehr schnell nachschauen, welche in die Zahl sind, für was geeignet, hab Speicherser und der Speicher, was ist besser, was ist schlechter und so ein Grundverständnis hilft dann schon im Alltag meiner Meinung nach.

48:13 [SPEAKER_01]: Jetzt habe ich dich Initial so angekündigt, als jemand mit Dr. Titel in Datenbangen. [SPEAKER_01]: Und gegen Ende dieser Episode und zerstörst du deine Querte billetie in dem du sagst, ja, ich weiß auch nicht, wie das unten runter funktioniert. [SPEAKER_00]: Obgang, so funktioniert Podcasts nämlich.

48:27 [SPEAKER_00]: Ist wahrscheinlich das Problem von dem wissenschaftlichen Ansatz, weil wenn du mal so Papers von der Fall der B zum Beispiel durchliest, da weißt du einfach, dass du eigentlich dann keine Ahnung hast, wenn du so ... [SPEAKER_00]: Irgendeine Indekstruktur, die des Delta vom Delta vom Delta, die ja vorrechnet und zeigt und irgendwelche Optimierungen macht auf der Indekstruktur und das keine Ahnung mehr, von was die eigentlich sprechen.

48:47 [SPEAKER_00]: Da merkst du, obwohl du da vieler Jahre verbracht hast, in dem Bereich, das ist dann schon unter Umständen. [SPEAKER_00]: Auch Sachen gibt eben den Kip, die so tief liegen, die du nicht verstehst und dann kann man das auch akzeptieren, dass man die nicht versteht. [SPEAKER_00]: Aber so grundlegende Optimierungen sind schon ganz hilfreich.

49:03 [SPEAKER_00]: Und dann am Ende sucht man sich einfach raus, was gut funktioniert. [SPEAKER_00]: Aber das ist mal zum Beispiel Hauptspeicher und Sekundärspeicher gibt, dass es da einfach unterschiedliche Inextrukturen auch gibt, wenn in klassischen Red Black Tree oder Afer-Eltree finden Hauptspeicher verwendet bin, ja, Baum und eben in klassischen B-Baum dann bin ich schon mal eigentlich ganz gut, um Weg und hab schon relativ viel verstanden.

49:23 [SPEAKER_01]: Lass mich nochmal auf die ganzen Absraktionen zurückkommen, denn du hast das gerade so abgewungen. [SPEAKER_01]: Ja, dann Promtes erhalten wir mit der KI so ein bisschen und dann muss das halt verstehen, da kann ich dir jetzt auch nicht helfen. [SPEAKER_01]: Ja, da merkt man schon ein bisschen typischer Professor der vorne unten im Hörsaal steht und einfach kein Bock mehr hat, weil ja alle zu dumm sind.

49:40 [SPEAKER_01]: Verstehe ich, nehme ich gerne an, ja, aber ich lasst das jetzt nicht auf mir sitzen für die ganze Hörerschaft hier. [SPEAKER_01]: Deswegen, wenn ich all das Selbstprogrammiere. [SPEAKER_01]: Da kann ich mich da so tief reinnörden, kann meine Structs optimieren, Cash-Line, Cash-In-Line und Piper-Po.

49:55 [SPEAKER_01]: Aber in meiner Postgrei, in meiner Mais, in meiner MariaDB, in meiner Oracle, in meiner Word-Ever-Datenbank, mache ich Create Index, freue mich darum, zu, wo Mittagessen gibt und gehen die Pause. [SPEAKER_01]: Also, lassen uns die ganze tematik doch mal bitte praktisch machen und die Leuten hier nicht immer Hausaufgaben geben, [SPEAKER_01]: Also, drei praktische Tipps, die du mir jetzt damit geben kannst, die ich jetzt heute Abend auf mal Zeitproject anwinden kann.

50:25 [SPEAKER_01]: Hop hop. [SPEAKER_00]: Also erstens im E-Bing-Kam-Professor, um das um das klarzustellen, trotzdem habe ich die sehr... Nee, nee, das ist glaubt. [SPEAKER_00]: Aber du verhältst dich ja, du verhältst dich ja genau so wie einer. [SPEAKER_00]: Trotzdem bin ich der Meinung und wenn du mir jetzt konkret nach drei Tipps fachst, wäre für mich schon ein Tipp grundsätzlich Sachen besser, [SPEAKER_00]: Verstehen zu wollen.

50:45 [SPEAKER_00]: Und gerade in der heutigen Zeit ist es eigentlich wichtig, dass man die Sachen besser versteht. [SPEAKER_00]: Und wenn du jetzt sagst, okay, in meiner Postgres, da kann ich ja nichts ändern, da mach ich nur Create Index. [SPEAKER_00]: Das stimmt schon. [SPEAKER_00]: Aber du kannst in der Postgres erstens mal auswählen, ob du B3 machst, ein Has, ein Chist, ein Gen, ein BR, ein N, ein Plumindex über ein Extension, also du hast schon auch bei Postgres, die war, was für Indexstrukturen wirklich verwendest.

51:10 [SPEAKER_00]: Und dann [SPEAKER_00]: auch da wieder, was für ein Workload hast du und wie wenn du den Index an. [SPEAKER_00]: Zusätzlich hast du jetzt auch, wenn man mal ganz klassischen Index verwenden im B-Tree, der halt so überall, der Around Index in der Datenbankwelt ist, auch da kannst du entscheiden, welche Spalte ist in meinem Index.

51:30 [SPEAKER_00]: Welchen Index? [SPEAKER_00]: Erzeug ich denn überhaupt, über welche Spalten? [SPEAKER_00]: Da kommen dann diese ganzen Zugriffsmuster nämlich auch noch mal in Spiel. [SPEAKER_00]: Du kannst ja mehr Respalten in einem Index hinzufügen und wenn du zum Beispiel jetzt [SPEAKER_00]: Zusätzlich zu einer E-Mail-Adresse, wenn man wieder auf das Beispiel zurückkommen, immer den Namen ein haben willst.

51:47 [SPEAKER_00]: Also du suchst eine E-Mail-Adresse und willst dann in Namen an die haben an die Grundwalt. [SPEAKER_00]: Dann kannst du in diesen Index die E-Mail-Adresse hineinsprechen, als Walter, die Studierungen läuft dann über die E-Mail. [SPEAKER_00]: Und als zweite Spalte noch den Namen, dann beinhalten nämlich dieser Index, [SPEAKER_00]: die E-Mailadresse und den Namen und KWAT diese zwei Spalten und für eine Anfrage über die E-Mailadresse gibt mir den Namen, brauchst du dann die eigentlichen Daten gar nicht.

52:13 [SPEAKER_00]: Das heißt, du kannst die Anfrage ausschließlich über den Indexbeantworten und solche Dinge helfen dir natürlich im Alltag weiter, weil dann Spaß zu dir wieder einen kompletten Zugriff auf die klassischen Daten. [SPEAKER_00]: Wir können mal in der eigene Episode dazu, so ob die Währungen ganz allgemein machen.

52:26 [SPEAKER_00]: welche Indekstrukturen man verwendet und wie man dann optimiert im speziellen. [SPEAKER_00]: Aber ganz allgemein kannst du sehr wohl viel machen im Houchpecker aus du sowieso alle Möglichkeiten. [SPEAKER_00]: Da kannst du ja machen, was du willst. [SPEAKER_00]: Vielleicht sollst du nicht alles selber programmieren vom Scratch.

52:39 [SPEAKER_00]: Also du wirst es jetzt lernen. [SPEAKER_00]: Ihr wird auch keine Hashmap neu implementieren, sondern eine Hashmap verwenden. [SPEAKER_00]: Aber dass man mal weiß, was kann man überhaupt verwenden? [SPEAKER_00]: Was gibt's für Indekstrukturen, welche Basen für meinen in the US case? [SPEAKER_00]: Und wie wenn die ich sie richtig an.

52:53 [SPEAKER_00]: Weil wie gesagt, der Beatrice war fix in a mice-colle oder in a post-gres, standard index, aber er betrotzt im viele Möglichkeiten, wie ich den dann auf meine Daten anwende. [SPEAKER_00]: Und da hilft mir dann schon das Grundverständnis, wie ihn index funktioniert. [SPEAKER_00]: Und was ich dann mit meinem Index machen kann, und die kann mir dann das über Explain-State-Mense zum Beispiel ausgeben lassen, um das dann vielleicht zu optimieren, um euch zu schauen, wie funktionieren meine Zugriff-Beterns, welche Indexstrukturen waren, überhaupt verwendet, vom Optimizer.

53:20 [SPEAKER_00]: da kann ich wirklich konkret ansetzen und meine Meinung nach muss man da auch konkret ansetzen. [SPEAKER_00]: Weil genau diese Stellen sind die Möglichkeit, wie uns Entwicklerinnen da Einfluss zu nehmen. [SPEAKER_00]: Auf dem Optimizer Einfluss zu nehmen, das ist schon nächste Level. [SPEAKER_00]: Aber mal grundsätzlich zu entscheiden, was für Indexstrukturen verwendig, welche Spalten Klatsche darin, was haben wir für einen Workflow, also dieses Vierergespannen von Datenstruktur Algorithmus, Hardware, [SPEAKER_00]: Zugriffsmuster zu kennen, zu verstehen und anzuwenden, macht meine Meinung am meisten Sinn und sich da vielleicht mal jetzt im Seidproject konkret anzuschauen, was habe ich denn übertwinn index.

53:56 [SPEAKER_00]: Was verwendierter finde index, Kenny überhaupt die Indexstruktur, was in meine Zugriffsmuster und kann ich da was optimieren. [SPEAKER_00]: Das wäre so mein Plan, wenn ihr an irgendwas rangehen will, um mal zu schauen, habe ich irgendwo ein Problem in meiner Implementierung, kann ich wo wir schneller machen, wenn ihr in dieser Richtung wirklich gehen will.

54:11 [SPEAKER_01]: Du hast gerade sehr viel über die Erstellung von Innexen innexen, innexen, Innexen, Innexes, geht bei des gesprochen. [SPEAKER_01]: Das ist ja fast mit Greenfield gleichzusetzen. [SPEAKER_01]: Ich habe eine neue Tabelle, die es noch ranziufreulich. [SPEAKER_00]: Na, du kannst ja, du kannst ja Innexes jeder Zeit erstellen und löschen.

54:26 [SPEAKER_01]: Ja, ja richtig. [SPEAKER_01]: Nur jetzt ist es ja so leg es sie verdient das Geld. [SPEAKER_01]: Und wir arbeiten ja alle in einem Team, an einer großen Applikation. [SPEAKER_01]: Mit hoher Wahrscheinlich kann ich existieren schon innexes oder Innexes, oder. [SPEAKER_01]: Efter. [SPEAKER_01]: keine Ahnung wie das Wort ist heißt.

54:39 [SPEAKER_01]: Willest du mir auch empfehlen? [SPEAKER_01]: Quartalzweise alle Innexse zu Reviewen und zu schauen, ist die Annahmen noch konkret oder würdest du auch empfehlen, die Annahmen pro Innex als SQL Kommentar ins Schema mitzupacken oder ähnliches, weil hört sich so an, als wären die Innexse auf Basit von Anna am Herstellt, ähnlich wie damals Designentscheidungen in deine Code getroffen wurden.

55:03 [SPEAKER_01]: Also so Architekcher, Decision Records für ICCs. [SPEAKER_01]: Oder eigentlich ist das ein bisschen obersetoppt. [SPEAKER_00]: Wieso jetzt meine Wissen schafft, ich hätte meine pragmatische Herangehensweise hören. [SPEAKER_00]: Ich will eine Antwort auf meine Frage. [SPEAKER_00]: Also grundsätzlich ist es so wie überall pragmatisch würde ich sagen, wenn du kein Problem hast, mach einfach nichts.

55:21 [SPEAKER_00]: Wenn das schnell läuft, dieses Ding und du nötigen Schmerzen hast, dann ändert ihr nichts. [SPEAKER_00]: Das kannst du immer noch machen, wenn du Probleme hast. [SPEAKER_00]: Aber was natürlich schon gut wäre, wenn grundsätzlich es Monitoring von dem ganzen wie schnell sind, denn meine Abfragen überhaupt auf der Datenbank.

55:35 [SPEAKER_00]: wie viel CPU-Load hat meine Datenbank und wie viel die eigentliche App zum Beispiel. [SPEAKER_00]: Also solche Grundsatz-Metricking mal zu haben, sind schon gut und wenn ich dann eine Fleißaufgabe machen wird und das ist dann die Wissenschaft der Rangensweise, die ich will was lernen oder ich habe einfach ...

55:50 [SPEAKER_00]: So viel Zeit, weil die LLMs meine Arbeit machen und ich so viel Freizeit habe, dass sie wieder tief eindarchen kann, dann kann man sich natürlich so ein Review mal überlegen, welche Indekstrukturen habe ich überhaupt, brauche ich, welche gibt's vielleicht so ein Slow Query Lock zum Beispiel, was sie meine langsamen Anfragen kann ich da irgendwo was beschleunigen.

56:10 [SPEAKER_00]: Es schade natürlich nie, da mal reinzuschauen, wenn man sowas hat, aber wie gesagt, wenn man [SPEAKER_01]: Es geht nicht um Probleme lösen, es geht der Teilweise auch um Bildung, es geht der Teilweise auch um Optimierung von Low Hanging Foods und besonders, wenn wir wer applicationen bauen, wissen wir ja alle jede Millisekunde zählt, also von daher weiß ich kann ich ob man hier immer nur Probleme lösen oder nicht wirklich guter Optimierung macht, um vielleicht dann die Konversion zu steiler.

56:40 [SPEAKER_00]: Was mir auch oft passiert ist, wenn die wirklich auf die Datenbank bei manuell irgendeiner query absätze und die so gefühlt, irgendwie 50 Kunden warten, ich denke schon irgendwie komisch langsam, auch wenn es nur eine Lockterbälle oder irgendwas ist, dann schauen wir mal kurz rein, gibt es da eigentlich Indezes, habe ich da die richtigen könnt ihr da vielleicht einen Index schnell drüberlegen, man muss auch aufpassen, gerade wenn man so riesige der Bellen hat und plötzlich einen Indexerzeug kann sein, dass man die ganze Datenbank lockt oder einen Großteil oder vielleicht auch produktiv.

57:07 [SPEAKER_00]: was kaputt macht, also da muss man auch aufpassen, aber wenn ich anzeichen sehe in irgendeiner Form, das heißt jetzt Slow Curie lock oder persönlich das irgendwas langsam läuft, wenn ihr eine Atokcurie abfeuer, dann schrei vielleicht mal kurz rein, wenn die Zeit habe und teilweise ist es ja wirklich nur 5 Minuten und man sieht okay, das jetzt ein Index der viel helfen würde, ist vielleicht keine riesen Tabelle, die jetzt alles langsam machen würde mit dem Index und dann probiere es einfach mal aus.

57:33 [SPEAKER_00]: Der Titel war noch ein Problem. [SPEAKER_00]: Ich habe diese Episode gehört. [SPEAKER_01]: Es gibt keine Probleme, es gibt nur Challengees an dir. [SPEAKER_01]: Herausforderung. [SPEAKER_01]: Ich mag dein positives Würding. [SPEAKER_01]: Danke, dass du mich daran erinnern. [SPEAKER_01]: Ich habe diese Episode jetzt gehört.

57:43 [SPEAKER_01]: Verinnerlicht. [SPEAKER_01]: Ich habe mich so nur Tizen gemacht. [SPEAKER_01]: Ich schau auf mein Datenbankschema. [SPEAKER_01]: Ich habe gelernt, Indexe zu maintainen, kann teuer sein. [SPEAKER_01]: Nicht jeder Index, bringt noch was, weil vielleicht die Datenannahme nicht mehr stimmt.

57:55 [SPEAKER_01]: Dann gibt es ja das Problem, wenn ich jetzt... [SPEAKER_01]: Meine Datenbank anpassen, mein Schema anpassen. [SPEAKER_01]: Ich nehme Ihnen in den nächste Weg, ich droppe den. [SPEAKER_01]: Und der war doch vielleicht doch im Begrau, und der war vielleicht doch noch im Belutzung von irgendeiner Creary, von irgendeim anderen Service.

58:10 [SPEAKER_01]: Und der ist jetzt ganz langsam. [SPEAKER_01]: Dann kann ich Ihnen nicht einfach so wieder hinzufügen. [SPEAKER_01]: Klar, ich kann Ihnen, ich kann die Creary absetzen zu. [SPEAKER_01]: Oh, takt Ihnen mal wieder dahin. [SPEAKER_01]: Aber das kann ja auch ein großer Performance in Pelt auf die Db haben, oder?

58:22 [SPEAKER_00]: Ja. [SPEAKER_00]: Aber das hat jede Änderung. [SPEAKER_00]: Du kannst ja auch einem Code ökten scheißbaren. [SPEAKER_01]: Ja ja richtig. [SPEAKER_01]: Nur der Unterschied ist, dass du halt, um die nächste wieder hinzuzufügen, sehr wahrscheinlich eine Haterlast auf die DB setzen kannst und somit produktiv traffic beeinflussen kann und zu weiter und zu fort.

58:38 [SPEAKER_01]: Meine Frage ist eigentlich, sollte man deswegen keine Inditi so robben. [SPEAKER_01]: Also ich meine, es geht schon alle in die Richtung, so nach dem Motto, wenn du Angst hast eine Änderung zu machen, ist das schon sehr problematisch. [SPEAKER_01]: Egal ob's während Zurschuld oder Datenmangel anhaben, aber das hat ja wirklich jetzt einen schwierigen Impact.

58:52 [SPEAKER_00]: Nein, das kann eigentlich schon überall sein. [SPEAKER_00]: Ich glaube nur, dass wir die Sicherheitsnetze in natürlich wenn es um Programm, Code, Änderungen geht schon aufgebaut haben und wir haben selten diese Sicherheitsnetze bei der Datenbank. [SPEAKER_00]: Weil du kannst natürlich diese Testzenarien genauso mit der Datenbank auch fahren.

59:08 [SPEAKER_00]: Du kannst dir mal ein Index löschen und dann, wenn du ein sauberen Test work load hast, den mal abfeuern und schauen, ist die Datenbank jetzt... [SPEAKER_00]: immer noch gleich schnell gibt es ein Problem, also kannst es ja auch mal in den Vorholen ein dessen. [SPEAKER_00]: Du kannst so ein High-Sophisticated-Szenarien haben wie in ein proxy SQL, der dir den gesamten Datenbank Traffic noch mal kubieren kann und an den anderen Server schicken, dann löscht du dort diesen Index und schaust mal, läuft das Server immer noch gleich weiter mit dem gleichen Load, mit dem Live Load, hast es ganz selber du blitziert, also wenn du natürlich [SPEAKER_00]: Und sonst kannst du es im kleinen Lokal natürlich auch testen.

59:47 [SPEAKER_00]: Und die würde mal sagen, wenn du sehr, sehr groß bist, dass das ein Problem ist, dann hast du vielleicht schon strukturen, um solche Sachen zu testen. [SPEAKER_00]: Und wenn du klein bist, hast du wahrscheinlich kein Problem, weil deine Datenbank einfach nicht so groß ist. [SPEAKER_00]: Und im Idealfall ist deine Datenbank sowieso nicht jetzt auf Anschlag.

1:00:03 [SPEAKER_00]: Und wenn du es dann in der Nacht machst, dann tachst du den Index halt wieder oder deine Datenbank ist mal langsam über eine gewisse Zeit. [SPEAKER_00]: Index erstellen ist normal gar nicht. [SPEAKER_00]: so das Problem, weil es relativ gut aussehen grown eigentlich funktioniert. [SPEAKER_00]: Und grundsätzlich, um deine Frage zu beantworten, sollte man nie dropen, grundsätzlich jeder Index braucht, performance, weil er immer abgedetet werden muss.

1:00:24 [SPEAKER_00]: Wenn du jetzt ganz viele Indexstrukturen hast, die du abdaten musst, du brauchst sie aber gar nicht, dann ist deine Datenbank wesentlich langsamer. [SPEAKER_00]: Also, es würde jetzt nicht unterschätzen, was das eigentlich ausmachen kann, nen Drop zu machen. [SPEAKER_01]: Ja, ich spreche nur diese Herausforderung an, die ich halt schon in Firmen gesehen habe, du hast halt irgendwelche System an Minisratoren, die können man sich halt um die Datenbank und die haben dann immer Angst, in den nächsten Dropen, weil sie all die Details nicht wissen, wie eine Hechme aufgebaut ist und so weiter und so fort überall, dass das wir hier gesprochen haben.

1:00:49 [SPEAKER_01]: Also, Edward Kates, du eigentlich dafür, dass man ein ordentliches Staging System hat, wo man ordentliche Lothest fahren kann mit Sicherheitstest, also ähnlich wie bei Code. [SPEAKER_01]: Das ist richtig. [SPEAKER_00]: In Grösse-Wernseiter ob sicher ist immer die Frage, hast du die Kapazität so was zu machen, aber klar, grundsätzlich gehört das natürlich zu einem guten Test dazu, funktioniert auch mein klassischer Workload noch mit dem Code, mit der Datenbank ist ja alles ein System und ihr will ja eigentlich alles testen.

1:01:14 [SPEAKER_00]: Genau wie dabei Observability hat Metrickin als allen Bereichen haben willst, du bist ja, wenn du jetzt ein Radies hast, weil der übrigens auch Datenstrukturen hat und eigentlich faszne Datenbank ist, aber das ist noch mal eine andere Diskussion, dann bist du ja auch Metrickin von Radies haben, du würdest ja nie sagen, ich mache nur die Metrick ganz ganz vorn auf der Appseite alles anderes mir gar, sondern du suchst ja schon hoffentlich die die richtigen Metrickin raus und von alles Systeme, die du hast, hast du [SPEAKER_00]: sind sie auf Anschlag, gibt es Probleme und dann kann so auch ein bisschen besser dem entsprechender gehen.

1:01:49 [SPEAKER_01]: Ja, das warst du da erzählt, das ist alles richtig und ist auch in 2026 immer noch korrekt. [SPEAKER_01]: Wieso aber auch irgendwie so eine Gedankenstruktur von 1990, denn du hast gerade gesagt, im großen Set-ups und wenn du dir das leisten möchtest, kannst du dir sicher jetzt nicht für Datenbanken aufbauen.

1:02:05 [SPEAKER_00]: Aber ja, es ist schon viel Arbeit, wenn du da so eine Infrastruktur aufbassst, wo du zwei die Datenbank hast, alle Spiedeln kannst, Workloads abführen kannst, also es ist nicht zu unterschätzen, würde ich mal sagen. [SPEAKER_01]: Ich habe eine Frau Marta-Schereleusung für dich. [SPEAKER_01]: Ja, zwar habe ich diese Frage nicht ohne Rundgestellt.

1:02:19 [SPEAKER_01]: Ich habe mir gedacht, in etlichen Episode haben wir Dead Jokes Programming Dead Jokes gemacht. [SPEAKER_01]: Hier habe ich jetzt einfach mal die Such-Anfrage gestartet. [SPEAKER_01]: Was ist denn so, der Skorielste Index-Type, den so eine Datenbank eigentlich hat? [SPEAKER_01]: So nach dem Motto um ein bisschen Humor hier reinzubringen, nach den ganzen Hashmap-Temartiken und so.

1:02:38 [SPEAKER_01]: Meist Guell hat mir ganz Wortet. [SPEAKER_01]: Bei Meist Guell gibt es inzwischen einen unsichtbaren Index. [SPEAKER_01]: Dieser unsichtbare Index wird vom Optimizer komplett links liegen gelassen. [SPEAKER_01]: Der wird geflägt von der Datenmarkt. [SPEAKER_01]: Der wird geabtet, der wird der Lerschweck aus alle Grundon.

1:02:53 [SPEAKER_01]: Nur der wird vom Optimizer komplett links liegen gelassen. [SPEAKER_01]: Und da fahren wir sie so her. [SPEAKER_01]: Warum gibt es diesen Indexseiten überhaupt? [SPEAKER_01]: Warum macht der Load auf die DB er wird vom Optimizer nicht verwendet? [SPEAKER_01]: Ja, ha. [SPEAKER_01]: Stellt sich heraus.

1:03:05 [SPEAKER_01]: Du kannst einen Index sichtbar und unsichtbar schalten, innerhalb von 1.000 Sekunden. [SPEAKER_01]: Und das ermöglicht natürlich genau das, was du da gerade angesprochen hast, performance testing von wird dieser Index noch benötigt. [SPEAKER_01]: Bedeutet, du kannst jetzt zum Beispiel auf deinem Mais-Guell-Daten-Mann-King gehen, auf irgendein Tabelle, schaltet es einen Index auf unsichtbar, Miss die Performance und wenn es eine Performance-Digundation hat, schaltet es zu ihnen wieder aus sichtbar.

1:03:30 [SPEAKER_01]: Ich weiß jetzt gerade leider nicht, ob das in anderen Datenbank auch der Fall ist, aber ich habe den, das mal für mein Skuelz, zumindest mit in die Shownotz gepackt. [SPEAKER_01]: Ich meine, das lasse ich dann als Hausaufgabe für die Hörer und Hörer, ob es gibt. [SPEAKER_01]: Aber da muss ich zugeben, schon irgendwie geil.

1:03:44 [SPEAKER_01]: Und das kannst du dann schon wirklich einsam mal so testigen Productions machen. [SPEAKER_01]: Vielleicht in so einer Load-Traffektion und morgen zum Acht oder so, oder Abend zum Acht kannst du einfach mal indeks auf in Wiese bestellen. [SPEAKER_00]: Ja, du kannst auch in einer High-Traffic-Situation machen, weil du sie ja recht schnell wieder zurückstellen kannst.

1:04:00 [SPEAKER_00]: Und dieses Witcher cool, das sowieso aufgebracht hast, weil es gibt schon eigentlich sehr lange. [SPEAKER_00]: Es gibt es glaube ich schon zehn Jahre oder so grundsätzlich bei MySQL. [SPEAKER_00]: Also es ist ein cooles Witcher, was man verwenden kann. [SPEAKER_00]: Ach, die Jahre gibt's aus Vietsche, kam imals wohl achtreien, aber nah dran.

1:04:16 [SPEAKER_01]: Aber ja, kann dich auch noch nicht, fand ich wirklich cool in Wissebel, in die CS, nun gut. [SPEAKER_01]: Und mit diesem Knowledge-Speit würde ich mal sagen, verlassen wir diese Episode. [SPEAKER_01]: Wer jetzt noch dran ist, hat ein Respekt, ich hoffe, euer Gehirn ist nicht. [SPEAKER_01]: zu sehr frittiert und er hat das Hausgabe mitgenommen, wie wird ein Hashmap aufgebaut?

1:04:34 [SPEAKER_01]: Fanfekt, wir haben uns auch mal überlegt, eine Episode zu machen, wie baut man eigentlich eine Hashmap bzw. wie funktioniert eine Hashmap unten drunter, haben wir dann aber wieder weggeschmissen, weil ohne weitbaut ist das echt komplizier zu erklären, weil du musst echt viele Feile zeichnen und nur auf Audio spuhrar, da kann man nicht wirklich folgen bzw. wir haben uns nicht zugetraut, dass ordentlich zu erklären.

1:04:55 [SPEAKER_01]: Na ja, Dr. Wolfgang Gastar, vielen Dank für diesen Datenbank-Ex-Kurs. [SPEAKER_01]: Ich habe bei der von die Schnauze voll verloren in den Nitzes. [SPEAKER_01]: Ich werde halt keinen mehr anlegen. [SPEAKER_01]: Wahrscheinlich nicht mehr zu Wochen nicht. [SPEAKER_00]: Ja, ich glaube, wir müssen meine Episode wirklich konkret zu den Indexstrukturen machen, die es so gibt, damit wir das mal auch.

1:05:13 [SPEAKER_00]: Es gibt schon cooles Sachen, so ein Blumenfilter zum Beispiel. [SPEAKER_00]: Oder die ganze Radix, Tri-Geschichte, Patricia, Tri-S und so weiter. [SPEAKER_00]: Das sind schon Kohle, Innexstrukturen und ist schön, was man da nicht so machen kann. [SPEAKER_00]: Es ist immer so die Beauty auf Index.

1:05:27 [SPEAKER_00]: Er vielleicht bin ich da an das Geburt. [SPEAKER_01]: Ja, ich finde das schön, was man sollte so cool finden. [SPEAKER_01]: Ich find ein Volksfest cool, wo es günstig Bier gibt. [SPEAKER_01]: Du blumpfelter, okay? [SPEAKER_01]: Lassen wir so stehen. [SPEAKER_01]: Und mit diesem Statement würde ich sagen, wir verabschieden uns von uns.

1:05:40 [SPEAKER_01]: Und dann ist es doch auch bis bald vorbei. [SPEAKER_01]: Ciao.