Protocols

Protokoll Weekly 1.11.22

Status Quo

• Masterprojekt berichtet was so passiert ist
  • SetUp fertig
  • lesen bzgl. IO → Aufstellung von Pro/Kontra als nächstes Todo
  • erstes Microbenchmark Gerüst erstellt

Nächste Woche

• Betreuer:
  • Zielvorgabe: Fokus auf MMAP
    • andere File IO Konzepte “Warm-Up”
  • Nächste Woche Montag Diskussion über File IO Konzepte / Microbenchmarks
  • Zusatzaufgabe:
    • 2 Personen sollen sich tiefer mit mmap beschäftigen
    • 2 Personen → “mmap not recommended” Paper
    • Advanced Programming Buch reicht als Resource aus
    • 2 Vorträge a 10 Minuten nächste Woche
  • Ziel: Nächste Woche Benchmark der Ansätze aus Kapitel 3
    • Danach Ziel → Alternativen zu mmap aufzeigen

Weitere Fragen/Diskussionen

• Diskussion/Fragen über konkrete Themen:
• Microbenchmarking
  • Ziel: Beispiele in Kapitel 3 anschauen
    • Latenzzeiten messen etc. → Vorteile/Nachteile von Methoden herausstellen
  • Am besten GB schreiben, damit man Leseeffekte sieht
  • Cache: Riesenproblem
    • Zwei Caches, die für uns relevant sind:
      • CPU Cache
      • File IO Cache
    • Wie kann man damit umgehen:
      • OpLinux Command aufrufen aus benchmark heraus, FileCache leeren
      • Datei im Setup kopieren, TearDown löschen ← evtl. langsam
  • Dimensionen:
    • verschieden große Mengen von Bytes lesen und schreiben, verschiedene Buffergrößen
    • Fokus auf Konsistenz → verzögertes Schreiben → sicher stellung das es auf Disk ist
      • sync?
      • Welche Flags könnte man an welche Funktionen setzen, um Konsistenz zu wahren? Schreibmethoden in DB-Kontext bringen. Segment ist gefüllt → muss auf Festplatte.
    • Mehrere Threads
  • Generell:
    • Posix basierte File I/O→ läuft unter Mac
    • ofstream → standard (wrappt tendenziell auch nur posix calls)
  • Buffer wird Rolle spielen!
    • Ansätze mit Fokus auf Buffer anschauen
    • Wie kann man read aus Disk in Datenstrukturen im Hauptspeicher verbringen
• io_uring → Limitierung auf Linux?
  • Potentiell als Weiche für Mac implementiert
  • Benchmark muss nicht auf Mac laufen können
• Das Betriebssystem garantiert einem nichts → Wenn man Garantieren haben möchte muss man syncen.
  • stdlib synct nach Ende von File schreiben
  • oder nach Row
  • Segmente → Granularität
• Constraint für alles was wir mit auf Disk speichern machen: Persistenz ist Key, Buffer und das dem OS überlassen ist keine Alternative für uns.
• Was wollen wir persistieren? (Welches Level an Abstraktion Segments/Chunks etc.?)
  • Am Ende: Möglichst viel von hyrise auf Disk. Nicht auf Tabellen beschränkt. (Also alles.)

Protokoll Weekly 7.11.22

• neues Weekly 13:00-14:00 Uhr

• done: Benchmarks für kap 3, MMAP diskussion, pro/con I/O methoden

• sudo fürs cache clearen?

• memcopy nehmen

• Was kommt bei mmap überhaupt raus? Können datei nicht öffnen

• besser barchart statt lineChart

• msync mit mmap aufrufen soll nicht so gut sein

• filedescriptor closen

• lseek bei write mit einbauen

• mmap mal ans limit testen

  • mehrere Threads
    • könnte bei nicht atomaren write kaputt gehen
    • jeder thread muss fixe filedescriptor bekommen
  • beim reden danach noch drüber iterieren
  • wenig read write, eher einmal viel lesen einen chunk
    • mehr fokus auf write benchmark
    • file muss nur einmal geschrieben werden
    • einmal geschrieben, viel lesen
  • segment ist 65k * datatype
    • allgemein kleier 100mB
    • geht aber nicht pro segment je eine datei
    • eher pro chunk eine datei

  Todo:

  • mmap benchmarks fertig
    • random und sequentiell
      • aus 1 mio einträge 1000 random auslesen
    • threads am spannendsten
  • mmap alternativen suchen (list existiert)
    • kernel anpassen müssen ist nix
    • muss schonmal implementiert sein
    • open source, verwendbar, linux/max, lizenz
    • umap (gute)
      • mmap benchmarks damit erweitern
  • umbra paper lesen
  • viktor leis blog post what every programmer should know about ssds
  • baseline messungen für benchmakrs finden /FIO wurde da im paper benutzt
    • vergleich ssd kapa und tatsächliche nutzung
    • was fio ist
    • schauen, dass wir max performance habe
    • sie ben masterarbeit
  • evaluieren, wie schnell read writes aus dem hauptspeicher sind
    • sequentiel und zufällige zugriffe messen
    • vector copy für write
    • vector summe bilden für read
    • dabei die summe prüfen

Protokoll Weekly 14.11.22

• Random-Read-Benchmark:
  • mmap() müsste schneller sein weil irgendwann das ganze File im RAM liegt
  • map_private deutlich schneller als map_shared
  • Unser Throughput ist größer als single-threaded möglich
    • Vermutlich Umrechnungsfehler im Benchmark
    • Caching als Ursache ausschließen -> Larger-than-Memory-Benchmark
