Abo-Attribute

Pub/Sub-Abo-Attribute sind die Eigenschaften eines Abos. Sie können beim Erstellen oder Aktualisieren eines Abos Attribute für das Abo festlegen.

In diesem Dokument werden die verschiedenen Aboeigenschaften beschrieben, die Sie für ein Abo festlegen können.

Hinweise

Allgemeine Abo-Properties

Wenn Sie ein Abo erstellen, müssen Sie eine Reihe von Optionen für die Einrichtung des Abos angeben. Einige dieser Properties sind für alle Abotypen gleich und werden in den folgenden Abschnitten erläutert.

Aufbewahrungsdauer für Nachrichten

Mit der Option Nachrichtenaufbewahrungsdauer wird angegeben, wie lange Pub/Sub Nachrichten nach der Veröffentlichung aufbewahrt. Nach Ablauf der Nachrichtenaufbewahrungsdauer kann Pub/Sub die Nachricht unabhängig vom Bestätigungsstatus der Nachricht verwerfen. Wie Sie bestätigte Nachrichten für die Aufbewahrungsdauer aufbewahren, erfahren Sie unter Nachrichten wiedergeben und verwerfen.

Folgende Werte sind für die Option Aufbewahrungsdauer von Nachrichten verfügbar:

  • Standardwert: 7 Tage
  • Mindestwert: 10 Minuten
  • Höchstwert: 31 Tage

Nicht bestätigte Nachrichten können auf inaktive Abos, Sicherungsanforderungen oder eine langsame Verarbeitung zurückzuführen sein. Wenn Sie die Nachrichten innerhalb von 24 Stunden verarbeiten können, fallen keine zusätzlichen Gebühren an. So kannst du neue Belastungen vermeiden:

  • Inaktive Abos Löschen Sie inaktive Abos, um Gebühren für die Aufbewahrung von Nachrichten zu vermeiden.

  • Sicherungsspeicher Wenn Sie die Aboaufbewahrung als Sicherungsspeicher verwenden, können Sie zu einer anderen Speicheroption wechseln, z. B. zur Aufbewahrung von Nachrichten für Themen oder zur Aufbewahrung bestätigter Nachrichten. Bei der Aufbewahrung von Themennachrichten werden Nachrichten nur einmal auf Themenebene gespeichert und sind bei Bedarf für alle Abos verfügbar.

  • Verarbeitungsverzögerungen Fügen Sie nach Möglichkeit weitere Abonnenten hinzu, damit die Nachrichten innerhalb eines Tages verarbeitet werden können.

Bestätigte Nachrichten speichern

Wenn Sie die Aufbewahrungsdauer für Nachrichten angeben, können Sie auch festlegen, ob bestätigte Nachrichten aufbewahrt werden sollen.

Mit der Option Bestätigte Nachrichten aufbewahren können Sie bestätigte Nachrichten für die angegebene Nachrichtenaufbewahrungsdauer aufbewahren. Dies erhöht die Gebühren für Nachrichtenspeicherung. Weitere Informationen finden Sie unter Speicherkosten.

Ablauffrist

Mit der Option Ablaufzeit können Sie die Ablaufzeit Ihres Abos verlängern.

Abos ohne Abonnentenaktivität oder Änderungen an den Abo-Attributen laufen ab. Erkennt Pub/Sub Aktivitäten von Abonnenten oder aktualisierst du eine der Aboeigenschaften, wird die Zeit bis zum Löschen des Abos wieder zurückgesetzt. Beispiele für Aktivitäten von Abonnenten sind offene Verbindungen, aktive Pull- oder erfolgreiche Push-Vorgänge.

Wenn Sie die Ablaufzeit angeben, muss der Wert länger sein als die Nachrichtenaufbewahrungsdauer, die in der Option Nachrichtenaufbewahrungsdauer angegeben ist.

Folgende Werte sind für die Option Gültigkeitsdauer verfügbar:

  • Standardwert: 31 Tage
  • Mindestwert = 1 Tag

Um zu verhindern, dass ein Abo abläuft, legen Sie die Ablaufzeit auf never expire fest.

Bestätigungsfrist

