PGSimCity – PostgreSQLs Funktionsweise als erkundbare 3D-Stadt visualisiert

 (nikolays.github.io)
2 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Eine 3D-Lernsimulation, die Verbindungen, Backends, Shared Memory, WAL, Storage, Checkpoints, Autovacuum und Replikation von PostgreSQL als Gebäude und Bezirke darstellt; jedes Gebäude und jede Animation entspricht einem realen Datenbankmechanismus
  • Zahlen und Größenordnungen wurden reduziert, damit sich interne Abläufe in einem verlangsamten Zeitmaßstab beobachten lassen, etwa die Clock-Sweep-Ersetzung von shared_buffers, WAL-Schreiben und -Flush, Checkpoint-Pacing, der xmin-Horizont und Tabellen-Bloat
  • Kein Emulator, der echten PostgreSQL-Code ausführt, sondern ein von Hand geschriebenes Modell; auf Basis der PostgreSQL-Dokumentation und des Quellcodes wurde es dreimal fachlich geprüft, zusätzlich visuell auditiert, und 210 Tests fixieren zentrale Berechnungen und Grenzwerte
  • Szenarien wie Buffer-Knappheit, lang laufende Transaktionen, Checkpoint-Stürme, synchronous_commit=off und langsames Replikations-Replay zeigen direkt, wie Betriebsparameter Latenz, Bloat, Dauerhaftigkeit und Replikationsverzögerung beeinflussen
  • Eine statische WebGL2-Anwendung mit three.js/TypeScript/Vite; als mögliche Richtung wird künftig auch eine Hybridarchitektur geprüft, die Abfrageergebnisse und Pläne eines echten WebAssembly-PostgreSQL mit dem aktuellen internen Modell verbindet

Wie PostgreSQL als Stadt dargestellt wird

  • PGSimCity ist ein unabhängiges, nichtkommerzielles Lern-Visualisierungsprojekt, in dem man die interne Struktur von PostgreSQL begehen und erkunden kann
  • Der zentrale Platz steht für shared_buffers; die Höhe der 1.024 Page-Frames zeigt den Clock-Sweep-usage_count, die Farbe den tatsächlichen Buffer-Zustand
  • Der orangefarbene Bezirk im Osten steht für WAL, die Ausgrabung unter dem Platz für das Datenverzeichnis, die Stadt im Süden für einen Standby-Server, der das vom Primärserver gesendete WAL mit leichter Verzögerung wiedergibt
  • Entwickelt wurde es, damit Engineers ohne eigene Betriebserfahrung mit Datenbanken die folgenden Phänomene verstehen können
    • warum Checkpoints die Latenz stark ansteigen lassen
    • wie eine nicht beendete Transaktion Tabellen-Bloat fortbestehen lässt
    • welche Kosten synchronous_commit beim Commit verursacht

Genauigkeit und Grenzen des Modells

  • PGSimCity ist derzeit ein Modell im 0.x-Stadium und kein PostgreSQL-Emulator
    • Es führt keinen PostgreSQL-Quellcode aus
    • Zahlen und Zeitskalen werden angepasst, damit Menschen Veränderungen sehen können
    • Es parst kein SQL und berechnet keine echten Abfrageergebnisse
  • Die Genauigkeit des PostgreSQL-Verhaltens wurde in drei fachlichen Reviews gegen postgresql.org/docs und den Quellcode abgeglichen; jeder Fund wurde von einem separaten Reviewer, der ihn widerlegen sollte, erneut geprüft
  • Auch Aussagen, die implizit durch Gebäudeanordnung, Nachbarschaften und Animationen entstehen, wurden separat auditiert
  • Enthalten sind 210 Tests; bei fehlschlagenden Tests wird der CI-Build gestoppt
    • WAL-basierter Checkpoint-Startpunkt: max_wal_size / (1 + checkpoint_completion_target)
    • Cache-Hit-Rate: blks_hit / (blks_hit + blks_read)
    • Maximalwert des Clock-Sweep-usage_count: 5
  • Gefundene Fehler und der Korrekturprozess sind in der Commit-Historie festgehalten
  • Touch-Bedienung ist bislang nur in der mobilen Chrome-Emulation verifiziert
  • Vereinfachte Verhaltensweisen werden im Inspector der jeweiligen Komponente ausdrücklich genannt