• Meiste mmap()-Alternativen wegen notwendiger Kernel-Eingriffe ungeeignete
  • umap() ist eine Ausnahme
  • Wird schon in Hyrise eingesetzt (privater Branch)
  • Vollständiger mmap()-Ersatz
  • Für Mac-Kompabilität könnte Weiche verwendet werden
  • umap() überschreibt Pagefault-Handler
  • Verwendete Speichergröße definierbar
  • Parallelisiert besser als mmap()
  • Sehr viel schneller
  • Viele Threads: Kann mit der Datenbank interferieren
  • Benchmarks!
• Umbra Fragen:
  • Mixed Workload Database
  • Interessantes Follow-Up-Paper zu Disk-based MVCC
  • Umbra benutzt jit compilation
    • Sehr effizient, schwerer zu optimieren, Kompilierzeiten fallen ins Gewicht
  • Everything You Always Wanted to Know About Compiled and Vectorized Queries But Were Afraid to Ask
  • Asynchrones IO ist besser parallelisierbar als synchrones IO mit vielen Threads
  • mmap() ersetzt Buffer Manager
• Zielsetzung
  • Welche Persistenz für Hyrise, Backups oder Big Data Queries
    • Noch Unklar, Entscheidung Dezember
    • Reads sollen irgendwann direkt auf Platte gespeichert werden: Log
    • Aktueller Stand bei ausgeschöpftem Memory: Hyrise wird gekillt
  • mapping/lesen von immutable Segments
  • Wenig Materalisierungen
  • Umbra nutzt Buffer Manager für alles
    • Auch für temporäre Daten
  • Wir brauchen kein Random Write
  • mmap() skaliert relativ gut bei sequentiellem read
  • Zu viele Threads sind problematisch
  • FIO soll für Baselines verwendet werden
    • Was schafft die SSD, was schafft ein Thread

Protokoll Weekly 14.11.22

• Team wegen Krankheit unvollständig
• Sanity Checks in den Benchmarks
• umap()
  • Inzwischen inkludiert
  • Derzeit noch verschiedene Runtimeerrors, sollten schnell beseitigt sein
  • Unterstützt kein MAP_SHARED
    • Wird für Hyrise voraussichtlich nicht benötigt
  • Muss ggf. nochmal mit anderen Compilerfalgs gebaut werden
• mmap()
  • Erneute Diskussionen über das mmap will ruin your life Paper
  • Zeitdimension sollte in den Benchmarks berücksichtigt werden um vollaufende Caches zu berücksichtigen
  • TLB Probleme vor allem bei hoher Parallelität
    • Benchmarks Multithreaded! (alle Varianten)
    • Benchmarks mit variabler "Last"
    • Page Cache limitieren
    • Direkte Vergleiche zwischen mmap() und umap()
  • Ausblick auf Implementierung an Hyrise
    • Zuerst kann von statischem Datenset ausgegangen werden
    • Informationen zu geänderten Daten befinden sich in MVCC-Spalten
    • Einfachste Methode soll zum Schreiben verwendet werden
  • An den mmap() / umap() Parametern rumspielen

Protokoll Weekly 28.11

Marcel kann nicht beurteilen, warum io_uring raus ist

TODO MMAP alternativen paper mäßig zusammenschreiben (nicht schön, aber okayish) - umap, mmap die 5 alternativen → kommt overleaf einladung → wird basis des reports, kann auch schon related work bezwecken

Problem mit io_uring:

• umfangreich
• komplex
• co-routinen
• viele verschiedene funktionen

Empfehlung: Co-routinen sind zu aufwändig, lieber threads stattdessen (s. Paper, wo die verglichen wurden)

TODO Schaut mal bitte, was man by aio_read in den struct alles reinpacken kann fürs threaden

• offset, buffsize etc

Recherche welche fälle mit (a?)io_uring abgedeckt wurden im vergleichspaper → was unterschied zwischen den async methoden → was verlieren wir, wenn io_uring nicht gebencht wird

Betreuer schauen, ob Jenkins klappt vs Github actions Was wir bräuchten:

• clang
• gcc
• clang tidy
• linting

Müssten evtl Google Benchmark weglegen, wenn es zu viel wird

Priorisierung der Aufgaben Load dimension: 1 Thread maximal laufen lassen, reicht für load Time dimension: time schleife drum rum, wie lange

Bei threading: Zuwachs/abfall in der Bandbreite interessant

Ziel bis nächste Woche: Shootdowns, mit threads und über Zeit interessant zu sehen, Fokus auf Lesen

Protokoll Weekly 05.12.22

Organisatorisches

• Neuer Weekly Slot Montags 15:15

Letzte Woche

• Viel Refactoring
• Unsere Benchmarks historisch gewachsen, nun etwas auseinandergezogen
• Feedback eingearbeitet
• Benchmarkergebnisse

Refactoring:

• Threading brachte neue Komplexität
  • Refactoring wurde notwendig
• MMap()-Benchmark separat
• Read-Performance wurde stark verbessert
  • Verhundertfacht!

Threading und Benchmarkergebnisse:

