Best Practices für den Datenaufnahmedurchsatz

Auf dieser Seite werden Best Practices zum Optimieren des Datendurchsatzes beim Eingeben von Daten in die Cloud Healthcare API beschrieben. Diese Empfehlungen richten sich an technische Fachkräfte mit Erfahrung in der Verwaltung des Datendurchsatzes für groß angelegte Systeme.

Datendurchsatz

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

Einschränkungen beim Datendurchsatz

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

• Sie haben nicht mit einem hohen Anfragevolumen gerechnet, das zu Trafficspitzen führt.
• Bandbreitenbeschrä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.
• 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

Der exponentielle Backoff mit eingeführtem Jitter ist eine Standardstrategie zur Fehlerbehebung für 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. Weitere Informationen finden Sie in der HTTP-Spezifikation unter 9.2.2 Idempotente Methoden.

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 den exponentiellen Backoff, wenn Sie folgende Anfragen wiederholen:

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

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

  LROs haben spezifische Fehler, die möglicherweise die Implementierung der folgenden Wiederholungsstrategien erfordern:

  • Verwenden Sie ein separates Bundle, um Daten zu speichern, bei denen ein Import- oder Erstellungsvorgang fehlgeschlagen ist.
  • 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 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 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 zufälligen Werts wird verhindert, dass Clients synchronisiert werden und viele Wiederholungsversuche gleichzeitig gesendet werden.

• 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 sich für Ihren Anwendungsfall am besten eignet.

• 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 den Vorgang wiederholen, nachdem er die maximum-backoff-Zeit erreicht hat, und dabei denselben Wert wie für das Backoff verwenden. Wenn die maximum-backoff-Zeit beispielsweise 64 Sekunden beträgt, wird alle 64 Sekunden ein neuer Versuch unternommen. Der Client darf nicht unbegrenzt wiederholen.

Clientseitige Ratenbegrenzung mit Traffic Shaping implementieren

Durch die Beschränkung der Rate werden große Systeme geschützt, damit sie nicht durch zu viele Anfragen überlastet werden. Wenn die clientseitige Ratenbegrenzung nicht ausreicht, kann das Cloud Healthcare API-Kontingentsystem den Datendurchsatz einschränken. Weitere Informationen finden Sie unter Best Practices für die Kontingentverwaltung.

Wenn Sie zusätzliche Anforderungen haben, z. B. eine garantierte Zustellung bei Wiederholungen, reichen die Strategien unter Fehlgeschlagene Anfragen noch einmal senden möglicherweise nicht aus. Traffic Shaping ist eine Ratenbegrenzungstechnik, mit der die Rate der clientseitigen Anfragen innerhalb der Bandbreitenbeschränkungen bleibt. 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 Implementierung der Traffic-Shaping-Funktion müssen folgende Anforderungen erfüllt sein:

• Eine speichergestützte Verarbeitungswarteschlange mit Redundanz, um Festplattenausfälle zu vermeiden.
• Koordinierte Worker, die Aufgaben aus der Verarbeitungswarteschlange abrufen.
• Die Gesamtnutzung wird erkannt, um die Anzahl der Worker und ihre Verarbeitungsgeschwindigkeit basierend auf Kontingentlimits anzupassen.
• 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 die Rate anpassen, mit der einzelne Arbeitseinheiten wie Abfragen pro Sekunde (QPS) oder aufgenommene Bytes pro Sekunde verarbeitet werden.

Implementieren Sie die Ratenbegrenzung in anderen Bereichen Ihres Systems.

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

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

• Die Java-Klasse RateLimiter aus den zentralen Java-Bibliotheken 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. Verwenden Sie je nach Art der erforderlichen Verkehrslenkung 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 verwendet werden, wenn Clients Leseergebnisse erhalten können.

Synchron

Die synchrone Verarbeitung bietet einen einfachen Feedbackmechanismus, wenn eine Arbeitseinheit von der Fertigstellung einer vorherigen Einheit abhängt. Eine Proxy-Ebene verzögert ausgehende Anfragen basierend auf QPS- oder Byte-Durchsatzlimits. Der Client blockiert und wartet auf die Antwort der Proxy-Ebene.

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. Damit die Proxyebene die Anzahl der Instanzen und ihre Ratenlimits im Blick behalten kann, kann jede Proxyinstanz regelmäßig eine Datei lesen oder einen Remote Procedure Call (RPC) mit den codierten Ratenlimits ausführen.

