Best Practices für den Durchsatz der Datenaufnahme

Auf dieser Seite werden Best Practices zur Optimierung des Datendurchsatzes bei der Aufnahme von Daten in die Cloud Healthcare API beschrieben. Diese Empfehlungen richten sich an technische Fachkräfte, die Erfahrung in der Verwaltung des Datendurchsatzes für große Systeme haben.

Datendurchsatz

Der Datendurchsatz ist die Menge an Ressourcen wie FHIR-Ressourcen oder DICOM-Instanzen oder Byte, die die Cloud Healthcare API pro Sekunde aufnimmt.

Einschränkungen des Datendurchsatzes

In der folgenden Liste werden Gründe beschrieben, warum der Datendurchsatz möglicherweise eingeschränkt ist:

• Sie haben keine Anfragen mit großem Volumen geplant, die zu Trafficspitzen führen.
• Bandbreiteneinschränkungen verlangsamen die Aufnahme großer Datenmengen, die in kurzer Zeit gesendet werden.
• Mehrere gleichzeitige Transaktionen ändern dieselbe Cloud Healthcare API-Ressource, was zu Datenkonflikten führt.
• Es werden zu viele kleine Anfragen gestellt. Weitere Informationen finden Sie unter Kleine Import- und Exportanfragen vermeiden.
• Zu viele Vorgänge mit langer Ausführungszeit (Long-Running Operations, LROs) werden gleichzeitig ausgeführt und die Bandbreite ist begrenzt.
• Es sind zu viele LROs gleichzeitig geplant, was zu Fehlern führt.

Fehlgeschlagene Anfragen wiederholen

Wenn ein Client Anfragen nach Fehlern schnell und wiederholt wiederholt, kann dies die Cloud Healthcare API-Kontingente überschreiten. In den folgenden Abschnitten wird beschrieben, wie fehlgeschlagene Anfragen effizient wiederholt werden.

Exponentiellen Backoff mit Jitter und persistenten Wiederholungswarteschlangen verwenden

Der exponentielle Backoff mit eingeführtem Jitter ist eine standardmäßige Strategie zur Fehlerbehandlung für Netzwerkanwendungen. Ein Client wiederholt fehlgeschlagene Anfragen regelmäßig mit exponentiell zunehmenden Verzögerungen zwischen den Wiederholungen und einer kleinen, zufälligen Verzögerung.

Die Implementierung des exponentiellen Backoffs muss für jeden Wiederholungsversuch idempotent sein. Das gilt insbesondere, wenn Sie eine benutzerdefinierte Logik zum Umgehen der Fehlerbedingungen verwenden. Weitere Informationen finden Sie in der HTTP-Spezifikation unter 9.2.2 Idempotente Methoden.

Die meisten Programmiersprachen bieten Bibliotheken, um die Implementierung von exponentiellen Backoffs und ähnlichen Wiederholungsstrategien zu vereinfachen. Implementieren Sie für langfristige oder Multi-Prozess-Wiederholungsversuche eine permanente Wiederholungswarteschlange. Diese Warteschlange kann den Wiederholungsmechanismus zurücksetzen, wenn Sie die maximale Backoff-Zeit überschreiten.

Verwenden Sie beim Wiederholen dieser Anfragen den exponentiellen Backoff:

• Vorgänge, die eine FHIR-Ressource oder ein Bundle von FHIR-Ressourcen ändern.

• Synchrone LRO-Anfragen Wiederholen Sie den Vorgang, wenn beim Start des LRO ein Fehler auftritt oder der LRO fehlschlägt.

  LROs haben eindeutige Fehler, die möglicherweise die Implementierung der folgenden Strategien für Wiederholungen erfordern:

  • Verwenden Sie ein separates Bundle zum Speichern von Daten, die einen Import- oder Erstellungsvorgang fehlgeschlagen sind.
  • Verwenden Sie synchrone Anfragen für Daten, die nicht verarbeitet werden konnten.

Beispiel für einen exponentiellen Backoff-Algorithmus

Ein exponentieller Backoff-Algorithmus wiederholt Anfragen exponentiell und verlängert dabei die Wartezeit zwischen zwei Wiederholungen bis zur maximalen Backoff-Zeit. Der folgende Algorithmus implementiert den abgeschnittenen exponentiellen Backoff mit Jitter:

1. Senden Sie eine Anfrage an die Cloud Healthcare API.