• In-Memory-Benchmarks und mmap()-read noch nicht threaded
• Benchmarks noch WIP
  • Teilweise merkwürdige Ergebnisse
  • Sehr große Varianz im threaded fileio -> Testen mit wie vielen Threads die Platte voll ausgelastet ist
    • FIO
    • Prüfen wie viel Zeit zwischen Starts der einzelnen Threads vergeht
    • Threads separat starten, später Arbeit zuweisen
      • Atomic int um Anzahl fertiger Threads zu tracken
    • Kleine Filegrößen eher weniger relevant
  • Random access Performance viel schlechter als Sequential
  • Throughput nach wie vor merkwürdig hoch
    • bis zu 35 GB/s
    • Faktor 10 zu hoch -> Ohne Cache-Reset vermessen
    • Limits setzen
    • FIO!!
    • Testen ob Werte ggf. in Bit statt in Byte -> Mehr Threads bringen mehr Durchsatz, das ist gut
  • read()-Performance nimmt mit mehr Threads zunächst ab, pread() steigt die ganze Zeit
    • Schauen wann Caches gecleart werden
  • Mmap()-write threaded mit hoher Varianz
    • Threading bringt keinen oder keinen positiven Impact
    • Passt zu Veröffentlichungen die besagen dass mmap() ab 8 Threads leided -> Martin fragt nach mehr write-Benchmarks
  • Von mmap() erzielte Ergebnisse dürftig
    • Bottleneck?
  • Offene Fragen zum mmap() Vectorzugriff
• Verschiedene Benchmarkansätze
  • Gesamtzeit pro Daten vs. MB/s im Verlauf der Zeit
• Benchmark sollen bald feature complete sein
  • umap(), io_uring und aio müssen noch integriert werden
  • Mehr Iterationen für Benchmarks
  • Benchmarks auch mit 24 und 48 Threads
  • 1 GB Filesize reicht
• Random Benchmarks mit oder ohne Duplikate?
  • Sollte nicht gebuffert sein
  • Beim Lesen der gesammten Daten irgendwann zwangläufig Cachetreffer -> Nur Teil der Daten zufällig lesen
    • Dateigröße sollte irrelevant sein

Nächste Woche

• Viele Charts
• Microbenchmarks vorläufig abschließen
• Schwerpunkt soll zeitah auf Hyrise verschoben werden
  • Crotty-Benchmark weniger relevant
• Übung bis nächste Woche:
  • Hyrise erweitern
  • Binary-Writer / Reader um Benchmarkdaten nicht jedes Mal neu generieren zu müssen
    • Export value kann hilfreich sein
  • Lesen bisher unsauber
    • In Vector hineinschreiben / UB Aufgabe:
• Segment erstellen, 23 Spalten, Integers
• Chunk auf Festplatte dumpen, unencoded
• Chunk wieder laden
• Überlegungen zu Dateiformat usw. anstellen

Protokoll Weekly 02.01.2023

Agenda

• Benchmarks
  • io_uring Messergebnisse
  • Setup on Server
  • Async Messungen
  • True Random Indices
• Exercise: Dictionary Implementierung
• CI
• Midterm Presentation

Benchmarks

• io_uring
  • Resultate wirken nicht realistisch
  • Wie kann dieses Ergebnis mit einem Thread ergeben?
  • Vergleich mit FIO?
• Setup on Server
  • keine Limitierung der CPUs nötig; aber es ist valide genau eine CPU für die MicroBenchmarks zu nutzen
    • durch explizite Einschränkung mit NumaCTL kann verhindert werden, dass Threads auf anderen Nodes gespawnt werden
    • aber eher unwahrscheinlich
  • Einschränkung von Page Cache ist interessant
• Async Messungen
  • "Wie sinnvoll ist es auf die Beendigung von async Reading-Ops?"
  • Marcel: Möchte wissen, wie io_uring im Detail funktioniert, um zu wissen, ob vergleichbar.
• True Random Indices
  • weniger Elemente sequentiell lesen

Exercise: Dictionary Implementierung

• Vorstellung DictionarySegments (siehe Weekly Präsentation)
  • Hyrise-interne Datenstruktur muss angepasst werden
• Wie mappt man Files auf Segmente?
• Meta-Daten sollten am Anfang der Datei gespeichert werden
  • evtl. andere Datei für Meta-Daten

Stefans weitere detaillierte technische Kommentare nachdem das Meetingzeit schon lange vorbei war

• Fixed Size pro Metainformation
  • in Präsi reinbringen
• Wie soll die Datei technisch aussehen?

Protokoll Weekly 09.01.2023

Was wurde so getan

• Diverse quick fixes für die Benchmarks

Thread Ausführung mit Flag

• Threads werden nun vor Beginn der Zeitmessung gespawnt, fangen an zu arbeiten sobald Flag gesetzt wird
• Stefan merkt an, dass die Threads ggf. wegen schlechten Scheduling sehr unterschiedlich lange laufen
  • Ergebnisse abwarten
  • Work Stealing könnte hier helfen

Benchmark-Visualisierungen und dazugehörige Fragen

• Threaded AIO skaliert nur wenn mehrere FDs verwendet werden
• Für PREAD sollen zukünftig auch mehrere FDs verwendet werden um Blocking zu vermeiden
• IO_URING funktioniert noch nicht richtig
• FIO-Performance deutlich schlechter als durch IO
  • Überprüfen von welchem Device gelesen wird, vermutlich nicht auf RAID
• Realistische RAID-Performance: 11 GB/s
  • Unsere Ergebnisse teilweise erheblich besser
  • Bits statt Byte?
• ToDo: Riesige Datei benchmarken um Caching zu verhindern

  • 100GB

  • Sicherer als Page Cache Limitierung