Mit der Option Bestätigungsfrist wird die ursprüngliche Frist angegeben, nach der eine unbestätigte Nachricht noch einmal gesendet wird. Sie können den Termin für die Bestätigung pro Nachricht verlängern, indem Sie nachfolgende ModifyAckDeadline-Anfragen senden.

Folgende Werte sind für die Option Termin für die Bestätigung zulässig:

  • Standardwert: 10 Sekunden
  • Mindestwert: 10 Sekunden
  • Höchstwert: 600 Sekunden

In einigen Fällen können Pub/Sub-Clientbibliotheken die Zustellungsrate steuern und die Bestätigungsfrist dynamisch ändern. In diesem Fall wird die Nachricht möglicherweise vor dem von Ihnen festgelegten Termin für die Bestätigung noch einmal gesendet. Wenn Sie dieses Verhalten überschreiben möchten, verwenden Sie minDurationPerAckExtension und maxDurationPerAckExtension. Weitere Informationen zur Verwendung dieser Werte finden Sie unter Unterstützung der Zustellung genau einmal in Clientbibliotheken.

Abo-Filter

Verwenden Sie die Option Abofilter, um einen String mit einem Filterausdruck anzugeben. Wenn ein Abo einen Filter hat, werden nur die Nachrichten zugestellt, die dem Filter entsprechen. Der Pub/Sub-Dienst bestätigt automatisch die Nachrichten, die nicht mit dem Filter übereinstimmen.

  • Sie können Nachrichten nach ihren Attributen, aber nicht nach den Daten in der Nachricht filtern.

  • Falls nicht anders angegeben, filtert das Abo die Nachrichten nicht und alle Abonnenten erhalten alle Nachrichten.

  • Filter können nach ihrer Anwendung nicht mehr geändert oder entfernt werden.

Wenn Sie Nachrichten aus einem Abo mit einem Filter erhalten, fallen keine Gebühren für ausgehenden Traffic für die von Pub/Sub angegebenen Nachrichten an. Für diese Nachrichten fallen Gebühren für die Nachrichtenzustellung und suchbezogene Speichergebühren an.

Weitere Informationen finden Sie unter Nachrichten von einem Abo filtern.

Nachrichtenreihenfolge

Wenn für ein Abo die Nachrichtenreihenfolge aktiviert ist, erhalten die Abonnentenclients Nachrichten, die in derselben Region mit demselben Reihenfolgeschlüssel veröffentlicht wurden, in der Reihenfolge, in der sie vom Dienst empfangen wurden.

Bei der geordneten Zustellung werden Bestätigungen für spätere Nachrichten erst verarbeitet, wenn die Bestätigungen für frühere Nachrichten verarbeitet wurden.

Die Publisher müssen Nachrichten mit einem Sortierschlüssel senden, damit Pub/Sub die Nachrichten in der richtigen Reihenfolge liefern kann.

Ist dies nicht festgelegt, stellt Pub/Sub Nachrichten möglicherweise nicht in der richtigen Reihenfolge zu, auch wenn sie einen Sortierungsschlüssel haben.

Thema für unzustellbare Nachrichten

Wenn eine Nachricht nach einer festgelegten Anzahl von Zustellversuchen nicht zugestellt werden kann oder ein Abonnent sie nicht bestätigen kann, können Sie ein Thema für unzustellbare Nachrichten konfigurieren, unter dem diese Nachrichten noch einmal veröffentlicht werden können.

Wenn Sie ein Thema für unzustellbare Nachrichten festlegen, können Sie auch die maximale Anzahl der Zustellungsversuche angeben. Die folgenden Werte sind für die maximale Anzahl von Zustellungsversuchen für das Thema für unzustellbare Nachrichten zulässig:

  • Standardwert: 5 Zustellungsversuche
  • Mindestwert = 5 Übermittlungsversuche
  • Höchstwert: 100 Zustellungsversuche

Wenn sich das Thema für unzustellbare Nachrichten in einem anderen Projekt als das Abo befindet, müssen Sie auch die Projekt-ID mit dem Thema für unzustellbare Nachrichten angeben.

Weitere Informationen finden Sie unter An Themen für unzustellbare Nachrichten weiterleiten.