2. Wenn die Anfrage fehlschlägt, wartet das System 1 + random-fraction Sekunden und wiederholt dann die Anfrage.

3. Wenn die Anfrage fehlschlägt, wartet das System 2 + random-fraction Sekunden und wiederholt dann die Anfrage.

4. Wenn die Anfrage fehlschlägt, wartet das System 4 + random-fraction Sekunden und wiederholt dann die Anfrage.

5. Fahren Sie mit diesem Muster fort und warten Sie nach jedem Wiederholungsversuch 2ⁿ + random-fraction Sekunden bis zu maximum-backoff.

6. Beenden Sie das Wiederholen der Anfrage nach deadline Sekunden.

Verwenden Sie beim Implementieren des Algorithmus die folgenden Werte:

• Vor jedem Wiederholungsversuch beträgt die Wartezeit min((2n + random-fraction), maximum-backoff), wobei n bei 0 beginnt und bei jedem Wiederholungsversuch um 1 erhöht wird.

• Ersetzen Sie random-fraction durch einen zufälligen Bruchwert, der kleiner oder gleich 1 ist. Verwenden Sie für jede Wiederholung einen anderen Wert. Durch das Hinzufügen dieses Zufallswerts wird verhindert, dass Clients synchronisiert werden und viele Wiederholungsversuche gleichzeitig senden.

• Ersetzen Sie maximum-backoff durch die maximale Zeit in Sekunden, die zwischen Wiederholungen gewartet werden soll. Übliche Werte sind 32 oder 64 Sekunden (2⁵ oder 2⁶ Sekunden). Wählen Sie den Wert aus, der für Ihren Anwendungsfall am besten geeignet ist.

• Ersetzen Sie deadline durch die maximale Anzahl von Sekunden, die Wiederholungsversuche gesendet werden sollen. Wählen Sie einen Wert aus, der Ihrem Anwendungsfall entspricht.

Der Client kann es nach Erreichen der maximum-backoff-Zeit noch einmal versuchen und dabei denselben Wert wie der Backoff verwenden. Wenn die maximum-backoff-Zeit beispielsweise 64 Sekunden beträgt, wiederholen Sie den Vorgang alle 64 Sekunden. Der Client sollte es nicht unbegrenzt versuchen.

Clientseitige Ratenbegrenzung mit Trafficmuster implementieren

Die Ratenbegrenzung schützt große Systeme, indem sie verhindert, dass sie durch übermäßige Anfragen überlastet werden. Wenn die clientseitige Ratenbegrenzung nicht ausreicht, kann das Kontingentsystem der Cloud Healthcare API den Datendurchsatz einschränken. Weitere Informationen finden Sie unter Best Practices für die Kontingentverwaltung.

Wenn Sie zusätzliche Anforderungen haben, z. B. garantierte Zustellung über mehrere Wiederholungen hinweg, sind die Strategien unter Fehlgeschlagene Anfragen wiederholen möglicherweise nicht ausreichend. Trafficmuster ist eine Methode zur Ratenbegrenzung, mit der die Rate clientseitiger Anfragen innerhalb der Bandbreitenbeschränkungen gehalten wird. Dadurch werden Lastspitzen über Stunden oder Minuten verteilt, was den Durchsatz verbessert. Bei beschränkten Kontingenten kann mit der Anpassung des Traffics ein höherer Durchsatz als mit Wiederholungsversuchen allein erzielt werden, da so Ablehnungen vermieden werden und Worker-Einheiten erfasst werden.

Sie können die Trafficmuster für synchrone CRUD-Vorgänge (Erstellen, Löschen, Aktualisieren und Löschen), einschließlich fhir.executeBundle, implementieren.

Anforderungen an Trafficmuster

Damit die Trafficmuster implementiert werden können, muss in Ihrem System Folgendes implementiert sein:

• Eine speichergestützte Verarbeitungswarteschlange mit Redundanz zur Vermeidung von Laufwerkausfällen.
• Koordinierte Worker, die Daten aus der Verarbeitungswarteschlange abrufen
• Erkennung der allgemeinen Nutzung, um die Anzahl der Worker und deren Verarbeitungsgeschwindigkeit anhand von Kontingentlimits anzupassen.
• Notfallwiederherstellung der speichergestützten Verarbeitungswarteschlange. Im Notfall muss Ihr System die Warteschlange dauerhaft löschen oder wiederherstellen können.
• Weniger lange Wartezeiten während der Spitzenzeiten. Weitere Informationen finden Sie unter Kontingente effizient planen und nutzen und LROs in die Warteschlange stellen und verwalten.