Möglichkeit der Kopplung mit einer echten Engine

  • Aktuell wird eine eigens geschriebene Simulation verwendet, um interne Schritte zu zeigen, die PostgreSQL nach außen nicht offenlegt, etwa wie Clock-Sweep Frame für Frame eine Opfer-Page auswählt
  • Würde man echtes PostgreSQL wie bei PGlite in WebAssembly ausführen, könnten Abfrageergebnisse und Ausführungspläne der echten Engine überlassen werden
  • Die Informationen, die eine echte Engine im Browser bereitstellen kann, sind auf das beschränkt, was PostgreSQL nach außen veröffentlicht, etwa Catalog, pg_stat_*-Views und EXPLAIN
  • Eine Hybridlösung, bei der echte Ausführung und echte Pläne die Bewegungen im Modellinneren antreiben, wäre ebenfalls möglich, ist aber eine künftige Richtung und keine verbindliche Entwicklungszusage

Bezirke und Komponenten der Stadt

  • Client sky: eingehende Verbindungen aus der Anwendungsschicht
  • Postmaster: Supervisory-Prozess, der pro Verbindung einen Backend-Prozess erzeugt, aber nicht direkt auf Nutzerdaten zugreift
  • Backend row: 16 Backend-Prozesse; Leuchten zeigen den aktuellen Status inklusive idle in transaction
  • Shared memory plaza
    • shared_buffers
    • wal_buffers
    • ProcArray
    • Lock-Tabelle
    • CLOG
    • Buffer-Mapping-Tabelle
  • The excavation: Grenze zwischen Speicher- und Plattenbereich
  • Storage
    • Heap-Dateien aus 8-KiB-Pages
    • B-Tree in tatsächlicher Baumform
    • TOAST
    • FSM
    • Visibility Map
    • Betriebssystem-Page-Cache
    • Festplatte
  • WAL district: walwriter → pg_wal-Segmente → archiver → walsender
  • Maintenance yard: checkpointer/background writer/autovacuum launcher und Worker
  • Standby: walreceiver/Startup-Prozess, der WAL wiedergibt/Verzögerung zwischen den beiden Prozessen
  • Query lab: zeigt die Anweisung des ausgewählten Backends aufgefächert in die Phasen parse → rewrite → plan → execute

Farben und visuelle Bedeutung

  • Farben sind keine Dekoration, sondern vermitteln Zustand und Mechanismus
    • WAL: Orange
    • Dirty Page: Rot
    • Clean Page: Blau
    • Vacuum: Violett
    • Checkpoint: Pink
    • Background Writer: Türkis
    • Replication: Orange
    • Storage: Grün
    • Index: Aqua
    • Lock: Rot
  • Strukturen sind matt dargestellt, bedeutungstragende Elemente in Neon; nur emittierende Materialien überschreiten den Bloom-Schwellenwert

Szenarien zum Ausprobieren

  • shared_buffers auf 64 Pages verkleinern
    • Der usage_count bricht ein und der Clock Hand rotiert schnell
    • Weil nicht genug Clean Pages zum Entfernen vorhanden sind, beginnen Backends, ihre eigenen Dirty Pages direkt zu schreiben
  • Long-running transaction aktivieren
    • Der xmin-Horizont im ProcArray sinkt und wird rot
    • Autovacuum-Worker laufen weiter im Kreis, können aber keine aufzuräumenden Tupel entfernen
    • Die Tabelle sessions bläht sich auf und erholt sich nicht
  • Checkpoint storm ausführen
    • Der Checkpointer beschleunigt, und die fsync-Phase gerät ins Wanken
    • Anschließend strömen Full-Page Writes in großer Menge in den WAL-Bezirk
  • synchronous_commit=off setzen
    • Backends warten nicht mehr in commit_wait
    • Man kann zugleich die Dauerhaftigkeitsbedingungen sehen, die gegen sofortige Antwort eingetauscht wurden
  • Slow replay aktivieren
    • Die sent/written/flushed/applied LSNs des Standby-Servers driften auseinander
    • Diese Differenz entspricht der Replikationsverzögerung, die man in pg_stat_replication beobachtet
  • Mit der Taste G wechselt man auf eine Gehperspektive in 1,7 m Höhe und kann Buffer und Gebäude auf Augenhöhe betrachten