Wiederholungsrichtlinie

Wenn die Bestätigungsfrist abläuft oder ein Abonnent mit einer negativen Bestätigung antwortet, kann Pub/Sub die Nachricht noch einmal senden. Dieser erneute Zustellungsversuch wird als Wiederholungsrichtlinie des Abos bezeichnet.

Standardmäßig ist für die Wiederholungsrichtlinie eines Abos Sofort wiederholen festgelegt. Bei dieser Option sendet Pub/Sub die Nachricht noch einmal, wenn die Bestätigungsfrist abläuft oder ein Abonnent mit einer negativen Bestätigung antwortet.

Sie können den Wert auch auf Wiederholung nach verspätetem exponentiellem Backoff festlegen. In diesem Fall müssen Sie die maximalen und minimalen Backoff-Werte angeben.

Hier finden Sie einige Richtlinien für die Festlegung der Werte für das maximale und minimale Backoff-Intervall:

  • Wenn Sie den maximalen Wert für die Backoff-Dauer festlegen, beträgt der Standardwert für die minimale Backoff-Dauer 10 Sekunden.

  • Wenn Sie den Mindestwert für die Backoff-Dauer festlegen, beträgt der Standardwert für die maximale Backoff-Dauer 600 Sekunden.

  • Sie können maximal 600 Sekunden festlegen.

Richtlinien für Wiederholungsversuche und Batch-Nachrichten

Wenn sich Nachrichten in einem Batch befinden, startet Pub/Sub das exponentielle Backoff, wenn eine der folgenden Situationen eintritt:

  • Der Abonnent sendet für jede Nachricht im Batch eine negative Bestätigung.

  • Die Bestätigungsfrist läuft ab.

Wiederholungsrichtlinie und Push-Abo

Wenn Sie Nachrichten von einem Push-Abo erhalten, sendet Pub/Sub Nachrichten nach dem Push-Backoff und nicht nach der exponentiellen Backoff-Dauer noch einmal. Wenn der Push-Backoff länger als die exponentielle Backoff-Dauer ist, sendet Pub/Sub nicht bestätigte Nachrichten nach dem Push-Backoff noch einmal.

Pull-Abo-Attribute

Wenn Sie ein Pull-Abo konfigurieren, können Sie die folgenden Eigenschaften angeben.

Genau einmal zugestellt

Genau einmal zugestellt. Wenn diese Option festgelegt ist, erfüllt Pub/Sub die Garantien für die genau einmalige Zustellung. Falls nicht anders angegeben, unterstützt das Abo die mindestens einmalige Zustellung für jede Nachricht.

Push-Abo-Attribute

Wenn Sie ein Push-Abo konfigurieren, können Sie die folgenden Eigenschaften angeben.

Endpunkte

Endpunkt-URL (erforderlich) Eine öffentlich zugängliche HTTPS-Adresse. Der Server für den Push-Endpunkt muss ein gültiges SSL-Zertifikat haben, das von einer Zertifizierungsstelle signiert wurde. Der Pub/Sub-Dienst sendet Nachrichten an Push-Endpunkte aus derselben Google Cloud-Region, in der der Pub/Sub-Dienst die Nachrichten speichert. Der Pub/Sub-Dienst sendet Nachrichten aus derselben Google Cloud-Region auf Best-Effort-Basis.

Für Pub/Sub ist kein Eigentumsnachweis für Domains für Push-Abos mehr erforderlich. Wenn Ihre Domain unerwartete POST-Anfragen von Pub/Sub erhält, können Sie einen mutmaßlichen Missbrauch melden.

Authentifizierung

Aktivieren Sie die Authentifizierung. Wenn diese Option aktiviert ist, enthalten von Pub/Sub an den Push-Endpunkt gesendete Nachrichten einen Autorisierungsheader, über den der Endpunkt die Anfrage authentifizieren kann. Für App Engine Standard- und Cloud Run-Funktionen-Endpunkte, die im selben Projekt wie das Abo gehostet werden, sind automatische Authentifizierungs- und Autorisierungsmechanismen verfügbar.

