Jeder schnelle Schreibvorgang verschiebt die Arbeit woanders hin
Every fast write moves work somewhere else
Jede Storage-Engine muss entscheiden, was abgeschlossen sein muss, bevor sie einem Client einen erfolgreichen Schreibvorgang meldet. Der schnellste Weg ist, nach dem Kopieren der Bytes in den Speicher zurückzukehren. Ein lokaler, dauerhafter Schreibvorgang wartet auf `fdatasync()` auf einer SSD im Datenbank-Host. Wenn der Schreibvorgang auch den Verlust dieses Hosts überleben soll, muss man auf ein Netzwerkvolume, einen Objektspeicher oder mehrere Datenbankserver warten. Diese Wahl verschiebt Latenz und Dauerhaftigkeit: Speicher ist schnell, aber ein Maschinenabsturz kann den Schreibvorgang verlieren. Ein lokales SSD überlebt Prozess- oder Kernel-Abstürze, aber nicht den Verlust des Geräts oder Hosts, während Remote-Speicher oder mehrere Server mehr Ausfälle überleben, indem sie Netzwerk- und Kopierzeit in jeden Schreibvorgang investieren. Der Artikel untersucht, wie ein einzelner Client-`PUT` durch Speicher, lokale SSD, Remote-Speicher und eine dauerhafte Mehrheit von Datenbankservern läuft, und warum ein schneller Benchmark ohne Kontext irreführend sein kann.
Ein lokaler WAL ist verlockend, weil die Latenzlücke groß sein kann: AWS beschreibt S3 Express One Zone mit konsistenten einstelligen Millisekunden-Latenzen, während ein lokales `fdatasync()` bei 1 ms etwa 6x schneller wäre – aber die beiden Pfade überleben auch unterschiedliche Ausfälle.