Änderung am Standarddauerhaftigkeitsmodus in IndexedDB

Der Standardmodus für die Datenbeständigkeit in IndexedDB wird ab Chrome 121 von strict zu relaxed geändert. Diese Anpassung dient dazu, die Leistung zu verbessern und sie an andere gängige Browser wie Firefox und Safari anzugleichen. Im Blogpost werden die Details dieser Änderung und ihre Auswirkungen auf Webentwickler erläutert.

IndexedDB-Haltbarkeitsmodi

IndexedDB ist eine leistungsstarke Web-API zum Speichern großer Mengen strukturierter Daten. Sie bietet zwei Beständigkeit-Modi für readwrite-Transaktionen:

  • strict:In diesem Modus wird das Betriebssystem explizit angewiesen, Änderungen auf die Festplatte zu schreiben, bevor das complete-Ereignis ausgegeben wird.
  • relaxed: In diesem Modus wird das standardmäßige Flushing-Verhalten des Betriebssystems verwendet und das complete-Ereignis wird ausgegeben, nachdem Änderungen in den Betriebssystempuffer geschrieben wurden. Dieser wird in der Regel alle paar Sekunden geleert.

strict garantiert nicht, dass Änderungen tatsächlich sofort auf die Festplatte geschrieben werden. Nachdem eine Website put() aufgerufen hat, kann es noch eine gewisse Zeit dauern, bis ein Stromausfall dazu führt, dass die Änderung nicht auf die Festplatte geschrieben wird und daher beim nächsten Ausführen der App fehlt.

Bei Garantien mit strict-Beständigkeit wird das IndexedDB-Transaktionsereignis complete erst nach dem tatsächlichen Schreiben der Daten ausgelöst. Bei relaxed-Beständigkeit werden die Daten noch geschrieben, wenn das complete-Ereignis ausgelöst wird. Weitere Informationen zum gesamten Prozess

strict ist also wirklich nur für Vorgänge gedacht, bei denen Sie unbedingt wissen müssen, dass der Code geschrieben wurde, bevor Sie den nächsten Schritt ausführen. Die Datenmigration ist ein Beispiel, bei dem strict-Langlebigkeit erforderlich ist. Wenn Sie von einem Sicherungsspeicher zu einem anderen wechseln, sollten Sie das alte Format erst löschen, wenn das neue geschrieben wurde. So ermöglicht die strict-Beständigkeit eine Migrationsroutine, die sich von einem Fehler in der Hälfte der Migration erholen kann.

Änderung des Standardmodus für die Robustheit

Der entscheidende Aspekt dieser Änderung ist der standardmäßige Durable-Modus für readwrite-Transaktionen in Chrome. Bisher war strict die Standardeinstellung, wodurch Datenänderungen sofort auf die Festplatte geschrieben wurden. Aus Leistungsgründen und zur Angleichung an andere wichtige Browser, die alle relaxed verwenden, plant Chrome jedoch, die Standardeinstellung ebenfalls auf relaxed zu ändern.

Diese Änderung soll ein besseres Gleichgewicht zwischen Leistung und Datenbeständigkeit schaffen. strict sorgt zwar für maximale Datenbeständigkeit, relaxed ist jedoch für viele Webanwendungen oft ausreichend und kann die Leistung auf folgende Weise erheblich verbessern:

  • Geschwindigkeit: In realen Beispielen hat das Chrome-Team Geschwindigkeitsverbesserungen zwischen dem Faktor 3 und 30 festgestellt.
  • Die Lebensdauer der Festplatte, insbesondere bei Geräten mit einer Solid State Disk (SSD).
  • Längere Akkulaufzeit
  • Eine Verbesserung der Lesegeschwindigkeit. Aufgrund der Architektur von IndexedDB, bei der Lesetransaktionen oft hinter Schreibtransaktionen blockiert werden, wird die Lesegeschwindigkeit als Nebeneffekt verbessert.
  • Das gesamte Gerät ist betroffen, da Festplattenvorgänge eine gemeinsam genutzte Systemressource sind.

Interoperabilität und Kompatibilität

Ein wichtiger Aspekt dieser Änderung sind die Auswirkungen auf Interoperabilität und Kompatibilität. Durch die Anpassung an das Verhalten anderer großer Browseranbieter wird die Interoperabilität von Chromium verbessert. Der Standard selbst lässt unterschiedliche Implementierungen zu. Mit dieser Änderung sollen diese Implementierungen harmonisiert werden. Weitere Informationen zu dieser Änderung

Was bedeutet das für Webentwickler?

Durch diese Änderung wird keine neue API eingeführt. Die vorhandene IndexedDB API bleibt unverändert. Diese Änderung betrifft hauptsächlich das Standardverhalten von readwrite-Transaktionen. Sie können beim Erstellen von Transaktionen den bevorzugten Modus für die Datenbeständigkeit angeben und so die Datenbeständigkeit und Leistung steuern. Im folgenden Codebeispiel wird gezeigt, wie Sie das alte Verhalten wiederherstellen, indem Sie durability im optionalen Optionsarray auf strict festlegen.

let db;
const DBOpenRequest = window.indexedDB.open("toDoList", 4);
DBOpenRequest.onsuccess = (event) => {
  db = DBOpenRequest.result;
};
const transaction = db.transaction(
  ['toDoList'],
  'readwrite',
  { durability: 'strict' });

Änderung vor der Veröffentlichung lokal testen

Die Änderung wird in Chrome 121 wirksam. Wenn Sie das neue Verhalten vorab lokal testen möchten, aktivieren Sie das Flag #indexed-db-default-durability-relaxed in chrome://flags.

Weitere Informationen

Weitere technische Details und Updates zu dieser Änderung finden Sie im Tracking-Fehler und im Chrome Platform Status-Eintrag.

Zusammenfassend lässt sich sagen, dass Chrome mit der Änderung des Standardmodus für die Datenbeständigkeit in IndexedDB die Leistung verbessern und gleichzeitig die Kompatibilität mit anderen wichtigen Browsern aufrechterhalten möchte. In den meisten Fällen empfehlen wir, nichts zu unternehmen, da die neue Standardeinstellung die Leistung verbessert. Bei Bedarf können Sie weiterhin den bevorzugten Durability-Modus angeben und so die Kontrolle über die Daten-Durability und ‑Leistung in Ihren Webanwendungen behalten.

Danksagungen

Dieser Artikel wurde von Evan Stade und Rachel Andrew überprüft.