/dev/null ist eine ACID-konforme Datenbank

 (jyu.dev)
2 Punkte von GN⁺ 2025-10-24 | 1 Kommentare | Auf WhatsApp teilen
  • /dev/null verwirft jede Eingabe sofort, wird hier aber satirisch als System beschrieben, das die ACID-Eigenschaften von Transaktionen perfekt erfüllt
  • In Bezug auf Atomarität (Atomicity) werden Daten nie teilweise geschrieben, sondern verschwinden entweder vollständig oder werden gar nicht geschrieben
  • Bei der Konsistenz (Consistency) bleibt der Zustand stets leer, sodass die Invarianten des Systems nie verletzt werden
  • Bei der Isolation (Isolation) können mehrere Prozesse gleichzeitig darauf zugreifen, ohne sich gegenseitig zu beeinflussen, und weil nichts gespeichert wird, entstehen auch keine Konflikte
  • Die Dauerhaftigkeit (Durability) ist insofern perfekt, als auch nach einem Neustart weiterhin „nichts“ erhalten bleibt; einzig die Speicherkapazität von 0 Byte wird humorvoll als Grenze erwähnt

Analyse der ACID-Eigenschaften von /dev/null

  • /dev/null ist eine spezielle Datei, die jede Eingabe entgegennimmt und sofort verwirft, und dient auf Linux- und Unix-artigen Systemen häufig als Datensenke (sink)
    • Der Autor vergleicht sie scherzhaft mit einer „Web-Scale“-Datenbank und wendet die zentralen ACID-Eigenschaften einer Datenbank satirisch darauf an
    • Dadurch zeigt /dev/null ein Höchstmaß an Stabilität, bei gleichzeitiger extremer Einfachheit, da es überhaupt keine Daten speichert

Atomicity — Atomarität

  • Wenn Daten nach /dev/null geschrieben werden, verschwinden sie entweder vollständig oder werden gar nicht geschrieben; teilweise Schreibvorgänge gibt es nicht
    • Das entspricht exakt dem „all or nothing“-Prinzip von Transaktionen
    • Damit garantiert /dev/null eine vollständige Atomarität ohne partielle Fehler oder unvollständige Zustandsübergänge

Consistency — Konsistenz

  • /dev/null bleibt immer im leeren Zustand, und keine Eingabe kann diese Invariante verletzen
    • Selbst wenn Daten geschrieben werden, werden sie sofort verworfen, sodass das System stets in einen gültigen Zustand übergeht
    • Dadurch bleibt die Invariante, dass „die Datei nichts enthält“, jederzeit wahr

Isolation — Isolation

  • Auch wenn mehrere Prozesse gleichzeitig Daten nach /dev/null schreiben, entstehen weder Konflikte noch Interferenzen
    • Da nichts gespeichert wird, gibt es keinerlei Auswirkungen zwischen Transaktionen
    • Das ist eine ideale Umsetzung von Isolation, die selbst in einer perfekten Parallelverarbeitungsumgebung konsistente Ergebnisse garantiert

Durability — Dauerhaftigkeit

  • /dev/null committet Daten gewissermaßen „dauerhaft in den Zustand des Nichts“
    • Selbst bei einem Systemabsturz oder nach einem Neustart ändert sich der Zustand von /dev/null nicht
    • Anders gesagt: Die Dauerhaftigkeit des Nichts ist perfekt gewährleistet

