Diese Seite wurde von der Cloud Translation API übersetzt.

Best Practices für lang andauernde Vorgänge

Auf dieser Seite werden Best Practices für die Ausführung und Verwaltung langer Laufzeiten beschrieben. Vorgänge (LROs) in der Cloud Healthcare API. Eine Übersicht über LROs in der Cloud Healthcare API finden Sie unter Vorgänge mit langer Ausführungszeit verwalten.

LRO-Properties

Die folgenden Abschnitte gelten für die unter Methoden, die einen LRO zurückgeben aufgeführten Methoden.

Auswirkungen auf das Kontingent

LROs teilen sich kein Kontingent mit den CRUD-Methoden (Create, Read, Update, Delete) der Cloud Healthcare API, die die folgenden Kontingenttypen verbrauchen:

Das LRO-Kontingent wird anhand der Messwerte fhir_store_lro_ops und dicom_store_lro_ops berechnet.

Die Cloud Healthcare API begrenzt die Anzahl der LROs, die gleichzeitig ausgeführt werden können in einem Google Cloud-Projekt. Weitere Informationen finden Sie unter Limits für die Anzahl der LROs.

Datendurchsatz

LRO-Methoden erreichen in der Regel einen höheren Datendurchsatz als entsprechende CRUD-Methoden. Beispielsweise ist der Import von DICOM-Instanzen mit dicomStores.import in der Regel schneller als das Speichern der Instanzen einzeln mit dicomStores.storeInstances.

Das gleichzeitige Ausführen mehrerer LROs erhöht den Datendurchsatz möglicherweise nicht, beachten Sie die folgenden Einschränkungen, insbesondere bei der Verarbeitung großer Datenmengen:

Kontingentbeschränkungen
Ressourcenkonflikte
Anderer Traffic, den Ihr Google Cloud-Projekt während der Ausführung eines LRO an die Cloud Healthcare API sendet

Für einen maximalen Datendurchsatz beim Ausführen von LROs sollten Sie Folgendes:

Kleine Import- und Export-Batches haben aufgrund des Overheads in der Regel einen geringen Durchsatz.
LROs werden unabhängig von anderen Cloud Healthcare API-Vorgängen ausgeführt und verbrauchen ein eigenes Kontingent.
Jeder LRO hat einen maximalen Durchsatz.
Gleichzeitige LROs für dieselbe Ressource können zu Sperrkonflikten führen.
Die Cloud Healthcare API begrenzt die Anzahl der LROs, die gleichzeitig in einem Google Cloud-Projekt ausgeführt werden können. Weitere Informationen finden Sie unter Einschränkungen für die Anzahl der LROs.

Planen Sie die Anzahl der LROs für Ihren Anwendungsfall ein. Wenn Sie große Datenbatches auf mehrere LROs aufteilen müssen, halten Sie die Anzahl der Partitionen möglichst gering.

Referenzielle FHIR-Integrität

Bei der Methode fhirStores.import wird die Einstellung disableReferentialIntegrity nicht berücksichtigt. So können Sie Daten mit beliebigen Abhängigkeiten importieren, die nicht sortiert oder gruppiert werden müssen. Dadurch wird der Datendurchsatz erhöht. Wenn die Eingabedaten ungültige Referenzen enthalten oder einige FHIR-Ressourcen nicht importiert werden, kann der Status des FHIR-Speichers die referenzielle Integrität verletzen.

Zur Verwendung von fhirStores.import muss Ihre Clientanwendung um sicherzustellen, dass FHIR-Ressourcenverweise gültig sind. Überprüfen Sie dazu Folgendes:

FHIR-Ressourcendaten und -formatierung sind korrekt
Alle während des Imports auftretenden Fehler werden verwaltet

Verwenden Sie fhir.create oder fhir.executeBundle anstelle von fhirStores.import, um die referenzielle Integrität zu erzwingen. Weitere Informationen finden Sie unter FHIR-Daten importieren oder Bundles ausführen.

Pub/Sub-Benachrichtigungen

Einige Cloud Healthcare API-Methoden senden Pub/Sub-Benachrichtigungen für klinische Ereignisse, z. B. das Erstellen oder Löschen einer Gesundheitsressource. Eine Liste der Methoden die Pub/Sub-Benachrichtigungen senden, siehe Pub/Sub-Benachrichtigungen konfigurieren.

Bei den folgenden Importmethoden werden keine Pub/Sub-Benachrichtigungen gesendet:

Wenn für Teile Ihrer Anwendung eine Benachrichtigung erforderlich ist, Import abgeschlossen haben, verwenden Sie eine andere Benachrichtigungsmethode, mit der die Daten in für den Import.

Limits für die Fehlerbehandlung

Die Cloud Healthcare API protokolliert möglicherweise nicht alle Fehler in einem LRO, insbesondere wenn der LRO große Datenmengen verarbeitet und viele Fehler erzeugt. Implementieren Sie eine Möglichkeit, die LRO-Verarbeitung und Fehler separat zu erfassen. Weitere Informationen finden Sie unter Umgang mit Ressourcenfehlern:

Daten- und Suchindexierung

Aufgrund der asynchronen Suchindexierung kann es zu Verzögerungen bei den Suchergebnissen kommen. Wenn ein LRO eine FHIR-Ressource erstellt oder aktualisiert, kann es zusätzliche Zeit dauern bevor die Änderungen in den Suchergebnissen angezeigt werden.

Beispiel: Bei der Suche nach Patientenressourcen in einem FHIR-Speicher werden möglicherweise nicht sofort alle Ergebnisse zurückgegeben nach einem FHIR-Importvorgang.

Ausführungsreihenfolge

LROs werden basierend auf der Verfügbarkeit von Google Cloud-Ressourcen geplant. Die Reihenfolge, in der LROs ausgeführt und abgeschlossen werden, entspricht möglicherweise nicht der Reihenfolge, in der sie angefordert wurden.

Kleine Import- und Exportanfragen vermeiden

In diesem Abschnitt werden die Einschränkungen von LRO bei der Verarbeitung kleiner Datenmengen beschrieben.

Durch Import- und Exportvorgänge zurückgegebene LROs können den Datendurchsatz skalieren da sie große Datenmengen schnell verarbeiten und Lastspitzen vermeiden. Bis kleine Datenmengen speichern, verwenden Sie eine andere Technik aus den Best Practices zum Speichern von Daten.

Limits für die Anzahl der LROs

Die Cloud Healthcare API begrenzt die Anzahl der LROs, die gleichzeitig ausgeführt werden können in einem Google Cloud-Projekt. Das Limit basiert auf Folgendem:

Der Typ der LRO.
Die Menge der Google Cloud-Ressourcen, die dem LRO zugewiesen sind. Das hängt von der Größe der Eingabedaten ab.

Wenn Sie zu viele LROs ausführen, werden die Raten der Cloud Healthcare API begrenzt, es kommt zu Fehlern und der LRO-Durchsatz kann sinken. Die Cloud Healthcare API schont automatisch Google Cloud-Ressourcen, damit die Anzahl der LROs innerhalb der Ressourcenlimits bleibt.

LROs sind Hintergrundprozesse. Wenn die Last von LROs Prozesse mit höherer Priorität behindern, wie CRUD kann die Cloud Healthcare API den LRO reduzieren, Durchsatz. So wird sichergestellt, dass die Prozesse mit höherer Priorität verfügbar sind.

Aufwand für Ressourcenzuweisung und Bereinigung

Wenn ein LRO gestartet wird, weist die Cloud Healthcare API Ressourcen zu. Dies kann dauert einige Minuten, da die Cloud Healthcare API Folgendes ausführen muss:

Starten Sie einen Controller-Prozess.
Worker aus einem Worker-Pool zuweisen
Legen Sie die Größe der Eingabedaten fest.
Aufgaben im großen Stil zuweisen

Das Beenden und Bereinigen eines LRO kann ebenfalls einige Minuten dauern.

Aufgrund des Aufwands kann ein LRO die eine kleine Datenmenge verarbeitet, kann die meiste Zeit auf die Zuweisung von Worker-Pools und die Bereinigung Ressourcen zu sammeln.

Wenn Sie viele dieser LROs haben, einen geringeren Datendurchsatz, da Sie Ihre Google Cloud- Projektkontingentlimits.

Limits für das Anfordern von LRO-Kontingenten

Implementieren Sie die Methode Best Practices für die Kontingentverwaltung. Wenn Sie noch mehr Kontingent benötigen, kontaktieren Sie Google Cloud Customer Care. Informationen dazu, wie Sie eine Anfrage stellen, finden Sie unter Best Practices zum Anfordern zusätzlicher Kontingente

Wenn Ihre Eingabedaten sehr groß sind, benötigen Sie möglicherweise zusätzliche Kontingente, zum Beispiel:

Sie importieren DICOM-Instanzen, die mehrere Petabyte (PB) groß sind.
Sie importieren Dutzende von Milliarden FHIR-Ressourcen.

LRO-Status und Fehlerstatus

Wenn Sie einen LRO starten, enthält die Antwort eine eindeutige ID. Sie können eine LRO-Status durch Abfragen seiner ID. Nach Abschluss der LRO hat sie einen der folgenden Status:

Ohne Fehler abgeschlossen
Mit einigen Fehlern abgeschlossen
Fertigstellen fehlgeschlagen, aber möglicherweise wurde vor dem Fehlschlagen eine Teilausgabe erzeugt

Im folgenden JSON-Beispiel wird die Antwort beschrieben, die zurückgegeben wird, wenn ein LRO beendet:

{
  "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/operations/OPERATION_ID",
  "metadata": {
    "@type": "METADATA_TYPE",
    "apiMethodName": "API_METHOD_NAME",
    "createTime": "YYYY-MM-DDTHH:MM:SS+ZZ:ZZ",
    "endTime": "YYYY-MM-DDTHH:MM:SS+ZZ:ZZ",
    "logsUrl": "https://console.cloud.google.com/CLOUD_LOGGING_URL"
    "counter": {
      "success": "SUCCESS_COUNT",
      // If there were any failures, they display in the `failure` field.
      "failure": "FAILURE_COUNT"
    }
  },
  "done": true,
  // The `response` field only displays if there were no errors.
  "response": {
    "@type": 
    
  },
  // If there were any errors, an `error` field displays instead of a `response` field.
  // See Troubleshooting long-running operations for a list of response codes.
  "error": {
    "code": ERROR_CODE,
    "message": "DESCRIPTION",
    "details": [
      {
        "@type": "...",
        FIELD1: ...,
        ...
      }
    ]
  }
}

Um den Status eines LRO abzurufen, listen Sie LROs auf und brechen Sie den Vorgang ab. LROs finden Sie unter Vorgänge mit langer Ausführungszeit verwalten.

LRO-Status und Fehlerstatus verwalten

Beachten Sie die folgenden Best Practices, um den LRO-Status und den Fehlerstatus zu verwalten:

Fragen Sie LROs ab, um ihren Status zu erhalten und prüfen Sie, ob sie fertig sind. Für die Abfrage eines LRO rufen Sie die Methode projects.locations.datasets.operations.get wiederholt auf, bis der Vorgang abgeschlossen ist. Verwenden Sie einen Backoff zwischen den Abfrageanfragen, z. B. 10 Sekunden. Wenn die Antwort "done": true enthält, wird der LRO ist abgeschlossen.
Prüfen Sie nach Abschluss eines LRO, ob die Antwort ein Feld error enthält. Wenn dies der Fall ist, bestimmen Sie anhand folgender Daten, ob der Vorgang wiederholt werden soll:
- Der Fehlercode. Siehe Fehlerbehebung bei LROs finden Sie Fehlercodes und empfohlene Maßnahmen.
- Die Anzahl der bereits durchgeführten Neuversuche.
- Die Zeit zwischen dem Beginn des LRO und dem Auftreten des Fehlers. Wenn z. B. ein LRO, der normalerweise mehrere Stunden dauert, mehrere Tage dauert und noch einen Fehlerstatus zurückgegeben hat, möchten Sie vielleicht, dass ein Mensch eingreift. Weitere Informationen dazu, wann eine manuelle Intervention erforderlich sein könnte, finden Sie unter Endgültige Fehlerstatus planen.
Informationen zum Wiederholen eines LRO finden Sie unter LRO in die Warteschlange stellen.
Wenn Sie den LRO nicht noch einmal versuchen, sehen Sie im Feld metadata.counter.failure nach, ob bei bestimmten Ressourcen Fehler aufgetreten sind. Möglicherweise können Sie die Ressourcen einzeln verarbeiten. Weitere Informationen finden Sie unter Umgang mit Ressourcenfehlern.

Ressourcenfehler behandeln

Eine LRO kann mit Fehlern abgeschlossen werden. Für Fehler in der LRO-Antwort gilt das Google Cloud-Fehlermodell. Die LRO-Antwort enthält einen Link zu Cloud Logging mit weiteren Informationen.

Details zum LRO-Fehler

LRO-Fehler in Cloud Logging haben folgende Eigenschaften:

Das Cloud Logging-Fehlerprotokoll enthält keine LRO-ID. Verwenden Sie die Methode operation.id und operation.producer, um den Status des LRO zu ermitteln und Fehler. LROs, die über die Methode projects.locations.datasets.fhirStores.import aufgerufen werden, enthalten beispielsweise import_fhir im Feld operation.producer.

