#273 Bäume, Hashes, Bitmaps: Performance ist kein Zufall

0:03 [SPEAKER_00]: Moin Moin und will kommen zu einer neuen Episode vom Engineering-Kios Podcast. [SPEAKER_00]: Kurz und knack ich, wir sprechen über Index und Darn schon Puhn, denn die machen oft in Unterschied zwischen Läuftschomm und warum es gläht das hier eigentlich nicht. [SPEAKER_00]: Wir schauen uns an, was Red Black Trees sind und wie diese in Engine X für Timeouts genutzt werden, weshalb B und B plus Bäume in Datenwacken so wichtig sind, wo Hash in die Zes glänzen und wo sie eben auch nicht helfen, außerdem gehen wir in die Richtung Tri Radix Tree, Bitmap Index und Blumenfilter und auch wie klassische hatte DPR-Router und gibt diese implementieren.

0:38 [SPEAKER_00]: Los geht's! [SPEAKER_00]: Aus einer Podcast sieht man so, der kriegt man relativ viele Daten raus. [SPEAKER_00]: Und ein Datenpunkt, den wir immer automatisch mitgenarieren, ist der jede Anteil von Wolfgang und Mia und oft kommt dann raus, dass ich mehr Quatsche, warum weiß ich jetzt auch nicht.

0:55 [SPEAKER_00]: Aber damit ich diese zahlverteidige hohe, ich jetzt mal ein bisschen aus, warum dieses Thema für heute relevantes Wolfgang ist so bereit. [SPEAKER_01]: Ich bin bereit und lasche die gerne, warum du übrigens immer mehr Redianteil hast, das glaube ich selbst erklären, das braucht niemand erklären, aber ihr lasst das mal aus.

1:09 [SPEAKER_01]: Nehmen wir im englischen Sakt Homework für unsere Listeners. [SPEAKER_00]: Kennst du das hier ist ein langer Brief? [SPEAKER_00]: Ich bin jetzt schon, ich hatte keine Zeit ein kurzen zu schreiben. [SPEAKER_01]: Ist du dir jetzt rausreden? [SPEAKER_01]: Also, und alles ist nägert, die für dich machen.

1:21 [SPEAKER_00]: Ich hatte keine Zeit, nicht kurz zu fassen. [SPEAKER_00]: Wie dem auch sein, fangen wir mit dem Thema an. [SPEAKER_00]: Und zwar war vor kurzem das Engineering-Kios-Mid-Up rein, wo wir in der Gegend wohnt, im Pot durch Solor aufkühlen und so weiter kann da gerne mal vorbei schauen, die nächste Nettischen ist.

1:34 [SPEAKER_00]: Wunderschöne gegen Wunderschöne gegen. [SPEAKER_00]: So, auf jeden Fall war das Mietab in Dysburg bei Krangeekomput. [SPEAKER_00]: Da ist ein Typ, der steht voll auf Retro Computing. [SPEAKER_00]: Und der hatte auf dem Mietab, das wusste ich gar nicht. [SPEAKER_00]: Ganz viel alte Computer.

1:48 [SPEAKER_00]: Da stehen. [SPEAKER_00]: Komodore und so ein Amiga und ich glaube da war auch ein Playstation 1, aber ich wusste gar nicht, dass ein Playstation 1 schon zu retrocomputing wird. [SPEAKER_00]: Wie dem auch sei, ein bisschen mit dem Equatschglundern sagt der, dass es eine riesen retrocompion, die in Gesehene gibt und das heute noch neue Spiele führen, zefe ihren 60 und so weiter rauskommen.

2:07 [SPEAKER_00]: Und dann fing er an, zu erzählen, dass er die Dinge auch repariert und das natürlich dann nicht nur immer die alte hat, wer eingebaut wird, sondern auch neue Hardware. [SPEAKER_00]: Stell dir mal vor, du hast einen Ailen Porsche und du willst neue Lichter haben, dann kannst du natürlich die originalen Lichter einwandt oder du kannst moderne LED scheinwerfer einbauen.

2:25 [SPEAKER_00]: Also es verändert ja schon eine bisschen in Porsche. [SPEAKER_00]: Auf jeden Fall hat er dann von so hex erzählt. [SPEAKER_00]: Ja, du hast dann irgendwie eine alte Grafikate und eine alte Prozesse und dann hast du eine neue Grafikate. [SPEAKER_00]: so weit zu gut. [SPEAKER_00]: Und das immer noch spiele für dieser allen Rechner rauskommen hat mich vorwundert.

2:46 [SPEAKER_00]: Und das hat mich wiederum an unsere Doomfolge erinnert, weil das Spiel Doom ist ja bekannt dafür, revolutionär gewesen zu sein, im Bezug auf die Algorithmen, das Grafigrenderin, Unter dem Kontext, der ich sag mal, heute zu Tage langsam in Hardware. [SPEAKER_00]: Und jetzt kommen wir zum Thema, wir sprechen mal über.

3:08 [SPEAKER_00]: Datenstrukturen. [SPEAKER_00]: Und das fragt sich jeder, wie so hängt die ganze Sache zusammen, du musst intelligente Datenstrukturen haben, um schnelles Prozessing unter anderem auf Alter-Hatwer laufen zu lassen. [SPEAKER_00]: Du war da super fürs Rendering, wir erinnern uns bei ein Respace-Partitioning, wer da nochmal Beinhalb möchte, Episode 106 und 40.

3:27 [SPEAKER_01]: Das heißt, jetzt wo wir neue Computer haben, neue Architekturen brauchen wir eigentlich nichts mehr machen. [SPEAKER_00]: Das ist alles richtig, theoretisch oder in sehr vielen Fällen. [SPEAKER_00]: Macht man den dritten Teil von Make it Work, Make it Beautiful, Make it Fast, eigentlich nicht mehr.

3:41 [SPEAKER_00]: Weil die Hardware schon fast genug ist. [SPEAKER_00]: Es kommt aber immer wieder vor. [SPEAKER_00]: Denn eine Sache und Leute, die uns schon sehr lange hören, wissen, dass sie da schon mehrfach erwähnt habe. [SPEAKER_00]: Eine Sache, die ich konstern in meiner Karriere höre, mindestens einmal im Jahr, ist, du arbeitest dann irgendein Software-System, es bricht unterlast zusammen oder du hast einen hohes Datenvolumen.

4:02 [SPEAKER_00]: ganz viele Daten, deine Lese, Operationen werden langsamer oder so weiter. [SPEAKER_00]: Dann kommt irgendwer, sagt, das skaliert nicht, was macht der klassische Junio oder mittlevelen Engineer, der geht nach Hacker News, sagt, mein Skuel ist skaliert nicht und kommt dann mit. [SPEAKER_00]: Was ist das heutige MongoDB?

4:17 [SPEAKER_00]: Rockstippie. [SPEAKER_01]: Weil es macht, dass Facebook heißt, es ist auch zu zu alt fast. [SPEAKER_00]: Ja, kommt dann auf jeden Fall meine anderen Zoffwer und dacht dann, wir müssen z.B. aus Tauschen. [SPEAKER_00]: Was ich mir immer denke, wenn ich so was leese, ist du Tauschen ein bekanntes Problemsset Arden durch ein unbekanntes Problemset B.

4:32 [SPEAKER_00]: Denn die Rude-Cons ist sehr, sehr oft Datenschruktur. [SPEAKER_00]: Und was meinigt damit, verhältnis von Lesen und Schreib zugriffen, wie teuer ist ein Leseforgang bzw. wie teuer ist ein Schreibvorgang, das dümmste Beispiel, was ich mir jetzt gerade ausgedacht habe, um die ganze Sache einfach mal zu verwirklichen ist.

4:49 [SPEAKER_00]: Bei einem Schreibvorgang in eine sortierte Liste muss die Liste immer neu sortiert werden, weil man beim Schreiben des Wertes nicht die richtige Stelle in der Liste kennt. [SPEAKER_00]: Das wäre zum Beispiel ein langsamer Schreibvorgang. [SPEAKER_00]: Und wenn man das sehr oft macht, dann zieht man die ganze Applikation gut.

5:04 [SPEAKER_00]: Und Leute, die uns sehr sehr lange hören, die wissen, dass das für kein neues Thema war uns. [SPEAKER_00]: Es ist mein im Juli 2022, das war vor knapp 4 Jahren, haben wir eine Episode über die Landau-Nutation gemacht. [SPEAKER_00]: Die Landau-Nutation, wie erinnern uns, ist die Big O-Nutation, das ist die Komplexität von Algorithmen.

5:20 [SPEAKER_00]: Und da haben wir uns die Frage gestellt, ist, dass ich mein Big der Alltag rielle fand. [SPEAKER_00]: Und ich sage ja, verdammt, es ist rielle Wand deswegen. [SPEAKER_00]: Hab ich mir heute noch mal den. [SPEAKER_00]: Wolfgang geschnoppt, der Wolfgang hat ja einen Doktor in Datenbanken so viel ich weiß.

5:33 [SPEAKER_00]: Datenbanken sind ja unter anderem bekannt für ganz viele Smarte-Index-Strukturen. [SPEAKER_00]: Aber sie kommen natürlich nicht nur in Datenbanken vor und deswegen gehen wir heute mal. [SPEAKER_00]: Ich sag mal so als zweite Episode zu den Performance Basics, die war in [SPEAKER_00]: Episode 260 gemacht haben, schauen wir uns noch mal ein paar Inneckschrukturen an, mit praktischen Beispielen, wo wir der Gramm eich verwendet, wie könnt ihr das eich verwendet und das ist nicht alles oberengineering, denn wenn ihr auch schon mal die Spuch gehört habt, das skaliert nicht, dann hört genau zu, denn oft ist eine gute Inneckschrukture.

6:06 [SPEAKER_00]: Kein Gebrutsche, sondern hilft euch das Problem zu lösen. [SPEAKER_00]: Jetzt bin ich mit der Intro fertig. [SPEAKER_00]: Ich habe ein bisschen ausgeholt, um ein Rederanteil nach oben zu schrauben. [SPEAKER_01]: In dem Fall, wenn jemand sagt, das kalliert nicht würde ich, ja sogar argumentieren, wenn man dann sagt, okay, steigere, was anderes um auf eine andere Indekstruktur, auf eine andere Library, die eine andere Indekstruktur hat, dann macht es ja vielleicht sogar Sinn.

6:27 [SPEAKER_01]: Ob man gleich ganzes Datenbanksystem auswechsen muss, ist dann noch meine andere Sache. [SPEAKER_01]: Aber wir sprechen ja auch viele über den Hauptspeicher. [SPEAKER_01]: Und da kann man natürlich vielleicht eine Implementierung durch als schneller ausdarschen und da macht es natürlich auch Sinn.

6:38 [SPEAKER_01]: Und es hilft dann in diesem Zusammenhang natürlich auch bei Indikstruktur und zu verstehen, grundsätzlich herangehensweisen, was es denn an Indikstruktur und so da draußen gibt und da werden wir halt ja auch bei machen die über den klassischen Babam hin ausgehen. [SPEAKER_01]: Aber vielleicht weil du die letzte Episode erwähnt hast, die wir zu dem ganzen Demer gemacht haben.