Die synchrone Verarbeitung hat manchmal die folgenden 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 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 an eine Warteschlange weiterzuleiten. In Cloud Tasks werden die folgenden Google Cloud-Kontingente automatisch festgelegt und überwacht:

• Maximale Burst-Größe und maximale Anzahl gleichzeitiger Anfragen mit dem RateLimits-Objekt
• Limits für Wiederholungen mit dem Objekt RetryConfig

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

Beachten Sie bei der Verwendung von Cloud Tasks Folgendes:

• Cloud Tasks garantiert keine genau einmalige Zustellung. Bei der Zustellung genau einmal werden alle Anfragen mit duplizierten Daten als Duplikate erkannt und vom Server ignoriert. Weitere Informationen finden Sie unter After Lambda: Exactly once processing in Dataflow, Part 1 (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 Ratenbegrenzern 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 FHIR-Batch- und ‑Transaktionsbundles an Cloud Tasks senden, von wo aus die Anfragen im Bundle an die Cloud Healthcare API gesendet werden. 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 Warteschlange des Ratenbegrenzers voll wird, indem Sie diese Ressourcen überwachen:

• Kontingente für FHIR-Vorgänge in der Cloud Healthcare API
• Kontingente für Ratenbegrenzungen
• Fehler bei der Ratenbegrenzung

Wenn die Warteschlange des Ratelimiters voll ist, muss Ihr System einen Nutzer 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. Dazu ist ein TCP-Handshake erforderlich, der zu einem Overhead führen und die Leistung beeinträchtigen 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, legen Sie den Connection-Header auf keep-alive fest:

Connection: keep-alive

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

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

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 sich die Leistung durch exponentielle Backoffs und clientseitige Ratenbegrenzung verbessert. 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 auf eine Antwort wartet, kann die Arbeitslast für Hintergrundverarbeitungsaufgaben reduziert werden, damit die Nutzerfreundlichkeit 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
• Mit der Cloud Monitoring API können Sie benutzerdefinierte Messwerte erstellen, um wichtige Messwerte wie Wiederholungen, Warteschlangengrößen und Warteschlangenalter zu erfassen.
• 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. Mit Benachrichtigungsrichtlinien werden Sie über Probleme informiert, z. B. wenn Ihr System überlastet ist oder menschliches Eingreifen erforderlich ist.
• Erstellen Sie Betriebshandbücher, 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 von überschrittenen Kontingentlimits
  • Eingehende Traffic-Spitzen

429 Resource Exhausted operation_too_costly-Fehler verhindern

Wenn täglich Tausende von parallelen Aktualisierungen an einer FHIR-Ressource vorgenommen werden, kann dies zu Sperrkonflikten, Latenz und verhinderten Transaktionen führen. Transaktionen, die nicht abgeschlossen werden können, können zu einem Rückstau 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"
}

Im Fehler 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 eine übermäßige Sperrkonfliktrate bei Datenbanksätzen 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 Sperrkonflikten. Fehlerantworten enthalten ein Feld diagnostics mit dem Text Resource type: PATIENT.

   Sie können die Aktualisierung der Patientenressource mit exponentiellem Backoff wiederholen. Lange Sperrzeiträ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 Rückstau von Transaktionen und reduziert die Last, indem er operation_too_costly-Fehler zurückgibt. Dadurch wird der Traffic begrenzt und weitere Fehler werden verhindert.

   Die operation_too_costly-Fehler beeinträchtigen alle FHIR-CRUD-Vorgänge in Ihrem Google Cloud-Projekt. Das wirkt sich auf alle mit Ihrem Projekt verbundenen Anwendungen aus.

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 Pakete vermeiden

Der Fehler 429 Too Many Requests tritt bei großen Transaktionspaketen häufiger auf. Bundles jeder Größe können zu Durchsatzengpässen führen. Testen Sie verschiedene Sets, um die optimale Größe zu finden.

Bei großen Bundles mit Wiederholungen kann die Leistung sinken und es ist wahrscheinlicher, dass es zu mehreren Fehlern kommt. Clients sollten zusätzliche Logik implementieren, um den Teil der FHIR-Ressourcen zu verwalten, die bei einer Transaktion fehlgeschlagen sind.

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

Vermeiden Sie große Pakete 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. Eine FHIR-Ressource ist beispielsweise möglicherweise nicht von der spezifischen Version einer anderen Ressource im selben Bundle abhängig.
• 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 ähnlichen Batch-Bundles kommt es seltener zu Konflikten, da sie keine Sperren für FHIR-Ressourcenupdates haben.

