Best Practices für den Datenaufnahmedurchsatz

Auf dieser Seite werden Best Practices zur Optimierung des Datendurchsatzes in folgenden Situationen beschrieben: Daten in die Cloud Healthcare API aufnehmen. Diese Empfehlungen gelten für Fachkräfte mit Erfahrung im Umgang mit Datendurchsatz für groß angelegte Systeme.

Datendurchsatz

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

Einschränkungen für den Datendurchsatz

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

• Sie haben keine Anfragen mit hohem Volumen eingeplant, die Traffic-Spitzen verursachen.
• 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 Vermeiden Sie kleine Import- und Exportanfragen.
• Zu viele Vorgänge mit langer Ausführungszeit werden gleichzeitig ausgeführt und die Bandbreite ist begrenzt.
• Zu viele LROs sind gleichzeitig geplant, was zu Fehlern führt.

Fehlgeschlagene Anfragen wiederholen

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

Exponentiellen Backoff mit Jitter und persistenten Warteschlangen für Wiederholungsversuche verwenden

Exponentieller Backoff mit dem eingeführten Jitter eine Standardstrategie zur Fehlerbehandlung bei Netzwerkanwendungen. Ein Client wiederholt regelmäßig fehlgeschlagene Anfragen 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, insbesondere wenn Sie benutzerdefinierte Logik verwenden, um Fehlerbedingungen zu umgehen. Siehe 9.2.2 Idempotente Methoden in der HTTP-Spezifikation finden Sie weitere Informationen.

Die meisten Programmiersprachen bieten Bibliotheken, die die Implementierung von exponentiellem Backoff und ähnlichen Wiederholungsstrategien vereinfachen. Für langfristige oder mehrstufige Wiederholungen implementieren Sie eine persistente Warteschlange für Wiederholungen. Diese Warteschlange kann den Wiederholungsmechanismus zurücksetzen, wenn die maximale Backoff-Zeit überschritten wird.

Verwenden Sie exponentiellen Backoff, wenn Sie diese Anfragen wiederholen:

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

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

  LROs weisen besondere Fehler auf, für die Sie möglicherweise Folgendes implementieren müssen: Wiederholungsstrategien:

  • Verwenden Sie ein separates Bundle, um Daten zu speichern, bei denen ein Import- oder Erstellungsvorgang fehlgeschlagen ist.
  • Verwenden Sie für Daten, die nicht verarbeitet werden konnten, synchronische Anfragen.

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 einen 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. Setzen Sie dieses Muster fort und warten Sie nach jedem Versuch 2ⁿ + random-fraction Sekunden bis zu einer Zeit von maximum-backoff.

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

Verwenden Sie beim Implementieren des Algorithmus die folgenden Werte:

• Vor jedem erneuten Versuch 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 zufälligen Werts wird verhindert, dass Clients synchronisiert werden und viele Wiederholungsversuche gleichzeitig gesendet werden.

• Ersetzen Sie maximum-backoff durch die maximale Wartezeit in Sekunden. zwischen den Wiederholungsversuchen. Übliche Werte sind 32 oder 64 Sekunden (2⁵ oder 2⁶ Sekunden). Auswählen den Wert ermitteln, 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 Ihren Anwendungsfall widerspiegelt.

Der Client kann es noch einmal versuchen, nachdem die maximum-backoff-Zeit mit demselben als Backoff festlegen. Wenn die maximum-backoff-Zeit beispielsweise 64 Sekunden beträgt, wird alle 64 Sekunden ein neuer Versuch unternommen. Achten Sie darauf, dass der Client es nicht auf unbestimmte Zeit wiederholt.

Clientseitige Ratenbegrenzung mit Traffic Shaping implementieren