In den folgenden Fällen ist die Trafficmuster möglicherweise nur für eine einzelne Pipelinephase erforderlich:

• Begrenzen der Anzahl von Workern, die Daten aus einem vorherigen Pipelineschritt abrufen.
• Individuelle Begrenzung der einzelnen Worker.
• Mit einem Worker-Pool-Koordinator die Geschwindigkeit anpassen, mit der einzelne Arbeitseinheiten wie Abfragen pro Sekunde oder aufgenommene Byte pro Sekunde verarbeitet werden.

Ratenbegrenzung in anderen Bereichen des Systems implementieren

Sie können vorhandene Programmiersprachen und Frameworks verwenden, um Trafficmuster zu implementieren. Betrachten Sie die folgenden Open-Source-Projekte und vordefinierte Lösungen:

• Clientseitige Drosselung in Apache Beam Weitere Informationen zum Steuern der Drosselung mit den Flags numWorkers und maxNumWorkers finden Sie unter Horizontales Autoscaling.

• Die Java-Klasse RateLimiter aus der Google Guava-Gruppe der Java-Kernbibliotheken.

• Das Python-Modul ratelimiter.

Verwenden Sie für die Ablaufsteuerung die allgemeine Pub/Sub-Clientbibliothek.

Asynchrone und synchrone Verarbeitung auswählen

Eine clientseitige Proxyebene, die Anfragen an die Cloud Healthcare API umschließt, die unter Fehler auf mehreren Ebenen verarbeiten gezeigt wird, kann auch die Drosselung für alle Dienste steuern, die die Cloud Healthcare API verwenden. Verwenden Sie je nach Art der erforderlichen Trafficmuster eine der folgenden Optionen:

Asynchron

Mit der asynchronen Verarbeitung können Sie Anfragen in die Warteschlange stellen und Worker steuern. Eine Proxy-Ebene schreibt eingehende Anfragen in die Warteschlange und gibt 200 OK-Antworten zurück, nachdem jede Anfrage in die Warteschlange gestellt wurde. Dies funktioniert am besten für Schreibanfragen, kann aber für Leseanfragen in einem LRO-Framework verwendet werden, wenn Clients Leseergebnisse erhalten können.

Synchron

Die synchrone Verarbeitung bietet einen einfachen Feedbackmechanismus, wenn eine Arbeitseinheit vom Abschluss einer vorherigen Einheit abhängt. Eine Proxyebene verzögert ausgehende Anfragen basierend auf den Abfragen pro Sekunde oder Bytedurchsatzgrenzwerten und der Client blockiert und wartet auf die Antwort der Proxyebene.

Die Proxy-Ebene kann die Ratenbegrenzung basierend auf der Anzahl der Instanzen anpassen oder mit einem Controller-Prozess koordinieren, der die Ratenbegrenzung alle paar Sekunden anpasst. Damit die Proxy-Ebene die Anzahl der Instanzen und deren Ratenbegrenzungen verfolgen kann, kann jede Proxy-Instanz regelmäßig eine Datei lesen oder einen Remote-Prozeduraufruf (Remote Procedure Call, RPC) mit codierten Ratenbegrenzungen ausführen.

Die synchrone Verarbeitung hat manchmal folgende Nachteile:

• Ressourcen auf der Client- und Proxy-Ebene sind nicht verfügbar, solange der Client blockiert und auf eine Antwort wartet. Dies kann zu Fehlern, Zeitüberschreitungen und einem geringeren Datendurchsatz führen, was die Skalierung erschwert.

• Wenn die Verbindung zwischen Client und Proxy-Ebene getrennt wird, ist mehr Arbeit erforderlich, um sicherzustellen, dass die Daten wie gewünscht geändert wurden.

Cloud Tasks verwenden

Verwenden Sie Cloud Tasks, um Anfragen in eine Warteschlange zu verlagern. Cloud Tasks legt automatisch die folgenden Google Cloud-Kontingente fest und überwacht sie:

• Maximale Burst-Größe und maximale Nebenläufigkeit von Anfragen mit dem RateLimits-Objekt
• Wiederholungslimits mit dem Objekt RetryConfig

Informationen zum Erstellen von Warteschlangen in Cloud Tasks finden Sie unter Warteschlangen erstellen. Die Ressource Queue zeigt die Optionen an, die Sie für eine Warteschlange festlegen können. Mit dem Objekt RetryConfig können Sie beispielsweise einen exponentiellen Backoff implementieren. Sprachspezifische Bibliotheken finden Sie unter Cloud Tasks-Clientbibliotheken.

