Bonnes pratiques concernant le débit d'ingestion de données

Cette page décrit les bonnes pratiques à suivre pour optimiser le débit de données lors de l'ingestion de données dans l'API Cloud Healthcare. Ces recommandations sont destinées des techniciens expérimentés dans la gestion du débit des données des systèmes à grande échelle.

Débit de données

Le débit de données correspond à la quantité de ressources, telles que les ressources FHIR ou les instances DICOM, ou d'octets que l'API Cloud Healthcare ingère chaque seconde.

Contraintes de débit de données

La liste suivante décrit les raisons pour lesquelles le débit de données peut être limité:

  • Vous n'aviez pas prévu de traiter de grandes requêtes qui entraînent des pics de trafic.
  • Les contraintes de bande passante ralentissent l'ingestion de grands volumes de données envoyés en peu de temps.
  • Plusieurs transactions simultanées modifient la même ressource de l'API Cloud Healthcare, ce qui entraîne un conflit de données.
  • Trop de petites requêtes sont effectuées. Pour en savoir plus, consultez Évitez les requêtes d'importation et d'exportation mineures.
  • Trop d'opérations de longue durée (LRO) s'exécutent simultanément et la bande passante est limitée.
  • Trop de LRO sont planifiées en même temps, ce qui entraîne des échecs.

Réessayer les requêtes ayant échoué

Si un client rapidement et relance les requêtes à plusieurs reprises après un échec, la valeur peut dépasser l'API Cloud Healthcare des quotas. Les sections suivantes expliquent comment relancer efficacement les requêtes ayant échoué.

Utiliser un intervalle exponentiel entre les tentatives avec la gigue et les files d'attente de nouvelles tentatives persistantes

Intervalle exponentiel entre les tentatives avec la gigue introduite est une stratégie standard de gestion des erreurs pour les applications réseau. Un client effectue régulièrement de nouvelles tentatives les requêtes ayant échoué avec des délais croissants de manière exponentielle entre les tentatives un petit délai aléatoire.

Assurez-vous que votre implémentation de l'intervalle exponentiel entre les tentatives est idempotente pour chaque nouvelle tentative, en particulier si vous utilisez une logique personnalisée les conditions de défaillance. Pour en savoir plus, consultez la section 9.2.2 Méthodes idempotentes de la spécification HTTP.

La plupart des langages de programmation proposent des bibliothèques pour simplifier l'implémentation du délai avant expiration exponentiel et des stratégies de nouvelle tentative similaires. Pour les tentatives à long terme ou multiprocessus, implémentez une méthode persistante de nouvelle tentative. Cette file d'attente peut réinitialiser le mécanisme de nouvelle tentative si vous dépassez le nombre maximal de tentatives autorisé entre les tentatives.

Utilisez un intervalle exponentiel entre les tentatives lorsque vous relancez ces requêtes:

  • Opérations qui modifient une ressource FHIR ou un groupe de ressources FHIR.

  • Requêtes de longue durée synchrones Réessayez en cas d'erreur au démarrage de l'opération de longue durée ou si l'opération de LRO échoue.

    Les opérations de longue durée présentent des erreurs uniques qui peuvent vous obliger à implémenter les actions suivantes : stratégies de nouvelle tentative:

    • Utilisez un bundle distinct pour stocker les données pour lesquelles une opération d'importation ou de création a échoué.
    • Utilisez des requêtes synchrones pour les données dont le traitement a échoué.

Exemple d'algorithme d'intervalle exponentiel entre les tentatives

Un algorithme d'intervalle exponentiel entre les tentatives relance les requêtes de manière exponentielle, en augmentant le temps d'attente entre les tentatives jusqu'à ce que la durée maximale de l'intervalle exponentiel soit atteinte. L'algorithme suivant met en œuvre un intervalle exponentiel entre les tentatives tronqué avec gigue :

  1. Envoyez une requête à l'API Cloud Healthcare.

  2. Si la requête échoue, attendez 1 + random-fraction secondes, puis effectuez une nouvelle tentative.

  3. Si la requête échoue, attendez 2 + random-fraction secondes, puis effectuez une nouvelle tentative.

  4. Si la requête échoue, attendez 4 + random-fraction secondes, puis effectuez une nouvelle tentative.

  5. Continuez ce modèle en attendant 2n + random-fraction secondes après chaque nouvelle tentative, jusqu'à maximum-backoff fois.

  6. Après deadline secondes, arrêtez de relancer la requête.

