Zero-Latency-SQLite-Speicher in jedem Durable Object

 (simonwillison.net)
2 Punkte von GN⁺ 2024-10-15 | 1 Kommentare | Auf WhatsApp teilen

  • Zero-latency SQLite storage in every Durable Object

    • Kenton Varda stellt die nächste Version von Cloudflares Durable-Object-Plattform vor. Die Plattform wurde kürzlich von einem Key-Value-Store zu einem vollständigen relationalen System auf SQLite-Basis aufgerüstet
    • Nützlichen Hintergrund zur ersten Version von Durable Objects bietet Paul Butlers Cloudflare’s durable multiplayer moat. Diese ist beliebt für den Aufbau von Echtzeit-Kollaborationsanwendungen auf WebSocket-Basis
    • Die neuen SQLite-basierten Durable Objects sind ein faszinierendes Element des Designs verteilter Systeme und schlagen interessante Wege für den Entwurf von Anwendungen im großen Maßstab vor

  • Grundidee von Durable Objects

    • Ein Durable Object platziert Anwendungslogik zusammen mit den Daten auf demselben physischen Host und bietet dadurch sehr schnelle Lese- und Schreibzugriffe
    • Ein einzelnes Objekt läuft auf einem einzelnen Thread einer einzelnen Maschine, daher ist der Durchsatz begrenzt. Um mehr Traffic zu verarbeiten, werden mehr Objekte erzeugt. Am einfachsten ist das, wenn jede Zustandseinheit wenig genug Traffic hat, um von einem einzelnen Objekt verarbeitet werden zu können

  • Beispiel eines Flugbuchungssystems

    • Jeder Flug kann auf ein dediziertes Durable Object mit eigener SQLite-Datenbank abgebildet werden. Pro Fluggesellschaft entstehen jeden Tag Tausende neuer Datenbanken
    • Jedes DO hat einen eindeutigen Namen, und Cloudflares Netzwerk leitet Anfragen zu diesem Objekt weiter, egal wo auf der Welt es sich befindet

  • Technische Details

    • Inspiriert von Litestream streamt jedes DO fortlaufend eine Sequenz von WAL-Einträgen in den Objektspeicher. Das geschieht in Batches von jeweils 16 MB oder alle 10 Sekunden
    • Um Haltbarkeit innerhalb des 10-Sekunden-Fensters zu garantieren, werden Schreibvorgänge unmittelbar nach dem Commit an fünf Replikate in nahegelegenen Rechenzentren weitergegeben; sobald drei bestätigt haben, wird der Schreibvorgang bestätigt

  • Design der JavaScript-API

    • Sie ist blockierend statt asynchron gestaltet. Ziel ist es, schnelle Persistenzoperationen auf einem einzelnen Thread bereitzustellen
    • Es sind Beispiele enthalten, die bewusst das N+1-Query-Muster zeigen, das SQLite gut verarbeiten kann

  • Storage Relay Service

    • Das zugrunde liegende System für Durable Objects, das bereits seit über einem Jahr Cloudflares bestehendes D1-SQLite-System unterstützt

  • Wo Durable Objects erzeugt werden

    • Durable Objects ändern ihren Standort nach der Erzeugung nicht. Standardmäßig werden sie in dem Rechenzentrum instanziiert, in dem die erste get()-Anfrage erfolgt
    • Um Durable Objects manuell an einem anderen Ort zu erzeugen, wird an get() der optionale Parameter locationHint übergeben

  • Website where.durableobjects.live

    • Eine Website, die verfolgt, wo im Cloudflare-Netzwerk DOs erzeugt werden