• Verständnis von Random Access von Fio potentiell anders
• Warum sinkt MMap()-Performance bei mehr als 16 Threads
  • Threading Overhead?
    • Thread-Erstellung aus Messzeit auslagern
  • Internes Locking?
  • Ggf. Timestamps der Threads mitschreiben um zu sehen wie stark sie Überlappen
• Bei UMap() werden derzeit keine Flags gesetzt
  • Impact sollte nicht zu groß sein

Midterm

• MMap() soll von Anfang an als angemessenster Ansatz präsentiert werden
  • Geringe Codekomplexität
  • Benutzt Posix unter der Haube => Mac- und Linux-Support
• Kehrseiten sollen auch beleuchtet werden
• Vergleich mit anderen Methoden
  • Martin: MMap() als Enabler
  • Nicht zu sehr in Fragen verstricken
  • Zuschauende nicht erschlagen, Informationen vorsichtig herausgeben

Planung

• Donnerstag Benchmark Freeze, Freitag Folien
• Folien sollten bestenfalls vor 15 Uhr abgeschickt werden
• Folien auch als PDF schicken
• Setting nach unseren Vorlieben, aber besser stehend
• Zoom

Fragen

• Keine weiteren IO-Methoden benchmarken
  • Postgres verwendet z.B. kein DIRECT_IO
• CPU Scaling Warning vermutlich nicht gravierend
• Vermutlich kein großer Unterschied zwischen CPU- und Realtime
  • Außer IO nicht in CPU-Time
  • Besser Realtime verwenden

Midterm Protokoll 16.01.2023

Frage: Leis ist ja sehr dagegen, wieso wir nicht?

Use-Case ist anders: Für deren Umbra SSD Approach ist das valide, für Hyrise brauchen wir nicht?!

Frage: Benchmark von Leis, nach Zeit, laufen unsere Benchmarks nach der Zeit? TODO: Unbedingt gucken, was passiert wenn Page Cache vollgelaufen ist.

Antwort von Niklas: Metadaten dauerhaft im Speicher halten —> also nur Vektoren auf Disk schreiben. Nachteil von Spans —> keine Ownerships , im Gegensatz zu Vektoren. Vektoren allozieren und deallozieren Speicher.

Daniel Konzeptfrage: Wegschreiben von Chunks anstatt Segments? Antwort von uns: Maximum von Filedescriptoren, aber noch offene Fragen bezüglich der Granularität.

Können wir es uns erlauben, die Metadaten nicht im Speicher behalten? Martin: Antwort Metafiles müssen persistent werden! Frage ist nur welches Format?

Frage: Filesystem vs. Blockdevices? Abwägung

Frage: Typische Chunkgröße in Hyrise? Antwort: Abhängig von Tabellengräße

Frage: Persistenz erwähnt, geht es um „Sind Daten nach Ausschalten noch da?“ oder nur während Ausführung. Antwort: „Hybrides Ziel“

Frage: Madvise verwendet? Antwort: Ja, haben wir, allerdings keine Evaluierungen gegenseitig.

Frage: Während der Ausführung (Query Execution) was muss bedacht werden? Antwort: Drauf achten, welche Chunks wann geliest werden?

Frage: Wie ist das Feld der Forschung hier gerade, welche SSDs verwenden wir genau? Genaue Zahlen? Antwort: Gibt eine deutlich langsamere noch auf Koro?

Frage: Related Work Übersicht zum Thema?. Antwort: Umbra setzt auf SSDs. Oft nutzen Leute MMap auch zum Schreiben.

Zu unseren Fragen auf der Slide: Antwort: Werden niemals einen Chunk komplett lesen?

Antwort: Mehr Zwischenschritte bei höherer Threadzahl (z.B. 24). Allgemeiner Typ zum Set-Up: Thread validity, was kann grenzwertig sein für meinen Benchmark? Liste mal durchgehen und unsere Benchmarks checken.

Frage: Wie groß ist ein TPCH Chunk size? Assumption: Datei selbst ist wahrscheinlich kleiner. Größe unserer Benchmarks ist jedoch valide, da wir chunks zusammefassen müssen.

Schritt vielleicht zu raw-block device?

Ab welcher Dateigröße ist es sinnvoll einen Thread aufzumachen?

Boost bietet auch einiges in Funktionalität an, evaluieren?

Lösung der Implementierung nicht abhängig von Zeitaufwand.

Kommentar zu Slide 9: Frage: Klarstellung von Tiering und so weiter. Besser: „Datenplatzierung“.

Protokoll Weekly 16.01.23

Wir werden niemals so viele Threads auf 1GB schicken. Realistischere Benchmarks: TODO: Run Benchmarks mit 100GB

FRAGE: Können wir sicherstellen, dass ein langsamer Thread nicht den Throughput runter reißt? —> TODO: Timestamp von jedem Thread, wenn er fertig ist. Keine Visualisierung, nur roh einfach mal gucken / zur Prüfung

Frage: Inwiefern sind unsere Benchmarks denn wirklich geeignet Hyrise Contest abzubilden. Antwort: Warten wir ab, sehen wir am Ende. Gegen Segmente abweichen, da zu viel maps (kernel-basierte Grenze)

Use-Case für MP: Nicht optimales Tiering sondern Persistent (um jeden Preis?)

Schnell Daten laden können, „teilweise / schrittweise Persistenz”

Frage: Wohin mit den Metadaten? Antwort: Klar, auf der Disk wegen Möglichkeit eines Neustarts. „Benchmark getriebene Read-only persistence”

