SQLite: Wal2-Modus

Aktivieren/Deaktivieren des Wal2-Modus

• Der "Wal2"-Modus von SQLite ist dem "wal (Write-Ahead Logging)"-Modus sehr ähnlich.
• Um eine Datenbank in den wal2-Modus zu versetzen, verwenden Sie den Befehl PRAGMA journal_mode = wal2;.
• Ein direkter Wechsel vom "wal"-Modus in den "wal2"-Modus ist nicht möglich; zuerst muss in den Rollback-Modus gewechselt werden.
• Um eine Datenbank im wal-Modus in den wal2-Modus umzuwandeln, verwenden Sie nach PRAGMA journal_mode = delete; den Befehl PRAGMA journal_mode = wal2;.
• Auf Datenbanken im wal2-Modus kann nur mit SQLite-Versionen zugegriffen werden, die aus diesem Branch kompiliert wurden.
• Wenn versucht wird, eine andere SQLite-Version zu verwenden, tritt der Fehler SQLITE_NOTADB auf.
• Um eine Datenbank im wal2-Modus wieder in den Rollback-Modus zu versetzen, sodass sie mit allen SQLite-Versionen zugänglich ist, verwenden Sie den Befehl PRAGMA journal_mode = delete;.

Vorteile des Wal2-Modus

• Im bisherigen wal-Modus verändert ein Writer beim Schreiben von Daten in die Datenbank die Datenbankdatei nicht direkt, sondern hängt neue Daten an die Datei "-wal" an.
• Lesevorgänge lesen Daten sowohl aus der ursprünglichen Datenbankdatei als auch aus der Datei "-wal".
• Zu einem bestimmten Zeitpunkt werden Daten aus der Datei "-wal" in die Datenbankdatei kopiert; dies wird als "Checkpoint" bezeichnet.
• Checkpoints können explizit über PRAGMA wal_checkpoint oder sqlite3_wal_checkpoint_v2() ausgeführt oder durch Setzen von PRAGMA wal_autocheckpoint automatisch durchgeführt werden (Standardeinstellung).
• Der Checkpointer blockiert den Writer nicht, und der Writer blockiert auch den Checkpointer nicht.
• Wenn der Writer jedoch während eines Checkpoints in die Datenbank schreibt, werden neue Daten an das Ende der wal-Datei angehängt, sodass die wal-Datei weiter wachsen kann.
• Im wal2-Modus tritt das Problem nicht auf, dass die wal-Datei unbegrenzt wächst, selbst wenn der Checkpointer keine Gelegenheit hat, ungestört abgeschlossen zu werden.
• Im wal2-Modus werden statt einer zwei wal-Dateien ("-wal" und "-wal2") verwendet.
• Beim Schreiben von Daten beginnt der Writer damit, neue Daten an die erste wal-Datei anzuhängen.
• Wenn die erste wal-Datei groß genug ist, beginnt der Writer, Daten an die zweite wal-Datei anzuhängen.
• Danach kann die erste wal-Datei checkpointed werden, und sobald die zweite wal-Datei groß genug ist und die erste Datei checkpointed wurde, wird wieder zur ersten Datei zurückgewechselt.

Anwendungsprogrammierung

• Aus Sicht des Benutzers besteht der Hauptunterschied zwischen wal- und wal2-Modus in den Checkpoints.
• Im wal-Modus kann jederzeit versucht werden, einen Checkpoint auszuführen; im wal2-Modus ist ein Checkpoint jedoch erst möglich, nachdem der Writer zur "anderen" wal-Datei gewechselt hat.
• Im wal-Modus wird der wal-hook (Callback) nach dem Commit einer Transaktion mit der Gesamtzahl der Seiten in der wal-Datei als Argument aufgerufen.
• Im wal2-Modus wird der wal-hook entweder mit der Gesamtzahl der noch nicht checkpointed Seiten in beiden wal-Dateien als Argument aufgerufen oder mit 0, wenn die "andere" wal-Datei leer ist oder bereits checkpointed wurde.
• Es wird empfohlen, dass Clients für Datenbanken im wal2-Modus dieselbe Checkpoint-Strategie wie im wal-Modus verwenden.
• Der wal-hook wird aufgerufen, nachdem die Transaktion auf die Festplatte committet und die Datenbanksperre freigegeben wurde, erfolgt aber innerhalb des Aufrufs von sqlite3_step().
• In BEGIN CONCURRENT-Systemen kann statt eines Checkpoints innerhalb des wal-hook ein Thread verwendet werden, der diese Arbeit verzögert, bis der Application-Mutex freigegeben wurde.