Lorsque vous appliquez l'algorithme, utilisez les valeurs suivantes :

  • Avant chaque nouvelle tentative, le temps d'attente est défini sur min((2n + random-fraction), maximum-backoff), avec n commençant à 0 et incrémenté de 1 pour chaque nouvelle tentative.

  • Remplacez random-fraction par une valeur fractionnelle aléatoire inférieure ou égale à 1. Utilisez une valeur différente pour chaque nouvelle tentative. L'ajout de cette valeur aléatoire empêche les clients de devenir synchronisés et en envoyant plusieurs tentatives en même temps.

  • Remplacez maximum-backoff par la durée maximale, en secondes, d'attente. entre les tentatives. Les valeurs habituelles sont de 32 ou 64 (25 ou 26) secondes. Choisir la valeur la plus adaptée à votre cas d'utilisation.

  • Remplacez deadline par le nombre maximal de secondes pendant lequel vous souhaitez continuer à envoyer des tentatives. Choisir une valeur qui reflète votre cas d'utilisation.

Le client peut réessayer une fois l'heure maximum-backoff atteinte en utilisant la même comme intervalle entre les tentatives. Par exemple, si la durée maximum-backoff est de 64 secondes, toutes les 64 secondes. Assurez-vous que le client n'effectue pas de nouvelles tentatives indéfiniment.

Implémenter la limitation du débit côté client avec le lissage du trafic

La limitation du débit protège les systèmes à grande échelle en les empêchant d'être submergé par un nombre excessif de requêtes. Si la limitation du débit côté client n'est pas est suffisant, le système de quotas de l'API Cloud Healthcare peut limiter le débit de données. Pour en savoir plus, consultez les bonnes pratiques de gestion des quotas.

Si vous avez des exigences supplémentaires, comme une livraison garantie entre les tentatives, les stratégies décrites dans Relancer des requêtes ayant échoué peuvent ne pas être suffisantes. Lissage du trafic est une technique de limitation du débit qui permet de maintenir le débit des requêtes côté client dans des limites de bande passante. Les pics de charge sont ainsi répartis sur des heures ou des minutes, ce qui améliore le débit. Lorsque le quota est limité, le lissage du trafic peut atteindre un débit supérieur à en utilisant uniquement la répétition des tentatives, car cela évite les refus et assure le suivi des unités de nœud de calcul.

Vous pouvez implémenter le modelage du trafic pour les opérations CRUD (créer, lire, mettre à jour et supprimer) synchrones, y compris fhir.executeBundle.

Exigences concernant la forme de trafic

Pour mettre en œuvre le modelage du trafic, votre système doit implémenter les éléments suivants :

  • File d'attente de traitement sauvegardée sur le stockage avec redondance pour éviter l'espace disque l'échec.
  • Nœuds de calcul coordonnés pour extraire des éléments de la file d'attente de traitement.
  • Utilisation globale de la détection pour ajuster le nombre de nœuds de calcul et leur vitesse de traitement en fonction des limites de quota.
  • Reprise après sinistre pour les environnements de stockage dans la file d'attente de traitement. En cas de sinistre, votre système doit pouvoir purger ou récupérer la file d'attente.
  • Réduction des LRO pendant les heures de pointe Pour en savoir plus, consultez Planifier et utiliser efficacement les quotas. et Mettre en file d'attente et gérer des opérations de longue durée.

Dans les cas suivants, la mise en forme du trafic peut ne s'appliquer qu'à une seule étape du pipeline :

  • Limiter le nombre de nœuds de calcul extraits d'une étape précédente du pipeline.
  • Limiter chaque nœud de calcul individuellement.
  • En utilisant un coordinateur de pool de nœuds de calcul pour ajuster la fréquence à laquelle Unités de travail individuelles, telles que le nombre de requêtes par seconde (RPS) ou ingérés par seconde, sont traités.