Die Authentifizierungskonfiguration für ein authentifiziertes Push-Abo besteht aus einem nutzerverwalteten Dienstkonto und den Zielgruppenparametern, die in einem create-, patch- oder ModifyPushConfig-Aufruf angegeben werden. Außerdem müssen Sie einem Kundenservicemitarbeiter eine bestimmte Rolle zuweisen, wie im nächsten Abschnitt beschrieben.

  • Nutzerverwaltetes Dienstkonto (erforderlich) Das Dienstkonto, das dem Push-Abo zugeordnet ist. Dieses Konto wird als email-Anspruch des generierten JSON Web Tokens (JWT) verwendet. Im Folgenden finden Sie eine Liste der Anforderungen an das Dienstkonto:

  • Zielgruppe Ein einzelner String ohne Berücksichtigung der Groß- und Kleinschreibung, mit dem der Webhook die beabsichtigte Zielgruppe dieses bestimmten Tokens überprüfen kann.

  • Dienst-Agent (erforderlich)

    • Pub/Sub erstellt automatisch ein Dienstkonto für Sie im Format service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com.

    • Diesem Dienst-Agent muss die Berechtigung iam.serviceAccounts.getOpenIdToken (in der Rolle roles/iam.serviceAccountTokenCreator enthalten) gewährt werden, damit Pub/Sub JWT-Tokens für authentifizierte Push-Anfragen erstellen kann.

Entpacken der Nutzlast

Mit der Option Entpacken der Nutzlast aktivieren werden aus Pub/Sub-Nachrichten alle Nachrichtenmetadaten entfernt, mit Ausnahme der Nachrichtendaten. Beim Entfernen der Nutzlast werden die Nachrichtendaten direkt als HTTP-Textkörper gesendet.

  • Metadaten schreiben Fügt dem Anfrageheader zuvor entfernte Nachrichtenmetadaten wieder hinzu.

BigQuery-Properties

Wenn Sie als Übermittlungstyp für das Abo In BigQuery schreiben auswählen, können Sie die folgenden zusätzlichen Eigenschaften angeben.

Schema des Themas verwenden

Mit dieser Option kann Pub/Sub das Schema des Pub/Sub-Themas verwenden, an das das Abo angehängt ist. Außerdem schreibt Pub/Sub die Felder in Nachrichten in die entsprechenden Spalten der BigQuery-Tabelle.

Beachten Sie bei der Verwendung dieser Option die folgenden zusätzlichen Anforderungen:

  • Die Felder im Themaschema und im BigQuery-Schema müssen dieselben Namen haben und ihre Typen müssen miteinander kompatibel sein.

  • Alle optionalen Felder im Schema des Themas müssen auch im BigQuery-Schema optional sein.

  • Erforderliche Felder im Themaschema müssen nicht im BigQuery-Schema erforderlich sein.

  • Wenn es BigQuery-Felder gibt, die nicht im Themaschema vorhanden sind, müssen diese BigQuery-Felder den Modus NULLABLE haben.

  • Wenn das Themaschema zusätzliche Felder enthält, die nicht im BigQuery-Schema vorhanden sind und gelöscht werden können, wählen Sie die Option Unbekannte Felder löschen aus.

  • Sie können nur eine der Aboeigenschaften auswählen: Themaschema verwenden oder Tabellenschema verwenden.

Wenn Sie die Option Schema des Themas verwenden oder Tabellenschema verwenden nicht auswählen, muss die BigQuery-Tabelle eine Spalte namens data vom Typ BYTES, STRING oder JSON haben. Pub/Sub schreibt die Nachricht in diese BigQuery-Spalte.

Änderungen am Pub/Sub-Themenschema oder am BigQuery-Tabellenschema werden möglicherweise nicht sofort wirksam, wenn Nachrichten in die BigQuery-Tabelle geschrieben werden. Wenn beispielsweise die Option Unbekannte Felder löschen aktiviert ist und ein Feld im Pub/Sub-Schema, aber nicht im BigQuery-Schema vorhanden ist, enthalten Nachrichten, die in die BigQuery-Tabelle geschrieben werden, das Feld möglicherweise auch dann nicht, wenn es dem BigQuery-Schema hinzugefügt wurde. Irgendwann werden die Schemas synchronisiert und nachfolgende Nachrichten enthalten das Feld.