Durch die Ratenbegrenzung werden große Systeme geschützt, damit sie nicht durch zu viele Anfragen überlastet werden. Wenn die clientseitige Ratenbegrenzung nicht ausreichend ist, 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 bei mehreren Wiederholungsversuchen, Die Strategien unter Fehlgeschlagene Anfragen wiederholen sind möglicherweise unzureichend. Traffic Shaping ist eine Ratenbegrenzungstechnik, die die Rate der clientseitigen Anfragen innerhalb der Bandbreitenbeschränkungen hält. Dadurch werden Lastspitzen über Stunden oder Minuten verteilt, was den Durchsatz verbessert. Wenn das Kontingent begrenzt ist, kann durch die Verkehrssteuerung ein höherer Durchsatz erzielt werden als durch reine Wiederholungen, da Pushbacks vermieden und Worker-Einheiten erfasst werden.

Sie können die Verkehrssteuerung für synchrone CRUD-Vorgänge (Create, Read, Update, Delete) implementieren, einschließlich fhir.executeBundle.

Anforderungen an die Anpassung an Traffic

Für die Anpassung an den Traffic muss Ihr System Folgendes implementieren:

• Eine speichergestützte Verarbeitungswarteschlange mit Redundanz, um Festplattenausfälle zu vermeiden.
• Koordinierte Worker, die aus der Verarbeitungswarteschlange abgerufen werden sollen.
• Allgemeine Verwendung der Erkennung, um die Anzahl der Worker und ihre Verarbeitungsgeschwindigkeit anzupassen basierend auf den Kontingentlimits.
• Notfallwiederherstellung für die speichergestützte Verarbeitungswarteschlange. Bei einem Notfall muss Ihr System die Warteschlange leeren oder wiederherstellen können.
• Verringerte LROs während der Spitzenzeiten. Weitere Informationen finden Sie unter Kontingente effizient planen und verwenden. und LROs in die Warteschlange stellen und verwalten.

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

• Begrenzung der Anzahl der Worker, die Daten aus einem vorherigen Pipelineschritt abrufen.
• Begrenzung einzelner Worker
• Mit einem Worker-Pool-Koordinator können Sie die Rate anpassen, einzelne Arbeitseinheiten wie Abfragen pro Sekunde (Queries per Second, QPS) aufgenommene Byte pro Sekunde verarbeitet.

Implementieren Sie die Ratenbegrenzung in anderen Bereichen Ihres Systems.

Sie können vorhandene Programmiersprachen und Frameworks verwenden, um Traffic zu implementieren. Forming. Die folgenden Open-Source-Projekte und vorgefertigten Lösungen sind eine gute Wahl:

• Clientseitige Drosselung in Apache Beam Unter Horizontales Autoscaling finden Sie Informationen dazu, wie Sie die Drosselung mit den Flags numWorkers und maxNumWorkers steuern.

• Die Java-Klasse RateLimiter aus den Java-Kernbibliotheken von Google Guava.

• Das Python-Modul ratelimiter

Verwende für die Ablaufsteuerung die Pub/Sub-Clientbibliothek.

Zwischen asynchroner und synchroner Verarbeitung wählen

Mit einer clientseitigen Proxyebene, die Anfragen an die Cloud Healthcare API umschließt (siehe Fehler in mehreren Schichten behandeln), lässt sich auch die Drosselung für Dienste steuern, die die Cloud Healthcare API verwenden. Je nach der erforderlichen Art der Trafficmusterung, verwenden Sie eine der folgenden Optionen:

Asynchron

Verwenden Sie die asynchrone Verarbeitung, um Anfragen in eine Warteschlange zu stellen und Worker zu 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 auch für Leseanfragen in einem LRO-Framework, wenn Clients Leseergebnisse empfangen können.

Synchron

Die synchrone Verarbeitung bietet einen einfachen Feedbackmechanismus, wenn eine Arbeitseinheit vom Abschluss einer vorherigen Einheit abhängt. Eine Proxy-Ebene verzögert ausgehende Anfragen über Limits für Abfragen pro Sekunde oder Bytedurchsatz und der Client blockiert und wartet auf den Proxy. in die Antwort der Ebene ein.

Die Proxy-Ebene kann die Ratenbegrenzung basierend auf der Anzahl der Instanzen anpassen oder sich mit einem Controllerprozess abstimmen, der die Ratenbegrenzung alle paar Sekunden anpasst. Für die Proxy-Layer, um die Anzahl der Instanzen und deren Rate zu verfolgen. kann jede Proxy-Instanz regelmäßig eine Datei lesen oder eine Remote-Instanz Prozeduraufruf (RPC) mit codierten Ratenbegrenzungen.

