Rapid Cache

Auf dieser Seite wird Rapid Cache beschrieben, eine Funktion, die einen SSD-gestützten, zonalen Lese-Cache für Cloud Storage-Buckets bietet, der den Durchsatz erhöhen und die Latenz bei Ihren gespeicherten Daten verringern kann. Rapid Cache bietet Speicherkapazität und Bandbreite, die automatisch an Ihre Anforderungen angepasst werden. Rapid Cache ist ein vollständig verwalteter Dienst, der konsistente Daten zurückgibt.

Rapid Cache ist hilfreich, um die Leistung von leseintensiven Arbeitslasten zu verbessern und die Netzwerkkosten zu senken. Weitere Informationen finden Sie unter Vorteile.

Informationen zum Erstellen und Verwalten von Caches mit Rapid Cache finden Sie unter Caches erstellen und verwalten.

Wie funktioniert Rapid Cache?

Mit Rapid Cache können Sie Caches in derselben Zone wie Ihre Arbeitslasten erstellen. Wenn Sie einen Cache in einer Zone erstellen, werden Datenleseanfragen, die aus der Zone stammen, vom Cache anstelle des Buckets verarbeitet. Jeder Cache bedient Clients in derselben Zone wie der Cache.

Daten aus einem Bucket werden in einen Cache aufgenommen, wenn sie von einer VM gelesen werden, die sich in derselben Zone wie der Cache befindet. Wenn Sie das Verhalten „Ingest-on-Write“ konfigurieren, werden Daten auch in den Cache aufgenommen, wenn sie in den Bucket geschrieben werden.

Metadaten werden nicht im Cache gespeichert. Anfragen für Objektmetadaten werden immer vom Bucket und nicht vom Cache verarbeitet.

Weitere Informationen dazu, wie Daten in einen Cache aufgenommen werden, finden Sie unter Datenaufnahme. Sie können die Gültigkeitsdauer (Time to Live, TTL) und das Ingest-on-Write-Verhalten eines Cache konfigurieren, wenn Sie den Cache erstellen oder aktualisieren.

Vorteile

Wenn Sie Ihre Daten mit Rapid Cache im Cache speichern, profitieren Sie von folgenden Vorteilen:

  • Schnellen Datenzugriff erhalten: Mit Rapid Cache werden Ihre Daten in derselben Zone wie Ihre Rechenressourcen platziert und vollständig von SSD unterstützt. So können Ihre Arbeitslasten einen Durchsatz von bis zu 2,5 TB/s erreichen und die Latenz für schnellere Lesevorgänge wird reduziert.

  • Gebühren für die multiregionale Datenübertragung reduzieren: Für Daten, die aus dem Cache gelesen werden, fallen reduzierte Gebühren für die Datenübertragung an, verglichen mit Daten, die direkt aus einem multiregionalen Bucket gelesen werden.

  • Abrufgebühren senken: Abrufgebühren für Buckets in Nearline Storage, Coldline Storage und Archive Storage fallen nicht für Datenlesevorgänge aus dem Cache an.

  • Geringere Kosten für Lesevorgänge erhalten: Lesevorgänge, die über Rapid Cache bereitgestellt werden, sind günstiger als Vorgänge der Klasse B, die über einen Bucket in Standard Storage bereitgestellt werden.

  • Cachegröße automatisch skalieren: Das dynamische SSD-Caching von Rapid Cache wird automatisch anhand der Nutzung skaliert, ohne dass Sie eine Cachegröße angeben müssen.

  • Caches effizient nutzen: Rapid Cache kann für vorhandene Buckets aktiviert werden, ohne dass Änderungen an Ihren vorhandenen Anwendungen oder APIs erforderlich sind. Daten, die in Rapid Cache gespeichert sind, sind strikt konsistent.

Weitere Informationen zu den Preisen finden Sie unter Preise für Rapid Cache. Informationen zu Kontingenten finden Sie unter Rapid Cache-Kontingente.

Wann sollten Sie Rapid Cache verwenden?

Verwenden Sie Rapid Cache für Daten, die selten geändert und häufig gelesen werden, um das Lesen von Daten für Analysearbeitslasten sowie das Trainieren und Laden von KI/ML-Modellen zu beschleunigen.

Angenommen, Sie trainieren ein KI-Modell über viele Google Kubernetes Engine-Knoten hinweg, die alle wiederholt Daten lesen, die in Ihren Cloud Storage-Buckets gespeichert sind und in derselben Zone ausgeführt werden. Wenn Sie einen Cache in der Zone erstellen, in der Ihre Arbeitslast ausgeführt wird, bietet der Cache zusätzliche Bandbreite und hilft Ihnen, die Gebühren für die Datenübertragung zu reduzieren, die mit dem Lesen von Daten in multiregionalen Buckets verbunden sind. So können Sie größere, skalierte Arbeitslasten effizienter ausführen.

Autoscaling von Cachegröße und Bandbreitenlimit

Rapid Cache bietet temporären Speicherplatz und Bandbreite, die automatisch je nach Menge der in einem Cache gespeicherten Daten skaliert werden.

