Hört auf, alle Daten zu synchronisieren

Ein neuer Ansatz für Edge-Replikation

• Datensynchronisierung ist ein schwierigeres Problem, als es auf den ersten Blick scheint. Bestehende Lösungen teilen sich meist in zwei Ansätze: Entweder wird der gesamte Datensatz mit dem Client synchronisiert, oder es werden logische Änderungen verfolgt.
• Graft wurde entwickelt, um diese Probleme zu lösen, und ist eine Open-Source-Storage-Engine, die einfache physische Replikation mit effizienter logischer Replikation kombiniert.

Faule Synchronisierung: Im gewünschten Tempo synchronisieren

• Graft erlaubt Clients zu wählen, wann sie synchronisieren, und eignet sich damit für Edge-Umgebungen, die nur zeitweise mit dem Netzwerk verbunden sind.
• Der Server liefert einen Index der Seiten, die sich seit dem letzten Snapshot des Clients geändert haben, und der Client kann selektiv nur die benötigten Daten abrufen.

Partielle Synchronisierung: Nur synchronisieren, was benötigt wird

• In Edge-Umgebungen kann nicht der gesamte Datensatz heruntergeladen werden, daher unterstützt Graft partielle Synchronisierung, bei der nur die benötigten Seiten selektiv abgerufen werden.
• Graft kann allgemeine Vorhersagealgorithmen und Domänenwissen nutzen, um benötigte Seiten im Voraus zu holen.

Edge: Synchronisierung nah am Einsatzort

• Graft stellt Daten über Edge-Server weltweit bereit und sorgt so unabhängig vom Standort der Nutzer für geringe Latenz und hohe Reaktionsfähigkeit.
• Die Clients sind leichtgewichtig aufgebaut und lassen sich einfach in Browser, mobile Apps und serverlose Umgebungen integrieren.

Konsistenz: Sichere Synchronisierung

• Graft bietet ein starkes Konsistenzmodell, das Konflikte zwischen Clients sicher behandelt.
• Über ein Snapshot-Isolation-Modell erhalten Clients eine konsistente Sicht auf die Daten, während Schreibvorgänge strikt serialisiert werden.

Was lässt sich mit Graft bauen?

• Graft bietet eine starke Grundlage für verschiedenste Edge-native Anwendungen.
• Möglich sind Offline-First-Apps, plattformübergreifende Daten, zustandslose Lesereplikate und die Replikation beliebiger Daten.

Graft-SQLite-Erweiterung (libgraft)

• libgraft ist eine native Erweiterung für SQLite, mit der Clients nur den tatsächlich genutzten Teil einer Datenbank replizieren können, sodass SQLite auch in ressourcenbeschränkten Umgebungen ausgeführt werden kann.
• Sie bietet Funktionen wie asynchrone Replikation, faule partielle Replikation, Snapshot Isolation und Point-in-Time Recovery.

So kann man mitmachen

• Graft wird auf GitHub entwickelt und freut sich über Beiträge aus der Community.
• Man kann dem Discord beitreten oder per E-Mail Feedback geben.
• Außerdem kann man sich in die Warteliste für den Managed Service von Graft eintragen.

Roadmap

• Graft befindet sich noch in Entwicklung; geplant sind unter anderem Unterstützung für WebAssembly, Integration mit SQLSync und Support für verschiedene Client-Bibliotheken.
• Ebenfalls vorgesehen sind geringere Schreiblatenz, Garbage Collection, Authentifizierung und Autorisierung, Volume Forking sowie Konfliktbehandlung.

Vergleich mit anderen SQLite-Replikationslösungen

• Graft hat im Vergleich zu mvSQLite, Litestream, cr-sqlite, Cloudflare Durable Objects, Cloudflare D1, Turso & libSQL, rqlite & dqlite und Verneuil eigene besondere Vorteile.
• Zu den wichtigsten Unterscheidungsmerkmalen zählen partielle Replikation, Unterstützung beliebiger Datenstrukturen und effiziente Replikation am Edge.

[GN⁺]

Hacker News-Kommentare

• Das Konsistenzmodell ist unklar

  • Der Graft-Client committet lokal und versucht asynchron, den Remote-Commit durchzuführen
  • Wenn zwei Clients gleichzeitig auf Basis desselben Snapshots committen, ist einer erfolgreich und der andere scheitert
  • Die API bietet nur einen einzelnen Commit-Vorgang
  • Wenn der lokale Commit erfolgreich ist, die asynchrone Weitergabe aber fehlschlägt, entsteht das Problem, dass ein Rollback nötig wird
  • Das Konzept von „Commit“ wird in mehreren unterschiedlichen Bedeutungen vermischt

• Der Autor von Graft bedankt sich

  • Nimmt in Washington, DC am Antithesis BugBash teil
  • Möchte Leute treffen, die in Washington sind

• Das Konsistenzmodell wird als ähnlich zu git verstanden

  • Man ändert die lokale Kopie, und beim „Pushen“ können Konflikte auftreten
  • Es gibt keine saubere Methode, Konflikte zu erkennen
  • Konflikte können durch Lesekonflikte entstehen

• Wenn ein Client Graft abruft, kann er genau erkennen, was sich geändert hat

  • Vergleich mit dem Manifest von Cloud-Backed SQLite
  • Es sind keine Berechnungen auf dem Server nötig

• Es werden keine Implementierungsdetails erwähnt

  • Es wird eine Sync-Schicht benötigt, bei der sich App-Entwickler nicht um die Synchronisierung kümmern müssen
  • Persönliche Synchronisierung könnte ohne Abonnement unterstützt werden

• Die Nutzung von VFS wird als interessanter „Hack“ angesehen

  • Es wird an einer eigenen Sync-Engine für eine Offline-First-IDE gearbeitet
  • Die Konfliktauflösung mit einer Baumstruktur ist eine Herausforderung

• Das Projekt mit dem Leap-Algorithmus ist sehr interessant

  • Es ist leicht, sich auf die SQLite-Integration zu konzentrieren, aber der Ansatz behandelt das Problem als allgemeineres Distributed-Storage-Problem auf niedrigerer Ebene
  • Eine allgemeine Lösung ohne konkrete Erfahrung kann riskant sein

• Es kann Probleme geben, wenn mobile Clients eine langsame Verbindung haben

  • Vorgeschlagen wird ein hybrider Ansatz, der langsame Synchronisierung erkennt und Anfragen direkt an den Server sendet

• Der Ansatz, Seiten als grundlegende Synchronisierungseinheit zu verwenden, ist interessant

  • Es kann zu Konflikten mit vielen gleichzeitigen Nutzern kommen
  • OT oder CRDT könnten besser sein

• Es ist ein sehr anspruchsvolles Problem

  • Würde das gern in einer React-Native-App ausprobieren