Frage: Block-device vs. File-system Antwort: File-system Fokus auf 100GB + Thread-Bearbeitungszeit-Statistik + Thread-Anzahl (24,36) und dann volle Fahrt in Hyrise.

Frage: „Bleibt MMAP?” Antwort: „Ja, das ist quasi als Untersuchungsobjekt” Im Report auch „nicht objektive” Sachen heranziehen, „Implementierungsaufwand” / „Erfahrungswerte”.

Forschungsfrage: „Ist MMAP ein geeignetes Tool für unseren Use-Case?”

Hyrise

Weitere Datenstrukturen werden in Chunks verwendet. Welche Datenstrukturen gibt es noch? Required:

• Segments
• Brüning statistics
• Sorted by
• Is mutable (sollte true sein, sowieso implizit) Fokus auf Dict Seg, da immutable und ValueSegments nicht trivial sind.

Protokoll 23.01.2023

Read / Write Problematik

• Vorstellung: Read / Write kann auf 100 GB gesetzt werden
  • Problem: Read / Write sind limitiert auf 2^32 / 2 (~2,1 Mrd.)
  • Lösung: Iteratives Read / Write
• Iteratives Lesen der Blocksize
  • Falls nicht Menge der Bytes zurückgegeben wird, nochmal lesen --> Common Problem
  • es ist fast egal, wie groß die Blocksize ist (1 MB ... 1 GB)

CGroups (Ansatz: Limitierung Page Cache)

• Grundsätzlich: Page Cache kann immer größer werden
• Es ist nicht ganz sicher, was passiert, wenn Hauptspeicher limitiert wird.
  • Welchen Effekt hat das für den Page Cache? --> Wird überhaupt der Page Cache limitiert?
• Empfehlung Blog Post: https://www.thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics

Threat Timing

• immer nach Start & vor dem join() messen

File Format

• Ist der Row Count fixed pro Chunk?
  • Chunk hat bis zu ~65k Einträge
  • kann aber auch weniger haben
• ColumnCount kann rausgelassen werden
  • Bezug dieser Info aus Segments
• Es fehlt Tabellenschema Infos.
  • kann in storage.json gespeichert werden.

Storage Manager Modes

• Sind Modi (DRAM-resident vs. MMaped) global?
  • Ja
• DRAM-resident: Ist DB File Startpunkt dafür und Daten werden davon geladen?
  • Ja
• Warum sollte man mmap nutzen für das pure "Laden" von Daten?
  • Keine Ahnung - wurde gedodged

--> Diskussion über Aufgaben-Dok im nächsten Weekly!

Protokoll Weekly 30.01.23

Themen:

1. FIO 100GB update
2. File Format Implementierungsupdate

1. FIO

• peak by 24 threads in unserer Implementierung
• mmap skaliert gut
• BITTE START UND ENDE VON DEN THREADED BENCHMAKRS CHECKEN! (Timestamps loggen)
  • Wie viele Iterations machen wir pro Run?
  • Problem:
    • Zahlen sind wieder sehr hoch in unseren Implementierungen 120GB/s m
    • Vermutung: Clear caches wurde evtl nicht gemacht - Nachschauen welche Zahlen wir bei der Zwischenpräsi hatten
    • Wieso FIO auf einmal langsamer?
    • Warum mmap bei FIO auf einmal am besten?
    • Feedback
      • Überhaupt mal die Ergebnisse verifizieren wäre wünschenswert
      • Zeil Grundlegende Aussage, wie schnell wir von der Platte lesen können
      • Weniger prio random, eher sequentiell
      • Idee: Evtl mal ohne Google Benchmark probieren

2. File Format

• update zu entfernten werten und chunk und segment header infos
• Idee Martin:
  • Das als Test schreiben, um das zu verifizieren, ob das gut klappt. Da kann man dann die chunk size usw variieren
• CompressedVectorType ID weiter nach vorne im Segment ziehen, da wir ja auch andere als Dictionary Segments unterstützen können
  • Muss am Anfang des Segments stehen!
• Was passiert, wenn wir mehrere Dateien für eine Tabelle haben? Müssen wir da noch was dazu speichern?
  • Storage.json meinte Tobias
• Martin unterstreicht: Schnell in Hyrise umziehen, um das mit evtl mit TPC-H laufen zu lassen
• Engineering Task:
  • Wo das alles hinpacken?
    • Vortragen, wo wir das hinpacken könnten
    • Wirklich alles in Storage manager?
    • Alles in die segmente?

Feedback:

• pseudocode für überblick, wenn mal was nicht funktioniert
• Assignment ins Github Board für wer welches Issue bearbeitet

Fragen:

• Wie lesen wir die Benchmark Dateien von TPC-H ein? Nehmen wir .csv und bauen dafür einen loader? Oder in binary files?
  • Wie sichergehen, dass Daten abgelegt werden? Wann werden die Daten eingelesen?
  • Database Storage dem Storage manager übergeben und dann wird da so viel ausgelsen wie möglich?
    • Stichwort: TPCH Table Generator

Feedback und Paper

Setup Beschreibung für die Benchmarks da rein packen

→ Idee: Overleaf schonmal starten und setup dort beschreiben

Benchmark Setup als Punkt

Related work

• andere nutzen mmap
• wir haben primär read workload
  • haben keine transaktionsschwierigkeiten nicht
• mmap paper kommen da rein

Mit eingeschränktem workload, der so und so aussieht schauen experimentel, wie gut es funktioneirt