Berücksichtigen Sie bei der Verwendung von Cloud Tasks Folgendes:

• Es kann nicht garantiert werden, dass Cloud Tasks genau einmal zugestellt wird. Genau nach der Übermittlung werden Anfragen mit doppelten Daten als Duplikate erkannt und vom Server ignoriert. Weitere Informationen finden Sie unter Nach Lambda: genau einmalige Verarbeitung in Dataflow, Teil 1.
• Die maximale Taskgröße ist möglicherweise viel kleiner als die maximale Größe des FHIR-Bundles in der Cloud Healthcare API. Weitere Informationen finden Sie unter Kontingente und Limits für Cloud Tasks und Kontingente und Limits für die Cloud Healthcare API.
• Bei Cloud Tasks gibt es Probleme und Einschränkungen.

FHIR-Bundles mit Ratenbegrenzungen kombinieren

Die Wiederholung von FHIR-Bundles mit exponentiellem Backoff und Ratenbegrenzungen hilft dabei, einen hohen Datendurchsatz aufrechtzuerhalten und Lastspitzen zu bewältigen.

Ein Client kann FHIR-Batch- und -Transaktions-Bundles an Cloud Tasks senden, das die Anfragen im Bundle an die Cloud Healthcare API sendet. Wenn die Ratenbegrenzung vollständig oder über dem Kontingent ist, weil die maximale Warteschlangengröße erreicht wurde und der Speicherplatz ausgeht, kann der Client einen exponentiellen Backoff implementieren, um die Bundles in die Warteschlange zu stellen.

Verhindern Sie, dass die Ratenbegrenzungswarteschlange voll wird, indem Sie diese Ressourcen überwachen:

• FHIR-Vorgangskontingente in der Cloud Healthcare API
• Ratenbegrenzungskontingente
• Ratenbegrenzungsfehler

Wenn die Ratenbegrenzungswarteschlange voll wird, muss Ihr System einen Mitarbeiter benachrichtigen und den Client daran hindern, Anfragen zu senden.

Persistente HTTP-Verbindungen (wiederverwendbare Keep-Alive-Verbindungen) verwenden

Standardmäßig öffnet die Cloud Healthcare API für jede CRUD-Anfrage eine neue TCP-Verbindung. Dies erfordert einen TCP-Handshake, der zu Mehraufwand und Leistungseinbußen führen kann. Verwenden Sie zur Verbesserung der Leistung HTTP-Keep-Alive, um die TCP-Verbindung für mehrere Anfragen offen zu halten.

Wenn Sie HTTP-Keep-Alive in HTTP/1.1 verwenden möchten, setzen Sie den Connection-Header auf keep-alive:

Connection: keep-alive

HTTP/2 verwendet eine TCP-Verbindung für sequenzielle und gleichzeitige Anfragen, wodurch der Aufwand automatisch vermieden wird.

Die Python-Bibliothek requests verwendet standardmäßig HTTP-Keep-Alive. Wenn Sie Node.js verwenden, legen Sie keepAlive auf true fest, wenn Sie ein http.Agent-Objekt erstellen, und übergeben Sie das Objekt dann in Ihrer Anfrage.

Test-Framework verwenden

Ein Test-Framework stellt sicher, dass Ihr Code funktioniert, und hilft Ihnen bei Folgendem:

• Auf plötzliche Trafficspitzen in einer Anwendung oder Pipeline vorbereiten.
• Testen Sie, ob der exponentielle Backoff und die clientseitige Ratenbegrenzung die Leistung verbessern. Tests können zeigen, ob diese Implementierungen einen Rückstand von Aufgaben verursachen, die separat verarbeitet werden müssen.
• Trennen Sie Traffic mit hoher Priorität und steuern Sie ihn. Wenn ein Nutzer beispielsweise auf eine Antwort wartet, kann die Arbeitslast für die Verarbeitung im Hintergrund reduziert werden, damit die Nutzerfreundlichkeit nicht beeinträchtigt wird.
• Testen Sie synchrone und asynchrone Warteschlangenstrategien zur Steuerung des Trafficflusses oder testen Sie, ob die Proxy-Ebene Pushbacks verarbeitet.
• Planen Sie eine Notfallwiederherstellung. Dazu müssen Sie in der Regel eingehenden Traffic zurücksetzen oder Warteschlangen verwenden, um ihn nach dem Notfall fortzusetzen.