6:54 [SPEAKER_01]: Die Episode 260, wo wir vor allem über so Grundlagen gesprochen haben, was ist eigentlich ein Index, was macht es aus? [SPEAKER_01]: Ein Index ist ein Vertrag aus Datenstrukturen, wie du schon richtig gesagt hast, die praktirektige Datenstruktur. [SPEAKER_01]: Ich brauche einen coolen Algorithmus, möglichst niedriges O, also O von 1 ist natürlich das Kulster, kann direkt draufzugreifen.

7:14 [SPEAKER_01]: Ihr muss die Hardler mit. [SPEAKER_01]: einbeziehen, also deine Playstation 1 und an die ja, du bist schon so alt, was kann meine Hardware und heute da gehen kann die Hardware natürlich viel viel mehr, sieben die und Barallelles processigen natürlich die verschiedenen Cashläres muss mal alles mitdenken und das allerwechtigste und es ist ja was du auch immer prädigst von deiner Kanzel da oben von deiner Dibelle per Kanzel, was ist der Workload?

7:38 [SPEAKER_01]: Was suchen wir eigentlich, weil es diese Unterschied wille eine ID immer rausholen aus meiner Datenbank oder aus meinem Index oder brauche in der Range Query, wille alle Werte zwischen 3,4 und 3,8 und das sind aber Millionen von Werte, also welche? [SPEAKER_01]: Anfragen habe ich was Speiche, eigentlich ab und nur wenn ich dieses Quadrat nennt ist mal, also diese vier Punkte, der Datenstrukturen Algorithmus, Hardware und Workload.

8:01 [SPEAKER_01]: Verstehe, nur dann kann ich sinnvoll agieren und dann kann ich auch entscheiden, wach in den neue Datenbank eskaliert es nicht oder habe ich halt vielleicht nur einen Punkt angeschaut von dem ganzen und habe auf die Hardware geschaut und eskaliert halt für diese Speziale hat wenn nicht.

8:15 [SPEAKER_00]: Wobei ich ja beaufsagen muss, z.h. [SPEAKER_00]: denkt die ganze Sache nicht. [SPEAKER_00]: Baut das einfach mal, schmeißt das mal auch Produktionen schaut, wie sich das verhält und habt halt Sicherheitbarkeit drauf. [SPEAKER_00]: Das bedeutet vielleicht ein paar Meträgen, ein paar Pazentile über Request-Zeiten, Datenbankzeiten und so weiter und da sieht man relativ schnell ein paar Ausreißer oder nicht.

8:34 [SPEAKER_00]: Aber z.h. [SPEAKER_00]: denkt die ganze Sache nicht immer direkt von Anfang an. [SPEAKER_00]: Meinst achtes nach Beheut, besonders heute diesem KI-Zeit alter. [SPEAKER_00]: Baut lieber mal richtig schnell in den dreckig gewaibkodelten Prototyp evaluiert das. [SPEAKER_00]: Schön machen kann man immer noch gar keine Frage, aber hab nicht gar kein Verständnis von unseren Datenschuturen von Lesel-Schrei-Pettons.

8:55 [SPEAKER_00]: Denn wenn man meines Affen auch das versteht, kann man solche Applikation einfacher machen. [SPEAKER_00]: Was meine ich damit, man kann den ganzen Cashlayer entfernen. [SPEAKER_00]: Denn Cashings immer ein Problem, Cash-Invalidation hat immer Backs und so weiter und so voll. [SPEAKER_00]: Und ich weiß viele Leute sagen, man wird nicht bezahlt für Simplifizierung des Decks, die Leute die unkoll sind und das bist du hoffentlich selbst für dein Steck, werden dir wahrscheinlich dann.

9:17 [SPEAKER_01]: Ich möchte keine Zusehrer in dieses KI dem, als ein Dauchen, aber das gerade zwei gute Punkte gesagt. [SPEAKER_01]: AI Generated Code kann nämlich genau in diese zwei Khaben schlagen. [SPEAKER_01]: Einerseits kann er von Anfang an schon sehr gut optimiert sein. [SPEAKER_01]: Ich hatte gerade vor zwei Tagen eine SQL query, da bin ich echt lang drüber gesessen und haben gedacht, wo hat der Fak was passiert, da und sie war aber korrekt und sie verdammt intelligent und verdammt gut gemacht, aber sagt, okay cool und die macht echt viel mit SQL.

9:43 [SPEAKER_01]: Aber auf der anderen Seite hat man dann wieder so Dinge, dass es absolut zugemüllt ist und wahrzielen die kompliziert irgendwas gemacht wurde, wo man dann vielleicht Manuell eingreifen muss. [SPEAKER_01]: Es gibt durchaus beide Varianten und drum ist es gut, auch da mal ein Blick drauf zu weit von Metricken zu haben und wie die richtige Sackers.

9:59 [SPEAKER_01]: Es macht keinen Sinn der Primate Show optimisation zu machen. [SPEAKER_01]: Aber wenn man sauberemetriken hat, dann findet man vielleicht da schnell raus, okay, was ist denn bei mir langsam. [SPEAKER_01]: Und wenn ihr dann eine spezielle Funktion habe, zum Beispiel die Langsam ist, dann kann ich da eintauchen und meistens kann ich da so viel Zeit wieder rausholen, mit der einen Optimierung, dass mein ganze System 90% vielleicht schneller wurde.

10:21 [SPEAKER_01]: Und da macht es dann natürlich auch Sinn, die Zeit zu investieren, in diesen kleinen Teil, aber nicht überall automatisch immer alles mitdenken und im Vorhänden ein Schubitdenken, sondern im Nachhinein gezielt reagieren, da wo es Probleme gibt, 80, 20 Krägel, da da geht dann tief ein. [SPEAKER_00]: Ich meine, das Geile jetzt, was du in dieser Episode auch lernen willst und dann hoffentlich auch anwenden kannst, ist ja.

10:40 [SPEAKER_00]: Wenn ich sagt, Gewaibkode, meine ich nicht, mach was schnell, lieber KI, sondern du hörst sie die Episode, das haben wir was mal auf anderem, worauf wir uns ein Radix triegesprochen. [SPEAKER_00]: Wer das vielleicht was? [SPEAKER_00]: Okay, schmeiß dann klar, oder irgendwie da in Okenkode, oder was so rummein nutzt, halt einfach mal auf deine Daten, und sag mal auf, schau dir mal die Daten an.

10:56 [SPEAKER_00]: Ich möchte, dass in dieser Form lesen, wer ein Radix trie hier sinnvoll. [SPEAKER_00]: Das ist ja, dass du die KI eigentlich mit den richtigen Quellen promenst und dann einfach die verschiedene Innexstrukturen vielleicht einmal durchdängst, mag vergleichen lässt, vielleicht sogar ein Benchmark von der KI im Baun lässt, nur umgefühl zu können.

11:14 [SPEAKER_00]: Da bist du wahrscheinlich schon in einer halben Stunde, dreifelstunde relativ weit und kannst es einschätzen, ob zum Beispiel einer Indexstruktur hilft oder nicht. [SPEAKER_00]: Wer aber jetzt sagt Innex für mich kann auch noch von dir reden wollen und also richtig ist, hört euch mal ganz kurz die Episode 266 noch mal an oder wenn ihr sonst gar nicht getan und dann hört ihr euch die Heinfach an, da haben wir relativ viele Basics gemacht so die right amplifikations, diese vier sichtweisen Datruktur-Ergruppen muss hart verwirklich und so weiter das, was der Woche funktioniert.

11:42 [SPEAKER_00]: Aber lass uns mal ganz kurz in die verschiedenen Kategorien der Innekschuturen einsteigen. [SPEAKER_01]: Wie ich damals studiert habe, in den 2000er-Jahren, also sehr am Anfang von den 2000er-Jahren, da hat es immer geheißen, ja, Ram ist schnell festplatt des Langsam. [SPEAKER_01]: Also brauchen wir spezielle Indexrukturen für den Ram und für die Festplatte.

12:00 [SPEAKER_01]: Das war so die Hauptkategorisierung, die wir eigentlich damals hatten, weil es eben so stark die Unterschiede gegeben hat. [SPEAKER_01]: Die Festplatte hat sich gedreht, also für alle, die es nicht mehr wissen, [SPEAKER_01]: speichern, sondern wirklich so klassische Spinning Disks und der Rambler haltes schnelle.

12:16 [SPEAKER_01]: Um uns so gesagt hat, da hat man Random Access Memory, also man kann überall schnell zu greifen. [SPEAKER_01]: Jetzt wie wir alle wissen, hat sich das stark geändert. [SPEAKER_01]: Mittlerweile haben wir super schnelle Festplatten, die eigentlich sehr nahe an dem Ramb dran sind. [SPEAKER_01]: Wir haben auf der ZB-Useite mittlerweile teilweise vier Kerschläge, L1 bis L4, es gibt hunderte Optimierungsvarianten.

12:40 [SPEAKER_01]: also sieben die zum Beispiel, dass man mehrere Operationen parallel machen kann, auf seinem Speicher oder auf dem Registe eigentlich. [SPEAKER_01]: Man hat optimierungen Brandspritiktions, ähnliche Dinge und CPU, als es ist super, super kompliziert geworden. [SPEAKER_01]: Das heißt von den vier Punkten ist dieser Hardware Seite eigentlich wesentlich komplexer geworden und heute kann man viel mehr eigentlich mit der Hardware machen und viel mehr optimieren auf eine spezielle Hardware.

13:05 [SPEAKER_01]: Auf der anderen Seite ist eben die Festplatte so mit dem Rahmen ziemlich zusammengewachsen und heute muss man eigentlich genau drauf schauen, was habe ich für hart bei eigentlich zu Verfügung in welchem Bereich von dieser hat, bei mach ich meine Berechnungen. [SPEAKER_01]: Sind's große Datenmengen, dann weil ich trotzdem auf der Festplatte sein ist, gibt immer noch [SPEAKER_01]: Dinge, die auf der Festplatte gelten, die im Rahmen nicht gelten.

13:26 [SPEAKER_01]: Das heißt, ich habe schon Unterschiede an sich, aber es geht mehr darum, wie groß sie meine Datenmengen, wo Speichel die Abwovurt berechnet, durch welche Lehrmusik durch muss ich das von der Festplatte bis in den Register bringen. [SPEAKER_01]: Hab ich was im Rahmen gespeichert, wie funktioniert das mit dem Persistenten Speicher?

13:41 [SPEAKER_01]: So solche Dinge muss ich mir überlegen und darauf bauen, kann ich dann entscheiden, überhaupt was ich für Indikstruktur verwende. [SPEAKER_01]: Früher... [SPEAKER_01]: Was easy, bin er, baum, hat mir im Habspeicher, Bebaum, Sekunde, Speicher und die Sache hat sich erledigt. [SPEAKER_01]: Da hat man dann schon 90 Prozent der Verlängig abgedeckt gehabt.

13:58 [SPEAKER_01]: Bei sich übrigens mehr interessiert für das ganze Kerstema. [SPEAKER_01]: Wir haben eine Episode der Andy hat das mir in die Vorbereitungsnotizengeschrieben Episode 73. [SPEAKER_01]: Ich kann mir alle gesagt, persönlich kann ich mir daran erinnern, aber scheinbar haben wir eine Episode gemacht über Kaches, CPU, Assetzung, Strategien, Invalidierung und wie das alles im Inneren funktioniert.