Navigation und Bedienung

  • Maus- und Touch-Bedienung
    • Linkes Ziehen: bewegen wie beim Verschieben einer Karte
    • Rechtes Ziehen: um die Stadt rotieren
    • Mausrad: relativ zur Cursorposition hinein-/herauszoomen
    • Ein Finger: bewegen
    • Zwei Finger: zoomen, rotieren, Neigung ändern
  • Bewegungsmodus
    • W/A/S/D oder Pfeiltasten: bewegen
    • Space/E: aufsteigen
    • C/Q: absteigen
    • Shift: schnelle Bewegung
    • Alt: präzise Bewegung
  • Wichtige Tasten
    • F: Flug-/Orbit-Kamera umschalten
    • G: Gehen am Boden
    • H: zur anfänglichen Gesamtansicht zurückkehren
    • T: Tour mit 14 Kapiteln durch die ganze Stadt
    • / oder Ctrl-K: Komponenten/Einstellungen/Szenarien suchen
    • ?: Tastaturbelegung und Farblegende
    • K oder P: pausieren/fortsetzen
    • ,/.: Geschwindigkeit von 0,1× bis 5× einstellen
    • 1~8: zu den Bezirken clients/backends/shared buffers/WAL/storage/checkpointer/autovacuum/standby springen