Wenn mehrere LROs die gleichen operation.id und operation.producer haben, Verwenden Sie die Zeitstempel createTime und endTime, um den richtigen LRO zu identifizieren.
Nicht alle LRO-Fehler sind in Cloud Logging verfügbar. Das metadata.counter.failure kann aus folgenden Gründen die Anzahl der tatsächlich protokollierten Fehler überschreiten:
- Einschränkungen für Cloud Logging-Kontingente
- Verfügbarkeit des Cloud Logging-Dienstes
- LRO-Loglimits
Wenn beispielsweise 10 Millionen FHIR-Ressourcen über eine LRO importiert werden und 50 % davon Formatierungsfehler aufweisen, werden aufgrund der Ratenbegrenzung und der Cloud Logging-Kontingente möglicherweise nur einige hundert oder tausend Fehler protokolliert.

Die Anzahl der protokollierten Fehler hängt auch davon ab, wie lange bei hohen Fehlerraten ausgeführt wird. Wenn die LRO langsam ausgeführt wird, werden in Cloud Logging möglicherweise mehr Fehler angezeigt, da die Fehler über einen längeren Zeitraum verteilt waren und nicht der Ratenbegrenzung unterworfen waren.

Auswirkungen der nochmaligen Ausführung eines LRO

Wenn bei einem LRO ein Fehler auftritt und eine Clientanwendung den Vorgang automatisch wiederholt dieselben Daten verwendet, kann der Wiederholungsversuch weitere Fehler verursachen.

Stellen Sie sich ein Szenario vor, bei dem ein LRO von fhirStores.import mit Fehlern abgeschlossen wird da einige der zu importierenden FHIR-Ressourcen ungültig waren. Wenn Sie den Import automatisch mit denselben Daten wiederholen, kann es zu vielen 409 ALREADY_EXISTS-Fehlern kommen, da einige FHIR-Ressourcen bereits beim ursprünglichen Vorgang importiert wurden. Wenn Sie einen LRO abfragen und eine fehlgeschlagene nicht automatisch wiederholen. Überprüfung durch einen Mitarbeiter 409 ALREADY_EXISTS Fehler.

Wenn ein Wiederholungsversuch erfolgreich ist, enthält das Feld metadata.counter.failure keinen aus früheren Vorgängen. Dies kann zu einer falschen Fehleranzahl führen, nach erfolgreicher Wiederholung enthält keine Fehler aus vorherigen Versuchen.

LRO noch einmal versuchen

Wenn Sie eine clientseitige Verarbeitungspipeline haben, die LRO-Fehler erkennt, sollten Sie Cloud Logging nicht verwenden. Wie in Details zum LRO-Fehler gezeigt, sind die Cloud Logging-Fehlerlogs für LROs unzuverlässig und unvollständig. Verwenden Sie die Methode in den folgenden Abschnitten.

Importvorgänge wiederholen

Um Daten zu ermitteln, die nicht importiert werden konnten, vergleichen Sie die importierten Daten in der Cloud Healthcare API mit den Quelldaten in Cloud Storage. Sie haben folgende Möglichkeiten, Daten zu importieren:

Verwenden Sie eine eindeutige Kennung, z. B. eine Patientenaktennummer (Medical Record Number, MRN) für eine FHIR-Patientenressource, um die Daten zu vergleichen.

Unter Auswirkungen des Wiederholens eines LROs finden Sie Informationen dazu, was Sie beim Wiederholen eines Importvorgangs beachten müssen.

Wenn Sie einen Import noch einmal ausführen, werden möglicherweise Ressourcen neu erstellt, die Sie zuvor gelöscht haben. Erwägen Sie folgendes Szenario:

Sie versuchen, 1.000.000 FHIR-Ressourcen zu importieren. 50.000 Ressourcen schlagen aufgrund von Formatierungsfehlern fehl.
Sie verbringen mehrere Tage damit, die Formatierungsfehler zu korrigieren. In dieser Zeit bittet ein Patient Sie, seine Daten zu entfernen.
Wenn Sie den Import noch einmal ausführen, riskieren Sie, die Patientendaten neu zu erstellen, die die Sie gelöscht haben.

Exportvorgänge wiederholen

Schreiben Sie ein Skript, um Daten zu erkennen, die nicht nach BigQuery exportiert werden konnten um eindeutige IDs in den Quelldaten mit den exportierten Daten zu vergleichen.

