SQLite-Speicher mit Zero Latency in jedem Durable Object
(simonwillison.net)- Cloudflares Durable Object wechselt von einem Key/Value-Speicher zu einem SQLite-basierten relationalen Speicher; Anwendungslogik und Daten laufen damit auf demselben physischen Host
- Skalierung erfolgt nicht dadurch, ein einzelnes Objekt zu vergrößern, sondern indem Durable Objects nach logischen Zustandseinheiten wie Dokumenten, Nutzern oder Datenbank-Shards aufgeteilt werden; ein einzelnes Objekt ist durch eine einzelne Maschine und einen einzelnen Thread begrenzt
- In Systemen mit klaren Zustandseinheiten, etwa Flugbuchungen, kann jeder Flug ein eigenes Durable Object samt eigener SQLite-Datenbank erhalten; pro Fluggesellschaft können dadurch täglich Tausende neue Datenbanken entstehen
- Dauerhaftigkeit wird durch WAL-Entry-Streaming, Speicherung in Object Storage und Replikation in nahegelegene Rechenzentren erreicht; Batches erfolgen alle 16 MB oder 10 Sekunden, Point-in-Time-Recovery wird für bis zu 30 Tage unterstützt
- Die JavaScript-API setzt für schnelle, Single-Thread-Persistenzoperationen auf eine blockierende Arbeitsweise; der Standort eines Durable Object ist nach der Erstellung fixiert, eine dynamische Verlagerung ist jedoch geplant
Das Durable-Object-Design mit SQLite
- Cloudflares Durable Object wurde von einem Key/Value-Speicher zu einem SQLite-basierten relationalen System aufgerüstet
- Der Kern besteht darin, Anwendungslogik am selben Ort wie die Daten auszuführen, die diese Logik verarbeitet
- Ein Durable Object besteht aus Code, der auf demselben physischen Host läuft wie die von ihm genutzte SQLite-Datenbank
- Lese- und Schreibvorgänge werden ohne Netzwerk-Roundtrip verarbeitet, wodurch sich Latenz leichter reduzieren lässt
- Für Verarbeitung in großem Maßstab wird der Ansatz gewählt, mehr Objekte zu erzeugen, statt den Durchsatz eines einzelnen Objekts zu erhöhen
- Ein einzelnes Objekt läuft in einem einzelnen Thread auf einer einzelnen Maschine und hat daher eine inhärente Durchsatzgrenze
- Wenn unterschiedliche logische Zustandseinheiten wie Dokumente, Nutzer oder Datenbank-Shards von separaten Objekten übernommen werden, lässt sich das System leichter skalieren
- In einem Flugbuchungssystem kann jeder Flug einem eigenen Durable Object und einer eigenen SQLite-Datenbank zugeordnet werden
- In dieser Struktur können pro Fluggesellschaft täglich Tausende neue Datenbanken entstehen
- Jedes Durable Object hat einen eindeutigen Namen, und das Cloudflare-Netzwerk routet Anfragen innerhalb des weltweiten Netzwerks an den Standort dieses Objekts
Dauerhaftigkeit durch WAL-Streaming und Replikation
- Das auf Durable Objects basierende System ist von Litestream inspiriert und streamt die Sequenz der WAL-Entries jedes Objekts kontinuierlich in Object Storage
- Batches werden alle 16 MB oder alle 10 Sekunden durchgeführt
- Durch das erneute Abspielen aufgezeichneter Transaktionen ist Point-in-Time-Recovery für bis zu 30 Tage möglich
- Um die Dauerhaftigkeit innerhalb des 10-Sekunden-Fensters zu ergänzen, werden Schreibvorgänge direkt nach dem Commit an 5 Replikate in nahegelegenen, separaten Rechenzentren weitergeleitet
- Erst wenn 3 davon bestätigen, wird die Schreibantwort freigegeben
- Das Basissystem von Durable Objects ist der Storage Relay Service und betreibt seit über einem Jahr Cloudflares separates D1 SQLite system
API und Standortverhalten von Objekten
- Die JavaScript-API verwendet keinen async-Ansatz, sondern eine blockierende Arbeitsweise
- Ziel des Designs ist es, schnelle Single-Thread-Persistenzoperationen bereitzustellen
- Der Beispielcode verwendet absichtlich ein N+1-Query-Pattern: Nach dem Abrufen einer Dokumentliste wird der Name des Autors jedes Dokuments per separater Query geholt
- SQLite wird als gut geeignetes Beispiel für die Verarbeitung dieses Patterns dargestellt
- Ein Durable Object ändert seinen Standort derzeit nach der Erstellung nicht
- Standardmäßig wird es in einem Rechenzentrum instanziiert, das nahe an dem Ort liegt, an dem die erste
get()-Anfrage erzeugt wurde - Für eine manuelle Erstellung an einem anderen Standort kann dem
get()der optionale ParameterlocationHintübergeben werden - Eine dynamische Verlagerung bestehender Durable Objects ist künftig geplant
- Standardmäßig wird es in einem Rechenzentrum instanziiert, das nahe an dem Ort liegt, an dem die erste
- where.durableobjects.live ist eine Website, die verfolgt, wo neue Durable Objects im Cloudflare-Netzwerk erstellt werden
- Bei einem Beispielbesuch wurde angezeigt, dass beim Laden der Seite in Half Moon Bay ein Worker in San Jose ein Durable Object in San Jose erstellt hat
1 Kommentare
Hacker-News-Kommentare
Es gibt noch ein paar weitere interessante Punkte: Die Schreib-API ist synchron, hat aber ein verstecktes asynchrones Warten; wenn ein Schreibvorgang beim Ausgeben der nächsten Antwort fehlschlägt, wandelt die Runtime die Antwort in einen HTTP-Fehler um.
Dadurch kann die Runtime Schreibvorgänge automatisch batchen und optimistisch von Erfolg ausgehen, ohne dass Nutzer Fehler oder Wartezeiten explizit behandeln müssen.
Lesetransaktionen gibt es nicht, dabei wären sie wohl nützlich gewesen, um einen Snapshot-Pointer zu einem bestimmten Zeitpunkt zu erhalten.
Jede Runtime-Instanz ist auf 128 MB RAM begrenzt.
WebSockets können in den Ruhezustand versetzt werden und verursachen während der Schlafenszeit keine Kosten, sodass Clients verbunden bleiben können, auch während das DO schläft.
Es gibt auch eine Art automatisches RPC-Feature, mit dem sich andere DOs oder Worker wie normale JS-Aufrufe behandeln lassen; tatsächlich können dabei andere Rechenzentren aufgerufen werden, Serialisierung und Parsing übernimmt die Runtime.
Das im Artikel erwähnte Litestream schlägt ebenfalls eine ähnliche Technik vor.
In normalem SQLite sind Lesetransaktionen nützlich, weil mehrere Prozesse gleichzeitig auf dieselbe Datenbank zugreifen können.
Hier kann nur ein einzelner Prozess auf die Datenbank zugreifen; daher lässt sich derselbe Effekt erzielen, indem man alle Lesevorgänge in einer synchronen Funktion ausführt oder selbst eine Sperre auf Prozessebene implementiert.
Dass WAL-Einträge alle 16 MB oder alle 10 Sekunden gebündelt in den Objektspeicher gestreamt werden, scheint zu bedeuten, dass es bis zu 10 Sekunden dauern kann, bis Schreibvorgänge global zuverlässig gelesen werden können.
Ich sehe nicht recht, wie das regionale Datenbankcluster ersetzen soll, die auf Kontinentebene Antworten im Millisekundenbereich liefern.
Ich verstehe, dass ein Stream verwendet wird, aber das Ziel sind nur fünf Follower, während Cloudflare Hunderte von Rechenzentren hat.
Wenn nicht jede SQLite-Instanz ständig verbunden ist, kann man Lesezeiten im Sekundenbereich physikalisch nicht garantieren; und selbst wenn sie verbunden ist, können Paketverzögerungen Probleme verursachen.
Wenn man schreibt und direkt danach liest, ist die Änderung sofort sichtbar. Denn Schreiben und Lesen aktualisieren auch den Speicherzustand des aktuellen Prozesses.
Wenn ein anderer Prozess, etwa ein anderes DO oder ein Worker, auf die Daten zugreifen will, muss er über das DO gehen, dem die Daten gehören, und sendet daher eine RPC- oder HTTP-Anfrage und erhält den aktuellen Stand.
Der Ruhezustand tritt erst nach einer gewissen Inaktivität ein; anders als vermutet scheint ein Schreibvorgang also nur dann unavailable zu werden, wenn das DO oder der Worker direkt nach dem Schreiben crasht.
Der Cloudflare-Blogartikel behandelt diesen Teil ausführlicher. So bleiben Schreibvorgänge schnell und sind dennoch dauerhaft gespeichert.
Diese Maschine hat stets eine konsistente Sicht auf ihre eigene SQLite-Datenbank.
Man kann Milliarden von Objekten erstellen, aber jedes Objekt hat eine separate Datenbank.
Es gibt keine Möglichkeit, diese Datenbank direkt von einer anderen Maschine als der zu lesen, auf der das DO läuft.
Jedes DO ist global eindeutig; ein DO mit einer bestimmten ID läuft irgendwo genau einmal und betreibt SQLite auf dem lokalen Speicher dieses Rechenzentrums.
Was ich bei Durable Objects noch nicht verstehe, ist der physische Standort.
Ich frage mich, ob es in der Region liegt, die den API-Aufruf gehostet hat, der ursprünglich zur Erstellung geführt hat.
Falls ja, frage ich mich auch, ob es einen Mechanismus gibt, der ein DO automatisch an einen anderen Standort verschiebt, wenn sich etwa zeigt, dass es zwar in Nordamerika erstellt wurde, später aber sämtlicher Lese-/Schreib-Traffic aus Australien kommt.
locationHintangeben. Für Australien verwendet man"oc": https://developers.cloudflare.com/durable-objects/reference/...Außerdem sollte man beachten, dass „die dynamische Neuplatzierung bestehender Durable Objects für die Zukunft geplant ist“.
Nur etwa 10–11 % der Cloudflare-PoPs hosten Durable Objects.
Anfragen, die zur Erstellung eines DO an einem anderen PoP eingehen, werden an einen der nahegelegenen PoPs weitergeleitet, die es hosten.
Soweit ich mich erinnere, kann Orleans (https://www.microsoft.com/en-us/research/wp-content/uploads/...) Actors zwischen Maschinen verschieben; dieses Modell scheint gut dazu zu passen, DOs zwischen Standorten zu verschieben.
Allerdings gibt es keinen API-Aufruf, um ein Durable Object zu verschieben.
Es darf keine Verbindungen geben, und bei der nächsten bzw. ersten Verbindung wird es im nächstgelegenen Rechenzentrum neu erstellt.
Dabei geht der Speicher im Arbeitsspeicher verloren, der persistente Speicher bleibt aber erhalten.
Vor Kurzem sind einige Detailfunktionen rund um Hibernation hinzugekommen, daher könnte diese Beschreibung etwas veraltet sein.
Geht es noch jemandem so, dass es schwierig wirkt, diese neuen Cloud-Technologien zu verstehen?
Ich habe über 15 Jahre Erfahrung in der Webentwicklung und habe mit dem Stack Laravel / Postgres / Redis gearbeitet, aber wenn ich solche Beiträge lese, denke ich einfach: Das passt nicht zu mir.
Echtzeit-Kollaborations-Apps, die einem sofort einfallen, sind Google Docs/Sheets, Notion, Miro und Figma.
Das sind alles Kollaborations-Apps im globalen Maßstab, und ich bin mir nicht sicher, ob der Laravel-Stack solche Use Cases unterstützen könnte.
Google musste vermutlich das meiste selbst implementieren und dürfte bei der Nutzung von CRDTs eine Vorreiterrolle gespielt haben.
Aber wenn sich Muster herausbilden und Bausteine als SaaS verfügbar werden, ist groß angelegte Echtzeit-Kollaboration kein riesiges Engineering-Problem mehr, und interessantere Produkte werden möglich.
Mir gefällt das Design von Durable Objects wirklich sehr. Besonders gut finde ich, dass leicht zu verstehen ist, wie es intern funktioniert.
Im Gegensatz zu vielen anderen Lösungen, die für Echtzeitdaten entwickelt wurden, haben Durable Objects eine Einfachheit wie Redis und italienisches Essen: Man sieht alle Zutaten.
Mit genug Zeit, Ressourcen und Rechenzentren könnte ein fähiger Programmierer vermutlich die DO-Dokumentation lesen und etwas Ähnliches nachbauen.
Dadurch lassen sich die damit verbundenen Trade-offs leichter einschätzen.
Allerdings habe ich die Sorge, dass DOs zwar gut dafür geeignet sind, schnelle Echtzeit-Erlebnisse mit wenig Overhead zu bauen, etwa eine Funktion, bei der fünf Leute gleichzeitig ein Dokument bearbeiten, dass sie es aber sehr schwierig machen können, Analysen und Übersichten zu erstellen.
Zum Beispiel Fragen wie, welche Gruppe letzte Woche welche Dokumente bearbeitet hat; wenn man die Daten in SQLite steckt, kann das noch schwieriger werden.
Man müsste irgendwie unzählige kleine SQLite-Instanzen abfragen und anschließend die Ergebnisse zusammenführen; daher frage ich mich, ob DOs dafür etwas bieten.
Genau deshalb lande ich am Ende immer wieder bei Postgres: Es lässt sich sowohl für zentrale App-Funktionen als auch für Übersichten, BI usw. verwenden.
Ein wirklich interessantes Design, aber solche cleveren Systeme liegen für mich persönlich immer im Uncanny Valley.
Es gibt genau zwei Fälle, in denen man so etwas braucht: wenn man ein System mit sehr hoher Last intelligent skalieren muss, oder wenn man zum Spaß ein Spielzeugprojekt baut.
Für ein Spielzeugprojekt kann man verwenden, was man will.
Aber für Produktion oder den beruflichen Einsatz braucht man etwas Bewährtes.
Wenn man nicht weiß, dass man das braucht, braucht man es nicht und kann einfach eine langweilige Postgres-Datenbank und eine VM oder Ähnliches verwenden.
Umgekehrt wird es schwierig, wenn man weiß, dass man es braucht. Es ist noch neu und nicht ausreichend gereift, sodass man wahrscheinlich auf viele seltsame Edge Cases stößt, und die wird man weder debuggen noch in Kauf nehmen wollen.
Am Ende weiß ich nicht, für wen solche Systeme eigentlich gedacht sind.
Sie sind zu nischig, als dass viele ernsthafte Player sie nutzen und sie dadurch leicht reifen könnten, und für 99,9 % der Unternehmen sind sie zu komplex und mit zu vielen Kompromissen verbunden.
Die einzige klare Zielgruppe scheinen Entwickler zu sein, die etwas Glänzendes sehen und darauf ein Unternehmen bauen – oder schlimmer noch, das Unternehmen anderer Leute darauf bauen – und es kurz darauf bereuen und zu etwas Langweiligerem wechseln.
Wenn man etwas wie ein weiteres Figma oder Google Docs bauen will, ist das Programmiermodell von Durable Objects sehr praktisch.
Dieser Artikel geht ausführlicher darauf ein: https://digest.browsertech.com/archive/browsertech-digest-cl...
Auch dieser ältere Artikel ist ziemlich relevant: http://ithare.com/scaling-stateful-objects/
Für Leute, die den Figma-Artikel zu Multiplayer gelesen und gedacht haben: „Das ist ungefähr das, was ich brauche“, dürften Durable Objects gut passen: https://www.figma.com/blog/rust-in-production-at-figma/
Es gibt auch andere Ansätze. Ich habe früher einmal CRDTs auf WebRTC ausprobiert, und das fühlte sich wirklich wie Zukunftstechnologie an.
Aber es ist deutlich komplexer als eine Grundlage aus einem WebSocket irgendwo in der Cloud und einer einzelnen Klasseninstanz.
Daten und Verhalten am selben Ort zu halten, reduziert tatsächlich messbar Komplexität.
Weil man sich weniger um Latenz und Bandbreite sorgen muss, reduziert das sowohl betriebliche als auch entwicklungsseitige Bedenken. Auch die Auswirkungen des bekannten N+1-Problems werden deutlich verringert.
Man kann argumentieren, dass ein über das Netzwerk angebundenes Postgres aus anderen Gründen besser ist, und das kann tatsächlich stimmen.
Aber SQLite gehört zu den langweiligsten und berechenbarsten Optionen und hat klar bekannte Stärken.
Deshalb wird es auch auf Servern immer beliebter.
Allerdings gefällt mir der Ansatz, viele kleine Datenbanken anzulegen, wie ihn Durable Objects nahelegen, nicht besonders.
Er erinnert an NoSQL-Albträume und kann wichtige Invarianten relationaler Datenbanken aufbrechen.
Meiner Ansicht nach eignet sich SQLite deutlich besser als monolithische Datenbank, wie bei Cloudflares D1-Produkt.
Cloudflare braucht gute Customer-Success-Storys, und es ist gut möglich, dass hervorragende Engineers dort im Gegenzug für eine Erfolgsgeschichte gemeinsam mit einem anschauen, wie das funktioniert, wie es hilft und wie Bugs behandelt werden.
Sobald es validiert ist, wird daraus wohl eine Service-Beziehung, aber am Anfang ist es eher eine Partnerschaft.
Es gibt viele Services, etwa interne Tools, die kein Performance-Tuning oder tiefe interne Einblicke brauchen.
Für solche Fälle passen Serverless-Frameworks gut, weil sie den Zeitaufwand für Deployments stark reduzieren.
Schnell zu sein ist gut, aber selten eine Kernanforderung.
Meist ist die Kernanforderung, schnell bauen zu können und wenig Wartungsaufwand zu haben.
Cloudflare kann hier vermutlich eine gute Developer Experience bieten, aber das ist nicht ihr zentrales Verkaufsargument, und es gibt viele konkurrierende Dienste, die ebenfalls versprechen, solche Entwicklung zu beschleunigen.
Wenn dagegen hohe Debuggbarkeit und interne Observability nötig sind, halte ich solche Dienste für weniger passend.
Wichtig ist, welche Metriken man bekommt, ob es Informationen gibt, um zu verstehen, warum manche Durable Objects langsam sind, ob man das beheben kann, wie es mit Logging aussieht und was es kostet.
Solche Services können gut sein, damit ein Startup ab Tag eins ein cleveres verteiltes System bauen und Skalierungsfragen aufschieben kann.
Aber bei einem Scale-up würde man vermutlich zu etwas wechseln wollen, in das man tiefer hineinsehen kann, und diese Migration dürfte schwierig werden.
Wie andere gesagt haben, ist der Einsatzfall Multiplayer, weil alle Änderungen so schnell wie möglich sehen müssen, damit sich die App gut anfühlt.
Allgemeiner betrachtet versucht die Storage-Branche schon lange, etwas Konsistentes, Niedriglatenzfähiges und Mehrbenutzertaugliches zu bauen.
Auch physikalisch gibt es zwischen Konsistenz und Latenz normalerweise einen Trade-off, was es sehr schwierig macht.
Deshalb werden verschiedene Modelle ausprobiert, und viele dieser Experimente drehen sich um SQLite. Nicht alle; Yugabyte oder Cockroach sind Ausnahmen.
Das Design von DO beeindruckt mich immer wieder.
Es ist leicht, reflexartig zu denken, dass an diesem Ansatz etwas falsch sein müsse, aber in Wirklichkeit sind meiner Ansicht nach viele reale Produkte implizit genau so aufgebaut.
Für jede atomare Einheit, die transaktionale Konsistenz braucht, wird auf sehr kleiner Skala eine Menge komplexer Arbeit erledigt.
Rückblickend war das, was wir bei Framer für ein Multiplayer-Support-Projekt gebaut haben, eine stärker angewandte Version dessen, was DO heute macht.
Bearbeitungen wurden mit 60 FPS repliziert und in der richtigen Reihenfolge auf alle Clients angewendet, und am Ende haben wir auch etwas WAL-Ähnliches für das Bearbeiten von JSON-Objekten gebaut.
Dadurch konnte ein Backup nahtlos übernehmen, selbst wenn eine Projektinstanz crashte.
Selbst wenn keine Zeit war, JSON-Patches auf das riesige Projektdatenobjekt zu committen, wurde es wie hier beschrieben alle N Updates oder alle M Sekunden verarbeitet.
Vielleicht ist das eine dumme Frage, aber ich frage mich, wie man in so einer Konfiguration Schema-Migrationen handhabt
So wie ich es verstehe, zielt das auf eine Datenbank pro Tenant ab, oder sogar auf eine noch feiner aufgeteilte Struktur
Ich frage mich, ob es eine vernünftige Methode gibt, Schema-Migrationen sauber zu handhaben, oder ob erwartet wird, dass solche Datenbanken eher kurzlebig sind und man bis zu ihrer Löschung mehrere DB-/DO-Versionen unterstützen muss
In meinem Kopf klänge es spannend, einen Bookmarking-Dienst mit einem DO pro Nutzer zu bauen
Aber sobald man einem bestehenden Table ein neues Feld hinzufügen will, stößt man auf das ziemlich knifflige Problem, diese Änderung auf jedes einzelne DO anwenden zu müssen
Vielleicht sind die Daten in diesem Beispiel einfach zu langlebig, und dieses Design ist eher für temporärere Zwecke gedacht
Mich würde interessieren, wie Leute, die das tatsächlich gemacht haben, damit umgehen
Ich habe eine Version für SQLite in Python geschrieben, weiß aber nicht, ob sie in Durable Objects laufen kann. Über WASM und Pyodide könnte es vielleicht gehen
Andernfalls müsste man sie nach JavaScript portieren
https://github.com/simonw/sqlite-migrate
In letzter Zeit scheint Cloudflare Entwickler dazu zu drängen, DO überall zu verwenden, statt Worker
Auch WebSocket-Verbindungen in Workern laufen nach etwa 30 Sekunden in ein Timeout, und der empfohlene Weg ist, DO zu verwenden
Die ursprüngliche Chat-Demo nutzte ab 2020 ebenfalls DO und WebSockets: https://github.com/cloudflare/workers-chat-demo
Bedeutet das, dass SQLite für DOs in Fehlersituationen eines DOs bis zu 10 Sekunden an Daten verlieren kann?
Hier wollte Simon vermutlich within sagen, nicht „beyond“