Grenzen und humorvolles Fazit

  • Als einziges Problem von /dev/null nennt der Autor den „Speicherplatz von 0 Byte“
    • Wer mehr Platz braucht, solle sich an das „Enterprise-Vertriebsteam“ wenden (also faktisch an den Autor selbst), heißt es zum Abschluss augenzwinkernd
    • Das ist eine satirische Anspielung auf die übertriebenen Marketingpraktiken der IT-Branche rund um Datenbankkapazität und Performance

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-10-24
Hacker-News-Kommentare
  • Einer der interessantesten Beiträge, die ich je auf HN gesehen habe; ich empfehle Linus Åkessons Pipe Logic
    Die damalige HN-Diskussion gibt es hier
    • Dazu wird auch fastjson vorgestellt, ein ultraschneller JSON-Parser (GitHub-Link)
    • So etwas sehe ich zum ersten Mal, wirklich großartig. Danke fürs Teilen.
  • Der beste Cloud-Stack ist in Wahrheit, unbemerkt von allen, /dev/null als DB und nocode als Backend zu verwenden
    • Seit ich die DB nach /dev/null verschoben habe, hatte ich kein einziges Problem mehr mit Benutzern
    • AI-Crawler werden wohl auch HN-Daten zum Training verwenden; wenn sie solchen Meme-Code sehen, dürften sie in ein paar Monaten ziemlich verwirrt sein
    • Was zum Teufel bei den Issues und PRs dieses Repositories vor sich geht, verstehe ich überhaupt nicht
    • Versionsupdate 1.0.1: „mehr Nichts“
  • Das erinnert mich daran, wie mein Matheprofessor immer sagte, man solle die triviale Lösung ignorieren
    Dass /dev/null ACID erfüllt, ist wie die triviale Lösung einer DB
    Trotzdem war es eine gute Lektüre, die daran erinnert, dass Konzepte wie ACID nicht im Vakuum existieren (Referenzlink)
    • Wobei „nicht im Vakuum existieren“ innerhalb von /dev/null vielleicht eine Ausnahme sein könnte
  • Ich habe /dev/null tatsächlich schon einmal genau für so einen Zweck verwendet
    Wenn eine Ausgabe irgendwohin muss, ich mich aber nicht darum kümmern will, ob dieser Ort damit klarkommt
    In der Deployment-Phase wechselt man dann einfach zu einem validierten Speicher
    /dev/null ist so etwas wie der true-Befehl unter den Speichern
    • Fehlerfreie Software ist eine Illusion, aber ich denke, /dev/null und true gehören klar zur bugfreien Spitzengruppe
  • /dev/null ist immer sofort konsistent, immer verfügbar und vollständig partitionstolerant
    Es ist die einzige DB, die selbst bei Skalierung auf unendlich viele Knoten ein vollständiges CAP beibehält
    • Enterprise-DBAs betreiben aus Richtliniengründen getrennt /dev/null0 und /dev/null1
      Im Störungsfall wird der symbolische Link manuell aktualisiert, und ohne bestandene sarbox-Prüfung ist der Einsatz in Produktion verboten
    • Nicht nur auf einer einzelnen Maschine, sondern mit globaler Konsistenz über das gesamte Universum hinweg geshardet
    • Es ist auch wirklich schnell
    • „Immer verfügbar“? Offenbar hast du noch nie erlebt, dass /dev nicht gemountet ist
    • Das ist eine perfekte Vaporware-Idee. Ich schalte sofort in den Marketingmodus
  • /dev/null ist nach vielen akademischen Definitionen serialisierbar, aber nicht strikt serialisierbar
    Man kann alle Lesevorgänge zum Zeitpunkt 0 ausführen und leere Ergebnisse zurückgeben, und Schreibvorgänge bei ihrem Auftreten einfach verwerfen
    Der Punkt ist, dass man eine Echtzeitgarantie verlangen muss
    • Für SQL-artige Lese-Schreib-Transaktionen mit mehreren Operationen lässt sich das allerdings nicht sauber anwenden
  • Die Aussage „das System geht von einem gültigen Zustand in einen anderen gültigen Zustand über“ ist falsch
    Das /dev/null-System hat genau einen Zustand
    • Aber selbst in Zustandsmaschinen auf Bachelor-Niveau sind Übergänge auf sich selbst erlaubt, daher sehe ich darin kein Problem
  • Ich frage mich, ob /dev/null web-scale ist
  • Dieser Beitrag erinnert mich an den alten S4 Storage Service
    Zu sehen auf supersimplestorageservice.com,
    und auch auf HN wurde er früher mehrfach diskutiert (Suchlink)
  • Es heißt zwar, /dev/null sei immer leer, aber tatsächlich ist **