Das Cache-Bandbreitenlimit beginnt bei 100 Gbit/s und wird mit einer Rate von 20 Gbit/s pro 1 TiB gespeicherter Daten skaliert. Sie können die Startbandbreite oder das gesamte Bandbreitenlimit erhöhen, indem Sie die Menge der im Cache gespeicherten Daten erhöhen, mehr Caches in einer Zone erstellen oder sich an Ihren Technical Account Manager oder Google-Ansprechpartner wenden.

Weitere Informationen zu Größen- und Bandbreitenlimits für Rapid Cache finden Sie unter Cloud Storage-Kontingente und ‑Limits.

Daten in Zonen im Cache speichern

Wenn Sie einen Cache für einen Bucket erstellen, muss er in einer Zone innerhalb des Standorts Ihres Buckets erstellt werden. Wenn sich Ihr Bucket beispielsweise in der Region us-east1 befindet, können Sie einen Cache in us-east1-b, aber nicht in us-central1-c erstellen. Wenn sich Ihr Bucket in der Dual-Region ASIA befindet, können Sie einen Cache in allen Zonen erstellen, aus denen die Regionen asia-east1 und asia-southeast1 bestehen.

Für jeden Bucket können Sie maximal einen Cache pro Zone erstellen. Wenn sich ein Bucket beispielsweise in der Region us-east1 befindet, können Sie einen Cache in us-east1-b und einen weiteren Cache in us-east1-c erstellen. Wenn sich ein Bucket in einer Multiregion befindet, die us-central1 und us-east1 umfasst, können Sie einen Cache in us-central1-a und einen weiteren Cache in us-east1-b erstellen.

Sie können Caches in Zonen erstellen, sofern Kapazität für die Zone verfügbar ist. Wenn die Kapazität zum Erstellen eines Caches nicht verfügbar ist, versucht Rapid Cache weiterhin, einen Cache zu erstellen, bis die Kapazität verfügbar ist oder der Erstellungsprozess vom Nutzer abgebrochen wird. Die Kapazität ist möglicherweise über einen längeren Zeitraum nicht verfügbar.

Sie können Rapid Cache in den folgenden Zonen verwenden. Diese Zonen können je nach Standorttyp Ihres Buckets verwendet werden.

Asien

In der folgenden Tabelle sind die Zonen und Standorte aufgeführt, die für Rapid Cache im geografischen Gebiet „Asien“ verfügbar sind.

Zonenname Region Dual-Region Multiregion Benutzerdefinierte Dual-Region
asia-east1-a
asia-east1-b
asia-east1-c
asia-northeast1-a
asia-northeast1-b
asia-northeast1-c
asia-south1-a
asia-south1-b
asia-south1-c
asia-southeast1-a
asia-southeast1-b
asia-southeast1-c

Europa

In der folgenden Tabelle sind die Zonen und Standorte aufgeführt, die für Rapid Cache in Europa verfügbar sind.

Zonenname Region Dual-Region Multiregion Benutzerdefinierte Dual-Region
europe-north1-a
europe-north1-b
europe-north1-c
europe-west1-b
europe-west1-c
europe-west1-d
europe-west3-a
europe-west3-b
europe-west3-c
europe-west4-a
europe-west4-b
europe-west4-c
europe-west4-ai1a (KI-Zone)
europe-west6-a
europe-west6-b

USA

In der folgenden Tabelle sind die Zonen und Standorte aufgeführt, die für Rapid Cache in den USA verfügbar sind.

Zonenname Region Dual-Region Multiregion Benutzerdefinierte Dual-Region
us-central1-a
us-central1-b
us-central1-c
us-central1-f
us-central1-ai1a (KI-Zone)
us-east1-b
us-east1-c
us-east1-d
us-east4-a
us-east4-b
us-east4-c
us-east5-a
us-east5-b
us-east5-c
us-south1-a
us-south1-b
us-south1-c
us-south1-ai1b (KI-Zone)
us-west1-a
us-west1-b
us-west1-c
us-west2-a
us-west3-a
us-west3-b
us-west3-c
us-west4-a
us-west4-b
us-west4-c

Datenaufnahme für Caches

Standardmäßig werden Daten in einen Cache aufgenommen, nachdem sie zum ersten Mal angefordert wurden.

Da der Cache leer ist, wenn diese erste Anfrage eingeht, können die Daten noch nicht im Cache gefunden werden. Dies führt zu einem ersten Cache-Fehler, bei dem das System die Daten stattdessen aus dem zugrunde liegenden Cloud Storage-Bucket abruft. Während das System diese abgerufenen Daten an den Nutzer sendet, werden sie gleichzeitig in den Cache aufgenommen.

Sobald diese erste Anfrage abgeschlossen ist, befinden sich die Daten im Cache. Alle nachfolgenden Lesevorgänge können dann direkt aus dem Cache als schnelle Cache-Treffer bereitgestellt werden. Dadurch wird die Leselatenz erheblich reduziert und der Datenabruf beschleunigt. Die aufgenommenen Daten verbleiben im Cache, bis ihre TTL abläuft. Danach werden die Daten aus dem Cache entfernt.

Um die langsame Erstanfrage zu vermeiden, können Sie den Cache so konfigurieren, dass Daten beim Schreiben aufgenommen werden.

Daten als Chunks aufnehmen