Die synchrone Verarbeitung hat mitunter folgende Nachteile:

• Ressourcen in der Client- und Proxy-Ebene sind nicht verfügbar, während der Client blockiert und auf eine Antwort wartet. Dies kann zu Fehlern, Zeitüberschreitungen und weniger Daten führen und 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

Mit Cloud Tasks Aufgaben lagern an eine Warteschlange stellen. In Cloud Tasks werden die folgenden Google Cloud-Kontingente automatisch festgelegt und überwacht:

• Maximale Burst-Größe und maximale Nebenläufigkeit von Anfragen mit dem Objekt RateLimits
• Limits für Wiederholungen mit dem Objekt RetryConfig

Informationen zum Erstellen von Warteschlangen in Cloud Tasks finden Sie unter Warteschlangen erstellen. Die Queue Ressource die Optionen anzeigt, die Sie für eine Warteschlange festlegen können. Sie können beispielsweise das RetryConfig-Objekt verwenden, um einen exponentiellen Backoff zu implementieren. Cloud Tasks-Clientbibliotheken für sprachspezifische Bibliotheken.

Beachten Sie bei der Verwendung von Cloud Tasks Folgendes:

• Cloud Tasks garantiert keine genau einmalige Zustellung. In genau einmal werden Anfragen mit doppelten Daten als Duplikate erkannt. und vom Server ignoriert werden. Weitere Informationen finden Sie unter Nach Lambda: genau einmalige Verarbeitung in Dataflow, Teil 1
• Die maximale Aufgabengröße kann viel kleiner als die maximale FHIR-Bundle-Größe in der Cloud Healthcare API sein. Weitere Informationen finden Sie unter Kontingente und Limits für Cloud Tasks und Kontingente und Limits der Cloud Healthcare API.
• Cloud Tasks hat Probleme und Einschränkungen.

FHIR-Bundles mit Ratenbegrenzungen kombinieren

Wenn Sie FHIR-Bundles mit exponentiellem Backoff und Ratenbegrenzern noch einmal versuchen, können Sie den Datendurchsatz aufrechterhalten und Lastspitzen bewältigen.

Ein Client kann Batch- und Transaktions-FHIR-Bundles an Cloud Tasks senden, der die Anfragen im Bundle an die Cloud Healthcare API sendet. Wenn der Ratenbegrenzer voll ist oder das Kontingent überschritten wird, weil die maximale Warteschlangengröße erreicht wurde und kein Speicherplatz mehr verfügbar ist, kann der Client ein exponentielles 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
• Kontingente für Ratenbegrenzungen
• Ratenbegrenzungsfehler

Wenn die Warteschlange der Ratenbegrenzungen voll ist, muss Ihr System einen Mitarbeiter und den Client daran zu 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. Hierfür ist ein TCP-Handshake was zu Overhead und Leistungseinbußen führen kann. Verwenden Sie zur Leistungssteigerung 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 Overhead automatisch vermieden wird.

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

Test-Framework verwenden

Ein Test-Framework sorgt dafür, dass Ihr Code funktioniert, und hilft Ihnen bei Folgendem:

• Bereiten Sie sich auf plötzliche Trafficspitzen in einer Anwendung oder Pipeline vor.
• Testen Sie, ob der exponentielle Backoff und die clientseitige Ratenbegrenzung aktiviert sind. die Leistung zu verbessern. Tests können zeigen, ob diese Implementierungen einen Backlog von Aufgaben verursachen, die separat bearbeitet werden müssen.
• Traffic mit hoher Priorität trennen und steuern. Wenn ein Nutzer beispielsweise für eine Antwort wird der Arbeitsaufwand für Hintergrundverarbeitungsaufgaben reduziert, damit die Nutzererfahrung nicht beeinträchtigt wird.
• Testen Sie synchrone und asynchrone Strategien für die Warteschlangenverwaltung, um den Trafficfluss zu regulieren, oder testen Sie, ob die Proxy-Ebene Pushbacks verarbeitet.
• Planen Sie die Notfallwiederherstellung. Dazu müssen in der Regel eingehende Zugriffe zurückgesetzt oder Warteschlangen verwendet werden, um den Traffic nach dem Notfall fortzusetzen.