14:18 [SPEAKER_01]: Aber es sei mir verziehen, wenn man über 250 Episode hat, dass man auch mal die eine oder andere vergesst. [SPEAKER_00]: Vielen ihm dankropper, dass du mal wieder vom Krieg erzählt hast mit diesen Raum und mit den Spinningdisk und so weiter. [SPEAKER_00]: Ja und von der Episode der 3 und 70, aber die hast du mir da eingeligt.

14:31 [SPEAKER_00]: Ja, irgendwie muss er diese Haut aufgaben hier machen. [SPEAKER_00]: Es ist also gesagt früher, weil die Frage Ramuladesk, sie fragen noch Existent, wo die Frage ersetzt oder sie fragen einfach weggefallen. [SPEAKER_01]: Also er hat schon ein bisschen angedeutet, es geht im Prinzip darum, wo läuft man Algorithmus, die Hardware und wie viele Daten habe ich natürlich zugreschmust und zu weiter und natürlich auch.

14:48 [SPEAKER_01]: Aber es sind so zwei Kernkomponenten, den großen Einfluss auf den Auswahlprozess haben. [SPEAKER_01]: Wir haben immer noch ganz klassisch Bäume als Indekstrukturen, also fast alle Indekstrukturen sind Bäume, weil die einen sich sehr gut als Indekstruktur, weil sie, [SPEAKER_00]: Logo-Rhythmisch und dann kommt es ja doch dann kommt es auf die Italien-Leutierung wir haben gleich ein Baumwisch sprechen und so weiter an.

15:12 [SPEAKER_00]: Aber ich würde sagen, wir fangen jetzt mal bei Logo-Rhythmisch an, was schon mal ganz gut ist. [SPEAKER_01]: Jetzt die Frage mal in dem Google-Perverbungsprozess übrigens gehabt, bei dem ganz anfänglichen Test und Logo-Rhythmisch ist richtig an die. [SPEAKER_01]: Also du wirst schon eine Einsprung weiter.

15:26 [SPEAKER_01]: Bäume sind immer Logo-Rhythmisch, genau weil mal bei jedem Knoten zwischen drin sich ausblitet. [SPEAKER_01]: 100-fache, 200-fache beim Benerbaum nur ist doppelt, aber auch das ist logaritmisch. [SPEAKER_01]: Bei mir den Zugraum eben immer teilt, im Idealfall mit einem möglichst hohen Faktor.

15:43 [SPEAKER_01]: Es gibt natürlich schon irgendwelche Indekstruktur, wie Bitmap Splumfilter, da kommen wir auch noch später drauf zu sprechen, aber die Hauptkategorie sind sicher Bäume. [SPEAKER_01]: Und dann ist die Frage, wie optimiere ich dem Baum auf meine Speicherstruktur? [SPEAKER_01]: Das heißt, im Rahmen oder in meinen Caches habe ich unterschiedliche Größen und üblicherweise optimiert [SPEAKER_01]: Auf dieses Zugriffsmuster im L1 Cash, L2 Cash, im Register, auf der Festplatte, je nachdem, wie viel ich gleichzeitig laden kann.

16:10 [SPEAKER_01]: Wir haben das ja auch bereits öfter schon besprochen. [SPEAKER_01]: Die CPU versucht, eigentlich mit ihr mitzudenken und macht so genanntes Prefetching. [SPEAKER_01]: Das heißt, es werden schon Daten vorgeladen, bzw. du musst da, was ihr die Daten einfach die rundherumble liegen von diesem Datensatz, den du eigentlich haben willst, die musst du einfach immer mitfetschen.

16:29 [SPEAKER_01]: Weil man kann halt keinen einzelnen Integer auf einer Festplatte lesen, sondern nur immer eine ganze Seite, die in der Memory geladen wird. [SPEAKER_01]: Das heißt, es wird prefetching betrieben, es wird etwas mitgeschickt. [SPEAKER_01]: Und wenn der Index dieses Mitladen würde es mal nennen, mitdenkt, dann kann er nur durch davon profitieren.

16:46 [SPEAKER_01]: Und Bäume optimieren genau ihre Größe, also wird es doppelt aufgesplitet, 200fach aufgesplitet pro. [SPEAKER_01]: Ast wird demensprechend auf die Größe von den Caches, von der Festplatte, von der Bage, demensprechend optimiert. [SPEAKER_01]: Und das ist eigentlich die Hauptoptimierung, die man mit so Bäume machen kann und dann unterscheiden sie sich gar nicht mehr so viel, egal ob das auf der Festplatte ist, im Rahmen oder vielleicht sonstige Optimierungen noch für die Cache leer zum Beispiel oben draufkommen.

17:13 [SPEAKER_00]: Aber eine Frage hast du mir noch nicht beantwortet. [SPEAKER_00]: Wenn ich in einem Baum von der Wurzel parallel nicht fähnndaut mache, auf all meine Kinsknoten auf dem ersten Level. [SPEAKER_00]: Und wir haben gesagt, es ist eine logaritmische Komplexität. [SPEAKER_00]: Ist es dann nicht besser, sehr viele Knoten auf dem ersten Level zu haben, weil dann der Algorithmus im Entresultat schneller wird, weil ich [SPEAKER_00]: eine geringere Tieverhabe in Baum.

17:42 [SPEAKER_00]: Also warum geht verschiedene Implementierungen, wie man den Fan Out von der Wurthelknoten macht, warum geht es ja nicht einstandert? [SPEAKER_01]: Also üblicherweise hat man den selben Fan Out. [SPEAKER_01]: Du hast vom Rutknoten 200 Kinsknoten und bei jedem Kinsknoten wieder 200 Kinsknoten, [SPEAKER_01]: drum hat man da an Lockdown von Basis 200 z.B. und das ist bei einem klassischen B-Baum, der jetzt in der normalen Datenbank verwendet wird, wenn du eine Fanat von 200 hast, was üblich ist, dann hast du auf der Ebene 3 schon 8 Millionen Nutzplatz.

18:12 [SPEAKER_01]: Das heißt, du musst nur 3 Schritte springen, um 8 Millionen Einträge überhaupt abzubilden in deinem Baum. [SPEAKER_01]: Trum ist es ja so effizient. [SPEAKER_01]: Jetzt deine Frage, warum gibt es da überhaupt unterschiedliche Verzweigungs, [SPEAKER_01]: Größen und vor allem, wenn man ja denkt, an den B-Baum ist er immer sehr verwirnt.

18:32 [SPEAKER_01]: Da B-Baum im Hauptspeicher hat er nur zwei Kindes knobben. [SPEAKER_01]: Jetzt wäre die Frage, warum habe ich überhaupt so eine und anfungszeichen schlechte Indextruktur für den Hauptspeicher. [SPEAKER_01]: Die Argumentation war natürlich früher, ich kann schnell springen in meinem Speicher.

18:47 [SPEAKER_01]: Aber ich habe natürlich auch dort Cashlines, die in der gewisse Größe haben. [SPEAKER_01]: Und das verwenden viele Indextrukturen mittlerweile. [SPEAKER_01]: Also das man da auch im Hauptspreiche nicht nur zwei Kinsknoten hat, sondern eben auch mehrere Angebast auf die Cashlines, aber man muss immer mitdenken, dass dann Trade auf der Hintersteckt.

19:03 [SPEAKER_01]: Weil das Ender an des Löschen, das hinzufügen, das kostet alles viel mehr Zeit. [SPEAKER_01]: Wenn du so eine komplexe Indikstruktur hast, wo du eben den Fanat von 200 hast. [SPEAKER_01]: Im Vergleich zu einem Genärbarm, wo man ganz einfach ein Hängen kann, super schnell die Operation. [SPEAKER_01]: Wenn ihr jetzt im Hauptsprecher ganz viele Insatz habt, abdates Änderungen in meiner Startenstruktur, dann macht es natürlich Sinn, da ein Trade-Off zu finden zwischen Komplexität meiner Innexstruktur und der Zeit, die benötigt um mit der Innexstruktur zu arbeiten.

19:31 [SPEAKER_01]: Und daher gibt es auch immer noch UseCases, die den Genärbarm wirklich im Hauptsprecher verwenden. [SPEAKER_01]: Wobei man da zusammus, der klassische Benäherbarm wird eigentlich kaum mehr verwendet, weil der nicht balanziert ist und ist übliche, was so verwendet wird, sind RedBlackTrees, AlphaLTrees.

19:47 [SPEAKER_01]: Das sind so die bisher besseren Benäher, Bäume, die balanziert sind, Barvorteile haben, dieser RedBlackTree, da wird dann jeder Knoten eingefallt und da roteknoten darf keinen roten Kinsknoten haben. [SPEAKER_01]: wird einfach da Algorithmus noch ein bisschen optimiert, damit es besser funktioniert und dessen eigentlich heutzutage so die klassischen Implementierungen von Natry Map, Inchava oder Map in in C++, da steckt im Hintergrund eigentlich immer so ein ganz einfacher in Enzmal Binärbaum dahinter bei der einfach [SPEAKER_01]: Super einfach ist, im normalen Verstnell funktioniert und für die meisten use cases eigentlich ausreicht.

20:26 [SPEAKER_00]: Den Red Black Tree, den habe ich auch noch in der Änderung, weil ich finde den, wie soll ich sagen, so pregnand vom Namen her, oder? [SPEAKER_00]: Das ist so die einzige Dachschokur, die mit Farben in Verbindung steht. [SPEAKER_00]: Und deswegen habe ich den schon irgendwie, ist ja irgendwie hängen geblieben aus der Studium.

20:41 [SPEAKER_00]: Das ist da doch mal rein springt, dass du mal wirklich gucken, okay, warum ist das Ding so knogger? [SPEAKER_01]: lässt sich mit einem Satz beantworten, der Trade-Off zwischen komplexität und Geschwindigkeit. [SPEAKER_01]: Er ist relativ schnell im Hauptschweicher und super einfach zu implementieren, ist zusätzlich noch balanziert, also balanziert heißt, dass der Baum nicht in eine Richtung hängt, weil nur ein ausgeglichener Baum ermöglicht, dass du schnell Elemente findest.

21:06 [SPEAKER_01]: Weil stell je mal in dem Baum vor, der [SPEAKER_01]: Bei der Wurzelanfängt links einen Knoten hat einen Subknoten und eine Million Knoten hängen irgendwo rechts dran. [SPEAKER_01]: Dann kann sie im Worst case sein, dass du eine Million Knoten durchwanderen muss, um einen Element zu finden.

21:21 [SPEAKER_01]: Weil der eben so rechtslastig ist und darunterhängt, komplett auf der rechten Seite. [SPEAKER_01]: Darum versucht man immer an balenzierten Baum zu machen, der ausgeglichen ist zwischen links und rechts von den Kinderknoten, damit man eben da dementsprechend auch schnell suchen kann. [SPEAKER_01]: Danach, dann zu balanzierten Bäumen, ist natürlich, dass sie balanziert werden müssen.

21:39 [SPEAKER_01]: Das heißt, wenn du irgendwie in Ungleichgewicht hast, dann musst du diesen kompletten Baum adaptieren, um ändern, Knoten umhängen und das kostet dann dementsprechend auch wieder. [SPEAKER_01]: Und da verhält sich der Red Black Tree eigentlich im Trade-Off sehr gut und wird darum, so as standard Implementierung verwendet, für alles was irgendwie studiert sein muss.