Beim Aufnehmen von Daten in einen Cache zerlegt Rapid Cache Objekte in kleinere Chunks mit fester Größe. Durch das Aufteilen von Objekten in Blöcke ist ein detaillierteres Caching möglich, insbesondere bei großen Dateien, auf die nur bestimmte Teile zugegriffen werden.

Ein Chunk ist ein 2 MB großer Datenblock. Wenn eine Anfrage für ein Objekt gestellt wird, ermittelt Rapid Cache, welche 2‑MB-Chunks den angeforderten Bytebereich abdecken, und verwaltet diese Chunks unabhängig voneinander.

Das Verhalten bei der Datenaufnahme hängt von der Größe des Objekts ab, das in den Cache aufgenommen wird:

  • Bei Leseanfragen für Objekte, die größer als 2 MB sind, werden nur die Chunks mit dem angeforderten Bytebereich aufgenommen. Wenn Sie beispielsweise die ersten 1 MB einer 100 MB großen Datei lesen, wird nur der erste 2 MB-Chunk aufgenommen.

  • Bei Leseanfragen für Objekte, die kleiner als 2 MB sind (z. B. ein 500 KB großes Bild), wird das gesamte Objekt in den Cache aufgenommen.

Daten beim Schreiben aufnehmen

Wenn Sie für einen Cache die Aufnahme von Daten beim Schreiben aktivieren, werden Daten in den Cache aufgenommen, sobald sie in den Bucket geschrieben werden. Dieses Verhalten kann optional zusätzlich zum Standard-Cacheverhalten aktiviert werden, bei dem Daten nach dem ersten Lesen aufgenommen werden.

Durch die Funktion „Ingest-on-Write“ werden anfängliche Cache-Fehler vermieden und Ihre Arbeitslast profitiert von einem sofortigen Cache-Treffer beim ersten Lesen von Daten. Durch die Aufnahme von Daten beim Schreiben werden Arbeitslasten beschleunigt, bei denen Daten nach dem Schreiben gelesen werden, z. B. beim Wiederherstellen von Systemprüfpunkten oder beim Vorbereiten von Datenpipelines für das Modelltraining.

Sie können einen Cache für die Aufnahme von Daten beim Schreiben aktivieren, wenn Sie den Cache erstellen oder aktualisieren. Sie können einen Cache so konfigurieren, dass alle Objekte aufgenommen werden, die in einen Bucket geschrieben werden (auch als „Bucket-Level Ingest-on-Write“ bezeichnet), oder Objekte, die in den Bucket unter einem angegebenen verwalteten Ordner geschrieben werden, selektiv aufnehmen (auch als „Prefix-Level Ingest-on-Write“ bezeichnet).

Angenommen, Sie aktivieren einen Cache, um die Aufnahme beim Schreiben auf Präfixebene für Objekte im Bucket my-bucket durchzuführen, deren Name das Präfix red/ enthält. Anschließend laden Sie drei Objekte in my-bucket hoch: die Objekte red/my-dog.png, blue/my-cat.png und red/my-goldfish.png. Daher werden nur die Objekte red/my-dog.png und red/my-goldfish.png in den Cache aufgenommen, wenn sie in my-bucket hochgeladen werden.

Wenn Sie die Aufnahme bei Schreibvorgängen auf Präfixebene mit bestimmten Tools (z. B. derGoogle Cloud -Konsole) konfigurieren, wird automatisch ein neuer verwalteter Ordner für Sie erstellt, wenn Sie ein Präfix angeben, das nicht der Name eines vorhandenen verwalteten Ordners ist. Wenn Sie die JSON API verwenden, müssen Sie den verwalteten Ordner jedoch manuell erstellen und ingestOnWrite-Einstellungen für jede Cachezone anwenden. Eine Anleitung zum Aktivieren oder Deaktivieren von „Ingest-on-Write“ mit den einzelnen Tools finden Sie unter Rapid Cache verwenden.

Wenn Sie die JSON API verwenden, können Sie den Abschnitt Datenaufnahme bei Schreibvorgang aktivieren maximieren, um zu erfahren, wie Sie die Datenaufnahme bei Schreibvorgang auf Bucket- oder Präfixebene aktivieren oder deaktivieren. Die Informationen in diesem Abschnitt beziehen sich hauptsächlich auf die JSON API. Bei anderen Tools wie derGoogle Cloud Console werden einige Einstellungen verschleiert, um das Aktivieren und Verwalten von „Ingest-on-Write“ zu vereinfachen.

Informationen zum Aktivieren von „Ingest-on-Write“

In diesem Abschnitt erfahren Sie, welche JSON API-Einstellungen Sie verwenden müssen, um die Aufnahme beim Schreiben für alle Objekte zu aktivieren, die in einen Bucket geschrieben werden, oder nur für ausgewählte Objekte, die unter einem Präfix für verwaltete Ordner in den Bucket geschrieben werden.

