Die drei Speicherprimitive von Cloudflare – KV, R2 und Cache API – erscheinen zusammen in der Dokumentation und teilen sich dieselbe Laufzeit, was den Eindruck erweckt, dass es sich um Alternativen für dasselbe Problem handelt. Das sind sie nicht. Jedes wurde mit einer anderen Architektur, für eine andere Arbeitslast und mit einem anderen Kostenmodell erstellt. Die Verwendung des falschen Mittels ist nicht nur ineffizient: In manchen Fällen funktioniert es auch einfach nicht.
Die Verwirrung ist verständlich. Alle drei „speichern Daten“. Der relevante Unterschied besteht jedoch nicht darin, was sie abstrakt tun, sondern darin, wie sie sich unter realem Datenverkehr verhalten, was sie im großen Maßstab kosten und welche Garantien sie bieten.
KV: der globale Speicher für kleine, häufig gelesene Daten
KV ist ein weltweit verteilter Schlüsselwertspeicher. Schreibvorgänge gehen an einen zentralen Speicher und verbreiten sich in bis zu 60 Sekunden an mehr als 300 PoPs. Lesevorgänge erfolgen innerhalb weniger Millisekunden, wenn der Schlüssel im nächstgelegenen PoP zwischengespeichert ist, oder in etwa 20 ms, wenn er aus dem zentralen Speicher abgerufen werden muss.
Das Kostenmodell begünstigt Volumenablesungen: 0,50 $ pro Million Lesungen nach den ersten 10 Millionen kostenlosen monatlichen Lesungen. Schreibvorgänge kosten die gleichen 0,50 US-Dollar pro Million, allerdings ist nur 1 Million kostenlos. Die maximale Grenze pro Wert beträgt 25 MB.
KV eignet sich gut für selten geschriebene und massiv gelesene Daten: Produktkonfiguration, Feature-Flags, Vorlagen, Inhaltsindizes, Sitzungstoken mit TTL. Es funktioniert schlecht für alles, was sich häufig ändert oder sofortige Konsistenz erfordert – letztendliche Konsistenz mit einem Fenster von bis zu 60 Sekunden und das Fehlen atomarer Operationen sind echte Einschränkungen, keine Dokumentationsdetails.
R2: Objektspeicher ohne Ausgangsgebühr
R2 ist der Objektspeicher von Cloudflare und funktional das Äquivalent zu S3. Es wurde für große Dateien entwickelt – Bilder, Videos, Backups, Datenexporte, statische Assets. Der Wettbewerbsunterschied zu S3 besteht darin, dass keine Ausgangsgebühr anfällt: Sie zahlen nicht für die Datenübertragung von R2 ins Internet, was bei S3 einer der schmerzhaftesten Punkte auf der Rechnung ist.
Die Speicherkosten betragen 0,015 $/GB-Monat. Jeder Lesevorgang (GET) in R2 zählt als Anfrage – es gibt keinen globalen automatischen Cache wie in KV. Wenn Sie in jeder Worker-Anfrage ein R2-Objekt abrufen, zahlen Sie für jede Anfrage plus die Latenzzeit jedes GET. Dies macht R2 ungeeignet für Daten mit hoher Lesefrequenz pro Anfrage.
Die richtige Kombination besteht darin, R2 für die Datei und KV (oder die Cache-API) für den Index oder die zwischengespeicherte Version zu verwenden. Ein Worker, der Bilder bereitstellt, kann die Binärdatei in R2 speichern und einen JSON-Code in KV mit signierten URLs, Metadaten und HTTP-Headern verwalten – sodass häufige Lesezugriffe auf KV in weniger als Millisekunden erfolgen und R2 nur zum Hochladen und Generieren von URLs berührt wird.
Das Limit pro Objekt ist in R2 nicht dasselbe wie in KV: Es werden mehrere GB-Dateien unterstützt. Für KV mit einem Maximum von 25 MB pro Wert ist R2 das natürliche Ziel für alle Daten, die diesen Schwellenwert überschreiten.
Cache-API: der HTTP-Antwort-Cache pro PoP
Die Cache-API speichert Response Objekte im HTTP-Cache des aktuellen PoP. Es ist kostenlos, ohne Betriebskontingente und fungiert als Caching-Ebene für HTTP-Antworten – nicht als gemeinsam genutzter Statusspeicher.
Das entscheidende Detail, das es von KV unterscheidet, ist der Umfang: Die Cache-API gilt pro PoP, nicht global. Ein Cache-Treffer im PoP São Paulo hat keine Auswirkungen auf den PoP Frankfurt. Wenn ein Worker in Frankfurt nie eine Anfrage für diese URL erhalten hat, ist der Cache in Frankfurt kalt, unabhängig davon, wie oft São Paulo diese Antwort aus dem Cache bereitgestellt hat.
Eine weitere Einschränkung: Inhalte in der Cache-API können aufgrund des LRU-Drucks jederzeit vom PoP entfernt werden. Es gibt keine Garantie für die Persistenz zwischen Anfragen – die nächste Anfrage für dieselbe Ressource kann auf den kalten Cache stoßen, selbst wenn die vorherige Anfrage ihn gefüllt hat.
Die Cache-API eignet sich gut für die Deduplizierung von Anfragen an APIs von Drittanbietern innerhalb kurzer Zeit – Sie rufen sie einmal ab, speichern Response 30 Sekunden lang zwischen und nachfolgende Anfragen im selben PoP verwenden die Antwort wieder, ohne die Upstream-API aufzurufen. Es dient auch zum Zwischenspeichern rechenintensiver Antworten, die in Bursts im selben PoP angefordert werden.
Was nicht funktioniert: Verwendung der Cache-API als gemeinsam genutzten Status zwischen Workern oder zwischen Regionen. Zwei Worker-Instanzen in unterschiedlichen PoPs sehen nicht denselben Cache-Status. Für den Shared State ist KV der richtige Weg.
Die Anti-Pattern-Matrix
Die Verwendung von R2 für die Anwendungskonfiguration ist der häufigste Fehler bei Teams, die aus S3 kommen. Unter S3 ist es üblich, config.json in einem Bucket zu speichern und es beim Anwendungsstart zu lesen – der Server hält Stunden oder Tage, sodass ein GET bei jedem Neustart kostengünstig ist. In Workers kann jedes Isolat häufig erstellt und zerstört werden. Jeder GET an R2 hat die Latenz einer Netzwerkanforderung und zählt als kostenpflichtiger Vorgang. Für die Konfiguration ist KV mit Caching auf Modulebene das richtige Modell.
Das andere Extrem ist die Verwendung von KV für Videodateien oder große Datensätze. Die 25-MB-Grenze pro Wert führt bereits zu unmittelbaren Problemen für jeden Vermögenswert in realer Größe. Aber jenseits dieser Grenze sind die Kosten für das Schreiben in KV für Dateien, die häufig per Benutzer-Upload eingehen, unerschwinglich. R2 ist mit 0,015 $/GB/Monat für die Speicherung großer Dateien um mehrere Größenordnungen günstiger.
Die Verwendung der Cache-API für jede Art von Zustand, der über PoPs hinweg konsistent sein muss, ist eine garantierte Quelle für unberechenbares Verhalten. Das typische Symptom ist ein Fehler, der „manchmal“ auftritt – weil der PoP, der die vorherige Anfrage bedient hat, den Cache gefüllt hatte, der PoP, der diese Anfrage bedient hat, jedoch nicht. Die Cache-API ersetzt nicht KV für globale Daten.
So wählen Sie aus
Die Entscheidung beginnt mit der Art der Daten und der Häufigkeit des Zugriffs. Kleine Datenmengen, die viele Male pro Sekunde gelesen werden, müssen global verteilt werden: KV. Große Datei, die per Upload geschrieben und mit geringer bis mäßiger Häufigkeit gelesen wird: R2. HTTP-Antwort, die sich selten ändert und möglicherweise lokal für die PoP: Cache-API ist.
Die Kosten bestätigen oder verwerfen die Auswahl. Wenn das Schreibvolumen hoch ist, wird KV teuer. Wenn das Volumen einzelner GETs pro Datei hoch ist, wird R2 teuer und langsam. Wenn Sie PoP-übergreifende Konsistenz benötigen, reicht die Cache-API nicht aus.
Die Kombination der drei ist das richtige Modell
Das Muster, das in ausgereiften Architekturen mit Workern am häufigsten auftritt, ist die bewusste Kombination. R2 speichert die Binärdatei. KV speichert den Index, die Metadaten und die kurzlebige signierte URL. Die Cache-API dedupliziert Burst-Anfragen an denselben PoP. Jede Schicht tut das, wofür sie entwickelt wurde, und das Ergebnis ist ein Speicherstapel, der eine gute Leistung erbringt und das kostet, was er kosten sollte.
Die Falle versucht, sie auf ein einzelnes Grundelement zu vereinfachen. Cloudflare bietet alle drei an, da jedes ein anderes Problem löst. Das Verständnis der Grenze zwischen ihnen ist es, was eine Implementierung, die in der Entwicklung funktioniert, von einer Implementierung unterscheidet, die den echten Datenverkehr übersteht.
Lesen Sie auch
- Cloudflare KV: Was bedeutet global verteilt, wenn Sie schreiben müssen
- Cache-Invalidierung in KV: das Problem, das niemand elegant löst
- Cloudflare Load Balancing und Geo Steering: Wenn DNS zu einer intelligenten Verkehrsschicht wird
- KV in der Produktion: Die Muster, die funktionieren und die, die am Anfang irreführen
- [KV für Ratenbegrenzung, Feature-Flags und verteilte Konfiguration: wo es funktioniert und wo es kaputt geht7
- Arbeiter + D1 + KV + R2: Zusammenstellen von Bindungen im selben Dienst