21:57 [SPEAKER_00]: Zu Vorbereitung, dieser Episode, habe ich mir gedacht, okay, der Wolfgang, kommt bei dem seinem Doktor-Wissen um die Ecke von irgendwelchen Professoren mit irgendwelchen Slides, erklärt mir einen von Trade-Off. [SPEAKER_00]: Und um Ende habe ich immer noch keine Ahnung, wo ich das implementiere.

22:11 [SPEAKER_00]: Deswegen habe ich mir einfach mal ein realen praktischen Juskes ausgesucht. [SPEAKER_00]: Der Webserware Engine X-Implementiert nämlich auch den Red Black 3 und zwar Nummer ganz kurz. [SPEAKER_00]: Engine X selbst ist bzw. läuft in einem großen Event-Blob. [SPEAKER_00]: Er kriegt natürlich Konnexionsreien, er rattet Pekonexions und eigentlich hat jede Konnexion ja einen Read Event und einen Write Event.

22:33 [SPEAKER_00]: Also man ließ die Konnexion und Engine nichts macht dann irgendwas oder der abstremen proxy macht dann irgendwas und dann wird irgendwas auf die Konnexion wieder geschrieben. [SPEAKER_00]: Und [SPEAKER_00]: Jedes dieser Schreib oder leese Events hat selbst oder ist selbst ein Red-Black-Tree-Knoten mit verschiedenen Timeouts und Unterknoten.

22:52 [SPEAKER_00]: Denn all diese Timeouts, Klein-Timeout, Server-Timeout, TLS-Timeout, upstream-Proxy-Timeout und so weiter uns vor, die müssen ja gemennenschwerden, da muss auf reagiert werden, da teilweise muss was blockiert werden, wenn man auf irgendwas wartet und so weiter uns. [SPEAKER_00]: All diese Timeouts werden in Red Black Tree selbst geminnetscht.

23:12 [SPEAKER_00]: So mit kann man eigentlich sagen, dass der Red Black Tree selbst war in GeneX so ein Bund gemischt erhaufen von allen offenen Deadlines von allen Verbindungen von allen Red Ride Events und zu weiter des einzelnen Engine X-Workers sind. [SPEAKER_00]: Dann kannst du sagen, okay, der linkeste Knoten ist immer die nixfällige Deadline und um so weiter und so rechts geht es, erhöht sich das Delta zwischen dem nächsten Timeout und so weiter und so fort.

23:34 [SPEAKER_01]: Und da sieht man schon, dass es ein perfekter UseCase ist, weil du hast ganz viele Connections üblicherweise bei Entschulden, also 1.000er-100.000er Connections dann multipliziert mit den Timeouts. [SPEAKER_01]: Also sehr viel, was ich auch schnell ändert, weil Connections sind ja meist nicht so lange lebe, ich muss warten, also ist extrem viel traffic right last auf diesem Baum und er muss zu dir sein.

23:57 [SPEAKER_01]: Und da eignet sich dann natürlich genau so den Hauptspeicher Index perfekt. [SPEAKER_01]: Wenn man das ganze jetzt auf der klassischen Sekundärspeicherseite betrachtet, da gibt es nur durch den klassischen Bebaum, dem man auch so immer lernt. [SPEAKER_01]: Wenn man irgendwann mal Datenbank studiert oder so, der Bebaum ist so der klassiker wird auch immer und überall noch verwendet.

24:16 [SPEAKER_01]: Wobei man ja genau sagen muss, das ist auch kein klassischer Bebaum mehr, sondern ein Beblussbaum oder es gibt ein Cash-Censitive B-Blast-Tree. [SPEAKER_01]: In CSB plus tree, das sind eher so die Dinge, die heutzutage verwendet werden, aber die passieren natürlich alle auf dem klassischen Bebau.

24:33 [SPEAKER_01]: Und wenn man Feinaut von Zweihatt im Hauptspreiche bei einem Binärbau, dann hat man beim Bebau einen sehr viel höheren Feinaut pro Knoten. [SPEAKER_01]: Das heißt man hat da üblicherweise 200 bis 400 Kinder Knoten, um [SPEAKER_01]: Eben den Zugrahmen möglichst stark aufzuteilen und dann hat mir eben auch ein Loggerismus zu Basis 200 im Endeffekt und bekommt ganz viele Knoten pro Ebene unter.

24:57 [SPEAKER_01]: Und darum ist der Beber im Einwächst so stark. [SPEAKER_00]: Wie plus Baum ist das Plus dann die Enterprise Version für dich dann mehr zahlen muss? [SPEAKER_00]: Oder wo für ist das Plus? [SPEAKER_00]: Ist Plus wirklich besser als der normale Beberum? [SPEAKER_01]: Es ist einfach eine Weiterentwicklung der Billbluesplem und der Billbluesplem und der Billbluesplem der Billbluesplem, der heute da gegeben anwendung findet.

25:14 [SPEAKER_01]: Ist eigentlich nur ein kleiner Unterschied beim klassischen Bebauen werden die einträge selbst, also die Zeilen von der Datenbank der Beile zum Beispiel in den Knoten gespeichert, jetzt nehmen wir den natürlich viel Platz weg, wenn du da diese ganze Zeile reinspeichert. [SPEAKER_01]: Was der Billbluesplem macht, ist, erlegt die ganzen Daten separat in den Blättern, also ganz unten im Baum.

25:34 [SPEAKER_01]: ab, damit du in den Knoten nur das Feld hast, auf das dein Index passiert, also die ID zum Beispiel. [SPEAKER_01]: Du speichest nur die ID, die Kunden, Nummer zum Beispiel in den Knoten, aber wieder ein Kunde heißt, ist dann ganz am Ende in den Blättern gespeichert und so bekommst du noch mehr in einen Knoten unter und das ist ja die Idee, dass der Knoten möglichst [SPEAKER_01]: deinen Zugraum separiert und den Knoten sollte eigentlich so groß sein wie eine festplatten Seite.

26:00 [SPEAKER_01]: Also diese Block, der immer von der festplatte geladen wird, egal wie viele du brauchst und muss immer diese ganze festplatten Seite laden, es probierst du deine Knoten genauso groß zu machen wie die festplatten Seite. [SPEAKER_01]: Und das macht der B-Blus beim einfach noch mal effizienter.

26:14 [SPEAKER_01]: Und darum wird der heute eigentlich überall eingesetzt. [SPEAKER_01]: Und der Cash-Sensitive B-Blast-Tree, also der C-SB-Plast-Tree, den ich ganz am Anfang auch erwähnt habe, der passt sich jetzt ganz speziell auf die Cash-Krösen noch mal an. [SPEAKER_01]: Das heißt meine Knoten werden so gewählt, wie groß meine Cash-Line sind, weil der dann auch wirklich im Hauptspeicher.

26:33 [SPEAKER_01]: anwendung findet. [SPEAKER_01]: Also nicht nur auf der Festplatte, sondern auch in meinem Hauptspreche und da sollte der Knoten dann genauso groß sein wie eine Cashline oder ein Vielfaches von der Cashline möglichst viele Elemente, die in irgendeinem Form zusammengehören, wie eine Kundennummer, die da gibt's halt Blackhead die zusammengehören, die Kundennummer 11 sollte neben 10 liegen und nicht neben 3460.

26:55 [SPEAKER_01]: Das heißt man studiert das richtig und probiert dann möglichst viel in eine so eine Cashline rein [SPEAKER_01]: Also auch dieser Klassiker, wo man sagt, der klassische B-Bahm ist nicht geeignet für den Hauptspeicher, stimmt, aber mit einem Cash-Sensitive B-Blast-Trade zum Beispiel schon und darum werden dann auch B-Bäume im Hauptspeicher durchaus angewendet und halt so da sind ja sehr viele Datenbanken überhaupt nur im Hauptspeicher, diese klassischen Hauptspeicher-Datenbanken wie eine HANA zum Beispiel von SAB, die ja sehr früh damit begonnen haben.

27:24 [SPEAKER_01]: Und die verwenden dann natürlich auf dem entsprechend angepasst der Bebeume, die auf den Hauptspeicher optimiert sind. [SPEAKER_01]: Und das klingt immer so komplex, aber im Prinzip die Hauptoptimierung liegt einfach in der Größe von so einem Knoten. [SPEAKER_01]: Weil da rest wird dann von der Hardwerk machen.

27:39 [SPEAKER_00]: Bäume Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume, Bäume [SPEAKER_00]: Und zwar habe ich immer, wenn ich Bäume höre, komplexe Datenschuckfuren im Sinn, komplexe Implementierung im Sinn.

27:58 [SPEAKER_00]: Und deswegen bin ich ja in der Hafen Freund der Einfachen sagt, ja. [SPEAKER_00]: Immer wenn ich nämlich ein Indekstrukturendekte, denke ich an den Herschendekst. [SPEAKER_01]: Worauf am Ende ist du denn? [SPEAKER_00]: Na ja, ja, ja, ja, ja, jede Kurmeersprache, ja, irgendwie eine Art von, ich sag mal, Herschmepp.

28:11 [SPEAKER_00]: Wenn man sogar, mein PRP ist es ein Erre, hatte ich glaube, ich schon mal irgendwann erwähnt hier, wo du eigentlich ein Kie und dann eine Schruppur drunter hast. [SPEAKER_00]: Ja, aber wer ist das an der Herschmepp? [SPEAKER_00]: Keine Typengradin-Rust nicht, aber ich würde sehr wohnen, wenn Rostkelle Hechbevette.

28:26 [SPEAKER_01]: Genau, auch da wieder ganz easy wird im Hauptspeichel ganz klassisch verwendet. [SPEAKER_01]: Gibt's in allen Programier-Sprang gibt's auch in Datenbanken. [SPEAKER_01]: MySQL hat er immer den Hash Index, dem man auf verwenden konnte, keine Ahnung, ob der Dapplicated ist. [SPEAKER_01]: In der Realität wird der kaum in Datenbanken eigentlich verwendet.

28:41 [SPEAKER_01]: Weil er den großen Nachdel hat, das dieses Ding eigentlich nur punkt. [SPEAKER_01]: abfragen, gut behandeln kann. [SPEAKER_01]: Das heißt, ich habe eine ID, will genau diesen einen Kunden haben, Kunden Nummer 5 und dann will ich die Daten haben. [SPEAKER_01]: Das heißt, einsprung im Hauptspeicher zu dem richtigen Datensatz, gibt mir das Ganze.

29:00 [SPEAKER_01]: Jetzt ganz klassisch in Datenbanken oder wenn man viele Daten processen will, dann will man meistens nicht nur einen Datensatz haben. [SPEAKER_01]: Ich mache eine Range Query, gibt mir alle Kunden in Deutschland, die weiblich sind, die von dem Gewissen, die in dem Gewissen alterspektrum sind und da will ihr irgendwas rausfinden.

29:18 [SPEAKER_01]: Und für solche Anfragen sind Hesh in die Zess ein Verschlächt geeignet, weil es eben so ein klassischer Sprung ist. [SPEAKER_01]: Das ganze passiert ja auf einer Heshfunktion, das heißt eine Funktion bekommt irgendein. [SPEAKER_01]: Kundenummer zum Beispiel und im Hintergrund wird es dann gemäbt auf eine Speicheratresse.

29:33 [SPEAKER_01]: Die einfachste Form einer Implementierung, die man mal gerne verwendet, ist Modulo. [SPEAKER_01]: Das heißt, ihr habt einen Speicherbereich von Kanernung, 100 oder 200 Einträgen, die Platz habt, dann mache in den Modulo-Funktion Modulo 200, nimmt die Kunden ID Modulo 200, weiß ihr, wo ihr das Ganze hinsetzen soll in meinem Speicher.