Es gibt zwei Einstellungen, mit denen gesteuert wird, ob in einem Cache Daten beim Schreiben für alle Objekte in einem Bucket oder nur für ausgewählte Objekte unter einem Präfix aufgenommen werden:

  • Die Aktivierung von „Ingest-on-Write“ auf Bucket-Ebene erfolgt über das Feld ingestOnWrite einer Cache-Ressource. Das Feld sieht so aus:

    {
"zone": "us-east1-a",
"ttl": "24h",
"ingestOnWrite": true
}
    • Wenn true festgelegt ist, wird „Ingest-on-Write“ für alle Objekte aktiviert, die in den Bucket geschrieben werden. Dadurch werden alle Einstellungen auf Ebene verwalteter Ordner überschrieben, die die Aufnahme beim Schreiben für ausgewählte Objekte nach Präfix ermöglichen.
    • Wenn das Attribut auf false gesetzt ist, wird die Aufnahme beim Schreiben für Objekte auf Bucket-Ebene deaktiviert. Mit dieser Einstellung kann die Ingest-on-Write-Funktion für ausgewählte Objekte nach Präfix über die Einstellungen für verwaltete Ordner aktiviert werden.

  • Die Aktivierung von „Ingest-on-Write“ auf Präfixebene erfolgt über verwaltete Ordner, die Präfixpfade darstellen, die mit einem nachgestellten Schrägstrich enden (z. B. my-prefix/). Wenn „Ingest-on-Write“ auf Präfixebene aktiviert ist, werden Objekte in einem Cache beim Schreiben nur dann selektiv aufgenommen, wenn das Objekt das Präfix in seinem Namen hat.

    Die Aufnahme bei Schreibvorgängen auf Präfixebene wird über das Feld ingestOnWrite der rapidCacheConfig.policies-Zuordnung in einer verwalteten Ordnerressource gesteuert. Eine Cache-Instanz muss vorhanden sein, damit sie in der rapidCacheConfig.policies-Zuordnung angegeben werden kann.

    Die rapidCacheConfig.policies-Zuordnung eines verwalteten Ordners sieht so aus:

    "rapidCacheConfig": {
  "policies": {
    "us-east1-a": {
      "rapidCacheId": "us-east1-a",
      "ingestOnWrite": "unspecified"
    }
    "us-east1-b": {
      ...,
      ...
    }
  }
}
    • Cache-Instanzen, die in der policies-Zuordnung angegeben sind, müssen bereits vorhanden sein, damit die Ingest-on-Write-Funktion auf Präfixebene funktioniert. Wenn Sie beispielsweise rapidCacheId: "us-east1-a" in der Zuordnung policies angeben möchten, muss zuerst ein Cache für die Zone us-east1-a vorhanden sein.
    • Sie können mehrere Cache-Instanzen, die in der policies-Zuordnung angegeben sind, in einem einzigen API-Aufruf aktualisieren.
    • Wenn ingestOnWrite auf enabled gesetzt ist, ist „Ingest-on-Write“ für alle Objekte aktiviert, die unter diesem verwalteten Ordnerpräfix in den Bucket geschrieben werden. Die Ingest-on-Write-Funktion auf Präfixebene kann nur aktiviert werden, wenn das Feld ingestOnWrite der Cache-Ressource false ist.
    • Wenn diese Option auf unspecified (Standard) festgelegt ist, wird die Aktivierung von „Ingest-on-Write“ von der unmittelbar übergeordneten Ressource übernommen. Das kann entweder ein übergeordneter verwalteter Ordner oder der Bucket sein, der den verwalteten Ordner enthält.
    • Alle Caches, die nicht in der Richtlinienzuordnung angegeben sind, werden so behandelt, als ob die Einstellung ingestOnWrite auf unspecified festgelegt ist.

Im Folgenden finden Sie eine Zusammenfassung der Konfiguration Ihres Caches und der verwalteten Ordnerressourcen, um die Aufnahme beim Schreiben auf Bucket- oder Präfixebene zu aktivieren oder zu deaktivieren:

  • Aufnahme beim Schreiben auf Bucket-Ebene aktivieren (nicht auf Präfixebene)

    • Konfiguration: Legen Sie das Feld ingestOnWrite der Cache-Ressource auf true fest.

    • Verhalten: „Ingest-on-write“ ist für alle Objekte aktiviert, die in den Bucket geschrieben werden. Diese Einstellung für den gesamten Bucket überschreibt alle Konfigurationen auf Ebene verwalteter Ordner. Das bedeutet, dass selektive Konfigurationen auf Präfixebene umgangen werden.

  • Ingest-on-Write auf Präfixebene aktivieren (nicht auf Bucket-Ebene)

    • Konfiguration:

      1. Setzen Sie das Feld ingestOnWrite der Cache-Ressource auf false.
      2. Konfigurieren Sie eine gültige policies-Zuordnung (nicht null) in der verwalteten Ordnerressource.
      3. Setzen Sie das Feld ingestOnWrite des verwalteten Ordners auf enabled (oder auf unspecified, wenn es sich um einen untergeordneten Ordner handelt, der enabled von einem aktivierten übergeordneten verwalteten Ordner übernimmt).

    • Verhalten: Die Aufnahme beim Schreiben erfolgt nur für Objekte, die unter übereinstimmenden Präfixen für verwaltete Ordner geschrieben werden.

  • Prefix-level ingest-on-write für übergeordnete und untergeordnete verwaltete Ordner aktivieren

    Es ist nicht möglich, die Ingest-on-Write-Funktion für untergeordnete verwaltete Ordner zu aktivieren, ohne sie auch für den übergeordneten verwalteten Ordner zu aktivieren.

  • Sowohl Bucket- als auch Präfix-Ingest-on-Write deaktivieren

    • Konfiguration:

      1. Setzen Sie das Feld ingestOnWrite der Cache-Ressource auf false.

      2. Setzen Sie alle ingestOnWrite-Felder verwalteter Ordner auf unspecified. Achten Sie darauf, dass das ingestOnWrite-Feld übergeordneter verwalteter Ordner nicht enabled ist.

        Alternativ können Sie auch keine Richtlinien konfigurieren, indem Sie die policies-Zuordnung null leer lassen oder die rapidCacheConfig-Konfiguration ganz weglassen.

    • Verhalten: „Ingest-on-write“ ist global für den Bucket und alle Präfixe deaktiviert.