Implémentez la limitation du débit dans d'autres zones de votre système

Vous pouvez utiliser des langages de programmation et des frameworks existants pour implémenter le trafic. mise en forme. Envisagez les projets Open Source et les solutions prédéfinies suivants :

Pour contrôler le flux, utilisez la bibliothèque cliente Pub/Sub de haut niveau.

Choisir entre le traitement asynchrone et le traitement synchrone

une couche proxy côté client qui encapsule les requêtes adressées à l'API Cloud Healthcare ; comme indiqué dans la section Gérer les erreurs au niveau de plusieurs couches, peuvent également contrôler la limitation de bande passante entre les services qui utilisent l'API Cloud Healthcare. Selon le type de gestion du trafic requis, utilisez l'une des options suivantes :

Asynchrone
Utilisez le traitement asynchrone pour mettre les requêtes en file d'attente et contrôler les nœuds de calcul. Une couche proxy écrit les requêtes entrantes dans la file d'attente et renvoie des réponses 200 OK une fois chaque requête mise en file d'attente. Cette méthode fonctionne mieux pour les requêtes d'écriture, des requêtes de lecture dans un framework de longue durée si les clients peuvent recevoir des résultats de lecture.
Synchrone

Le traitement synchrone fournit un mécanisme de rétroaction simple lorsqu'une unité de dépend de la fin d'une unité précédente. Une couche proxy retarde les requêtes sortantes en fonction sur les limites de débit en RPS ou en octets, et le client bloque et attend le proxy la réponse de la couche de stockage.

La couche proxy peut ajuster sa limitation du débit en fonction le nombre d'instances, ou il peut se coordonner avec du contrôleur qui ajuste la fréquence limite à des intervalles de quelques secondes. Pour le couche proxy pour suivre le nombre d'instances et leur taux chaque instance de proxy peut lire régulièrement un fichier ou créer une session appel de procédure (RPC) avec les limites de débit encodées.

Le traitement synchrone présente parfois les inconvénients suivants:

  • Ressources dans le client et les couches proxy sont indisponibles lorsque le client bloque attend une réponse. Cela peut entraîner des erreurs, des délais avant expiration et une diminution du débit de données, ce qui rend la mise à l'échelle plus difficile.

  • Si le client et la couche proxy se déconnectent, des efforts supplémentaires sont nécessaires pour garantir les données ont été modifiées comme demandé.

Utiliser Cloud Tasks

Utilisez Cloud Tasks pour décharger dans une file d'attente. Cloud Tasks configure et surveille automatiquement les quotas Google Cloud suivants:

  • Taille maximale d'utilisation intensive et simultanéité maximale des requêtes à l'aide de l'objet RateLimits
  • Limites de nouvelle tentative à l'aide de l'objet RetryConfig

Consultez la section Créer des files d'attente pour créer et les files d'attente dans Cloud Tasks. La ressource Queue affiche les options que vous pouvez définir sur une file d'attente. Par exemple, vous pouvez utiliser l'objet RetryConfig pour implémenter un intervalle exponentiel entre les tentatives. Consultez la page Bibliothèques clientes Cloud Tasks. pour les bibliothèques propres à chaque langage.

Lorsque vous utilisez Cloud Tasks, tenez compte des points suivants :

Combiner des bundles FHIR avec des limiteurs de débit

Nouvelle tentative des lots FHIR avec un intervalle exponentiel entre les tentatives et des limiteurs de débit permet de maintenir un débit de données élevé et de gérer les pics de charge.

Un client peut envoyer des bundles FHIR de transactions et par lots à Cloud Tasks, qui envoie les requêtes du groupe à l'API Cloud Healthcare. Si le le limiteur de débit est saturé ou dépasse le quota, car il a atteint sa taille maximale de file d'attente et épuisé l'espace disque, le client peut implémenter un intervalle exponentiel entre les tentatives pour placer les bundles en file d'attente.

Pour éviter que la file d'attente du limiteur de débit ne soit saturée, surveillez les ressources suivantes :

  • Quotas d'opérations FHIR dans l'API Cloud Healthcare
  • Quotas de limiteurs de débit
  • Erreurs du limiteur de fréquence