29:51 [SPEAKER_01]: Wenn ihr die Kundenummer 250 habt, Modulo 200, [SPEAKER_01]: Landet es beim Index 50. [SPEAKER_01]: Das ist super einfach. [SPEAKER_01]: Gibt es natürlich auch komplexer Werhäschfunktionen? [SPEAKER_01]: Kann man teilweise auch selber festlegen, die Häschfunktionen, aber super einfach super schnell zu berechnen, weil diese Funktion am Modolo-Berechnung ist super schnell und die bekommt direkt die Speichertresse.

30:12 [SPEAKER_01]: Also ganz einfachestruktur, aber eben nur vier Punkte an Fragen und keine Range queries, um E-Aso im Hauptspeicher oder im klassischen Kodding anzutrefft. [SPEAKER_00]: Ich mein Modolo ist ein bekanndes Beispiel hat sich schon erwähnt, MD5 auch sehr schnell wird es nicht für irgendwelche Passpörter zu nutzen bitte aber für so eine Hashmap und so weiter eigentlich total super oder ein short MD5 mit mit 16 characters hat es schon 32 aber immer wenn ich über Hashes spreche, kommen wir auch immer diese theoretisch oder vielleicht auch praktischen Angriffen von Hash-Kollisionen in sie wie geht denn so eine Hashmap mit Hash-Kollisionen um?

30:45 [SPEAKER_01]: Die Türke legt dem Detail und besonders per Dahesche Implementierung, weil klassischerweise heißt es ja immer der Hessch hat O von 1. [SPEAKER_01]: Weil du eine Eingabe wert hast, eine Speikertreise rausbekommst, O von 1. [SPEAKER_01]: Super gute Komplexität sollte ihr super schnell sein.

31:03 [SPEAKER_01]: Da stellt sich übrigens auch die Frage, wenn das zu schnell ist, worum kann ihr das nicht dann eine Range Grill machen, ich kann ja fünf, all dies anfragen, aber ich muss das ganze halt fünf mal ausführen. [SPEAKER_01]: Also rein von der Ohneutation, fünf mal eins ist zwar immer noch konstantes Beat, aber in der Realität, wenn ich halt fünf, 1000 mal eine Anfrage mache.

31:21 [SPEAKER_01]: Und die auch sehr schnell ist, punktabfrage ist es halt trotzdem 5.000 mal sehr schnell und das ist dann vielleicht schon wieder langsam. [SPEAKER_01]: Nur weil etwas Ofon 1 ist, heißt es nicht, dass es für jeden Anwendungszweck funktioniert und wie du sagst das andere Problem ist, wenn mein Speicherbereich in dem ich eigentlich die Dinge ablege oder berechnen mit meiner Hashfunktion, wenn dieser wesentlich kleiner ist, [SPEAKER_01]: als die Anzahl der Elemente, die ich habe.

31:44 [SPEAKER_01]: Oder meine Herstfunktion einfach schlecht gewählt ist, dass sie ganz viele verschiedene Elemente immer auf diesem selben Speicher oder Lägenbild. [SPEAKER_01]: Weil dann bekommen wir diese Koalition und dann muss ich irgendwas mit dieser Koalition machen. [SPEAKER_01]: Üblicherweise gibt es da Verkette der Listen, die da dran gehängt werden.

31:59 [SPEAKER_01]: Oder vielleicht eine Unterindekstruktur, dass sie, wenn die gleiche Speichertresse mätbeld, dass sie da dann in irgendeiner Formen 9 Index dran hängen, indem wir dann wieder suchen. [SPEAKER_01]: muss aber das Problem besteht, dass im Burstcase bei der klassischen Implementierung natürlich sein kann, dass alle meine Elemente genau am selben Ort landen und die dann einfach eine Ertverkette der Liste dort habt und die muss durch 1000 Elemente durch obwohl die zuerst einen super schnellen Sprung habt, aber dort liegen halt 1000 Elemente und die muss wieder durch alle 1000 Elemente durch und da degradiert [SPEAKER_01]: Dann mein Speed natürlich extrem und von dem muss ich mir immer verhanhalten, drum sagt man so üblicherweise eine Hashmap sollte nur drei, vier, vier gefüllt sein und man sollte die Größe dann dem entsprechend adaptieren.

32:38 [SPEAKER_01]: Meistens gibt es da auch ein Parameter, wenn man programmiert, ab wann soll die Hashmap vergrößert werden. [SPEAKER_01]: Das Speichebereich dahinter, weil da muss ja alles umorganisiert werden. [SPEAKER_01]: Wenn ihr jetzt in Modulo habt, zum Beispiel muss das alles neu berechnet werden, wolegen meine Elemente kostet dem entsprechend wieder Zeit, will ihr ihn natürlich verhindern.

32:53 [SPEAKER_01]: Da gibt es dann Unterschiede in der Implementierung glücklicherweise, wenn man eine klassische Implementierung verwendet, in der Programmiersprache, der Wahl, dann wird es im Hintergrund meistens weg abstrahiert und gemanetscht. [SPEAKER_01]: Aber wenn einmal eine Hashmap super langsam sein sollte, kann so was durchaus der Grund sein.

33:10 [SPEAKER_00]: Und immer wenn man die Hashmap selbst reorganisieren muss, wie der Wolfgang gerade gesagt hat, dann nehmen wir das Recycling, also vergrößern und so weiter, oder halt auch vor Klannern. [SPEAKER_01]: Mit Ziegen solls ja auch Ruby Hashchen, je nachdem, was wir für eine Hashfunktion hat, dass man wirklich alle Speicherauten noch mal neu berechnen muss.

33:25 [SPEAKER_01]: Also man muss wirklich durch alle meine Elemente durchgehen, immer wieder in Hashbilden schauen, hat sich der verändert, muss ja irgendwas umspeichern. [SPEAKER_01]: Super teuer an natürlich. [SPEAKER_00]: Super teuer, vielleicht sogar Stop of the World, für deine Applegation, vielleicht machst du das irgendwie einen Background threat, aber dann ist der Zug auf diese Datenschruktur ja auch irgendwie gehindert.

33:41 [SPEAKER_00]: Redis hat dafür eine sehr schönen Plimentierung. [SPEAKER_00]: Deswegen mag ich Redis ja, das wissen wir ja. [SPEAKER_00]: Eine Episode ohne Redis will ich mal erleben. [SPEAKER_00]: Aber... Redis hat halt ein Detail implementiert, was im Lehrbuch oft erwähnt wird, aber in der Praxis oft fehlt und zwar nett sich das im Kriminal re-hashing.

33:58 [SPEAKER_00]: Was die tun ist, [SPEAKER_00]: Unten drunter für ihr der Hashmap, wenn Tain die eigentlich zwei Hashtabellen. [SPEAKER_00]: Und wenn die erste Hashtabelle, ich sag mal, den Riesal sind guterzogen werden, muss dann würde das eigentlich so stopp auf sowohl bedeuten, die wird neu berechnen und so weiter.

34:11 [SPEAKER_00]: Was die eigentlich machen ist, immer wenn auf die Hashmap zugegriffen wird, also das bedeutet wenn nun ätter und die Lied oder dann fein von deinem Element macht, dann verschieben die ein Element oder ein Bucket in die zweite Hashmap. [SPEAKER_00]: Das bedeutet, die [SPEAKER_00]: ziehen das Recycling eigentlich über die Stretchen, die die Stretchen das Recycling eigentlich über eine gewisse Zeit und sind dann natürlich nicht einmal ganz teuer, sondern kontinuierlich immer so ein bisschen teurer, also mit einem Minimal Overhead.

34:43 [SPEAKER_00]: Und das finde ich natürlich schon eine sehr schöne Lösung, weil ich sag mal, dass versucht die Trade aufs irgendwie so ein bisschen zu geländen. [SPEAKER_00]: In anderen praktischen schönen USK ist der nicht gefunden, habe es wo man eigentlich zum Beispiel eine Hashmap einsetzen würde, oder ein Hash Index einsetzen würde, ist stellte vor, du hast einen Allerting System, der kriegt natürlich dauerhaft alleurts und soll ich dann anrufen oder Page oder ähnliches.

35:07 [SPEAKER_00]: Und ab und zu ist man ja zum Beispiel an dem Sörbe am Arbeit. [SPEAKER_00]: Das bedeutet, ich habe da jetzt irgendwie meine Datenbank und wir wissen, dass Obstim macht der Raddatenbank mit Hähnens und da kann das mal sein, dass dann irgendwelche Allös fliegen. [SPEAKER_00]: Deswegen hat meist jeder Allös-Manager oder hier das Allös-Ting-Tul irgendwie so eine Funktion macht diesen Allös mal leise, also Seilenz zu den Mal.

35:29 [SPEAKER_00]: Und das ist natürlich perfekt für so ein Hash-Index. [SPEAKER_00]: Du hast an den Allörtnahmen den Packs, du als Key in die Hash-Map und sagst, als Value dann 1 zum Beispiel. [SPEAKER_00]: Und wenn der Allörtrein kommt in das Allörting-System, dann guckt das Allörting-System, habe ich diesen Allört in meiner Zusei-Lenzen-Liste, wenn ja dann Verwerfer den Allört und Feuer, den nicht rauspage, den Wolfgang nicht.

35:53 [SPEAKER_00]: Das ist so zum Beispiel ein ganz einfacher Use-Kes, [SPEAKER_00]: Herschmal oder Herschindig. [SPEAKER_01]: Jetzt weißt du, was das schöne ist an AI, man kann nebenbei, während du sprichtst, mal so Sachen über Priffen lassen. [SPEAKER_01]: Ihr habt es leider nicht 100% die Gras gefunden, ob Redis sehr früh dran war.

36:10 [SPEAKER_01]: Sie waren zumindest nicht spät mit der Implementierung, aber das wird die vielleicht noch mehr freuen, so wie es aussieht, war das erst 2013 und GO hat der schon 2012 an die. [SPEAKER_01]: Und schar war kam dann über das 2014. [SPEAKER_00]: Ich habe jetzt nicht geguckt, werher das kommt, was ich aber weiß ist, dass der Auto von Redis und auch die Köpfe hinter Go, Rob Pike und Coen natürlich sehr, sehr, sehr, sehr viel Paper ist.

36:34 [SPEAKER_00]: Und das auf der anderen Seite auch die Köpfe hinter Go, sehr viel im Cooperative Programming unterwegs waren, das würde heute die haben auch. [SPEAKER_00]: unglaublich gute Fundamente, was Algorithmen, Performance und Koan geht. [SPEAKER_01]: Man muss sich das Ganze ja nur anschauen, wo das eigentlich ein Problem wird und zwar wenn du ganz viele Daten hast.

36:53 [SPEAKER_01]: Das hast du halt klassische Weise in der Datenbank Welt oder Klargo-Google hat wahrscheinlich auch sehr viele Daten. [SPEAKER_01]: Wenn du eine kleine Hashmap hast mit 200 Einträgen ist es komplett egal. [SPEAKER_01]: Aber wenn du natürlich Millionen von Einträgen hast, dann wird es schon dem man muss ich meine [SPEAKER_01]: Um irgendwas zu ändern oder zu Reciessen und dann ist es natürlich ein ganz anderes Thema.