Cloud Monitoring verwenden

Verwenden Sie Cloud Monitoring, um Ihre Test- und Produktionsumgebungen zu überwachen. Beachten Sie diese Empfehlungen:

• Cloud Tasks in andere Logging- und Monitoring-Dienste von Google Cloud wie Cloud-Audit-Logs einbinden
• Erstellen Sie benutzerdefinierte Messwerte mit der Cloud Monitoring API, um wichtige Messwerte wie Wiederholungsversuche, Warteschlangengrößen und Warteschlangenalter zu verfolgen.
• Service Level Objectives (SLOs) und Service Level Indicators (SLIs) für Ihre Umgebungen erstellen Empfehlungen finden Sie unter Einführung in SLIs.
• Erstellen Sie Benachrichtigungsrichtlinien mit Google Cloud-Beobachtbarkeit. Benachrichtigungsrichtlinien informieren Sie über Probleme, z. B. wenn Ihr System unter Stress steht oder menschliches Eingreifen erfordert.
• Erstellen Sie operative Playbooks, damit Systemadministratoren wissen, was zu tun ist, wenn eine Benachrichtigungsrichtlinie eine Benachrichtigung sendet.

• Verwenden Sie die operativen Playbooks in einer Staging-Umgebung, um auf die folgenden Szenarien zu reagieren:

  • Rückstände aufgrund von Ratenbegrenzung
  • Ablehnung aufgrund einer Überschreitung von Kontingentlimits
  • Spitzen beim eingehenden Traffic

429 Resource Exhausted operation_too_costly Fehler vermeiden

Tausende parallele Aktualisierungen an einer FHIR-Ressource können jeden Tag zu Sperrenkonflikten und Latenz führen und den Abschluss von Transaktionen verhindern. Transaktionen, die nicht abgeschlossen werden können, können zu einem Rückstand von 429 Resource Exhausted operation_too_costly-Fehlern führen:

HTTP/1.1 429 Too many requests
...

{
  "issue": [
    {
      "code": "too-costly",
      "details": {
        "text": "operation_too_costly"
      },
      "diagnostics": "aborted due to lock contention while executing transactional bundle. Resource type: FHIR_RESOURCE_TYPE",
      "severity": "error"
    }
  ],
  "resourceType": "OperationOutcome"
}

In der Fehlermeldung bezieht sich „Kosten“ auf die Ressourcennutzung und den Datendurchsatz, nicht auf die Abrechnungskosten.

Ein 429 Too Many Requests-Fehler weist nicht immer auf ein Kontingentproblem hin. Der Fehler kann auftreten, wenn der FHIR-Server der Cloud Healthcare API übermäßige Sperrkonflikte bei Datenbankeinträgen erkennt. Dies kann aufgrund vieler Vorgänge in einem FHIR-Bundle oder einer Kombination von CRUD-Vorgängen geschehen.

Stellen Sie sich folgendes Szenario vor:

1. Ein FHIR-Transaktions-Bundle, das eine Patientenressource und andere FHIR-Ressourcen aktualisiert, sperrt die Patientenressource, bis die Transaktion abgeschlossen ist.

2. Mehrere FHIR-Bundles versuchen, die Patientenressource parallel zu aktualisieren, und es kommt zu Sperrenkonflikten. Fehlerantworten enthalten das Feld diagnostics mit dem Text Resource type: PATIENT.

   Sie können versuchen, die Patientenressource mit exponentiellem Backoff zu aktualisieren. Lange Sperrkonflikte können jedoch zu Zeitüberschreitungen, verringertem Durchsatz und erhöhter Ressourcennutzung führen.

3. Der FHIR-Server der Cloud Healthcare API erkennt schließlich einen Rückstand von Transaktionen und Load-Sheeten, indem er operation_too_costly-Fehler zurückgibt. Dadurch wird der Traffic eingeschränkt und weitere Fehler vermieden.

   Der Fehler operation_too_costly drosselt alle FHIR-CRUD-Vorgänge in Ihrem Google Cloud-Projekt, was alle mit Ihrem Projekt verbundenen Anwendungen betrifft.

429 Too Many Requests Fehler beheben

Suchen Sie in Cloud Logging, um 429 Too Many Requests-Fehler zu beheben. Fehler, die operation_too_costly enthalten, weisen auf einen Sperrkonflikt hin. Wenn die Fehler durch eine Ressourcenerschöpfung verursacht werden, prüfen Sie, ob Kontingentprobleme vorliegen.