Wenn Sie die Option Themenschema verwenden für Ihr BigQuery-Abo verwenden, können Sie auch BigQuery Change Data Capture (CDC) nutzen. CDC aktualisiert Ihre BigQuery-Tabellen durch Verarbeitung und Anwendung von Änderungen auf vorhandene Zeilen.

Weitere Informationen zu dieser Funktion finden Sie unter Tabellenaktualisierungen mit Change Data Capture streamen.

Informationen zur Verwendung dieser Funktion mit BigQuery-Abos finden Sie unter BigQuery-Change Data Capture.

Schema der Tabelle verwenden

Mit dieser Option kann Pub/Sub das Schema der BigQuery-Tabelle verwenden, um die Felder einer JSON-Nachricht in die entsprechenden Spalten zu schreiben. Beachten Sie bei Verwendung dieser Option die folgenden zusätzlichen Anforderungen:

  • Veröffentlichte Nachrichten müssen im JSON-Format vorliegen.

  • Die folgenden JSON-Konvertierungen werden unterstützt:

    JSON-Typ BigQuery-Datentyp
    string NUMERIC, BIGNUMERIC, DATE, TIME, DATETIME oder TIMESTAMP
    number NUMERIC, BIGNUMERIC, DATE, TIME, DATETIME oder TIMESTAMP
    • Wenn Sie number bis DATE, DATETIME, TIME oder TIMESTAMP-Conversions verwenden, muss die Zahl den unterstützten Darstellungen entsprechen.
    • Bei der Umwandlung von number in NUMERIC oder BIGNUMERIC sind Genauigkeit und Wertebereich auf die Werte beschränkt, die vom IEEE 754-Standard für Gleitkommaarithmetik akzeptiert werden. Wenn Sie eine hohe Genauigkeit oder einen größeren Wertebereich benötigen, verwenden Sie stattdessen string bis NUMERIC oder BIGNUMERIC-Conversions.
    • Bei der Verwendung von string- bis NUMERIC- oder BIGNUMERIC-Konvertierungen geht Pub/Sub davon aus, dass der String eine für Menschen lesbare Zahl ist (z.B. "123.124"). Wenn die Verarbeitung des Strings als für Menschen lesbare Zahl fehlschlägt, behandelt Pub/Sub den String als mit dem BigDecimalByteStringEncoder codierte Bytes.

  • Wenn dem Thema des Abos ein Schema zugewiesen ist, muss die Eigenschaft „Nachrichtencodierung“ auf JSON festgelegt sein.

  • Wenn BigQuery-Felder vorhanden sind, die nicht in den Nachrichten enthalten sind, müssen diese BigQuery-Felder sich im Modus NULLABLE befinden.

  • Wenn die Nachrichten zusätzliche Felder enthalten, die nicht im BigQuery-Schema vorhanden sind und gelöscht werden können, wählen Sie die Option Unbekannte Felder löschen aus.

  • Sie können nur eine der Aboeigenschaften auswählen: Themaschema verwenden oder Tabellenschema verwenden.

Wenn Sie die Option Schema des Themas verwenden oder Tabellenschema verwenden nicht auswählen, muss die BigQuery-Tabelle eine Spalte namens data vom Typ BYTES, STRING oder JSON haben. Pub/Sub schreibt die Nachricht in diese BigQuery-Spalte.

Änderungen am BigQuery-Tabellenschema werden möglicherweise nicht sofort für Nachrichten übernommen, die in die BigQuery-Tabelle geschrieben werden. Wenn beispielsweise die Option Unbekannte Felder löschen aktiviert ist und ein Feld in den Nachrichten, aber nicht im BigQuery-Schema vorhanden ist, enthalten Nachrichten, die in die BigQuery-Tabelle geschrieben werden, das Feld möglicherweise auch dann nicht, wenn es dem BigQuery-Schema hinzugefügt wurde. Nach einiger Zeit wird das Schema synchronisiert und nachfolgende Nachrichten enthalten das Feld.

Wenn Sie für Ihr BigQuery-Abo die Option Tabellenschema verwenden verwenden, können Sie auch BigQuery Change Data Capture (CDC) nutzen. CDC aktualisiert Ihre BigQuery-Tabellen durch Verarbeitung und Anwendung von Änderungen auf vorhandene Zeilen.