Wenn Sie die Aufnahme beim Schreiben auf Präfixebene für einen übergeordneten verwalteten Ordner aktivieren, wird die Aufnahme beim Schreiben für alle untergeordneten verwalteten Ordner aktiviert, die in diesem übergeordneten verwalteten Ordner verschachtelt sind. Weitere Informationen dazu, wie Ressourcen die Aktivierung und Deaktivierung von „Ingest-on-Write“ übernehmen, finden Sie im Abschnitt Funktionsweise der Übernahme von „Ingest-on-Write“.

Funktionsweise der Übernahme beim Schreiben

Wenn für einen verwalteten Ordner die Aufnahme beim Schreiben nicht explizit aktiviert ist (d. h. das Feld ingestOnWrite des verwalteten Ordners ist auf unspecified festgelegt), wird das Verhalten des Cache in Bezug auf die Aufnahme beim Schreiben von der übergeordneten Ressource des verwalteten Ordners übernommen, unabhängig davon, ob es sich um den Bucket oder einen übergeordneten verwalteten Ordner handelt.

Wenn Sie „Ingest-on-Write“ auf Präfixebene verwenden, wird die „Ingest-on-Write“-Einstellung, die Sie für einen übergeordneten verwalteten Ordner konfigurieren, von allen untergeordneten verwalteten Ordnern übernommen.

Betrachten wir folgendes Szenario:

  • Sie haben einen verwalteten Ordner a/, dessen übergeordnete Ressource der Bucket my-bucket ist.
  • Sie haben einen verwalteten Ordner a/b/, dessen übergeordnete Ressource der verwaltete Ordner a/ in my-bucket ist.

Wenn ein Objekt mit dem Namen a/b/info.txt geschrieben wird, wertet Rapid Cache die Konfigurationshierarchie von oben nach unten aus:

  1. Unmittelbaren verwalteten Ordner prüfen: Wenn a/b/ auf enabled festgelegt ist, ist die Aufnahme beim Schreiben auf Präfixebene für Objekte aktiviert, die unter a/b/ geschrieben werden. Wenn a/b/ auf unspecified festgelegt ist, prüft Rapid Cache die unmittelbar übergeordnete Ressource, also den verwalteten Ordner a/.
  2. Überprüfen Sie den übergeordneten verwalteten Ordner: Wenn a/ auf enabled festgelegt ist, ist die Aufnahme beim Schreiben auf Präfixebene für a/ und a/b/ aktiviert. Wenn a/ auf unspecified festgelegt ist, wird der übergeordnete Bucket von Rapid Cache geprüft.
  3. Cache-EbeneingestOnWrite des Buckets prüfen: Wenn das Feld ingestOnWrite des Caches auf true festgelegt ist, ist die Ingest-on-Write-Funktion auf Bucket-Ebene aktiviert und überschreibt alle verwalteten Ordner, für die die Ingest-on-Write-Funktion auf Präfixebene konfiguriert ist. Wenn das Feld ingestOnWrite des Cache false ist und das Feld ingestOnWrite der verwalteten Ordner des übergeordneten und des untergeordneten Elements unspecified ist, wird die Ingest-on-Write-Funktion für Objekte im Bucket deaktiviert, die sich in den verwalteten Ordnern des übergeordneten und des untergeordneten Elements befinden. Wenn in diesem Szenario keine anderen verwalteten Ordner im Bucket mit aktivierter Ingest-on-Write-Funktion vorhanden sind, wird Ingest-on-Write für alle Objekte im Bucket deaktiviert.

Time to Live (TTL)

Die TTL eines Cache bestimmt, wie lange Daten im Cache verbleiben, bevor sie entfernt werden. Die TTL ist die Zeitspanne, in der Daten ab dem letzten Lesevorgang im Cache verbleiben. Wenn die TTL beispielsweise auf 24 Stunden festgelegt ist, wird ein Datenblock, der zuletzt am Montag um 11:00 Uhr gelesen wurde und danach nicht mehr, am Dienstag um 11:00 Uhr aus dem Cache entfernt.

Sie können die TTL eines Caches beim Erstellen oder Aktualisieren des Caches festlegen. Sie können die TTL eines Cache auf einen Wert zwischen 24 Stunden und 7 Tagen (einschließlich) festlegen. Wenn nicht angegeben, beträgt die TTL standardmäßig 24 Stunden.