Technischer Bericht geht auch! → aber sollte schon gut nahe am Paper sein, nicht larifari. Trotzdem gute Argumentation

→ Wir geben Gliederung vor und sie geben feedback dazu und passen an

TODO bis nächste Woche

• Ideen sammeln für wo das in Hyrise reinpasst → Präsentieren (2 Personen)
  • Wo findet der mmap call statt?
• File Format: Alle Chunks auslesen können, danach weg vom Playground
• Memcpy nicht mehr nutzen, span einführen → mmap nutzen
• Wie dicts mit span implementieren (1 Person)
  • Angepasste Segmente nutzen oder kopieren und umbauen
• Benchmarks
  • 1GB read sequential
  • Thread timing
  • neueste changes mit cache clearing rein
• Hyrise Tabelle in unser Format automatisiert bringen
  • Unser File Format
• Paper Outline und Story draften und vorstellen

Protokoll Weekly 06.02.23

• Progress
  • Mehrere Chunks können jetzt gelesen und geschrieben wereden
  • Benchmark Thread Start und Entzeitpunkte wurden gemessen
    • Zeitpunkte sehr ähnlich verteilt, es gibt aber Außreißer
    • V.a. bei 64 Threads große Varianz
    • Betreuer nicht überrascht über Varianz
  • Architecture
    • Verschiedene Dict Typen benutzen, vektor und span?
      • Erstmal ja
    • Was passiert wenn Segment während des Persistierens zugegriffen wird
      • Erstmal durch atomaren Tausch ausschließen
    • Der Chunk muss nicht mit Binärcode umgehen können
      • Evtl. könnte der SM die Segmente auf der MMAP konstruieren
      • Danach braucht der SM keine Referenzen auf seine Segmente, Hierarchie beibehalten
    • Ownership der Maps verbleibt im Storage Manager
    • Ist MMAP ein Buffer Manager oder ein Allokator / eine Memory Ressource
    • Wie sollen die Mappings im StorageManager verwaltet werden?
      • Maps, Buffer Pool
      • Anforderungen an den StorageManager müssen dringend zu Papier gebracht werden
      • DRAM or not DRAM
    • Chunk direkt persistieren?
      • Für Martin aktuell okay
      • Sicherste Methode
      • Performance vermutlich schlechter, allerdings gerade nicht wichtig
    • Mapping pro Map oder pro Chunk
      • Mmap limit unklar, wenn 65’000 Stimmt dann geht per Chunk nicht
  • Paper Outline
    • Zwei konkurrierende Ansätze
    • Fraglich ob wir weit genug kommen für unsere Ansätze
    • Focus: Mehr auf larger then memory als auf IO methoden
    • Vorsichtig mit dem Persitenezbegriff
    • Überprüfung von Pavlos Paper
    • Neue Drafts diese Woche
  • Next Steps
    • Implementierung und SM-Anforderungen blocken sich nicht
    • Anforderungen bis morgen Abend bestenfalls
    • Implememnierung sofort beginnen
    • Parallel arbeiten
    • nlohmann json
    • Langsam Dinge aus dem Playground rüberziehen

Protokoll Weekly 13.02.23

• Progress

  • Viel erreicht, aber alles noch nicht zusammengemergt

• Benchmarks

  • Thread-Laufzeitdifferenzen können jetzt automatisiert berechnet werden
  • Nochmal Benchmarks mit 100GB durchführen
  • Stefan mahnt zu genaueren Messungen fürs Paper
    • Threads laufen z.B. den Großteil der Zeit nicht gleichzeitig
    • Workstealing einbauen oder Bandbreite beobachten
    • Machbar aber es sollte überprüft werden ob es den Aufwand wert ist (Fokus liegt ja auf Hyrise)

• Storage.json

  • StorageManager::update_json() wurde implementiert
  • Unterstützt add_table(), drop_table() und write_chunk_to_disk()
  • Problem: Chunks werden bei Finalisierung geschrieben, sind zu diesem Zeitpunkt aber oft noch nicht im StorageManager eingecheckt
    • Daten für die Json fehlen
    • Chunks wissen wenig Metadaten
  • Martin: Chunks ohne Tabelle schreiben ergibt keinen Sinn, wenn das derzeit passiert muss es geändert werden
    • Bei den Benchmarks entstehen viele temporäre Tabellen die nicht geschrieben werden sollen
    • Chunk.finalize() soll nur geschrieben werden wenn auch im StorageManager eingecheckt
    • Chunks sollen weiterhin möglichst wenig wissen
      • Ggf. Schreibmethoden doch im Table oder StorageManager einbauen

• StorageManager-Interface

  • Wichtig zu wissen ob Chunk in DRAM oder auf Disk
    • Disk-Typen später differenzieren kein großer Aufwand
  • Unmapping sollte im Destruktor stattfinden
    • unique_ptr

• Zweites Meeting

  • Remote, Freitag 9:30 voraussichtlich

• Nächste Schritte

  • Bester Unittest ist TPC-H
  • Möglichst schnell dahinprügeln

Treffen: 17.02.2023

Thema: Storage Manager Interface

Moderator: Sandro

Protokoll: Theresa

1. Requirements

• Persist on which kind of disk a chunk is persisted
• To each chunk, store whether it is stored on disc or RAM
• After a chunk is finalized, replace its segments with SpanSegments
• Deleted Tables:
  • Unmap storage
  • Remove references from storage manager
• Map-Only for persisted chunks

2. Memory Regions

• How to unmap?
  • Memory Region