Weitere Informationen zu dieser Funktion finden Sie unter Tabellenaktualisierungen mit Change Data Capture streamen.

Informationen zur Verwendung dieser Funktion mit BigQuery-Abos finden Sie unter BigQuery-Change Data Capture.

Unbekannte Felder löschen

Diese Option wird mit der Option Schema des Themas verwenden oder Schema der Tabelle verwenden verwendet. Mit dieser Option kann Pub/Sub alle Felder löschen, die im Schema des Themas oder in der Nachricht, aber nicht im BigQuery-Schema vorhanden sind. Wenn Unbekannte Felder löschen nicht festgelegt ist, werden Nachrichten mit zusätzlichen Feldern nicht in BigQuery geschrieben und verbleiben im Rückstand des Abos. Das Abo befindet sich dann im Fehlerstatus.

Metadaten schreiben

Mit dieser Option kann Pub/Sub die Metadaten jeder Nachricht in zusätzliche Spalten in der BigQuery-Tabelle schreiben. Andernfalls werden die Metadaten nicht in die BigQuery-Tabelle geschrieben.

Wenn Sie die Option Metadaten schreiben auswählen, muss die BigQuery-Tabelle die in der folgenden Tabelle beschriebenen Felder enthalten.

Wenn Sie die Option Metadaten schreiben nicht auswählen, ist für die BigQuery-Tabelle nur das Feld data erforderlich, es sei denn, use_topic_schema ist wahr. Wenn Sie sowohl die Option Metadaten schreiben als auch Schema des Themas verwenden auswählen, darf das Schema des Themas keine Felder mit Namen enthalten, die mit denen der Metadatenparameter übereinstimmen. Diese Einschränkung gilt auch für CamelCase-Versionen dieser Parameter.

Parameter
subscription_name

STRING

Name eines Abos.
message_id

STRING

ID einer Nachricht
publish_time

TIMESTAMP

Der Zeitpunkt der Veröffentlichung einer Nachricht.
data

BYTES, STRING oder JSON

Den Nachrichtentext.

Das Feld data ist für alle BigQuery-Zieltabellen erforderlich, für die nicht Schema des Themas verwenden oder Tabellenschema verwenden ausgewählt ist. Wenn das Feld vom Typ „JSON“ ist, muss der Nachrichtentext in einem gültigen JSON-Format sein.
attributes

STRING oder JSON

Ein JSON-Objekt mit allen Nachrichtenattributen. Außerdem enthält es zusätzliche Felder, die Teil der Pub/Sub-Nachricht sind, einschließlich des Sortierungsschlüssels, sofern vorhanden.

Cloud Storage-Properties

Wenn du als Übermittlungstyp für das Abo In Cloud Storage schreiben auswählst, kannst du die folgenden zusätzlichen Properties angeben.

Bucket-Name

Ein Cloud Storage-Bucket muss bereits vorhanden sein, bevor Sie ein Cloud Storage-Abo erstellen.

Die Nachrichten werden als Batches gesendet und im Cloud Storage-Bucket gespeichert. Ein einzelner Batch oder eine einzelne Datei wird als Objekt im Bucket gespeichert.

Für den Cloud Storage-Bucket muss Anfragender bezahlt deaktiviert sein.

Informationen zum Erstellen eines Cloud Storage-Bucket finden Sie unter Buckets erstellen.

Präfix, Suffix und Datum/Uhrzeit für Dateinamen

Die vom Cloud Storage-Abo generierten Cloud Storage-Ausgabedateien werden als Objekte im Cloud Storage-Bucket gespeichert. Der Name des im Cloud Storage-Bucket gespeicherten Objekts hat das folgende Format: <file-prefix><UTC-date-time>_<uuid><file-suffix>.