Wenn eine Drosselung auftritt, schlagen Transaktions-Bundles möglicherweise aufgrund von Sperrenkonflikten fehl und der folgende Fehler wird angezeigt:

HTTP/1.1 429 Too many requests
...

{
  "issue": [
    {
      "code": "too-costly",
      "details": {
        "text": "operation_too_costly"
      },
      "diagnostics": "aborted due to cumulative heavy load or lock contention in this project while executing transactional bundle, please see https://cloud.google.com/healthcare-api/docs/troubleshooting#fhir_transaction_bundle_heavy_load for more information",
      "severity": "error"
    }
  ],
  "resourceType": "OperationOutcome"
}

Rufen Sie im Feld diagnostics den Link FHIR-Transaktions-Bundle aufgrund kumulativer hoher Last abgebrochen auf, um den Fehler zu beheben.

Große Sets vermeiden

Der Fehler 429 Too Many Requests ist bei großen Transaktions-Bundles wahrscheinlicher. Sets jeder Größe können zu Durchsatzengpässen führen. Testen Sie verschiedene Sets, um die optimale Größe zu finden.

Große Bundles mit Wiederholungsversuchen können zu Leistungseinbußen führen und sind anfälliger für mehrere Fehler. Clients sollten zusätzliche Logik implementieren, um die Teilmenge der FHIR-Ressourcen zu verwalten, die bei einer Transaktion fehlgeschlagen sind.

Bei Batch-Bundles können 429 Too Many Requests- und 413 Request Entity Too Large-Fehler sowie Durchsatzengpässe auftreten, wenn sie groß sind oder eine hohe Anzahl von Abfragen pro Sekunde haben.

Vermeiden Sie große Sets mit Tausenden von Transaktionen. Gehen Sie stattdessen so vor:

• Verwenden Sie kleinere Transaktions-Bundles, die Datenkonsistenz unterstützen. Wenn FHIR-Ressourcen nicht voneinander abhängig sind, aktualisieren Sie sie separat. Beispielsweise hängt eine FHIR-Ressource möglicherweise nicht von der spezifischen Version einer anderen Ressource im selben Bundle ab.
• Verwenden Sie Batches in Bundles und vermeiden Sie einzelne Anfragen. Batches können zwar die Leistung verbessern, große Batches können jedoch zu Fehlern führen und den Datendurchsatz beeinträchtigen. Batch-Bundles ähnlicher Größe haben weniger Konflikte, da sie keine Sperren über FHIR-Ressourcenaktualisierungen haben.

Kleine Transaktions-Bundles vermeiden Konflikte, da sie nur wenige Sperren gleichzeitig enthalten und schnell beendet werden. Dadurch wird ein Rückstand von gestapelten Transaktionen vermieden.

Durchsatz bei langer Ausführungszeit (LRO)

Siehe LRO-Datendurchsatz.

FHIR-Datenspeicheroptionen

Wenn Ihr FHIR-Datenvolumen klein bis mäßig ist, verwenden Sie fhir.create zum Speichern von Daten. Zum Speichern großer Mengen von FHIR-Ressourcen verwenden Sie fhir.executeBundle oder fhirStores.import. Informationen zu den einzelnen Methoden finden Sie unter FHIR-Importoptionen.

FHIR-Ressourcen importieren

Beachten Sie bei der Entscheidung, ob Sie den FHIR-Import verwenden möchten, Folgendes:

• Der FHIR-Import beschränkt die Gesamtgröße der importierten Daten nicht. Wenn ein FHIR-Bundle 50 MB überschreitet, können Sie die FHIR-Ressourcen in Cloud Storage hochladen und importieren. Vermeiden Sie gleichzeitige Importe mit hoher Latenz oder große Importe. Andernfalls ist der Datendurchsatz möglicherweise begrenzt.

• Der FHIR-Import ist weniger komplex als die Verwendung von FHIR-Bundles. Sie müssen beispielsweise Folgendes nicht tun:

  • Große Bundles in kleinere aufteilen
  • Zeitpläne verwalten
  • Vorübergehende Fehler auf Ressourcen- oder Bundle-Ebene wiederholen

• Der FHIR-Import erzwingt keine referenzielle Integrität. Weitere Informationen finden Sie unter Referenzielle FHIR-Integrität.