37:14 [SPEAKER_01]: Darum haben die Datenbankentwickler in der natürlich vielmehren Augenmerk auf solche Dinge natürlich auch gewaufen. [SPEAKER_01]: Und das sind klassisches Problemen, wenn du ein Index updatest. [SPEAKER_00]: Eine Gefahr, die ich euch auch mitgeben möchte, weil die wird oft übersehen. [SPEAKER_00]: Wenn du eine Häschfunktion hast, um dein Index zu bauen.

37:31 [SPEAKER_00]: Pass bitte auf, welche Häschfunktionen du nutzt. [SPEAKER_00]: und welchen Content du hesschen möchtest? [SPEAKER_00]: Warum? [SPEAKER_00]: Es gibt Herschfunktion, die eine komplizitätsalgorithmus von O von N oder vielleicht sogar höher haben. [SPEAKER_00]: Das bedeutet, dass die Länge des Contentes, die du da hesschen möchtest, teilweise auch auf die Dauer der Herschfunktion schlagen kann.

37:52 [SPEAKER_00]: Wenn du also einmal die Bibel, [SPEAKER_00]: Durch eine Hechfunktion hierax, dann wird das in der Regel länger dauern, als wenn du den Namen Wolfgang Hechchen möchtest. [SPEAKER_00]: Und wenn du jetzt nicht nur einmal die Bibel machst, sondern sehr oft die Bibel. [SPEAKER_00]: Und wenn du nicht nur einen Request sendest, sondern so viele Request wie es Kirchen auf dieser Welt gibt.

38:11 [SPEAKER_00]: Da kann das sein, dass nur durch die Hechfunktion eine Dine auf Service-Attack ausgeführt wird, weil die Hechfunktion so teuer ist, weil du einfach dauerhaft versucht, einen sehr großen Kondezöcheln. [SPEAKER_00]: Das ist ein gängiger, angeres Faktor bei Lock-Informularen. [SPEAKER_00]: Du knallst einfach ein unglaublich langes Passbrot da rein, also wirklich so 500-mal Liebe.

38:33 [SPEAKER_00]: Und auf einmal merkst du, der Server braucht enorm lange zum Antworten. [SPEAKER_00]: Dann weißt du, du hast da was getroffen. [SPEAKER_00]: Das ist eine Timingartakke und das funktioniert natürlich überall, wo du eine suboptimale Herschwunktion gewählt hast. [SPEAKER_00]: Deswegen ein bisschen aufpassen, was in der ALS-Kie versuchst zu häschen und welche Funktionen habt.

38:51 [SPEAKER_01]: Einen kleinen Baum ausflugt, möchte ich noch machen und zwar den sogenannten Tri-Geschrieben TREE-E-E. [SPEAKER_01]: Also Tri, aber aussprechen tut man so üblicherweise Tri, kommt von Retrieval, Information Retrieval, Text Retrieval. [SPEAKER_01]: Und jetzt befinden wir uns schon in dem ganzen Bereich von Text, Suche, Strings, Suche, weil der klassische B-Baum, der wird der üblicherweise mit Intetches, [SPEAKER_01]: gefüllt, man kann natürlich Text auch genauso reinstecken, aber es gibt natürlich Bäume, die optimiert sind für Text, weil was ist das größte Problem mit Text an die, die sind scheiße zu vergleichen.

39:25 [SPEAKER_01]: Ja, das auch und was damit zusammenhängt, dass sie scheiße zu vergleichen sind, ist die Größe. [SPEAKER_01]: Text hat einfach viel mehr in der Tröverde im Hintergrund als eine Zahl, ist halt üblicherweise einfach lang. [SPEAKER_01]: Und das ist eigentlich immer das Problem, wenn man indeksbaut, weil indeks ist ja immer in Öntnerfung eine Kobi oder ein View auf die Daten, das heißt man muss was du blitieren.

39:46 [SPEAKER_01]: Wenn man jetzt Text du blitiert, ist das üblicherweise ein Problem, weil es einfach viel Speicherplatz braucht. [SPEAKER_01]: Und dann auf dem entsprechenden Langsam wird. [SPEAKER_01]: Da Try ist in gewisser Weise vergleichbar mit einem B-Bauen, ist halt auch ein Baum. [SPEAKER_01]: Da Unterschied ist, du hast jetzt keine Zahl auf den Knoten, sondern du hast einen Buchstaben.

40:04 [SPEAKER_01]: Und du trenst, je nachdem ist es ein Buchstabe, der weiter vorne im Alphabet ist, weit dahinten im Alphabet und so werden deine Kinderknoten aufgeteilt. [SPEAKER_01]: Also das ist die recht, naiv erhangen, gehen zwei, sie machen ein klassischen Baum, verwendet halt Buchstaben für meine Elemente.

40:19 [SPEAKER_01]: Es waren diese Bäume natürlich sehr, sehr groß und darum hat man natürlich auch optimierungen draufgelegt. [SPEAKER_01]: Betrische try zum Beispiel ist so eine, wo man dann zum Beispiel substrings die Gemeinsam in Wörtern vorkommen, dass man die in einen Knoten liegt. [SPEAKER_01]: Also wenn du jetzt zum Beispiel Engineering Kioskust, Engine, Engage.

40:39 [SPEAKER_01]: End large, whatever it is, dann hast du das ENG oder EN, hast du zum Beispiel als Entscheidungskriterium auf einem Knoten liegen und alles, was den selben Sub-String hat, wird da dann demen sprechen gemeinsam abgespeichert. [SPEAKER_01]: So Spaß du dir natürlich Buchstaben, weil sonst müsstest du bei E-Springen, bei Endspringen, bei G-Springen, bei E-Springen und hättest immer neuen Knoten.

41:05 [SPEAKER_01]: Mehrfach vorkommen, in verschiedenen Wörtern auf einen Knoten. [SPEAKER_01]: Das ist so eine Optimierung, heißt eben auch Radix-Tree, adaptive Radix-Tree. [SPEAKER_01]: Gibt es noch mal, der der Dementsprechend noch mal mehr drauflegt und adaptiert. [SPEAKER_01]: Also man sieht schon, die Bäume sind eigentlich alles sehr, sehr ähnlich aufgebaut.

41:20 [SPEAKER_01]: Es ist nur die Frage, was Speichel ich in den Knoten ab, wie groß die Seine so ein Knoten, was sie meine Kriterien, um zu entscheiden, springen in der Flingsrechte in der Mitte, zu einem Kinder Knoten und das sind eigentlich die Einsägen. [SPEAKER_01]: mit logaritmischer Komplexität ist eigentlich immer vorhanden und ist eigentlich so Basis von fast jedem Index.

41:41 [SPEAKER_00]: Das Beispiel, was du erkennt, ist das passt eigentlich sehr gut für mein praktisches Beispiel, denn wo wird nen TRI oder nen Radix schie eigentlich verwendet? [SPEAKER_00]: Und zwar findet der sich wirklich wirklich oft in Routingleiberis. [SPEAKER_00]: Also ich sag mal, in hat der TP-Route oder in nicht so full web Applikation, denn die meisten web frameworks haben irgendwo eine Definitionstelle, wo du da eine Ruten definierst.

42:08 [SPEAKER_00]: Engineering Kiosk.dev, slash podcast, Engineering Kiosk.dev, slash podcast, slash episodeentitle, Engineering Kiosk.dev, slash impressome, Engineering Kiosk.dev, slash host, slash Wolfgang und [SPEAKER_00]: Und die Match on slash host, slash Wolfgang, slash host, slash Andy, das Wort host ist doppelt, kann ein Knoten sein.

42:31 [SPEAKER_00]: Also hat der TPP-Roten, besonders dynamische hat der TPP-Roten, wo du zum Beispiel dynamische Elemente, als wie zum Beispiel in den Episodeen, Titel, wie zum Beispiel irgendwelche Gettparameter vielleicht sogar, die damit einfließen können, perfekt eigentlich in einem solchen Tree, in anderen solchen Tri-Schuldigung.

42:49 [SPEAKER_00]: Es ist ja auch ein Tree. [SPEAKER_01]: Ist ja okay, Tri Tree. [SPEAKER_01]: oder Patricia, da ist es wieder try, es ist schwierig, aber am Ende ist es immer ein Tree, das recht ist gut, es ist beispielsweise was du netzt, jeder der wie es Code verwendet, kennt es auch, wenn man den Ordner hat, wo nur ein anderer Ordner ist und keine anderen Ordner oder da da in liegen, dann werden zwei Ordner zusammengefasst und auf eine Ebene gezogen.

43:12 [SPEAKER_01]: Das heißt, du siehst dann nur Ordner, Slash, Sup Ordner und du kannst es gar nicht aufklappen. [SPEAKER_01]: Es wird zusammengezogen. [SPEAKER_01]: Das ist eigentlich die Vorgehensweise, was ein Radix Tree aufmacht. [SPEAKER_01]: Also ist eigentlich logisch, wo die Versagen, wenn man auf solche Dinge blickt.

43:25 [SPEAKER_01]: Aber wenn man das natürlich dann demensprechend implementiert und optimiert, implementiert, steckt schon da mehr dahinter. [SPEAKER_00]: Du kannst die ganze Sache natürlich auch in der Hechweb fahren. [SPEAKER_00]: Dann hast du aber wieder die Duplikation von den URL-Pre-Fexten, dann hast du gegebenenfalls Problem mit dynamischen Parametern und so weiter und so fort.

43:43 [SPEAKER_00]: Deswegen bei sehr, sehr vielen Hattet-Perootern wird das verwendet. [SPEAKER_00]: Und ich hab euch mal einen Hattet-Perooter Library in Go verlinkt, die sogar in der Read-Nie da tiefer drauf eingeht, wie bzw. warum dieser Try in der Implementierung verwendet wird. [SPEAKER_01]: Und was ganz klassisch immer im Vergleich zu einer Hesch Map oder zu einem Hesch Index ist, du kannst auch da wieder keine Range queries fahren.

44:07 [SPEAKER_01]: Weil so bekommst du nur durch total easy, gibt mir alle Unterseiten vom Engineering Kiersk. [SPEAKER_01]: Das ist ein Knoten, der Engineering Kierskpunkt darf Knoten und alles was da runter liegt, sind die Website. [SPEAKER_01]: Eine super schnelle Anfrage, macht es mal mit einem Hash Index, hast du gar keine Chance, da musst du durch deinen kompletten Datenstamm durchgehen, weil der Hash Index eben nur punktuell funktioniert, wenn du genau weißt, was du suchst.

44:29 [SPEAKER_00]: Okay, Bäume, Bäume, Bäume, Bäume, Bäume sind super gar keine Frage, aber mein Vater war ein Gärtner und was machen Gärtner, Gärtner zwischen Blumen und was hast du vorhin erwähnt, den Blumenfilter, wo es jetzt ist am Hang da? [SPEAKER_01]: Ihr seht schon, du hast ein Problem mit Bäume, du hast ja schon auf den Hatch Index übergeleitet.

44:45 [SPEAKER_01]: Jetzt leitest du auf den Plumfilter über. [SPEAKER_01]: Grundsätzlich gibt es natürlich auch ganz viele Innexstruktur und die keine Bäume sind. [SPEAKER_01]: Der Bitmap Index ist auch so einer. [SPEAKER_01]: Und der Bitmap Index ist noch ein Index im Gegensatz zum Plumfilter, drum heißt da auch eine Plumindex oder Plumfilter.