Si la file d'attente du limiteur de fréquence est pleine, le système doit alerter empêcher le client d'envoyer des requêtes.

Utiliser des connexions HTTP persistantes (keep-alive réutilisables)

Par défaut, l'API Cloud Healthcare ouvre une nouvelle connexion TCP pour chaque Requête CRUD. Pour cela, Handshake TCP ce qui peut entraîner une surcharge et dégrader les performances. Pour améliorer les performances, utilisez Message keep-alive HTTP pour garder la connexion TCP ouverte pour plusieurs requêtes.

Pour utiliser le message keep-alive HTTP dans HTTP/1.1, définissez l'en-tête Connection sur keep-alive:

Connection: keep-alive

HTTP/2 utilise une connexion TCP pour les requêtes séquentielles et simultanées, ce qui évite automatiquement les frais généraux.

Python requests utilise le message keep-alive HTTP par défaut. Si vous utilisez Node.js, définissez keepAlive sur true lorsque vous créez un objet http.Agent, puis transmettez l'objet dans votre requête.

Utiliser un framework de test

Un framework de test garantit le bon fonctionnement de votre code et vous aide à effectuer les opérations suivantes:

  • Se préparer aux pics de trafic soudains dans une application ou un pipeline
  • Vérifier si un intervalle exponentiel entre les tentatives et une limitation du débit côté client améliorer les performances. Les tests peuvent montrer si ces implémentations créent un les tâches en attente qui doivent être traitées séparément.
  • Séparer et contrôler le trafic à priorité élevée Par exemple, si un utilisateur attend une réponse, la charge de travail des tâches de traitement en arrière-plan peut être réduite pour s'assurer que l'expérience utilisateur n'est pas dégradée.
  • Testez les stratégies de mise en file d'attente synchrones et asynchrones pour réguler le flux de trafic, ou vérifiez si la couche proxy gère le pushback.
  • Planifiez la reprise après sinistre. Cette opération nécessite généralement de réinitialiser ou utiliser des files d'attente pour reprendre après la fin du sinistre.

Utilisez Cloud Monitoring

Utilisez Cloud Monitoring pour surveiller vos tests environnements de production. Suivez ces recommandations :

  • Intégrer Cloud Tasks à d'autres les services de journalisation et de surveillance de Google Cloud, tels que Cloud Audit Logs ;
  • Créez des métriques personnalisées à l'aide de la fonction l'API Cloud Monitoring pour suivre des métriques clés telles que les nouvelles tentatives, la taille des files d'attente et âge de la file d'attente.
  • Créer des objectifs de niveau de service (SLO) et des indicateurs de niveau de service (SLI) pour vos environnements. Voir Présentation des SLI pour obtenir des recommandations.
  • Créez des règles d'alerte à l'aide de l'observabilité Google Cloud. Les règles d'alerte vous informent en cas de problème, par exemple si votre système est soumis à un stress ou nécessite une intervention humaine.
  • Créer des playbooks opérationnels afin que les administrateurs système savent quoi faire si une règle d'alerte envoie une notification.

  • Utilisez les playbooks opérationnels dans un environnement de préproduction pour répondre aux scénarios suivants:

    • Files d'attente causés par la limitation du débit
    • Rejet causé par le dépassement des limites de quota
    • Pics de trafic entrant

Éviter les erreurs 429 Resource Exhausted operation_too_costly

Effectuer des milliers de mises à jour parallèles chaque jour sur une ressource FHIR peut entraîner verrouiller les conflits, la latence transactions. Les transactions qui ne peuvent pas être finalisées peuvent créer des tâches en attente erreur(s) sur 429 Resource Exhausted operation_too_costly:

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

Dans l'erreur, "cost" fait référence à l'utilisation des ressources et au débit des données, pas aux coûts de facturation.

Une erreur 429 Too Many Requests n'indique pas toujours un problème de quota. La Une erreur peut se produire lorsque le serveur FHIR de l'API Cloud Healthcare détecte un verrouillage excessif. sur les enregistrements de base de données. Cela peut se produire en raison de nombreuses opérations dans un lot FHIR ou d'une combinaison d'opérations CRUD.