• Diskussion:
  • Marcel:
    • Von gemappter Memory Region Information speichern → welche Segmente Teile dieses AddressBereiches nutzen? Zu klärender Punkt. Das könnte mit MemoryRegionObjekt gespeichert werden als Statistik.
    • Mit Mmap müssen wir uns nicht um Laden/Schreiben von einzelnen Bereichen kümmern → MemoryRegion müsste sich nur um mmap und unmap kümmern.
  • Martin:
    • Könnte MemoryRegion auch DRAM Allokation handeln?
    • Vllt MemoryRegion umbennen → SegmentResourceManager → Komplette Allokation handeln?
    • Github Diskussion
    • Resource die Zuordnung wo liegen Segmente für alle regelt
  • Marcel:
    • Idee von MemoryRegion als Name: gerade haben wir managed MemoryRegion, für potentielle zukünftige Implementierungen (BufferPool) andere MemoryRegions, die wir selbst verwalten. Würde Speicherpointer etc. halten.
  • Martin:
    • Nicht zu viel Boilerplate → die zukünftig genutzt werden. Jetzt leichtgewichtig bleiben (20 Zeilen) um schnell vorwärts zu kommen. (Nicht langfristig planen und in kurzfristiger Arbeit einschränken.)
  • Marcel:
    • Speicherort→ Enum in Segmenttype speichern
  • Martin:
    • Muss nur einen Punkt locken im Segment statt großer Map, Statistiken etc. führen für Performancereasons. Im Segment → SingleSourceOfTruth
  • Theresa: Speicherverwaltung StorageMaanger
  • Marcel: Refernce Counting
  • Martin: Gerade ist das über SharedPointer gelöst → ReferenceCounting per Hand nicht machen.
  • Sandro: Was übernimmt StorageManager?
    • Hält: Liste von MemoryRegions, orchestriert leichter Zugang zu wo liegen Segmente → Interface nach außen → müssen nicht wissen wie Regions aussehen, FileHandling
  • Fazit:
    • MemoryRegion → Handle Memory
    • Discussion (Github-Feature) für MemoryLoctionStatistics → for future work
    • ReferenceCounting über SharedPointer handlen?
    • Nice To Have Feature: Wo liegt welches Segment → jetzt erstmal nicht machen.
      • Speicherort von Segment in Segment als Enum (Discussion: Statistik)
      • Stefan: Eig. lieber weglassen, weil wir es nicht brauchen und Implementierung easy ist

3. Open Discussion

• Marcel: Termonologie vereinheitlichen: MemoryRegion, AdressSpace, Map

Treffen: 17.02.2023

Bitpacking geht vmtl nicht Nachfrage, wie lesen wir die Datentypen der Spalten aus Vector bzgl der DictionarySegments - kommt der raus? DictionarySpan fliegt raus und könnte DictionaryData werden

Wer verwaltet den Speicher des Dictionary Segments? DictionaryEncoder als Vorschlag von Martin → Hört sich besser an Oder sollte das Dictionary das machen? Vectoren sollen aus den Segmenten rausfliegen

Bzgl Zeitplan Sieht gut aus Hook für finalize und Big Table support ist harte dependency TPC-H 100 schauen, obs in-memory durchläuft (eine Person fest, schauen, wann es crasht) TPC-H 1000 failt momentan wegen Statistiken schauen, ob Histogramme sequentiell erstell werden können

Wie schreiben wir die Daten auf disk? nicht mmap, wegen nicht sicherheit, wann write stattfindet system call write way to go kann man später noch flexibel ändern

Grafik ist zu abstrakt chunk is zuständig, die segmente mit span segments austauscht chunk gibt std:span an segment manager und erhält dann neuen pointer, mit dem er å bei sich austauscht chunk würde dafür ref auf storage manager benötigen hat er bei default schon, weil StorageManager singleton ist Teilt man sich memory mapped region oder kapselt sie das interface nur und gibt es eine region pro table? Thema Abstraktionsgrad der Memory Region ist gut Wie verwaltet der SM die MappedRegions? Doch erstmal alles im Storage Manager machen? Stefan gibt ein approve Im storage manager hat man files, im chunk die vektoren dict segments pfeil direkt als funktion machen replace_dict_segments() und unten nur der return type nähere gedanken über create_span_dict_segments call machen

Treffen 28.02.2023

"Stand Up"-Teil

• Martin: mehr aktiver anpingen

TPCH Ergebnisse

• Vergleich Hyrise Master <-> unser Stand
• schlechtere Ergebnisse mit Cache Reset --> Ist das valide?
  • Daten werden parallel zu den Queries geladen
  • Idee: Warmup Run nutzen, um zu erkennen, wann Daten geladen sind
• Welche Benchmarks sollten ausgeführt werden?
  • TPCH (weitere?)
• How to get SF 1000 running?
  • eher auf SF 100 gehen --> dafür Page Cache mit CGroups limitieren, um selben Effekt zu erkennen
  • andere Researchfrage: Rel. größe des SF zu Page Cache? Gibt es da Unterschiede?
• Welche Scalefaktoren?
  • SF > 10 (go for 100)
  • "keine DB läuft auf einem Thread"
  • immer für mehrere Threads gehen
• Wie viele Clients und Cores?
  • 2 Setups: Single Threaded mit n Clients + Multi-Threaded mit n Clients
  • Wie hat Ben das gemacht?

storage.json