• Verwenden Sie den FHIR-Import nicht, wenn die Datenaktualität eine hohe Priorität hat. Importe können schnell sein, können sich aber um Stunden oder Tage verzögern.

• FHIR-Importe funktionieren besser, wenn im Google Cloud-Projekt nur wenige LROs vorhanden sind.

• Mit dem FHIR-Import kann ein hoher Datendurchsatz erzielt werden, wenn Ihre Anwendung Bulk-Fehler und -Fehler für eine Teilmenge von Ressourcen verarbeiten kann.

FHIR-Bundles verwenden

Verwenden Sie in den folgenden Fällen FHIR-Bundles anstelle des FHIR-Imports:

• Es ist zu teuer, entweder in Bezug auf die Abrechnungskosten oder die Netzwerkbandbreite, eine Pipeline zu erstellen, um Daten in Cloud Storage zu speichern und zu importieren.

• Referenzielle Integrität muss erzwungen werden.

• Die FHIR-Profilvalidierung muss erzwungen werden.

• Sie müssen Pub/Sub-Benachrichtigungen senden, wenn FHIR-Ressourcen gespeichert sind. Der FHIR-Import unterstützt keine Pub/Sub-Benachrichtigungen.

• Die Datenaktualität hat Priorität und Daten müssen innerhalb von Sekunden oder Minuten aufgenommen werden. Allerdings kann selbst in einem gut strukturierten System der Datendurchsatz durch Folgendes eingeschränkt werden:

  • Upstream-Verzögerungen in Verarbeitungspipelines. Pipelines benötigen möglicherweise mehr Zeit für die Vorbereitung von Daten, bevor die Daten aufgenommen werden können.
  • Backoffs, Wiederholungsversuche und Proxy-Ebenen zur Anpassung an den Traffic.

Für FHIR-Bundles gelten die folgenden Einschränkungen:

• Kontingent und Abrechnung werden auf jeden Vorgang im Bundle angewendet, als ob jeder Vorgang unabhängig ausgeführt würde. Wenn ein Bundle beispielsweise 10 POST-Vorgänge, 5 GET-Vorgänge und 1 DELETE-Vorgang enthält, gelten das Kontingent und die Abrechnung für das Bundle genauso, als ob diese Vorgänge unabhängig ausgeführt würden.

• Bei großen Transaktions-Bundles ist die Wahrscheinlichkeit höher, dass es Transaktionskonflikte gibt, die zu Sperrenkonflikten führen. Weitere Informationen finden Sie unter 429 Resource Exhausted operation_too_costly-Fehler verhindern.

• Batch-Bundles können den Datendurchsatz verbessern, bieten aber keine Funktionen für Transaktionskonsistenz wie referenzielle Integrität.

• Große Batch-Bundles können den Durchsatz verringern. Weitere Informationen finden Sie unter Große Sets vermeiden.

Optionen für DICOM-Datenspeicher

Mit den folgenden Methoden können Sie einen hohen Datendurchsatz erzielen, wenn Sie Daten von einem Bildarchiv- und Kommunikationssystem (Picture Archive and Communication System, PACS) an die Cloud Healthcare API senden:

Der Open-Source-DICOM-Adapter der Cloud Healthcare API mit dem DICOM-Nachrichtendienstelement (DIMSE)-Protokoll

Der Adapter optimiert den Datendurchsatz, wenn Sie einen PACS mit der Cloud Healthcare API synchronisieren. Führen Sie vor der Synchronisierung Leistungstests durch und prüfen Sie, ob der Adapter einen Spitzendatendurchsatz aufrechterhalten kann.

Verwenden Sie diesen Adapter, wenn Sie DICOM-Dateien nicht mit dem Storage Transfer Service oder einer anderen Übertragungsoption in Cloud Storage hochladen können. Beispielsweise können Sie die folgenden Storage Transfer Service-Anforderungen möglicherweise nicht erfüllen:

• Stellen Sie auf jedem Computer, der Agents in Ihrem Agent-Pool hostet, ein Dateisystem bereit, um Quelldaten abzurufen.
• Wenn Sie Daten in regelmäßigen Abständen und nicht zu einem einmaligen Batchladevorgang übertragen, müssen Sie Änderungen an der Größe der Daten im Zeitverlauf messen, um festzustellen, was sich geändert hat.
• Übertragungsleistung des Agents maximieren
• Cloud Storage-Speicher bezahlen und zuweisen
• Datenübertragungen zu Cloud Storage prüfen
• Cloud Storage-Ressourcen entfernen, nachdem Sie Daten in die Cloud Healthcare API importiert haben, und etwaige Importfehler beheben
• Batchaufnahmeintervalle basierend auf der Netzwerk- und Speicherkapazität eines klinischen Systems planen.