44:59 [SPEAKER_01]: Aber starten wir immer kurz beim Bitmap Index. [SPEAKER_01]: Der Bitmap Index ist eigentlich nichts anderes als eine große Bitmaske. [SPEAKER_01]: kennt man ja 0 1 0 1 0 1 0 oder der war. [SPEAKER_01]: Und am besten funktioniert der, wie der Name schon sagt, bei Binären, Feldern, z.B. [SPEAKER_01]: Aktiv, nicht aktiv.

45:15 [SPEAKER_01]: Und die Speichheit ist einfach anstatt. [SPEAKER_01]: Diese ganze Tabelle in irgendeine Form abzuspalten oder im B-Bauen speicheln wir einfach eine lange Kette von 0 und 1. [SPEAKER_01]: 0 ist inaktiv 1 ist aktiv. [SPEAKER_01]: Und dadurch bitz. [SPEAKER_01]: Ihr super schnell verarbeitbar sind, kann in der auch relativ schnell durchgehen und sagen, find mir alle aktive Zeilen einträge, die ich gespeichert habe.

45:36 [SPEAKER_01]: Also lässt es ein Bitmap Index, hat gar nichts mit Bäumen zu tun, ist aber natürlich limitiert, weil im Idealfall es es binäher oder im Ustern für... [SPEAKER_01]: Jede Ausprägungen in eigenen Bitmap Speichern, also wenn jetzt zum Beispiel ein Status von dem Dickensystem haben, offen, Open-Closed, abgelehnt oder nicht nachvollziehbar, da muss wir für alle, die offen sind, ein Bitmap Index machen, für alle, die geschlossen sind, ein Bitmap machen und für alle abgelehnten, auch ein Bitmap, abspeichern, also da wird's dann schon komplizierter.

46:07 [SPEAKER_01]: Einen sich aber natürlich super, um diese ganzen Performance-Vorteile, heute da geht von den CBOs auszunitzen, CMD, Single-Denstraction-Malty-Beldäter, zusätzlich ist das natürlich sehr blatschbar wend, das heißt es kann auch wieder schnell optimiert weil es liegt alles hintereinander, das heißt die kann es so richtig schön einmal durch die CBO durchpipen und was man auch oben drauf knallen kann, auf diese Bitmap, Indextruktur ist eine Komprämierung, [SPEAKER_01]: weil solche Bitt abfolgen lassen sich auch super komprimieren, lauflängen Kudierung, eigene Zicht zum Beispiel gut.

46:37 [SPEAKER_01]: Also wenn ihr ganz viele Dikets habt, die aktiv sind, da muss ihr nicht alle Einzen von meinen aktiven Dikets speichern, sondern wenn die nächsten 100 IDs alle aktiv sind, dann speichert ihr das nur einmal und sagt die nächsten 110 aktiv. [SPEAKER_01]: Das heißt, die kann superkomprimieren, gibt es auch noch komplexere, komprämierungsalgerütmann, roaring bitmap heißt es zum Beispiel dann, das ist dann nur hierarchisch organisiert.

46:59 [SPEAKER_01]: Also da gibt es meistens optimierungen, oben drauf, die das halt noch mal verbessern und dem es sparkend noch mal den Sprecherplatz. [SPEAKER_01]: mehr ausnützen. [SPEAKER_01]: Und was denn Speicherplatz richtig gut ausnützt ist eben das sogenannte Plumfilter. [SPEAKER_01]: Und wie gesagt hat ist es ein Filter kein Index.

47:14 [SPEAKER_01]: Das heißt ein Plumfilter kann mir nicht sagen, wo liegt denn irgendwas. [SPEAKER_01]: Wasser war ein Plumfilter sagen kann und das ist die Grund Idee von einem Plumfilter habe ich einen gewissen Welt. [SPEAKER_01]: eine Kundennummer bei mir im Datensatz gespeichert oder nicht. [SPEAKER_01]: Und zwar kann aber nur sagen, kommt diese Datensatz nicht vor.

47:33 [SPEAKER_01]: Das heißt, ich hab den garantiert nicht gespeichert oder vielleicht dieser gespeichert. [SPEAKER_01]: Das heißt, alles aus der Welt. [SPEAKER_01]: Blumfilter fix sagen kann ist habe ich habe etwas nicht gespeichert und das ist eigentlich die Idee des Blumfilters dafür kann der superkomprimiert das ganze abspeichern und die kann da wirklich lange Zeichenketten unter umständen in ein bar bitt oder beit abspeichern und diese Fragen beantworten [SPEAKER_01]: Und das ist eigentlich die große Stärke.

48:01 [SPEAKER_01]: Also erst einerseits super schnell, weil das super kleines und die kann da plötzlich Kompräberungen machen, die sonst eigentlich nicht möglich sind. [SPEAKER_01]: Aber wenn die ich jetzt gefragt hätte, an die kann die Kunden nun mal irgendwie komprämieren. [SPEAKER_01]: Dann hat sie sogar schon einmal gesagt, nein, Interger, wie soll denn Interger komprämieren?

48:17 [SPEAKER_01]: Das ist das kleinste, was sie haben kann. [SPEAKER_01]: Ein Blumenfälter kann sogar in Detscher komprimieren. [SPEAKER_01]: Ich verlier natürlich Informationen, weil er nun mehr Antworten kann. [SPEAKER_01]: Nein, diesen Kunden habe ich nicht. [SPEAKER_01]: Aber dafür habe ich eine Komprimierungsmedode, die sonst eigentlich klassisch nicht möglich war in dieser Form.

48:34 [SPEAKER_01]: Wie funktioniert es das Ganze? [SPEAKER_01]: Es werden mehrere Hashingfunktionen verwendet, wie beim Hashingdex aber multibler Haschfunktionen. [SPEAKER_01]: Und dieser Game ist dann auf ein BIT zum Beispiel in meinem Index gelegt. [SPEAKER_01]: Wenn ihr zum Beispiel an die jetzt in meinem Plumfilter ablegen will.

48:50 [SPEAKER_01]: Und ihr bei einem Plumfilter mit 20 Bit, dann habe ich wahrscheinlich 20 Cash-Funktionen und die 20 Cash-Funktionen werden auf Andi aufgerufen und entscheiden jeweils dieses Null oder 1. [SPEAKER_01]: Und dann bekommen wir einen ganz individuelles Bett dann heraus für Andi, wo ihren Einsätzen muss, meinen Plumfilter und wo eben nicht eins gesetzt wird.

49:08 [SPEAKER_01]: Und wenn ihr jetzt später die Frage stellen, ist der Andi in meinem Datensatz verfügbar, dann kann ich schauen, [SPEAKER_01]: Sind diese Einzer von Andi alle eins gesetzt? [SPEAKER_01]: Wenn es der Fall ist, dann ist die Chance, zumindest es gegeben, dass Andi verfügbar ist, wenn da aber irgendwo null steht, dann kann die mit hundertprozentiger Sicherheit sagen, der Andi ist nicht in meinem Datensatz.

49:28 [SPEAKER_01]: Weil wenn ich den Andi mal gesehen hätte, in meinem Datensatz, dann hätte ich ja diese Bitz an den jeweiligen Stellen auf eins gesetzt. [SPEAKER_00]: Perfekt der Überleitung mit den Bitz. [SPEAKER_00]: Muss ich dir wirklich sagen, wenn man ein Praxis beispielsweise passt, nämlich Perfekt und zwar vorgenommen war.

49:44 [SPEAKER_01]: Ja, es wäre schlecht, wenn dein Beispiel nicht auf meine Erklärung was sind würde, wie ein Blumfilter funktioniert. [SPEAKER_01]: Ich hoffe, dass er gleich funktioniert bei dir. [SPEAKER_00]: Jetzt nur mal so als SideTrack, auch ein Blumfilter, die da schon cool ist, im Red ist auch verfügbar, wer das war.

49:56 [SPEAKER_00]: Öfflen wir mit hier ein Wetter mit mir rutschern. [SPEAKER_00]: Aber das hat sich jetzt nur mal so als SideTrack hier. [SPEAKER_00]: Denn es geht um geht, geht implementiert ein Blumfilter. [SPEAKER_00]: Wenn du... [SPEAKER_00]: Den Command geht Lock aus Fürst und dort ein Argument übergibt's.

50:11 [SPEAKER_00]: Und übergibt's du in der Regel den Schare eines einzelnen Gid-Komits oder? [SPEAKER_01]: Ja. [SPEAKER_00]: Das wird mit hoher Wahrscheinlichkeit und Rundern Hashmaplook auf sein. [SPEAKER_00]: Weil der Schare von einem Gid-Komit kann es ja so als Primary-Kie von dein Komitz ansehen. [SPEAKER_00]: Richtig.

50:26 [SPEAKER_01]: Ja, als primary key, wie man dann identiziert ist, noch mal eine andere Sache. [SPEAKER_00]: Aber genau, aber das ist so ganz simple. [SPEAKER_00]: Jetzt ist es aber so, du kannst auch eine ein der Teipfahrt angetlocken. [SPEAKER_00]: Du kannst sagen, geht lock, minus, minus und dann Fahrzuneuteil.

50:41 [SPEAKER_00]: Diese Operation ist relativ teuer. [SPEAKER_00]: Denn was geht und nur und amachen muss, der muss für jeden geht, kommit, prüfen, ob sich die der Teil, die du angegeben hast, gegenüber dem parent in dem Baum, in dem geht Baum geändert hat. [SPEAKER_00]: Das heißt eigentlich unten drunter, müssen verschiedene Bäume kontinuierlich für jeden Gitcomit gedift werden.

51:00 [SPEAKER_00]: Gibt es eine Änderung zu mal. [SPEAKER_00]: Tadah, du merkst schon, wo wir er hingehen, wir bauen eine Inneckschruktur und zwar nehmen wir da einen Blumenfilter. [SPEAKER_00]: Und immer wenn ein Komit gemacht wird, wird der Komit graf. [SPEAKER_00]: pro Commit in ein Blumfilter überführt wo dann verschiedene Bits gesetzt werden für diesen einzelnen Commit und wenn du git lock minus minus far zu einer Datei machst dann schaut der erst in den Blumfilter nach oh habe ich hier was und da hat der dann verschiedene Bits gesetzt und man handt der Bits die gesetzt wurden entscheiden er ja diese Datei wird geändert nein diese [SPEAKER_00]: Nur in dem Fall von Maybe, das ist ja ein probabilistisches Ergebnis, dann macht er die teure Operation von dem Bäume, dürfen die sowieso gemacht, hätte ohne die Inneckschaftture.

51:54 [SPEAKER_00]: Und das ist so eine schöne, so ein schönes Beispiel, dass man eigentlich diese Innekschrukturen, ja, für dich sagen, zumindest ist es wöchentlich verwendet. [SPEAKER_01]: Also ich möchte ich korrigieren, wie gesagt, Innekschruktur kann man als darüber streiten. [SPEAKER_01]: Ich würde es nicht Innekschruktur nennen, weil eine Innekschruktur kann den normal etwas zurückklefern.

52:13 [SPEAKER_01]: Oder sagen, wo der eigentliche Wert liegt, es kann den Blubfilter nicht. [SPEAKER_01]: Und... [SPEAKER_01]: Ich bin der Akademische Part in dem Podcast rumprobiertes. [SPEAKER_01]: Es ist wieder auf ein allgemeines Level zu heben, wo ein Blumfilter sinnvoll ist. [SPEAKER_01]: Und zwar macht ein Blumfilter.