• Setup sieht gut aus
• default Pfad für storage.json (kein DRAM-only mode)
• Problem: im Moment table_persist() schreibt und mapped
  • ändern, so dass schreiben und mappen unterschiedlich ist
  • "trennen"

100 GB Benchmarks

• Problem des Cache Clearings gelöst, durch nicht "wiederverwenden" von Dateien

End Presentation Content Präsentation

• Format: 30 min, am Lehrstuhl (theoretisch öffentlich, aber eigentlich nur EPIC Studis)

• "Further Work" umbennen zu "Related Work"

• SF anpassen an Maximum, das erreicht wird

• Viktor Leis Kritik an mmap erwähnen?

  • Keine hohe Priorisierung
  • wenn erwähnt, dann zusammen mit den Gründen, warum die Kritik keine große Rolle spielt (lesender Zugriff, sequentieller Zugriff, ...)

• Engineering sehr großer Teil

  • solte nicht unerwähnt bleiben, aber muss zur Story passen

• Was sollte Konsequenzen / Evaluierung / Diskussion sein?

  • Diskussion der IO Methoden
  • "Welche Konsequenzen hätte es eine andere IO Methode zu nutzen?"
    • "eingeschränkter Workload geht mit Performance-Senkung von X % einher"
    • Machbarkeit des Projektes hervorheben
  • Evaluierung: TPCH Ergebnissse
  • aktuell: Opener mit Ergebnisplot (Ergebnis von TPCH 1000)
  • --> Standard Paper Format

• grobe Struktur:

  1. Ziel
  2. Recap
  3. Experimentelle Evaluierung
  4. Wie gemacht?
  5. Next Steps

Weekly 6.3

• TPC-H Benchmark
  • Kein Padding mehr nötig
  • PR zum Reviewen von den Betreuenden wird gestellt
  • Ansätze fürs Benchmarken
    • Benchmarks sind nur durchgelaufen, weil CGROUPS nicht funktioniert
    • Prozess wird gekillt weil out of memory
      • Ansatz: Timer für Warm up und dann CGroups setzen, aber funktioniert bei uns scheinbar nicht
      • Idee: Testen, ob bin files vorhanden sind
      • Nachfrage Cores: Wie GB Verwendung von Cores lesen (CGroups) → sollte sich eig auf Prozess beziehen
    • Wollen physischen Speicher limitieren
    • Ziel: CGroups zum laufen kriegen
• Cold Start
  • Problem mit mvcc_data
    • Die Dateien beim Laden erstellen
    • Asserten, dass die Dateien nicht modifiziert wurden
  • So wenig wie möglich in die Storage Json schreiben
    • ist aber noch alles ok
  • Filename mapping ist kritisch, da Tabellen Namen sich auch ändern können → s. Postgres
    • Postgres hat directory, welches self contained ist
  • TODO Directory structure für unsere Lösung
  • Diskussionen im PR
• 100 GB Benchmarks
  • Müssen wir bei 10GB in batches schreiben?
  • PREAD skaliert bei 10GB garnicht
  • Warum nur zwei Methoden?
  • Haben wir unsere Ergebnisse mit den SSD Spezifikationen verglichen?
  • FIO mit 8 GBs
• Präsentation
  • 30min Präsentation
  • 15min diskussion
  • Donnerstag Abend + Freitag morgen ersten Entwurf schicken
• Weekly noch nach der final Präsi

Weekly 20.03.

Präsentation

• Marcel: Welche Stellen wollen wir uns noch anschauen? Welche Inhalte sollen noch im Report landen?

• Martin: Was dauert 2/5 Sekunden im ColdStart? Aufschlüsselung in wie lang -> Mapping/Query Time etc., evtl. Stacked Bar Chart, Intuition Mmap ist kostenlos

• Martin: Wieso 6GB -> Pagefaults reinzeichnen

• Martin: Dictionary Encoding: 10GB Raw Daten -> 10,5GB Dictionary In Memory? Wie viel Speicherplatz verbrauchen wir für .bin?

• Stefan: 12er -> Ein Ausreißer -> Disjunkte Mengen in PageCache, drum herum einmal messen

• Martin: Wieso bei 20GB so viel langsamer? Marcel: Profiling

• Measure:

  • Mmap-based ohne Cgroup - single-client, single-threaded, wenn das deutlich unter < 40000 Latency -> Cgroups / Cgroup Script
  • Hyrise Master etc.

• Generell erstmal alles noch mal exakter Messen.

• Graphen bei Latency 0 starten lassen

• Neues Benchmark statt: Cores = 2x Client -> Fix 48 Cores, increase Clients

• Realistic Scenario: Does mmap have overhead?

• Schnellstmögliche Latency -> 35sec auf schnellstem Master. -> Hyrise Master zu langsam

• How To IO-Methoden einbringen?

  • Komplett in Background
  • Zweiteilige Evaluierung -> Aspekte aufgreifen

• Report -> Lessons Learnt -> Benchmarking etc. PRead, Threading etc.

• Differing relative memory peaks

  • Verschiedene Ausführungstrategien zwischen 1GB und 10GB? Können da ungünstige Dinge rauskommen?

• Sauberes Larger Than Memory -> 5 GB von MMAP geschenkt

• Fokus worauf:

  • Integration Tests eher als Unit Tests (Flags, die weitergegeben werden etc., python integration tests mit pexpect wie z.B. hyrise server test)
  • Reproduzierbarer Code eher als PR-Ready

• Noch eine Iteration für Code -> im Verlauf der Woche, Anpingen für PR

• Feedback auf Paper -> Ende der Woche