Sie können Daten mit den folgenden Methoden nach BigQuery exportieren:

LROs in die Warteschlange stellen und verwalten

Wenn Sie LROs ausführen, die große Datenmengen für das Onboarding oder regelmäßig verarbeiten implementieren Sie die folgenden LRO-Warteschlangentechniken:

Beschränken Sie gleichzeitige LROs auf eine kleine Anzahl wie 5. Sie können dieses Limit je nach Größe und Art der LROs, die Sie ausführen.
Überwachen Sie den Abschluss des LRO. Wenn Fehler auftreten, planen Sie die LRO neu oder beheben Sie die Fehler separat in Ihrer Verarbeitungspipeline.
Fehler unter Umgang mit Ressourcenfehlern automatisch beheben wenn möglich.
- Informieren Sie sich über den Anwendungsfall für FHIR-Importe, um zu entscheiden, ob 409 ALREADY_EXISTS-Fehler ignoriert oder separate CRUD-Vorgänge ausgeführt werden sollen, um die Fehler zu beheben. Wie in Details zum LRO-Fehler gezeigt, Einige 409 ALREADY_EXISTS-Fehler werden möglicherweise nicht in Cloud Logging protokolliert. Wenn Ihre Anwendung auf Fehlerlogs angewiesen ist, verwenden Sie eine der Methoden in Wiederholen Sie einen LRO.
- Wenn Sie nur einige Fehler beheben möchten, legen Sie eine kleinere LRO für die Daten in die Warteschlange, bei denen die Fehler aufgetreten sind, oder führen Sie separate CRUD-Vorgänge aus.
- Um viele Fehler zu beheben, ist das erneute Ausführen des LRO möglicherweise die einfachste Option, um für Konsistenz zu sorgen. Unter Importvorgänge noch einmal ausführen finden Sie Informationen zu den Risiken, die mit dem erneuten Ausführen eines Imports auf gelöschte Daten verbunden sind.
Automatisch erkennen, ob menschliches Eingreifen erforderlich ist, um Fehler zu beheben. Sie sollten Tools und operative Playbooks für Systemadministratoren. Zu den Aufgaben zur Behebung von Fehlern gehören:
- LRO verschieben
- Verschieben Sie eine Teilmenge von Daten aus einem vorherigen LRO um.
- Prüfen Sie die Fehler und beheben Sie die Probleme mit den einzelnen Datenelementen. Diese Aufgabe ist nur möglich, wenn dass alle Fehler im LRO protokolliert wurden.
Bestimmen Sie Zeitpläne für LROs. Sie können LROs so planen, dass sie nicht zu Spitzenzeiten ausgeführt werden, wenn viele CRUD-Vorgänge ausgeführt werden. Weitere Informationen finden Sie unter Kontingent verwalten, um den Datendurchsatz zu maximieren.

Überwachen und Benachrichtigungen erhalten

Erstellen und Verwalten von Verfahren zur Überwachung von LROs und zur Behebung von Warnmeldungen. Benachrichtigungen werden hauptsächlich durch LRO-Status und Warteschlangen verursacht. Probleme. Die Verfahren sollten für die folgenden Situationen geeignet sein:

LROs, die mehrmals als konfiguriert erfolglos wiederholt werden.
Probleme, die ein manuelles Eingreifen erfordern, um einen Teil der Fehler zu beheben. Wenn beispielsweise ein LRO fehlschlägt und der Kunde die Fehler nicht beheben kann, ist ein menschliches Eingreifen erforderlich. ist wahrscheinlich erforderlich. Siehe Warteschlangen und Vorgänge mit langer Ausführungszeit verwalten. .
Warteschlangen, die eine Länge überschreiten oder zu schnell wachsen.
Richtlinienanforderungen werden nicht erfüllt, z. B. ein Berechtigungsproblem oder eine Fehlkonfiguration.
Konsistenzprüfungen, die systemische Probleme in mehreren LROs aufzeigen. Möglicherweise haben Sie mehrere LROs zur De-Identifikation, für die das Quell- und das Ziel-Dataset dieselbe Anzahl von FHIR-Ressourcen enthalten müssen. Wenn es eine Diskrepanz gibt, die mit der Zeit zunimmt, kann das auf unverarbeitete Daten hindeuten.
Probleme mit LRO-Kontingenten Weitere Informationen finden Sie unter Kontingente verwalten, um den Datendurchsatz zu maximieren und Best Practices für die Kontingentverwaltung.