Imaginez le scénario suivant :

  1. Un lot de transactions FHIR qui met à jour une ressource Patient et d'autres ressources FHIR verrouille la ressource Patient jusqu'à la fin de la transaction.

  2. Plusieurs groupes FHIR tente de mettre à jour la ressource Patient en parallèle, ce qui entraîne un conflit de verrouillage. Erreur les réponses incluent un champ diagnostics avec le texte Resource type: PATIENT.

    Vous pouvez réessayer de mettre à jour la ressource Patient avec un intervalle exponentiel entre les tentatives, mais de longues périodes de conflits de verrous peuvent entraîner des délais d'inactivité, une réduction du débit et une utilisation accrue des ressources.

  3. Le serveur FHIR de l'API Cloud Healthcare détecte finalement des transactions en attente et des bassins de charge en renvoyant operation_too_costly les erreurs. Cela permet de limiter le trafic et d'éviter d'autres erreurs.

    Les erreurs operation_too_costly limitent toutes les opérations CRUD FHIR dans votre un projet Google Cloud, qui affecte toutes les applications associées à votre projet.

Résoudre les erreurs liées à 429 Too Many Requests

Pour résoudre les erreurs 429 Too Many Requests, effectuez une recherche dans Cloud Logging. Les erreurs contenant operation_too_costly indiquent un conflit de verrouillage. Si les erreurs sont dues à l'épuisement des ressources, recherchez des problèmes de quota.

Si une limitation se produit, les lots de transactions peuvent échouer en raison de niveaux élevés de conflit de verrouillage et générer l'erreur suivante :

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

Pour résoudre l'erreur, accédez au lien Groupe transactionnel FHIR annulé en raison d'une charge importante cumulative dans le champ diagnostics.

Éviter les lots volumineux

L'erreur 429 Too Many Requests est plus probable avec une transaction importante des offres groupées. Les bundles de toute taille peuvent créer des goulots d'étranglement de débit. Testez différentes pour trouver la taille optimale.

Les lots volumineux avec de nouvelles tentatives peuvent présenter des performances de moins en moins bonnes et plus susceptibles d'avoir plusieurs défaillances. Les clients doivent implémenter logique supplémentaire pour gérer le sous-ensemble de ressources FHIR ayant échoué dans une transaction.

Les lots groupés peuvent rencontrer des 429 Too Many Requests et des 413 Request Entity Too Large et les goulots d'étranglement de débit lorsqu'ils sont volumineux ou qui présentent un nombre élevé de RPS.

Évitez d'utiliser des lots volumineux contenant des milliers de transactions. Procédez plutôt comme suit :

  • Utilisez des groupes de transactions plus petits compatibles avec la cohérence des données. Si FHIR les ressources ne dépendent pas les unes des autres. Vous devez les mettre à jour séparément. Par exemple, une ressource FHIR peut ne pas dépendre de la version spécifique d'une autre ressource du même lot.
  • Utilisez quelques lots par lot et évitez les requêtes individuelles. Traitement par lot peut améliorer les performances, mais les lots volumineux peuvent provoquer des erreurs et se dégrader débit de données. Les lots de tailles similaires ont moins de conflits, car ils ne contiennent pas de verrous pour les mises à jour de ressources FHIR.

Les petits lots de transactions évitent les conflits, car ils ne contiennent que quelques verrous à la fois et de terminer rapidement. Cela permet d'éviter les transactions empilées en attente.

Débit de longue durée

Consultez la section Débit de données de longue durée.

Options de stockage des données FHIR

Si votre volume de données FHIR est faible ou modéré, utilisez fhir.create pour stocker des données. Pour stocker de grands volumes de ressources FHIR, utilisez fhir.executeBundle ou fhirStores.import. Pour en savoir plus sur chaque méthode, reportez-vous à la section Options d'importation FHIR.

Importer des ressources FHIR