Cache-Vorgänge

In diesem Abschnitt werden die Vorgänge beschrieben, die Sie für Rapid Cache-Caches ausführen können. Einige Vorgänge sind asynchron und geben einen Vorgang mit langer Ausführungszeit zurück, während andere Vorgänge synchron sind, bei denen die Vorgänge sofort ausgeführt werden und eine AnywhereCache-Ressource zurückgeben.

Cache erstellen

Sie können den Standort, die TTL und das Verhalten bei der Datenaufnahme eines Caches festlegen, wenn Sie den Cache erstellen. Der Cache hat den Status WIRD ERSTELLT und wechselt in den Status WIRD AUSGEFÜHRT, sobald er aktiv ausgeführt wird. Das Erstellen des Caches kann bis zu 48 Stunden dauern. Danach überschreitet der Vorgang das Zeitlimit.

Die AnywhereCaches Create API ist asynchron. Bei einem Erstellungsvorgang wird ein Vorgang mit langer Ausführungszeit zurückgegeben. Der Vorgang mit langer Ausführungszeit gibt den Status des Erstellungsvorgangs an und ermöglicht es Ihnen, den Vorgang abzubrechen, bevor er abgeschlossen ist.

Cache aktualisieren

Sie können die TTL oder das Verhalten bei der Datenaufnahme eines Caches festlegen, wenn Sie den Cache aktualisieren. Sie können nur Caches im Status WIRD AUSGEFÜHRT aktualisieren. Ein Cache im Status WIRD ERSTELLT oder DEAKTIVIERT kann nicht aktualisiert werden.

Wenn ein Cache gerade aktualisiert wird, ergibt das Feld pending_update den Wert true. Solange das Feld pending_update den Wert true ergibt, kann der Cache nicht noch einmal aktualisiert werden. Wenn die Aktualisierung der TTL eines Caches abgeschlossen ist, wird die neue TTL sofort auf vorhandene und neue Daten im Cache angewendet.

Die AnywhereCaches Update API ist asynchron und gibt einen Vorgang mit langer Ausführungszeit zurück.

Cache abrufen

Wenn Sie einen Cache abrufen, gibt Rapid Cache den Status und die Konfiguration der Cache-Instanz zurück. Die AnywhereCaches Get API ist synchron und gibt eine AnywhereCache-Ressource zurück.

Caches auflisten

Sie können eine Liste der zugehörigen Caches für einen bestimmten Bucket zurückgeben. Die AnywhereCaches List API ist synchron und unterstützt die Paginierung.

Cache deaktivieren

Sie können einen Cache deaktivieren, um ihn dauerhaft aus der Konfiguration Ihres Buckets zu entfernen. Wenn Sie einen Cache deaktivieren, wechselt er in den Status DEAKTIVIERT. In diesem Zustand können Sie weiterhin vorhandene Daten aus dem Cache lesen, aber keine neuen Daten in den Cache aufnehmen.

Nachdem Sie einen Cache deaktiviert haben, haben Sie einen 1-stündigen Kulanzzeitraum, um die Deaktivierung abzubrechen, indem Sie den Cache fortsetzen. Nach Ablauf dieses 1-stündigen Kulanzzeitraums wird der Cache gelöscht. Wenn der Cache gelöscht wird, werden alle Daten im Cache entfernt und der Cache wird aus dem Bucket entfernt.

Während des 1-stündigen Zeitraums, bevor der Cache gelöscht wird, können Sie den Status DEAKTIVIERT rückgängig machen, indem Sie den Cache fortsetzen. Der Cache wird dann im Status WIRD AUSGEFÜHRT fortgesetzt.

Die AnywhereCaches Disable API ist synchron und gibt eine AnywhereCache-Ressource zurück.

Cache fortsetzen

Sie können Caches fortsetzen, die den Status DEAKTIVIERT haben, sofern der deaktivierte Cache innerhalb des 1-stündigen Kulanzzeitraums liegt. Nach Ablauf des 1-stündigen Kulanzzeitraums wird der Vorgang zum Fortsetzen nach dem Best-Effort-Prinzip ausgeführt, da der Cache jederzeit nach Ablauf des Kulanzzeitraums gelöscht werden kann. Sobald ein Cache fortgesetzt wurde, wechselt er in den Status WIRD AUSGEFÜHRT.

Die AnywhereCaches Resume API ist synchron und gibt eine AnywhereCache-Ressource zurück.

Rapid Cache-Recommender

Der Rapid Cache-Recommender bietet Empfehlungen und Statistiken zum Erstellen von Caches in Bucket-Zonen-Paaren, indem er Ihre Datennutzung und Ihren Speicher analysiert. Übersichtsinformationen und Anleitungen zur Verwendung des Rapid Cache-Recommenders finden Sie unter Rapid Cache-Recommender.

Lesevorgänge für BigQuery mit Rapid Cache beschleunigen

Rapid Cache kann verwendet werden, um Daten für Leseanfragen für Objekte bereitzustellen, die von BigQuery ausgegeben werden. Mit Rapid Cache können Sie das Lesen von Daten für Ihre Anwendungen beschleunigen und gleichzeitig die Kosteneffizienz optimieren.