Lizenz und Marken

  • Veröffentlicht unter der Apache-2.0-Lizenz
  • Enthält keinen Code, keine Assets, Bilder, Logos, Charaktere, Audiodateien oder Spielinhalte von SimCity
  • Ein unabhängiges Bildungsprojekt ohne Verbindung, Sponsoring oder Freigabe durch Electronic Arts oder das PostgreSQL-Projekt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Hacker-News-Kommentare

  • Mir gefällt die Richtung, die hier eingeschlagen wird, wirklich sehr, aber die Tour-Funktion hat viel zu viel Rauschen. Auf dem Bildschirm ändern sich ständig unzählige Kästen und Elemente, sodass schwer zu erkennen ist, was passiert; außerdem sollte der Nutzer selbst weiterklicken können, statt automatisch zum nächsten Thema zu wechseln.
    Wenn man die auf einmal hereinprasselnden Informationen nur passiv anschaut, ist das verwirrend. Der Ansatz, die internen Abläufe der Technologie zu zeigen, ist an sich nützlich, aber statt noch mehr Daten, Grafiken und Info-Boxen hinzuzufügen, sollte der Fokus enger gesetzt werden.

    • 80 % der schicken 3D-Ansicht werden von Pop-ups verdeckt. Es wäre gut, eine gut sichtbare Funktion zum einfachen Reduzieren des Rauschens anzubieten und die Pop-ups halbtransparent zu machen.
    • Es wäre einen Versuch wert, der Tour TTS hinzuzufügen.
    • Wenn Software eine Tour-Funktion braucht, kann das ein Zeichen dafür sein, dass die UX verbessert werden sollte. Auch wenn man neue Funktionen bekannt machen möchte, entdecken Nutzer sie ganz natürlich, wenn sie sie brauchen.

  • Die Grenzen des menschlichen Gehirns sind für Entwickler und Nutzer gleich. Selbst wenn man mit LLMs Komplexes bauen kann: Wenn die dekorative Komplexität von Greebles ein gewisses Maß überschreitet, fühlt es sich nicht mehr so an, als wäre es für andere Menschen zum Erleben entworfen.
    Hätte man es ohne LLM gebaut, hätte der Entwickler das gesamte mentale Modell vermutlich nicht im Kopf behalten können und deshalb die Komplexität reduziert; Nutzer haben dieselben Grenzen. Selbst wenn man versucht, die Metaphern aus Animationen und blinkenden Lichtern zu verstehen, geht die Bedeutung darin unter.
    Ich verstehe nicht, warum ein neuer Prozess ein Rechteck ist, das durch ein Rohr fährt und bei einem Gebäude ankommt, und danach ein Flipper-Schalter rot aufleuchtet. Wenn man etwas anklickt, erscheint kurz ein kleines Pop-up mit "sessions is the victim" und einem Absatz und verschwindet wieder, was es noch verwirrender macht.
    Vielleicht ist es auch gar nicht als Lehrmaterial gedacht, und vielleicht fehlt mir auch das Wissen, aber als kurioses Werk betrachtet ist es ziemlich cool.

  • Als ich den ersten Bildschirm sah, erwartete ich, dass man eine Query eingibt und dann den gesamten Ablauf vom Parsen der Eingabe bis zur Rückgabe des Ergebnisses Schritt für Schritt gezeigt bekommt, und dass man außerdem autonome Prozesse versteht, die unabhängig von der Query parallel ständig laufen.
    Der Versuch an sich ist großartig, aber ich weiß nicht, wo ich anfangen und wo ich aufhören soll.

    • Drück mal T.

  • Um das Scheduling im Inneren einer Datenbank zu verstehen, brauchte man früher unzählige Architekturdiagramme. PGSimCity überrascht, weil es komplexe technische Implementierungsabläufe spannend darstellt.
    Da es Open Source ist, scheint sich dieselbe Idee auch in anderen Bereichen wie Cloud Computing oder Kubernetes wiederverwenden zu lassen.

    • Ich wollte schon immer ein Tool bauen, das das Deployment-System und State-Tracking von Fly.io mit Factorio als visueller Metapher erklärt.
    • Ich möchte weiterhin ein Visualisierungstool für Kubernetes bauen. Es gibt zwar schon bestehende Tools, aber als ich sie mir zuletzt angesehen habe, wirkten sie nicht besonders überzeugend.

  • Das ähnelt sehr dem Bild, das ich im Kopf habe, wenn ich ein Programm mit gdb debugge und tief konzentriert bin. Wenn man VR-Debugging mit solcher Grafik erleben könnte, gäbe es wohl keine bessere Methode, eine Codebase zu lernen.
    Ich frage mich, wie gut eine Erfahrung man erzeugen könnte, wenn man aus beliebigem Code eine 3D-Karte generiert.

  • Wenn das ein Vibe-Coding-Ergebnis von weniger als 48 Stunden ist, frage ich mich, ob der Inhalt tatsächlich korrekt ist. Besteht nicht die Gefahr, dass es zu falschen Schlussfolgerungen oder Halbwissen führt?

    • Ganz sicher kann man sich nicht sein, aber die Person, die das gebaut hat, kennt Postgres sehr gut.
    • Ich frage mich, ob man hier konkret etwas herausfinden oder lernen kann. Für mich wirkt es wie ein brutalistisches Deko-Objekt.
    • Die Genauigkeit von LLMs ist heutzutage nicht mehr so schlecht.

  • Kaum zu glauben, dass "Rendering The First Frame..." nicht "Reticulating Splines..." ist. Die UI ist cool.

  • Ich kenne die interne Struktur von Postgres ziemlich gut, war aber eher verwirrt. Der Bildschirm ist zu unruhig und schwer zu verstehen; zumindest wäre ein Button zum Verlangsamen gut.

    • Unten links gibt es zwei Buttons zum Pausieren und zum Einstellen der Geschwindigkeit bis auf 0,1×. Bei einigen Elementen der Stadt kann man per Klick Werte anpassen; ich habe das auch bei transactions/s gesehen.

  • Es sieht wirklich cool aus. Vor ein paar Wochen habe ich angefangen, per Vibe Coding Doom für Beam zu bauen, bei dem man durch die Beam VM wie über eine Fabrikhalle läuft und die Verbindungen zwischen Modulen und Funktionen, Ausführungslast und funkensprühende Fehler sehen kann.
    Viel habe ich noch nicht gebaut, aber ich möchte weiter daran entwickeln – schon als Rechtfertigung, mir ein VR-Headset zu kaufen.

  • Es sieht so aus, als sei es mit Hilfe von AI gebaut worden. Ich habe ebenfalls mit AI ein ähnliches Vibe-Coding-Projekt umgesetzt, das katastrophales Vergessen erklärt.
    Ich bin zufrieden damit, dass man sich jetzt jederzeit von AI helfen lassen kann, wenn man wirklich etwas lernen möchte. Früher war es schwer, gute Materialien zu finden; heute verlagert sich der Flaschenhals weg vom Material hin zur eigenen Konzentration und Eigeninitiative.