Die folgende Liste enthält Details zum Dateiformat und zu den Feldern, die Sie anpassen können:

  • <file-prefix> ist das benutzerdefinierte Dateinamenspräfix. Dieses Feld ist optional.

  • <UTC-date-time> ist ein anpassbarer, automatisch generierter String, der auf dem Zeitpunkt basiert, zu dem das Objekt erstellt wurde.

  • <uuid> ist ein automatisch generierter Zufallsstring für das Objekt.

  • <file-suffix> ist das benutzerdefinierte Dateinamensuffix. Dieses Feld ist optional. Das Dateiendung darf nicht auf „/“ enden.

  • Sie können das Präfix und Suffix des Dateinamens ändern:

    • Wenn der Wert des Dateinamenspräfixes beispielsweise prod_ und der Wert des Dateinamenssuffixes _archive ist, lautet ein Beispielobjektname prod_2023-09-25T04:10:00+00:00_uN1QuE_archive.

    • Wenn Sie kein Dateinamenpräfix und ‑suffix angeben, hat der im Cloud Storage-Bucket gespeicherte Objektname das Format: <UTC-date-time>_<uuid>.

    • Die Anforderungen für die Benennung von Cloud Storage-Objekten gelten auch für das Präfix und Suffix des Dateinamens. Weitere Informationen finden Sie unter Cloud Storage-Objekte.

  • Sie können festlegen, wie Datum und Uhrzeit im Dateinamen angezeigt werden:

    • Erforderliche Datum/Uhrzeit-Abgleiche, die nur einmal verwendet werden können: Jahr (YYYY oder YY), Monat (MM), Tag (DD), Stunde (hh), Minute (mm), Sekunde (ss). YY-YYYY oder MMM sind beispielsweise ungültig.

    • Optionale Übereinstimmungen, die nur einmal verwendet werden können: Datums-/Uhrzeit-Trennzeichen (T) und Zeitzonendifferenz (Z oder +00:00).

    • Optionale Elemente, die Sie mehrmals verwenden können: Bindestrich (-), Unterstrich (_), Doppelpunkt (:) und Schrägstrich (/).

    • Wenn der Wert des Dateinamens im Datums-/Uhrzeitformat beispielsweise YYYY-MM-DD/hh_mm_ssZ ist, ist ein Beispielobjektname prod_2023-09-25/04_10_00Z_uNiQuE_archive.

    • Wenn das Datums-/Uhrzeitformat des Dateinamens auf ein Zeichen endet, das kein Übereinstimmungszeichen ist, wird dieses Zeichen durch das Trennzeichen zwischen <UTC-date-time> und <uuid> ersetzt. Wenn der Wert des Dateinamens im Datums-/Uhrzeitformat beispielsweise YYYY-MM-DDThh_mm_ss- ist, ist ein Beispielobjektname prod_2023-09-25T04_10_00-uNiQuE_archive.

Batchverarbeitung von Dateien

Mit Cloud Storage-Abos können Sie festlegen, wann eine neue Ausgabedatei erstellt werden soll, die als Objekt im Cloud Storage-Bucket gespeichert wird. Pub/Sub schreibt eine Ausgabedatei, wenn eine der angegebenen Batch-Bedingungen erfüllt ist. Die folgenden Bedingungen gelten für die Batchverarbeitung in Cloud Storage:

  • Maximale Storage-Batchdauer Diese Einstellung ist erforderlich. Das Cloud Storage-Abo schreibt eine neue Ausgabedatei, wenn der angegebene Wert für die maximale Dauer überschritten wird. Wenn Sie keinen Wert angeben, wird der Standardwert „5 Minuten“ verwendet. Folgende Werte sind für die maximale Dauer zulässig:

    • Mindestwert = 1 Minute
    • Standardwert: 5 Minuten
    • Maximalwert: 10 Minuten

  • Max.Storage-Batchbyte Diese Einstellung ist optional. Das Cloud Storage-Abo schreibt eine neue Ausgabedatei, wenn der angegebene Wert für die maximale Anzahl von Byte überschritten wird. Folgende Werte sind für „max. Bytes“ zulässig:

    • Mindestwert = 1 KB
    • Maximalwert = 10 GiB

  • Storage-Batch-Nachrichten Diese Einstellung ist optional. Das Cloud Storage-Abo schreibt eine neue Ausgabedatei, wenn die angegebene maximale Anzahl von Nachrichten überschritten wird. Folgende Werte sind für „max. Nachrichten“ zulässig:

    • Mindestwert = 1.000