BigQuery ist zwar ein regionaler Dienst, die zugrunde liegenden Rechenressourcen können jedoch aus Gründen des Load-Balancing gelegentlich zwischen Zonen verschoben werden. Es hat sich bewährt, Rapid Cache für eine BigQuery-Arbeitslast in allen Zonen einer Region zu aktivieren, damit ein verfügbarer Cache verwendet werden kann, falls sich die zugrunde liegenden Rechenressourcen in andere Zonen verschieben. Wenn ein Cache in einer Zone nicht verwendet wird, fallen keine zusätzlichen Kosten an, da Rapid Cache nutzungsbasiert abgerechnet wird. Wenn sich die Ressourcen einer Arbeitslast in eine andere Zone verschieben, müssen die Daten im Cache in der neuen Zone noch einmal aufgenommen werden. Dadurch können einmalige Kosten für die Datenaufnahme entstehen.

Verschlüsselung von Daten im Cache

Die Daten werden im Cache im ursprünglichen serverseitig verschlüsselten Format gespeichert. So wird die Kompatibilität mit den von Cloud Storage unterstützten Verschlüsselungsoptionen gewährleistet.

Limits und Einschränkungen

  • Wenn Sie einen Bucket löschen möchten, müssen Sie zuerst alle zugehörigen Caches löschen. Die einzige Ausnahme ist das Löschen eines Buckets über die Google Cloud Console. Dabei werden alle zugehörigen Caches zusammen mit dem Bucket gelöscht.

  • Wenn Sie Vorgänge zum Erstellen, Deaktivieren, Fortsetzen oder Aktualisieren des Caches ausführen, beschränken Sie die Rate der Vorgänge auf maximal einen Vorgang pro Sekunde. Wenn Sie mehr als einen Vorgang pro Sekunde ausführen, kann dies zu Fehlern führen.

  • Rapid Cache ist kein langlebiger Speicher. Daten können in verschiedenen Szenarien aus dem Cache entfernt werden. Ein Szenario ist, wenn die Größe des Cache automatisch angepasst wird, um sicherzustellen, dass genügend Ressourcen für Ihre Arbeitslasten verfügbar sind. In diesem Fall werden einige Daten möglicherweise gemäß einem Algorithmus der am längsten zurückliegenden Verwendung (least recently used, LRU) entfernt, bis der Rapid Cache-Dienst die Cachegröße erhöht hat.

    Ihre Daten bleiben in jedem Fall sicher in Ihrem Quell-Bucket gespeichert. Wenn Daten aus anderen Gründen aus dem Cache entfernt werden als dem Ablauf der TTL, versucht der Rapid Cache-Dienst, die Daten transparent und ohne zusätzliche Kosten für Sie wieder in den Cache aufzunehmen. Wenn die Daten nicht transparent neu aufgenommen werden können oder aufgrund des Ablaufs der TTL gelöscht wurden, nimmt der Rapid Cache-Dienst die Daten beim ersten Lesevorgang neu auf.

  • Empfehlungen und Statistiken, die vom Rapid Cache-Recommender generiert werden, können nicht mit BigQuery gelesen werden.

Hinweise zur Leistung

  • Fehlende Chunks: Wenn sich eine Anfrage auf mehrere Chunks bezieht und einige Chunks im Cache sind, andere jedoch nicht, ruft Rapid Cache die fehlenden Chunks transparent aus dem Quell-Bucket ab.

  • TTL und Entfernung: Die Richtlinien zur Gültigkeitsdauer (Time to Live, TTL) und zur Entfernung der am wenigsten genutzten Einheiten (Least Recently Used, LRU) werden auch auf Chunks angewendet. Häufig verwendete Teile einer großen Datei bleiben möglicherweise im Cache, während selten verwendete Teile entfernt werden.

Preise

Informationen zu den Preisen für die Verwendung von Rapid Cache finden Sie unter Rapid Cache-Preise.

Kostenkontrollen

Maximieren Sie die folgenden Tipps, um zu erfahren, wie Sie die Kosten für die Ausführung von Caches minimieren können:

Bucket-Auswahl

Sie sollten nur Caches für Buckets erstellen, die Daten enthalten, die Sie im Cache speichern möchten.

Zonenauswahl

Sie sollten Caches nur in Zonen erstellen, in denen Ihre Arbeitslast vom Caching profitiert.

TTL-Einstellung

Sie sollten die minimale TTL angeben, die zum Speichern von Daten im Cache erforderlich ist. Die TTL kann unterbrechungsfrei geändert werden. Der Standardwert ist 1 Tag.

Cache deaktivieren

Sie können einen Cache deaktivieren, um ihn dauerhaft aus dem Dienst zu entfernen und alle zugehörigen Cachegebühren zu stoppen.

Beheben von Problemen durch vorübergehenden Mangel an Ressourcen

In den folgenden Abschnitten wird beschrieben, wie Sie Probleme beheben, wenn ein vorübergehender Ressourcenmangel auftritt, bei dem in einer bestimmten Zone nicht genügend SSD-Kapazität oder Bereitstellungskapazität vorhanden ist, um einen Cache zu erstellen, die Größe eines Caches zu erhöhen oder das Bandbreitenlimit eines Caches zu erhöhen.