Meinung von GN⁺

• Der wal2-Modus von SQLite bietet ein neues Journaling-Verfahren, das die Parallelität und Effizienz der Datenbank verbessert.
• Es ist wichtig, das Problem des unbegrenzten Wachstums der wal-Datei zu lösen, um Stabilität und Leistung des Systems zu verbessern.
• Entwickler sollten durch die Einführung des wal2-Modus ihre Checkpoint-Strategie für Datenbanken überdenken und geeignete Checkpoint-Logik für eine bessere Parallelität implementieren.

[GN⁺]

Hacker-News-Kommentare

• Im WAL2-Modus werden statt einer zwei WAL-Dateien verwendet. Die Dateien heißen "<Datenbank>-wal" und "<Datenbank>-wal2". Wenn Daten in die Datenbank geschrieben werden, beginnen Schreibvorgänge damit, neue Daten an die erste WAL-Datei anzuhängen. Wenn die erste WAL-Datei groß genug wird, wechseln die Schreibvorgänge dazu, Daten an die zweite WAL-Datei anzuhängen. An diesem Punkt kann die erste WAL-Datei checkpointed werden (und danach überschrieben werden), und wenn die zweite WAL-Datei groß genug geworden ist und die erste Datei checkpointed wurde, wird wieder zurück zur ersten WAL-Datei gewechselt. Dieser Prozess setzt sich fort.

  • Dieser Ansatz ist so logisch, dass ich nicht verstehe, warum der WAL-Modus nicht von Anfang an so implementiert wurde. Vielleicht galt es als vorzeitige Optimierung.
  • Ich hoffe, dass dieser Modus allgemein verfügbar wird.

• Bedrock

  • Bedrock ist der interessantere Branch.
  • Enthält die Funktionen WAL2 + CONCURRENT.
  • Das ist der Branch, den Expensify verwendet, um auf einem einzelnen Node auf bis zu 4M QPS zu skalieren (vor 6 Jahren).

• Verweis auf das left-right primitive, eine dem WAL2-Modus ähnliche Technik.

  • Diese Technik ist älter als die verlinkte Implementierung, wurde aber unabhängig wiederentdeckt und insbesondere geschrieben, um eine andere High-Performance-SQL-Datenbank namens Noria zu unterstützen.

• Im WAL2-Modus werden statt einer zwei WAL-Dateien verwendet. Die Dateien heißen "<Datenbank>-wal" und "<Datenbank>-wal2".

  • Ich frage mich, wie viele Leute die wal-Datei löschen werden. Da auf wal2 umgeschaltet wurde, könnten sie denken, dass die wal-Datei nur übrig geblieben ist.

• Microsoft SQL Server verwendet eine ähnliche Architektur, weist aber innerhalb der physischen (auf der Festplatte liegenden) Log-Datei Virtual Log Files (VLF) zu, statt separate Log-Dateien zu verwenden. VLFs werden in einem Ringpuffer zugewiesen und es kann Tausende davon geben.

• Man sieht, dass dieses Feature noch nicht veröffentlicht ist.

• Ich habe mir immer Sorgen darüber gemacht, dass WAL eigentlich dazu da ist, Datenintegrität zu gewährleisten und bei Abstürzen die Wiederherstellung zu unterstützen. Die Datei selbst wird jedoch in Batches geschrieben (zuverlässig auf die Festplatte committed) und nicht nach jeder einzelnen Änderung an der Datenbank, um Performance zu gewinnen. Untergräbt das nicht den Zweck? Allgemein, nicht nur auf Datenbanken bezogen, konnte ich darauf keine Antwort finden.

• Ich frage mich, welche Auswirkungen das auf neue verteilte SQLite-Systeme wie Litestream haben wird.

• Ist das also im Grunde Double Buffering für die Datenbank? Ergibt Sinn.

• Der WAL2-Modus wurde in die Benchmarks der HC-tree-Backend-Forschung aufgenommen.