52:26 [SPEAKER_01]: Und natürlich nur da sind, wo ich viele Anfragen bekomme. [SPEAKER_01]: Und die Chance, aber gering, ist das eigentlichen Wert in meiner Datenbank, in meinem Datensätt überhaupt verfügbar ist. [SPEAKER_01]: Weil sonst, wenn die Ständig, die ihn vorbekommen, ja, ist eben verfügbar, dann muss sie durch das ganze Datenshett durch, ist natürlich schlecht.

52:42 [SPEAKER_01]: Also es macht natürlich, am ersten Sinn, wenn die Antwort oft nö ist nicht bei mir im Datensatz. [SPEAKER_01]: Ist oder, wenn das anschauen an sich extrem teuer ist? [SPEAKER_01]: Das heißt, wenn ihr jetzt zum Beispiel in einem Distribute-Zystem bin und die will wissen, wo liegt denn der Welt auf Note 1, auf Note 2, auf Note 3 und die müsst damit Netzwerk erst mal nachfragen, dann werde es natürlich super langsam und [SPEAKER_01]: Blumenfilter kann mir das natürlich im Feuer hineinbeantworten.

53:07 [SPEAKER_01]: Und um noch ein Beispiel zu lernen, was Andy's Lieblingsdamer ist, Tier Storage. [SPEAKER_01]: Das heißt, ihr habt verschiedene Storage Layer und wie Storage Layer, die ganz schnell sind, meine Festplatte, irgendwelche Remote Storage Layer, die super langsam sind, die Kohl sind, da kann ich natürlich im Blumenfilter davor setzen, damit ihr nicht [SPEAKER_01]: In meinem Bergwerk gehen muss und auf irgendeinem Bandnachschirm muss, ist da irgendwie ein Datum eine Datei vorhanden, sondern das kann der Blumfilter beantworten, der superkompackt und im Falle muss ich dann natürlich im Detail noch mal nachschauen.

53:38 [SPEAKER_01]: Und das dem Grund wird übrigens auch bei LSM-Trees, das ist die Inextruktur von Rockstippie und der anderen, die Facebook ja verwendet, stark eingesetzt, weil es eben auch so ein tiered storage Modell verwendet. [SPEAKER_00]: Und jetzt habe ich einfach mal ein perfektes Beispiel, wo ihr mal einfach hart ganz dumf, weibkoden könnt.

53:56 [SPEAKER_00]: Auch wenn ihr jetzt sagt, oh, da rollt sich die Finger nicht hoch, aber der Wolfgang ist für die Theorie zuständig. [SPEAKER_00]: Und ich bin der praktische Typ, deswegen pussch ich euch mal in die Richtung, springt doch einfach mal in eure KI, sagt. [SPEAKER_00]: Bauen wir doch mal eine Blumenfilter-Implementierung, interviewen mich dazu zu meinen Daten setzen.

54:14 [SPEAKER_00]: Und dann forsiere doch einfach mal eine Blumenfilter-Implementierung von Daten, die du kennst. [SPEAKER_00]: Und dann lässt du dir das in einer Sprache dann aber in eine minime Code-Ball-Spiele mal generieren und ließ dir, dass du im einfach mal Verständnis zu kriegen. [SPEAKER_00]: Denn zumindest für mich.

54:29 [SPEAKER_00]: Hören sich diese theoretischen Kontrukte immer super an und ja, ich klick dann die Slide immer durch und dann sehe ich dann die Trade-Offs und die Pro und die Kronen sind dieses alles gut, aber richtig Klick macht's halt, wenn die ganze Sache auf Daten läuft, die ich kenne, also die ich, wo ich domainen Experte vielleicht bin und wenn ich mir per KI einfach drei, vier Projekte generieren lasse, unabhängig davon, ob die Struktur [SPEAKER_00]: Auch wenn ich, ich bezeichne Blufilter jetzt auch als Indigstruktur, kann der Wolfgang, das Geile ist ja wie lehme ja wie Mode auf, das würde sich der Wolfgang kann mich gar nicht hauen.

55:03 [SPEAKER_00]: Es ist viel zu weit weg. [SPEAKER_00]: Aber dann hab ich auf jeden Fall dort hier aus Verständnis, wo ich denn den Kram hoffentlich besser verstehe. [SPEAKER_01]: Und Bloomfield, da ist ja wirklich so der neue heiße Scheiß, zumindest seit die Erwirt mal sagen, 15 Jahren, aber einmal zurückblickt, erfunden ist das ganze 1970 wurden.

55:21 [SPEAKER_01]: Also lang lang, bevor das eigentlich alles ein Thema war, das sieht man wie lang so, was dann wirklich benötigt, bis es dann schlüsse ähnlich, auch die Anwendung findet und an die du kannst gerne indikstrukturen nennen, ist vollkommen, okay, es ist ja eine Datenstruktur, also so weit können wir uns jetzt darauf einigen.

55:36 [SPEAKER_01]: Und vielleicht noch als Kleiderseitenhaut, ich habe [SPEAKER_01]: ziemlich lang gebraucht, bis die Blumenfeld richtig verstanden habe. [SPEAKER_01]: Also ich habe da einige Infos durchgelesend damals und bis es so richtig verstanden habe, hat es eine Zeit wirklich benötigt, insofern findet einen Approach super gut, weil früher war es natürlich nicht so einfach da irgendwie ein Beispiel zu sehen oder welche Bizwände da belegt, wenn ihr da irgendwo dort ein gibt.

55:58 [SPEAKER_01]: Da hat es ja keine Online-Simulatoren gegeben, die dir das so einfach berechnet haben. [SPEAKER_01]: Jetzt kannst du dir das einfach weibkoden oder wirklich mal ein persönliches Beispiel ausgeben lassen und du kannst gezählt Fragen stellen. [SPEAKER_01]: Es ist eigentlich ideal, um irgendwas zu lernen.

56:12 [SPEAKER_00]: Ich mache das gar nicht so oft da dich gezielt Fragen stellen. [SPEAKER_00]: Ich sag dir im off Initial, okay, kommentiere das für eine Union-Engine oder ähnliches. [SPEAKER_00]: Oder für einen 5-4-Ault, und natürlich ist das an super excessive und da stehen dann super viele Kommentare, alles gut.

56:27 [SPEAKER_00]: Aber ich hab's ja in ganz kurz generiert. [SPEAKER_00]: 3-4 Minuten leset mir durch oder dann schmeiß ich ja eben da weg, ich will's ja nur verstehen. [SPEAKER_00]: Von daher, da muss ich schon zugeben jetzt mal unabhängig davon operas im Produktionschip für oder nicht. [SPEAKER_00]: Das nenne ich mal reale Code Generation.

56:41 [SPEAKER_00]: Aber wer immer noch dran ist, nicht wegepend ist. [SPEAKER_00]: Und noch mehr von unserem Kram hören möchte. [SPEAKER_01]: Hört sich die Episode 151 an, weil da haben wir über ganz viele Bäume gesprochen, andere Bäume und zwar über Geo in die Zäs, also räumliche Datenstrukturen und Indekstrukturen.

56:58 [SPEAKER_01]: Und wer weniger auf Bäume steht, der hört sich an das fast Lieblingsfolge würde sagen an. [SPEAKER_01]: Und zwar die 146 oder an, die über Duben über das Computer spiel, viele so fiert und [SPEAKER_01]: Viel technologische Schwier, auch erzählt, aber unter anderem auch, was hinter diesen ganzen räumlichen Indexstrukturen steht, damit man's rendering verbessert und die Lichtstrahlen irgendwie richtig berechnen kann und so weiter.

57:23 [SPEAKER_01]: Also auch dessen Indexstrukturen, die Dumpfolge ist definitiv auch zu empfehlen, 146. [SPEAKER_00]: Wie ihr es von uns gewohnt seid, alle links in den Shownuts. [SPEAKER_00]: Und jetzt erwartet ich eigentlich von jedem als Hausaufgabe, dass ihr mal in die Code-Bellen springt an der ihr Profisündel arbeitet.

57:38 [SPEAKER_00]: Schmeißsieker wieder auf und sagt, welche Inneckschupfen habe ich denn hier im KWL-Code verwendet. [SPEAKER_00]: Und lasst euch mal da die Code-Zahlen zeigen und... [SPEAKER_00]: Wenn ihr dann die Discord-Community kommt und die Anzahl der verschiedenen Indexstrukturen einfach am Postet, der Gewinner mit der Code-Base, mit den meisten verschiedenen Indexstrukturen kriegt ein Kaffee von uns.

57:57 [SPEAKER_00]: Wie war denn übermitteln, weil sie jetzt auch noch nicht kriegen war schon irgendwo hier in der Vorgung auf der Konferenz. [SPEAKER_00]: Aber ich bin gespannt. [SPEAKER_00]: Am Geilz wäre mit so ein bisschen Kontext, wie viele Leins auf Code hat denn die Code-Base, was macht die Code-Base denn und so weiter und so vor.

58:09 [SPEAKER_00]: Da bin ich mal gespannt. [SPEAKER_01]: Zählter dann die Datenbank indexstrukturen schon mit, oder? [SPEAKER_01]: Weil die sieht mehr in der Code, da ist nicht. [SPEAKER_00]: Nee, nee, nee, nee. [SPEAKER_00]: Schon die, die im Quell Code. [SPEAKER_01]: Adi im Code, okay. [SPEAKER_00]: Ja, ja, ja, genau.

58:19 [SPEAKER_00]: Und wenn du jetzt zweimal eine Blumenfüllte hast, jahres Eins, ja. [SPEAKER_01]: Weil ich sag ja verschiedene ... Dann gewinnen alle die Notsche es verwenden, oder? [SPEAKER_01]: Weil da hat man gar nicht so viele Becketsches eingebunden. [SPEAKER_01]: Und die alle wieder irgendwelche anderen indexstrukturen verwenden.

58:31 [SPEAKER_01]: Oder musst du es auf der ersten Ebene sein? [SPEAKER_01]: Ihr seht schon an, die haut da immer so diese Gewinnspiele raus und sie mussten wir dann um diese rechtlichen Demenkümmen. [SPEAKER_01]: Oder wir machen es einfach so wie ihr entscheiden das am Ende wer gewinnt. [SPEAKER_00]: Irgendwo müssen wir die Power ja auch mal ausnutzen.

58:44 [SPEAKER_00]: Eben, genau. [SPEAKER_00]: So machen wir das. [SPEAKER_00]: Wir haben nicht gefällt, der wird einfach wieder aussehen, die Skolkümpft hier ausgeschmissen, relativ einfach. [SPEAKER_00]: Es bissert noch nie passiert, aber... [SPEAKER_00]: Schauen wir mal. [SPEAKER_00]: So, das war's von uns.

58:55 [SPEAKER_00]: Ich hoffe, ihr habt eine Sache mitgenommen. [SPEAKER_00]: Wie immer hören wir uns nächste Woche. [SPEAKER_00]: Und falls ihr noch nicht alte Personen gehört habt, dann wird einfach mal irgendwelche andere Episode aus. [SPEAKER_00]: Hört euch die An und empfiehlt die einfach mal einer Kollegin und einem Kollegen weiter.

59:09 [SPEAKER_00]: Das war's von uns. [SPEAKER_00]: Wir sind weg und Tschüss. [SPEAKER_00]: Ciao.