Fehler beim Erstellen eines neuen Caches

Rapid Cache kann in einer bestimmten Zone keinen neuen Cache erstellen, weil entweder die SSD-Kapazität oder die Durchsatz-Bereitstellungsressourcen nicht ausreichen. Dies führt zu einem vorübergehenden Ressourcenmangel. In diesem Zeitraum versucht Rapid Cache bis zu 48 Stunden lang, den neuen Cache zu erstellen. Wenn innerhalb von 48 Stunden Ressourcen verfügbar werden, schließt Rapid Cache die Anfrage zum Erstellen des Caches erfolgreich ab. Wenn Ressourcen nicht innerhalb von 48 Stunden verfügbar werden, schlägt die Anfrage zur Erstellung des Caches fehl.

Fehlerbehebung: Um Störungen beim Caching zu vermeiden, können Sie den Vorgang zum Erstellen des Caches manuell abbrechen und einen neuen Cache in einer anderen Zone erstellen, in der möglicherweise Kapazität verfügbar ist. Informationen zum Überwachen oder Abbrechen eines Vorgangs zum Erstellen eines Caches finden Sie unter Vorgänge mit langer Ausführungszeit verwenden.

Cache-Größe kann nicht erhöht werden

Rapid Cache kann die Größe eines Caches nicht erhöhen, wenn die erforderliche SSD-Kapazität in der Zone des Caches nicht verfügbar ist.

Rapid Cache bietet zwar automatische On-Demand-Cache-Größenerhöhungen diese sind jedoch von der Verfügbarkeit der SSD-Kapazität abhängig. Wenn die SSD-Kapazität nicht verfügbar ist, wenn die Anfrage zur automatischen Erhöhung der Cachegröße gestellt wird, wird die Anfrage von Rapid Cache so lange gesendet, bis der vorübergehende Ressourcenmangel endet oder eine Erhöhung der Cachegröße nicht mehr erforderlich ist.

Bei einem vorübergehenden Ressourcenmangel werden neue Daten aufgenommen und vorhandene Daten im Cache werden auf Grundlage der am wenigsten verwendeten Daten entfernt. Bei Caches, die groß genug sind, um die meisten aktiven Daten zu speichern, werden die Cache-Messwerte kaum oder gar nicht beeinträchtigt. Bei Caches mit weniger Kapazität als die Menge an aktiven Daten kann es vorkommen, dass Daten häufiger entfernt und wieder aufgenommen werden als bei Caches, die nicht von Ressourcenmängeln betroffen sind. Wenn die tatsächliche Größe Ihres Cache viel kleiner ist als die benötigte Kapazität, kann es zu folgenden Problemen kommen, die mit Ressourcenmängeln verbunden sind:

  • Ein niedrigeres Cache-Bandbreitenlimit, ein niedrigerer Cache-Durchsatz, ein höherer Verbrauch des Bandbreitenkontingents für die Datenübertragung und mögliche Auswirkungen auf andere Messwerte
  • Die Abrechnung kann auf folgende Weise beeinträchtigt sein:
    • Höhere Kosten durch die Cache-Aufnahmegebühr
    • Geringere Kosten durch die Cache-Speichergebühr
    • Geringere Kosten durch die Gebühr für die ausgehende Cache-Datenübertragung
    • Geringere Kosten durch die Gebühren für den ausgehenden Cache-Datenübertragungsvorgang
    • Höhere Kosten durch die Gebühr für die multiregionale Datenübertragung
    • Höhere Kosten durch die Verwendung von Vorgängen der Klasse B

Informationen zu diesen Gebühren finden Sie unter Rapid Cache-Preise.

Fehlerbehebung: Um bei einem vorübergehenden Ressourcenmangel optimale Ergebnisse zu erzielen, empfehlen wir, Ihre Caches zu überwachen und unnötige Caches oder Arbeitslasten nach Bedarf zu deaktivieren.

Bandbreitenlimit eines Cache kann nicht hochskaliert werden

Ein Mangel an Cache-Bandbreitenlimit kann vorübergehend auftreten, wenn die Cachegröße erhöht wird und die Durchsatz-Bereitstellungsressourcen in einer bestimmten Zone nicht ausreichen, um das Cache-Bandbreitenlimit vorhandener Caches mit 20 Gbit/s pro TiB zu skalieren. Bei einem Mangel an Cache-Bandbreite erlaubt Rapid Cache nicht, dass das Cache-Bandbreitenlimit von mit 20 Gbit/s pro TiB an Daten skaliert wird, der Cache verarbeitet jedoch weiterhin Leseanfragen. Sie können mehr Cache-Bandbreite anfordern, indem Sie sich an Ihren Technical Account Manager oder Google-Ansprechpartner wenden. Bei einem Mangel an verfügbarer Cache-Bandbreite kann es zu einem Anstieg des Bandbreitenverbrauchs im ausgehenden Datentraffic Ihres Buckets kommen.

Fehlerbehebung: Um bei einem vorübergehenden Ressourcenmangel optimale Ergebnisse zu erzielen, empfehlen wir, Ihre Caches zu überwachen und unnötige Caches oder Arbeitslasten nach Bedarf zu deaktivieren.

Nächste Schritte