Cloud Monitoring verwenden

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

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

• Verwenden Sie die Playbooks für die Betriebsabläufe in einer Staging-Umgebung, um auf die folgenden Szenarien zu reagieren:

  • Backlogs aufgrund von Ratenbegrenzungen
  • Ablehnung aufgrund einer Überschreitung des Kontingentlimits
  • Eingehende Traffic-Spitzen

429 Resource Exhausted operation_too_costly-Fehler vermeiden

Wenn täglich Tausende parallele Aktualisierungen an einer FHIR-Ressource durchgeführt werden, kann dies zu Sperrenkonflikte, Latenz und verhindert, Transaktionen nach dem Abschluss. Transaktionen, die nicht abgeschlossen werden können, können zu einem Rückstand führen von 429 Resource Exhausted operation_too_costly Fehlern:

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"
}

Im Fehler bezieht sich „Kosten“ auf die Ressourcennutzung und den Datendurchsatz, nicht auf die Abrechnungskosten.

Der Fehler 429 Too Many Requests weist nicht immer auf ein Kontingentproblem hin. Die Fehler kann auftreten, wenn der FHIR-Server der Cloud Healthcare API zu viele Sperren erkennt Konflikten mit Datenbankeinträgen. Dies kann auf viele Vorgänge in einem FHIR-Bundle oder eine Kombination von CRUD-Vorgängen zurückzuführen sein.

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 Sperrungskonflikten. Fehlerantworten enthalten ein diagnostics-Feld mit dem Text Resource type: PATIENT.

   Sie können die Aktualisierung der Patientenressource mit exponentiellem Backoff wiederholen. Lange Sperrkonfliktzeiträume können jedoch zu Zeitüberschreitungen, reduziertem Durchsatz und erhöhter Ressourcennutzung führen.

3. Der FHIR-Server der Cloud Healthcare API erkennt schließlich einen Transaktionsrückstand. und Ladeschuppen durch Rückgabe von operation_too_costly Fehler. Dadurch wird der Traffic eingeschränkt und weitere Fehler verhindert.

   Der Fehler operation_too_costly drosselt alle FHIR-CRUD-Vorgänge in Ihrem Google Cloud-Projekt, das alle Anwendungen betrifft die mit Ihrem Projekt verbunden sind.

429 Too Many Requests-Fehler beheben

Suchen Sie in Cloud Logging nach 429 Too Many Requests-Fehlern, um sie zu beheben. Fehler mit operation_too_costly weisen auf eine Blockierung hin. Wenn die Fehler durch eine Ressourcenausschöpfung verursacht werden, prüfen Sie, ob Kontingentprobleme vorliegen.

Bei einer Drosselung können Transaktionsbundles aufgrund hoher Sperrkonflikte fehlschlagen und den folgenden Fehler verursachen:

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"
}

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

Große Sets vermeiden

Der 429 Too Many Requests-Fehler ist bei großen Transaktionen wahrscheinlicher Sets. Bei Gruppierungen beliebiger Größe können Durchsatzengpässe auftreten. Anderes testen um die optimale Größe zu ermitteln.

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

Bei großen Batch-Bundles oder bei einer hohen Anzahl von Abfragen pro Sekunde können 429 Too Many Requests- und 413 Request Entity Too Large-Fehler sowie Durchsatzengpässe auftreten.

Vermeiden Sie die Verwendung großer Bundles mit Tausenden von Transaktionen. Gehen Sie stattdessen so vor:

• Verwenden Sie kleinere Transaktionspakete, die für Datenkonsistenz sorgen. Wenn FHIR-Ressourcen nicht voneinander abhängig sind, aktualisieren Sie sie separat. Beispiel: Eine FHIR-Ressource ist möglicherweise nicht von der spezifischen Version einer anderen Ressource abhängig. im selben Bundle.
• Verwenden Sie Batch-Anfragen in Bundles und vermeiden Sie einzelne Anfragen. Durch Batching kann die Leistung verbessert werden. Große Batches können jedoch zu Fehlern führen und den Datendurchsatz beeinträchtigen. Bei Batch-Bundles mit ähnlicher Größe kommt es seltener zu Konflikten, da sie keine Sperren für FHIR-Ressourcenupdates halten.

Kleine Transaktions-Bundles vermeiden Konflikte, da sie nur wenige Sperren enthalten und schnell fertig werden. So wird ein Rückstau von gestapelten Transaktionen vermieden.

LRO-Durchsatz

Weitere Informationen finden Sie unter LRO-Datendurchsatz.

Optionen für den FHIR-Datenspeicher

Wenn Ihr FHIR-Datenvolumen klein bis mittel ist, verwenden Sie fhir.create um Daten zu speichern. Verwenden Sie fhir.executeBundle oder fhirStores.import, um große Mengen von FHIR-Ressourcen zu speichern. Informationen zu den einzelnen Methoden Siehe FHIR-Importoptionen.

FHIR-Ressourcen importieren

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

• Beim FHIR-Import wird die Gesamtgröße der importierten Daten nicht begrenzt. 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ßen Datenmengen, da der Datendurchsatz sonst möglicherweise eingeschränkt wird.

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

  • Große Sets in kleinere aufteilen
  • Zeitpläne verwalten
  • Vorübergehende Fehler auf Ressourcen- oder Bundle-Ebene noch einmal versuchen

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

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

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

• Der FHIR-Import kann einen hohen Datendurchsatz erreichen, wenn Ihre Anwendung Bulk-Fehler und -Fehler bei einer Teilmenge von Ressourcen.

FHIR-Bundles verwenden

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

• Es ist zu teuer, entweder die Kosten für die Abrechnung oder die Netzwerkbandbreite, um eine Pipeline zu erstellen, um Daten in Cloud Storage zu speichern und zu importieren.

• Die referenzielle Integrität muss erzwungen werden.

• Die Validierung des FHIR-Profils muss erzwungen werden.

• Sie müssen Pub/Sub-Benachrichtigungen senden, wenn FHIR-Ressourcen gespeichert werden. FHIR-Import wird nicht unterstützt Pub/Sub-Benachrichtigungen

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

  • Vorgelagerte Verzögerungen bei der Verarbeitung von Pipelines. Für die Datenvorbereitung in Pipelines ist möglicherweise mehr Zeit erforderlich, bevor die Daten aufgenommen werden können.
  • Backoffs, Wiederholungen und Traffic-Shaping-Proxy-Ebenen

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

• Kontingent und Abrechnung werden auf alle Vorgänge im Bundle angewendet, unabhängig voneinander ausgeführt wurde. Beispiel: wenn ein Bundle 10 POST-Vorgänge, 5 GET-Vorgänge und 1 DELETE-Vorgang enthält, Das Kontingent und die Abrechnung, die auf das Bundle angewendet werden, sind dieselben, als wenn diese Vorgänge unabhängig voneinander durchgeführt wurden.

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

• Mit Batch-Bundles lässt sich der Datendurchsatz verbessern, sie bieten jedoch keine Funktionen zur Transaktionskonsistenz wie die referenzielle Integrität.

• Bei großen Batch-Bundles kann der Durchsatz reduziert sein. Weitere Informationen finden Sie unter Große Bundles vermeiden.

Optionen für den DICOM-Datenspeicher

Mit den folgenden Methoden können Sie beim Senden von Daten einen hohen Datendurchsatz erzielen Bildarchivierungs- und Kommunikationssystem (PACS) Cloud Healthcare API:

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

Der Adapter optimiert den Datendurchsatz, wenn Sie ein PACS mit der Cloud Healthcare API synchronisieren. Führen Sie vor der Synchronisierung Leistungstests durch und prüfen Sie, ob der Adapter den 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. Möglicherweise können Sie beispielsweise die folgenden Anforderungen für den Storage Transfer Service nicht erfüllen:

• Sie müssen ein Dateisystem auf jedem Computer bereitstellen, auf dem Agents in Ihrem Agent-Pool gehostet werden, um Quelldaten abzurufen.
• Wenn Sie Daten in regelmäßigen Abständen statt einmalig im Batch laden, müssen Sie Änderungen der Datengröße im Zeitverlauf zu messen und zu bestimmen.
• Leistung der Kundenservicemitarbeiter bei der Weiterleitung maximieren
• Cloud Storage-Speicher bezahlen und zuweisen.
• Validierung von Datenübertragungen zu Cloud Storage
• Entfernen Sie Cloud Storage-Ressourcen, nachdem Sie Daten in die Cloud Healthcare API importiert und alle Importfehler behoben haben.
• Batchaufnahmeintervalle basierend auf dem Netzwerk und der Speicherkapazität eines klinischen Systems planen.

Wir empfehlen, Storage Transfer Service für einen einzelnen Batch-Ladevorgang zu verwenden, einen DICOM-Speicher. Regelmäßige Nutzung des Storage Transfer Service erfordert zusätzlichen Aufwand, z. B. eine synchrone Importpipeline. Weitere Informationen finden Sie unter Details zur Dateisystemübertragung mit Storage Transfer Service.

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 zur Optimierung des Datendurchsatzes verwalten

In den folgenden Abschnitten wird beschrieben, wie Sie Kontingente zur Optimierung von Daten verwalten und planen können. Durchsatz. Allgemeine Best Practices für die 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 größeres Kontingent planen, als Sie durchschnittlich benötigen. Dies hilft Ihnen, Fehler zu vermeiden und bietet eine Sicherheitsspanne gegen Traffic-Spitzen oder eine gelegentliche Steigerung der täglichen Nutzung.

Das folgende Diagramm zeigt Anfragen an die Cloud Healthcare API, die einheitlich groß sind und in vorhersehbaren Mustern gesendet werden:

Abbildung 1: Die stündliche API-Nutzung in Datasets und Datenspeichern in einem Google Cloud-Projekt.

Tarifkontingent für Anfragen mit hohem Volumen

Planen Sie keine großen Batchjobs während Spitzenzeiten. Weitere Informationen finden Sie unter Transaktionen mit geringem Volumen bevorzugt verwenden.

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

Abbildung 2: Eine unregelmäßige Verteilung der Ressourcennutzung, die durch einen großen Batchjob während der Stoßzeiten verursacht wird.

Wenn Ihr System über ein zusätzliches Flexibilitätskontingent verfügt, werden kleine Traffic-Spitzen nicht Fehler verursachen oder vorhersehbare Spitzenlasten verursachen, auf Fehler stoßen. Die kleinen Spitzen müssen auf viele Datenspeicher, Anwendungen und andere Clients verteilt werden, die eine Auslastung im Google Cloud-Projekt verursachen.

Wie Sie verhindern, dass ein einzelner großer Batchjob zu Trafficspitzen führt, erfahren Sie unter Große Bundles vermeiden.

Weitere Kontingente anfordern

Um einen hohen Datendurchsatz aufrechtzuerhalten und 429 Resource Exhausted-Fehler zu vermeiden, finden Sie in den Best Practices auf dieser Seite, insbesondere unter Kontingent verwalten, um den Datendurchsatz zu optimieren. Diese Best Practices sorgen dafür, dass Ihre Clientanwendung robust und skalierbar ist bei Änderungen des Anfragevolumens. Wenn Sie ein zusätzliches Kontingent anfordern, ohne die Best Practices zu implementieren, ist es unwahrscheinlich, dass Sie langfristig Fehler vermeiden können.

Wenn Sie die Best Practices implementieren und trotzdem ein größeres Kontingent benötigen, lesen Sie den Hilfeartikel Best Practices für das Anfordern zusätzlicher Kontingente.

Ressourcen für den Datenaufnahmedurchsatz

Weitere Informationen zum Datenaufnahmedurchsatz finden Sie unter Traffic und Auslastung für Ihre Arbeitslasten in Google Cloud verwalten.