Tenez compte des points suivants lorsque vous décidez d'utiliser l'importation FHIR :

  • L'importation FHIR ne limite pas la taille totale des données qu'elle des importations. Si un bundle FHIR dépasse 50 Mo, vous pouvez charger les ressources FHIR dans Cloud Storage et les importer. Éviter les opérations simultanées les importations volumineuses ou à latence élevée, ou le débit de données peut être limité.

  • L'importation FHIR est moins complexe que l'utilisation de bundles FHIR. Par exemple, vous ne devez pas vous devez procéder comme suit:

    • Partitionner les grands groupes en groupes plus petits
    • Gérer les planifications
    • Relancer les erreurs temporaires au niveau de la ressource ou du bundle

  • L'importation FHIR n'applique pas l'intégrité référentielle. Pour plus d'informations, consultez la section Intégrité référentielle FHIR.

  • N'utilisez pas l'importation FHIR lorsque la fraîcheur des données est une priorité élevée. Les importations peuvent sont rapides, mais peuvent être retardés de plusieurs heures ou jours.

  • Les importations FHIR sont plus efficaces lorsque votre projet Google Cloud contient peu de LRO.

  • L'importation FHIR peut atteindre un débit de données élevé si votre application peut gérer des erreurs et des échecs groupés sur un sous-ensemble de ressources.

Utiliser des groupes FHIR

Utilisez des groupes FHIR au lieu de l'importation FHIR dans les cas suivants:

  • C'est trop cher, en termes de coûts de facturation ou de bande passante réseau, pour créer un pipeline permettant de stocker des données dans Cloud Storage et de les importer.

  • L'intégrité référentielle doit être appliquée.

  • La validation du profil FHIR doit être appliquée.

  • Vous devez envoyer des notifications Pub/Sub. quand les ressources FHIR sont stockées. L'importation FHIR n'est pas compatible avec les notifications Pub/Sub.

  • La fraîcheur des données est une priorité. Elles doivent être ingérées en quelques secondes ou minutes. Toutefois, même dans un système bien structuré, le débit de données peut être limité par les éléments suivants:

    • Retards en amont dans les pipelines de traitement. Les pipelines peuvent nécessiter plus de temps pour préparer les données avant qu'elles ne puissent être ingérées.
    • Les couches proxy de temporisation, de nouvelle tentative et de gestion du trafic.

Les lots FHIR présentent les limites suivantes:

  • Le quota et la facturation sont appliqués à chaque opération du lot comme si chaque opération était exécutée indépendamment. Par exemple : Si un bundle comporte 10 opérations POST, 5 opérations GET et 1 opération DELETE, le quota et la facturation appliqués au lot sont les mêmes que si ces opérations ont été exécutés indépendamment.

  • Les lots de transactions volumineux sont plus susceptibles de générer des conflits de transactions peuvent entraîner des conflits de verrouillage. Pour en savoir plus, consultez Prévenir les erreurs 429 Resource Exhausted operation_too_costly.

  • Les lots par lots peuvent améliorer le débit de données, mais n'ont pas d'impact transactionnelle des fonctionnalités de cohérence telles que l'intégrité référentielle.

  • Les lots de lots volumineux peuvent avoir un débit réduit. Pour en savoir plus, consultez Éviter les lots volumineux.

Options de stockage des données DICOM

Vous pouvez utiliser les méthodes suivantes pour obtenir un débit de données élevé lors de l'envoi de données d’un système d’archivage et de communication des images (PACS) vers le API Cloud Healthcare:

L'adaptateur DICOM de l'API Cloud Healthcare Open Source utilisant le protocole DICOM Message Service Element (DIMSE)

L'adaptateur optimise le débit de données lorsque vous synchronisez un PACS avec l'API Cloud Healthcare. Avant la synchronisation, exécutez des tests de performance et vérifiez que l'adaptateur peut maintenir un débit de données maximal.