Zusammenfassung von GN⁺

  • Cloudflares Durable Objects auf SQLite-Basis eröffnen neue Möglichkeiten für das Design großskaliger Anwendungen. Sie liefern hohe Performance, indem Daten und Anwendungslogik auf demselben physischen Host platziert werden
  • Das System ist besonders nützlich für Echtzeit-Kollaborationsanwendungen und bietet Flexibilität bei der Verarbeitung verschiedener Zustandseinheiten
  • Durable Objects erzeugen Replikate über mehrere Rechenzentren hinweg, um Datenhaltbarkeit sicherzustellen, was Stabilität und Zuverlässigkeit erhöht
  • Die Technik könnte für Entwickler interessant sein, die sich für den Entwurf großer verteilter Systeme interessieren. Vergleichbare Systeme mit ähnlichen Funktionen sind Amazons DynamoDB und Googles Firestore

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-10-15
Hacker-News-Kommentare

  • Die Schreib-API ist synchron, hat aber eine versteckte asynchrone Wartefunktion. Wenn ein Schreibvorgang fehlschlägt, ersetzt die Runtime die Antwort durch einen HTTP-Fehler, sodass Schreibvorgänge automatisch gebündelt und als erfolgreich angenommen werden können

    • Es gibt keine Lese-Transaktionen, daher ist es schwierig, einen Snapshot zu einem bestimmten Zeitpunkt zu erhalten
    • Jede Runtime-Instanz ist auf 128 MB RAM begrenzt
    • WebSockets können in den Ruhezustand versetzt werden, wobei in diesem Zustand keine Kosten anfallen. Dadurch können Clients die Verbindung aufrechterhalten, auch wenn das DO schläft
    • Es gibt eine automatische RPC-Funktion, sodass mit anderen DOs oder Workern wie mit normalen JS-Aufrufen kommuniziert werden kann. Die Runtime übernimmt Serialisierung und Parsing

  • Jedes DO streamt eine Sequenz von WAL-Einträgen in den Objektspeicher, die alle 16 MB oder alle 10 Sekunden gebündelt werden

    • Weltweit kann es bis zu 10 Sekunden dauern, bis Schreibvorgänge lesbar sind
    • Regional bereitgestellte Datenbankcluster lassen sich nur schwer ersetzen

  • Das Design von Durable Objects gefällt mir. Die interne Funktionsweise ist leicht zu verstehen

    • DOs eignen sich gut, um schnelle und kostengünstige Echtzeit-Erlebnisse zu bauen, aber Analysen und Übersichten sind schwierig
    • Wenn Daten in SQLite liegen, muss man viele kleine SQLite-Instanzen abfragen und die Ergebnisse zusammenführen

  • Es ist schwer zu verstehen, wo sich Durable Objects physisch befinden

    • Ich frage mich, ob sie in der Region liegen, in der der API-Aufruf erfolgt
    • Ich frage mich, ob ein DO automatisch an einen anderen Ort verschoben werden kann

  • Es ist schwer, neue Cloud-Technologien zu verstehen

    • Ich habe mehr als 15 Jahre Erfahrung in der Webentwicklung, habe aber das Gefühl, dass solche Technologien nichts für mich sind

  • Ich frage mich, wie Schema-Migrationen gehandhabt werden sollen

    • Wenn die Datenbank pro Tenant existiert, ist es schwierig, Schema-Änderungen auf jedes DO anzuwenden

  • Das DO-Design ist interessant, aber ich denke, es eignet sich nur für Systeme mit hoher Last oder für Spielzeugprojekte

    • In der Praxis braucht man bewährte Systeme, und DOs sind noch nicht ausgereift

  • Ich bin vom DO-Design beeindruckt. Die Art, wie komplexe Aufgaben in kleinem Maßstab verarbeitet werden, ähnelt aus meiner Sicht dem Aufbau realer Produkte

  • Mir ist aufgefallen, dass CF Entwickler zur Nutzung von DOs ermutigt

    • WebSocket-Verbindungen von Workern laufen nach 30 Sekunden in ein Timeout, daher wird die Nutzung von DOs empfohlen

  • Ich frage mich, ob DOs dem "Model" in der MVC-Architektur entsprechen

    • Ich frage mich, wie man DOs pro Tenant nutzt und wie man alle DOs abfragt oder Joins zwischen ihnen ausführt