Sie können beispielsweise „max_duration“ auf 6 Minuten und „max_bytes“ auf 2 GB konfigurieren. Wenn die Ausgabedatei in der 4. Minute eine Dateigröße von 2 GB erreicht, schließt Pub/Sub die vorherige Datei ab und beginnt, in eine neue Datei zu schreiben.

Ein Cloud Storage-Abo kann gleichzeitig in mehrere Dateien in einem Cloud Storage-Bucket schreiben. Wenn Sie Ihr Abo so konfiguriert haben, dass alle sechs Minuten eine neue Datei erstellt wird, werden möglicherweise alle sechs Minuten mehrere Cloud Storage-Dateien erstellt.

In einigen Fällen beginnt Pub/Sub möglicherweise früher mit dem Schreiben in eine neue Datei, als in den Bedingungen für die Dateigruppierung konfiguriert. Eine Datei kann auch den Wert „Max. Bytes“ überschreiten, wenn das Abo Nachrichten empfängt, die größer als der Wert „Max. Bytes“ sind.

Dateiformat

Wenn Sie ein Cloud Storage-Abo erstellen, können Sie das Format der Ausgabedateien, die in einem Cloud Storage-Bucket gespeichert werden sollen, als Text oder Avro angeben.

  • Text: Die Nachrichten werden als Nur-Text gespeichert. Ein Zeilenumbruch trennt eine Nachricht von der vorherigen Nachricht in der Datei. Es werden nur Nachrichtennutzlasten gespeichert, keine Attribute oder anderen Metadaten.

  • Avro: Die Nachrichten werden im binären Apache Avro-Format gespeichert. Wenn Sie Avro auswählen, können Sie die folgenden zusätzlichen Properties aktivieren:

    • Metadaten schreiben: Mit dieser Option können Sie die Nachrichtenmetadaten zusammen mit der Nachricht speichern. Metadaten wie subscription_name-, message_id-, publish_time- und attributes-Felder werden in die obersten Felder des Ausgabe-Avro-Objekts geschrieben. Alle anderen Nachrichteneigenschaften außer Daten (z. B. ein vorhandener „ordering_key“) werden als Einträge in die attributes-Map eingefügt.

      Wenn Metadaten schreiben deaktiviert ist, wird nur die Nachrichtenn-Nutzlast in das Ausgabe-Avro-Objekt geschrieben. Hier ist das Avro-Schema für die Ausgabenachrichten, bei dem Metadaten schreiben deaktiviert ist:

      {
  "type": "record",
  "namespace": "com.google.pubsub",
  "name": "PubsubMessage",
  "fields": [
    { "name": "data", "type": "bytes" }
  ]
}

      Hier ist das Avro-Schema für die Ausgabenachrichten mit aktivierter Option Metadaten schreiben:

      {
  "type": "record",
  "namespace": "com.google.pubsub",
  "name": "PubsubMessageWithMetadata",
  "fields": [
    { "name": "subscription_name", "type": "string" },
    { "name": "message_id", "type": "string"  },
    { "name": "publish_time", "type": {
        "type": "long",
        "logicalType": "timestamp-micros"
      }
    },
    { "name": "attributes", "type": { "type": "map", "values": "string" } },
    { "name": "data", "type": "bytes" }
  ]
}

    • Schema des Themas verwenden: Mit dieser Option kann Pub/Sub beim Schreiben von Avro-Dateien das Schema des Pub/Sub-Themas verwenden, an das das Abo angehängt ist.

      Beachten Sie bei der Verwendung dieser Option die folgenden zusätzlichen Anforderungen:

      • Das Themenschema muss im Apache Avro-Format vorliegen.

      • Wenn sowohl Topic-Schema verwenden als auch Metadaten schreiben aktiviert sind, muss das Topic-Schema ein Record-Objekt als Stamm haben. Pub/Sub erweitert die Liste der Felder des Datensatzes um die Metadatenfelder. Daher darf der Datensatz keine Felder mit demselben Namen wie die Metadatenfelder (subscription_name, message_id, publish_time oder attributes) enthalten.

Nächste Schritte