Utilisez cet adaptateur si vous ne pouvez pas importer de fichiers DICOM dans Cloud Storage à l'aide de Service de transfert de stockage ou un autre . Par exemple, vous ne pourrez peut-être pas répondre à ces Exigences liées au service de transfert de stockage:

  • Installer un système de fichiers sur chaque machine hébergeant des agents dans votre pool d'agents pour récupérer les données sources.
  • Si vous transférez des données à intervalle régulier au lieu d'un chargement par lot ponctuel, vous devez mesurer les changements de la taille des données au fil du temps pour déterminer ce qui a changé.
  • Maximiser les performances de transfert d'agent.
  • Payer et attribuer le stockage Cloud Storage
  • Valider des transferts de données vers Cloud Storage
  • Supprimez les ressources Cloud Storage après avoir importé des données dans l'API Cloud Healthcare et corrigé les erreurs d'importation.
  • Planification d'intervalles d'ingestion par lots en fonction du réseau et de la capacité de stockage d'un système clinique.

Nous vous recommandons d'utiliser le service de transfert de stockage pour effectuer un chargement par lot unique un magasin DICOM. L'utilisation régulière du service de transfert de stockage nécessite un travail supplémentaire, comme un pipeline d'importation synchrone. Pour Pour en savoir plus, consultez Détails des transferts du système de fichiers avec le service de transfert de stockage.

dicomStores.import

Utilisez cette méthode pour stocker de grands volumes de données DICOM.

Transaction du magasin DICOMweb

Utilisez cette méthode pour stocker des données DICOM de manière programmatique.

Gérer le quota pour optimiser le débit de données

Les sections suivantes décrivent comment gérer et planifier les quotas pour optimiser les données débit. Pour connaître les bonnes pratiques générales de gestion des quotas, consultez Bonnes pratiques pour la gestion des quotas

Planifier un quota pour un trafic prévisible

Planifiez vos besoins en quotas en analysant d'abord le trafic quotidien typique de votre application cliente. Même si le trafic est prévisible, prévoyez plus de quotas que vous n'en avez besoin en moyenne. Cela vous permet d'éviter les erreurs et offre une marge de sécurité contre les pics de trafic. ou des augmentations occasionnelles de l'utilisation quotidienne.

Le schéma suivant illustre les requêtes adressées à l'API Cloud Healthcare qui sont de taille cohérente et envoyées de manière prévisible:

Comparaison de l'utilisation des quotas entre les heures de pointe et les heures normales
Figure 1. Charge horaire agrégée de l'API sur les ensembles de données dans un projet Google Cloud.

Planifier un quota pour les requêtes volumineuses

Évitez de planifier de grosses tâches par lot pendant les heures de pointe. Pour en savoir plus, consultez Privilégier les transactions à faible volume de manière cohérente.

Le schéma suivant illustre un modèle de trafic prévisible. Toutefois, une requête par lot de grand volume pendant une période de pic de trafic dépasse le quota disponible. Cela peut entraîner des erreurs 429 Resource Exhausted pour toutes les requêtes dans votre projet.

Comparaison de l'utilisation des quotas entre les heures de pointe et les heures normales un pic plus élevé.
Figure 2 Distribution irrégulière de l'utilisation des ressources causée par une tâche par lot importante pendant les heures de pointe.

Si votre système dispose d'un quota de flexibilité supplémentaire, vous ne pouvez pas enregistrer de petits pics de trafic provoquer des erreurs ou provoquer des pics de charge prévisibles rencontrer des erreurs. Les petits pics doivent être répartis entre de nombreux data stores, applications et autres clients générant une charge dans le projet Google Cloud.

Pour éviter qu'un seul job par lot volumineux ne provoque des pics de trafic, consultez Évitez les lots trop volumineux.

Demander un quota supplémentaire

Pour maintenir un débit de données élevé et éviter les erreurs 429 Resource Exhausted, consultez les bonnes pratiques décrites sur cette page, en particulier Gérer le quota pour optimiser le débit de données. Ces bonnes pratiques garantissent que votre application cliente est robuste et peut évoluer en fonction des variations du volume de requêtes. Il est peu probable que demander des quotas supplémentaires sans appliquer les bonnes pratiques pour éviter les erreurs à long terme.

Si vous appliquez les bonnes pratiques et que vous avez encore besoin d'un quota plus élevé, consultez Bonnes pratiques pour demander des quotas supplémentaires

Ressources de débit pour l'ingestion de données

Pour en savoir plus sur le débit d'ingestion de données, consultez Gérez le trafic et la charge de vos charges de travail dans Google Cloud.