Bei kleinen Transaktionsbündeln wird ein Kampf um Ressourcen vermieden, da nur wenige Sperren gleichzeitig gehalten werden und die Ausführung schnell abgeschlossen wird. 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 mittelmäßig ist, verwenden Sie fhir.create zum Speichern von Daten. Verwenden Sie fhir.executeBundle oder fhirStores.import, um große Mengen an FHIR-Ressourcen zu speichern. Informationen zu den einzelnen Methoden finden Sie unter 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. Folgendes ist beispielsweise nicht erforderlich:

  • Große Bundles in kleinere aufteilen
  • Plä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 Aktualität der Daten eine hohe Priorität hat. Importe können schnell gehen, aber auch Stunden oder Tage dauern.

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

• Beim FHIR-Import kann ein hoher Datendurchsatz erzielt werden, wenn Ihre Anwendung Bulk-Fehler und Fehler bei einer Teilmenge von Ressourcen verarbeiten kann.

FHIR-Bundles verwenden

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

• Es ist zu teuer, entweder in Bezug auf die Abrechnungskosten oder die Netzwerkbandbreite, eine Pipeline zum Speichern von Daten in Cloud Storage und zum Importieren zu erstellen.

• Die referenzielle Integrität muss erzwungen werden.

• Die FHIR-Profilvalidierung muss erzwungen werden.

• Sie müssen Pub/Sub-Benachrichtigungen senden, wenn FHIR-Ressourcen gespeichert werden. Der FHIR-Import unterstützt keine 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:

  • Verzögerungen in der Verarbeitungspipeline 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 jeden Vorgang im Paket angewendet, als wäre er unabhängig ausgeführt worden. Wenn ein Paket beispielsweise 10 POST-Vorgänge, 5 GET-Vorgänge und 1 DELETE-Vorgang enthält, sind das Kontingent und die Abrechnung für das Paket gleich, als würden diese Vorgänge unabhängig voneinander ausgeführt.

• Bei großen Transaktionsbündeln treten häufiger Transaktionskonflikte auf, die zu Sperrkonflikten führen. Weitere Informationen finden Sie unter 429 Resource Exhausted operation_too_costly-Fehler verhindern.

• 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 einen hohen Datendurchsatz beim Senden von Daten aus einem Bildarchivierungs- und Kommunikationssystem (Picture Archiving and Communication System, PACS) an die Cloud Healthcare API erzielen:

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 in einem einmaligen Batch-Ladevorgang übertragen, müssen Sie die Änderungen an der Größe der Daten im Zeitverlauf messen, um festzustellen, was sich geändert hat.
• Leistung der Kundenservicemitarbeiter bei der Weiterleitung maximieren
• Cloud Storage-Speicherplatz 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.
• Intervalle für die Batchaufnahme basierend auf der Netzwerk- und Speicherkapazität eines klinischen Systems planen

Wir empfehlen, den Storage Transfer Service für eine einzelne Batch-Ladung zu verwenden, um einen DICOM-Speicher zu füllen. Die regelmäßige Verwendung des Storage Transfer Service erfordert zusätzliche Arbeit, 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 verwalten, um den Datendurchsatz zu optimieren

In den folgenden Abschnitten wird beschrieben, wie Sie das Kontingent verwalten und planen, um den Datendurchsatz zu optimieren. 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. So lassen sich Fehler vermeiden und Sie haben einen Sicherheitsabstand bei Traffic-Spitzen oder gelegentlichen Steigerungen 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.

Kontingent für große Anfragen planen

Planen Sie keine großen Batchjobs während Spitzenzeiten. Weitere Informationen finden Sie unter Transaktionen mit geringem Volumen regelmäßig ausführen.

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 ein zusätzliches Flexibilitäts-Kontingent hat, führen kleine Traffic-Spitzen nicht zu Fehlern und vorhersehbare Spitzenlasten führen nicht zu Fehlern. 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

Wenn Sie einen hohen Datendurchsatz aufrechterhalten und 429 Resource Exhausted-Fehler vermeiden möchten, lesen Sie die Best Practices auf dieser Seite, insbesondere den Abschnitt Quota verwalten, um den Datendurchsatz zu optimieren. Mit diesen Best Practices sorgen Sie dafür, dass Ihre Clientanwendung robust ist und bei Änderungen des Anfragevolumens skaliert werden kann. 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.