Wir empfehlen, den Storage Transfer Service für einen einzelnen Batchladevorgang zu verwenden, um einen DICOM-Speicher zu füllen. Die regelmäßige Nutzung von Storage Transfer Service erfordert zusätzliche Arbeit, z. B. eine synchrone Importpipeline. Weitere Informationen finden Sie unter Übertragungsdetails des Storage Transfer Service-Dateisystems.

dicomStores.import

Verwenden Sie diese Methode, um große Mengen von DICOM-Daten zu speichern.

DICOMweb-Speichertransaktion

Verwenden Sie diese Methode, um DICOM-Daten programmatisch zu speichern.

Kontingent verwalten, um den Datendurchsatz zu optimieren

In den folgenden Abschnitten wird beschrieben, wie Sie Kontingente verwalten und planen, um den Datendurchsatz zu optimieren. Allgemeine Best Practices zur Kontingentverwaltung finden Sie unter Best Practices für die Kontingentverwaltung.

Kontingent für vorhersehbaren Traffic planen

Planen Sie Ihre Kontingentanforderungen, indem Sie zuerst den typischen täglichen Traffic Ihrer Clientanwendung analysieren. Auch wenn der Traffic vorhersehbar ist, sollten Sie ein höheres Kontingent einplanen, als Sie im Durchschnitt benötigen. Dies hilft Ihnen, Fehler zu vermeiden, und bietet einen Sicherheitsmarge gegen Traffic-Spitzen oder gelegentliche Anstiege der täglichen Nutzung.

Das folgende Diagramm zeigt Anfragen an die Cloud Healthcare API, deren Größe konsistent ist und in vorhersehbaren Mustern gesendet wurde:

Abbildung 1: Die zusammengefasste stündliche API-Last für Datasets und Datenspeicher in einem Google Cloud-Projekt.

Kontingent für Anfragen mit großem Volumen planen

Vermeiden Sie die Planung großer Batchjobs während Spitzenzeiten. Weitere Informationen finden Sie unter Transaktionen mit geringem Volumen einheitlich nutzen.

Das folgende Diagramm zeigt ein vorhersehbares Traffic-Muster. Eine Batchanfrage mit großem Volumen während eines Spitzenverkehrszeitraums überschreitet jedoch das verfügbare Kontingent. Dies kann bei allen Anfragen in Ihrem Projekt zu 429 Resource Exhausted-Fehlern führen.

Abbildung 2: Eine unregelmäßige Verteilung der Ressourcennutzung, die durch einen umfangreichen Batchjob zu Spitzenzeiten verursacht wird.

Wenn Ihr System ein zusätzliches Flexibilitätskontingent hat, führen kleine Trafficspitzen nicht zu Fehlern oder vorhersehbaren Spitzenlasten, die zu Fehlern führen. Die kleinen Spitzen müssen auf viele Datenspeicher, Anwendungen und andere Clients verteilt werden, die Last innerhalb des Google Cloud-Projekts verursachen.

Informationen dazu, wie Sie verhindern, dass ein einzelner großer Batchjob Trafficspitzen verursacht, finden Sie unter Große Bundles vermeiden.

Weitere Kontingente anfordern

Um einen hohen Datendurchsatz aufrechtzuerhalten und Fehler vom Typ 429 Resource Exhausted zu vermeiden, lesen Sie die Best Practices auf dieser Seite, insbesondere unter Kontingent zur Optimierung des Datendurchsatzes verwalten. Mit diesen Best Practices sorgen Sie dafür, dass Ihre Clientanwendung robust ist und bei Änderungen des Anfragevolumens skaliert werden kann. Wenn Sie zusätzliche Kontingente anfordern, ohne die Best Practices zu implementieren, ist es unwahrscheinlich, dass Fehler langfristig vermieden werden.

Wenn Sie die Best Practices implementiert haben und dennoch ein größeres Kontingent benötigen, lesen Sie Best Practices zum Anfordern eines zusätzlichen Kontingents.

Durchsatzressourcen für die Datenaufnahme

Weitere Informationen zum Durchsatz der Datenaufnahme finden Sie unter Traffic und Last für Ihre Arbeitslasten in Google Cloud verwalten.