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 s'adressent aux professionnels techniques ayant de l'expérience dans la gestion du débit de données pour les 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'avez pas prévu de demandes volumineuses qui provoquent 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 la section Éviter les petites demandes d'importation et d'exportation.
  • Trop d'opérations de longue durée (LROs) 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 réessaient rapidement et de manière répétée les requêtes après un échec, il peut dépasser les quotas de l'API Cloud Healthcare. Les sections suivantes expliquent comment relancer efficacement les requêtes ayant échoué.

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

L'intervalle exponentiel entre les tentatives avec l'introduction de gigue est une stratégie standard de gestion des erreurs pour les applications réseau. Un client relance régulièrement les requêtes ayant échoué avec des délais croissants entre les tentatives et un petit délai aléatoire.

Assurez-vous que votre implémentation d'intervalle exponentiel entre les tentatives est idempotente pour chaque nouvelle tentative, en particulier si vous utilisez une logique personnalisée pour contourner les conditions d'échec. 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 de nouvelle exécution à long terme ou multiprocessus, implémentez une file d'attente de nouvelle exécution persistante. Cette file d'attente peut réinitialiser le mécanisme de nouvelle tentative si vous dépassez le délai maximal entre les tentatives.

Utilisez un intervalle exponentiel entre les tentatives de ces requêtes:

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

  • Requêtes LRO synchrones. Réessayez en cas d'erreur au démarrage de l'opération de récupération de l'objet ou en cas d'échec de l'opération.

    Les erreurs uniques des LRO peuvent vous obliger à implémenter les stratégies de nouvelle tentative suivantes:

    • 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 qui n'ont pas pu être traitées.

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 tronqué entre les tentatives 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 d'être synchronisés et d'envoyer de nombreuses tentatives en même temps.

  • Remplacez maximum-backoff par le délai d'attente maximal, en secondes, entre les nouvelles tentatives. Les valeurs habituelles sont de 32 ou 64 (25 ou 26) secondes. Choisissez la valeur qui convient le mieux à votre cas d'utilisation.

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

Le client peut réessayer après avoir atteint le délai maximum-backoff à l'aide de la même valeur que le délai avant expiration. Par exemple, si la valeur maximum-backoff est de 64 secondes, effectuez une nouvelle tentative toutes les 64 secondes. Assurez-vous que le client n'effectue pas de nouvelles tentatives à l'infini.

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

La limitation de débit protège les systèmes à grande échelle en les empêchant d'être submergés par des requêtes excessives. Si la limitation du débit côté client n'est pas suffisante, le système de quota 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 la distribution garantie lors des nouvelles tentatives, les stratégies de la section Réessayer les requêtes ayant échoué peuvent être insuffisantes. Le trafic shaping est une technique de limitation du débit qui maintient le débit des requêtes côté client dans les limites de bande passante. Cela répartit les pics de charge sur plusieurs heures ou minutes, ce qui améliore le débit. Lorsque le quota est limité, la mise en forme du trafic peut générer un débit plus élevé que l'utilisation des nouvelles tentatives uniquement, car elle évite les refus et suit les unités de travail.

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 le lissage du trafic

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

  • Une file d'attente de traitement basée sur le stockage avec redondance pour éviter les défaillances de disque.
  • Nœuds de calcul coordonnés pour extraire des éléments de la file d'attente de traitement.
  • Détection de l'utilisation globale 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 la file d'attente de traitement basée sur le stockage. 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 les pages Planifier et utiliser efficacement les quotas et Mettre en file d'attente et gérer les 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 qui extraient des données à partir d'une étape de pipeline précédente.
  • Limiter chaque nœud de calcul individuellement.
  • Utilisation d'un coordinateur de pool de nœuds de calcul pour ajuster le débit de traitement des unités de travail individuelles, telles que les requêtes par seconde (RPS) ou les octets ingérés par seconde.

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

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

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

Choisir entre le traitement asynchrone et synchrone

Une couche de proxy côté client qui encapsule les requêtes envoyées à l'API Cloud Healthcare, illustrée dans Gérer les erreurs à plusieurs niveaux, peut également contrôler le débit des 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 en file d'attente les requêtes et contrôler les workers. Une couche proxy écrit les requêtes entrantes dans la file d'attente et renvoie des réponses 200 OK après chaque requête mise en file d'attente. Cette méthode fonctionne mieux pour les requêtes d'écriture, mais peut être utilisée pour les requêtes de lecture dans un framework LRO si les clients peuvent recevoir des résultats de lecture.
Synchrone

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

La couche proxy peut ajuster sa limitation du débit en fonction du nombre d'instances, ou elle peut se coordonner avec un processus de contrôleur qui ajuste la limite de débit toutes les quelques secondes. Pour que la couche proxy puisse suivre le nombre d'instances et leurs limites de débit, chaque instance de proxy peut lire régulièrement un fichier ou effectuer un appel de procédure à distance (RPC) avec les limites de débit encodées.

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

  • Les ressources des couches client et proxy ne sont pas disponibles pendant que le client bloque et 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, plus de travail est nécessaire pour s'assurer que les données ont été modifiées comme demandé.

Utiliser Cloud Tasks

Utilisez Cloud Tasks pour transférer les requêtes vers une file d'attente. Cloud Tasks définit et surveille automatiquement les quotas Google Cloud suivants:

  • Taille maximale en 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 Créer des files d'attente pour créer des 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. Pour en savoir plus sur les bibliothèques propres aux langages, consultez la page Bibliothèques clientes Cloud Tasks.

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

Combiner des groupes FHIR avec des limiteurs de débit

Réessayer des bundles FHIR avec un délai avant expiration exponentiel 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 lots et des bundles de transactions FHIR à Cloud Tasks, qui envoie les requêtes du lot à l'API Cloud Healthcare. Si le limiteur de débit est plein ou dépasse le quota, car il a atteint sa taille de file d'attente maximale et qu'il n'a plus d'espace disque, le client peut implémenter un délai avant réessai exponentiel pour mettre en file d'attente les bundles.

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 limitation du débit
  • Erreurs liées au limiteur de débit

Si la file d'attente du limiteur de débit est saturée, votre système doit alerter un humain et 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. Cela nécessite un handshake TCP, ce qui peut entraîner des frais généraux et dégrader les performances. Pour améliorer les performances, utilisez le message keepalive HTTP pour maintenir la connexion TCP ouverte pour plusieurs requêtes.

Pour utiliser le 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.

La bibliothèque Python requests utilise la méthode 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 que votre code fonctionne et vous aide à effectuer les opérations suivantes:

  • Préparez-vous à des pics de trafic soudains dans une application ou un pipeline.
  • Vérifiez si le backoff exponentiel et la limitation de débit côté client améliorent les performances. Les tests peuvent montrer si ces implémentations créent un arriéré de tâches qui doivent être gérées séparément.
  • Séparez et contrôlez 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. Pour ce faire, vous devez généralement réinitialiser le trafic entrant ou utiliser des files d'attente pour reprendre le trafic une fois le sinistre terminé.

Utilisez Cloud Monitoring

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

  • Intégrer Cloud Tasks à d'autres services de journalisation et de surveillance Google Cloud, tels que les journaux d'audit Cloud
  • Créez des métriques personnalisées avec l'API Cloud Monitoring pour suivre les métriques clés telles que les nouvelles tentatives, les tailles de file d'attente et l'âge de la file d'attente.
  • Créez des objectifs de niveau de service (SLO) et des indicateurs de niveau de service (SLI) pour vos environnements. Pour obtenir des recommandations, consultez la section Présentation des SLI.
  • Créez des règles d'alerte à l'aide de Google Cloud Observability. Les règles d'alerte vous avertissent des problèmes, par exemple si votre système est soumis à une charge importante ou nécessite une intervention humaine.
  • Créez des livres de jeu opérationnels pour que les administrateurs système sachent 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:

    • Retards causés par la limitation du débit
    • Rejet dû au 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 des conflits de verrouillage, une latence et empêcher l'achèvement des transactions. Les transactions qui ne peuvent pas être finalisées peuvent créer un arriéré d'erreurs 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, le terme "coût" fait référence à l'utilisation des ressources et au débit de données, et non aux coûts de facturation.

Une erreur 429 Too Many Requests n'indique pas toujours un problème de quota. Cette erreur peut se produire lorsque le serveur FHIR de l'API Cloud Healthcare détecte une contention de verrouillage excessive sur les enregistrements de la 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 groupe 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 tentent de mettre à jour la ressource Patient en parallèle, et un conflit de verrouillage se produit. Les réponses d'erreur 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 conflit de verrouillage peuvent entraîner des délais avant expiration, une réduction du débit et une augmentation de l'utilisation des ressources.

  3. Le serveur FHIR de l'API Cloud Healthcare finit par détecter un arriéré de transactions et des décharges de charge en renvoyant des erreurs operation_too_costly. Cela limite le trafic et évite d'autres erreurs.

    Les erreurs operation_too_costly limitent toutes les opérations CRUD FHIR de votre projet Google Cloud, ce qui affecte toutes les applications connectées à votre projet.

Résoudre les erreurs 429 Too Many Requests

Pour résoudre les erreurs 429 Too Many Requests, recherchez 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 grands lots

L'erreur 429 Too Many Requests est plus probable avec de grands lots de transactions. Les bundles de toute taille peuvent créer des goulots d'étranglement de débit. Testez différents bundles pour trouver la taille optimale.

Les grands lots avec des nouvelles tentatives peuvent avoir des résultats de performances diminutifs et sont plus susceptibles de rencontrer plusieurs échecs. Les clients doivent implémenter une logique supplémentaire pour gérer le sous-ensemble de ressources FHIR qui ont échoué dans une transaction.

Les lots peuvent rencontrer des erreurs 429 Too Many Requests et 413 Request Entity Too Large, ainsi que des goulots d'étranglement de débit s'ils sont volumineux ou s'ils présentent un RPS élevé.

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

  • Utilisez des lots de transactions plus petits qui favorisent la cohérence des données. Si les ressources FHIR ne dépendent pas les unes des autres, mettez-les à 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 le traitement par lot dans les lots et évitez les requêtes individuelles. Le traitement par lot peut améliorer les performances, mais les lots volumineux peuvent entraîner des erreurs et dégrader le débit des données. Les lots de taille similaire présentent moins de conflits, car ils ne maintiennent pas de verrouillages pour les mises à jour des ressources FHIR.

Les petits lots de transactions évitent les conflits, car ils ne maintiennent que quelques verrous à la fois et se terminent rapidement. Cela permet d'éviter l'accumulation de transactions.

Débit LRO

Consultez la section Débit de données LRO.

Options de stockage des données FHIR

Si le volume de données FHIR est faible ou modéré, utilisez fhir.create pour stocker les données. Pour stocker de grands volumes de ressources FHIR, utilisez fhir.executeBundle ou fhirStores.import. Pour en savoir plus sur chaque méthode, consultez 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 importe. Si un bundle FHIR dépasse 50 Mo, vous pouvez importer les ressources FHIR dans Cloud Storage. Évitez les importations simultanées à latence élevée ou volumineuses, car le débit de données risque d'être limité.

  • L'importation FHIR est moins complexe que l'utilisation de groupes FHIR. Par exemple, vous n'avez pas besoin de procéder comme suit:

    • Diviser les grands bundles en plus petits
    • Gérer les planifications
    • Réessayer les erreurs temporaires au niveau de la ressource ou du lot

  • L'importation FHIR n'applique pas l'intégrité référentielle. Pour en savoir plus, 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é. Les importations peuvent être rapides, mais peuvent être retardées 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 les erreurs et les échecs groupés sur un sous-ensemble de ressources.

Utiliser des groupes FHIR

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

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

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

  • La validation des profils FHIR doit être appliquée.

  • Vous devez envoyer des notifications Pub/Sub lorsque des 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 conçu, 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 avoir besoin de 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 bundles 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 lot contient 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 étaient exécutées indépendamment.

  • Les grands lots de transactions sont plus susceptibles de présenter des conflits de transactions qui entraînent des conflits de verrouillage. Pour en savoir plus, consultez Prévenir les erreurs 429 Resource Exhausted operation_too_costly.

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

  • Les lots volumineux peuvent réduire le débit. Pour en savoir plus, consultez Éviter les grands bundles.

Options de stockage des données DICOM

Vous pouvez utiliser les méthodes suivantes pour obtenir un débit de données élevé lorsque vous envoyez des données à partir d'un système d'archivage et de transmission d'images (PACS) vers l'API Cloud Healthcare:

L'adaptateur DICOM de l'API Cloud Healthcare Open Source, qui utilise le protocole DIMSE (DICOM message service element)

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 performances et vérifiez que l'adaptateur peut maintenir le débit de données maximal.

Utilisez cet adaptateur si vous ne parvenez pas à importer des fichiers DICOM dans Cloud Storage à l'aide du service de transfert de stockage ou d'une autre option de transfert. Par exemple, vous ne pourrez peut-être pas répondre aux exigences suivantes du 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 à intervalles réguliers au lieu d'une importation par lot unique, vous devez mesurer les modifications apportées à la taille des données au fil du temps pour déterminer ce qui a changé.
  • Maximiser les performances de transfert des agents
  • Payer et allouer de l'espace de 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.
  • Planifier les intervalles d'ingestion par lot en fonction de la capacité réseau et de stockage d'un système clinique

Nous vous recommandons d'utiliser le service de transfert de stockage pour une seule importation par lot afin de renseigner 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 en savoir plus, consultez la page Détails du transfert de système de fichiers du service de transfert de stockage.

dicomStores.import

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

Transaction de magasin DICOMweb

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

Gérer les quotas pour optimiser le débit de données

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

Planifier un quota pour le 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 de disposer d'une marge de sécurité contre les pics de trafic ou les augmentations occasionnelles de l'utilisation quotidienne.

Le diagramme suivant montre les requêtes envoyées à l'API Cloud Healthcare, qui sont de taille cohérente et envoyées selon des schémas prévisibles:

Comparaison de l'utilisation des quotas entre les heures de pointe et les heures habituelles.
Figure 1 Charge API horaire globale sur les ensembles de données et les datastores d'un projet Google Cloud.

Planifier un quota pour les requêtes volumineuses

Évitez de planifier de grandes 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 montre 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 de votre projet.

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

Si votre système dispose d'un quota de flexibilité supplémentaire, les pics de trafic de faible ampleur ne généreront pas d'erreurs ni de pics de charge prévisibles. Les petits pics doivent être répartis entre de nombreux datastores, applications et autres clients produisant de la charge dans le projet Google Cloud.

Pour éviter qu'une seule job par lot volumineuse ne provoque des pics de trafic, consultez la section Éviter les lots 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 de cette page, en particulier Gérer les quotas pour optimiser le débit de données. Ces bonnes pratiques garantissent que votre application cliente est robuste et peut évoluer en fonction des changements de volume de requêtes. Demander une augmentation du quota sans appliquer les bonnes pratiques ne vous permettra probablement pas d'éviter les erreurs à long terme.

Si vous suivez ces bonnes pratiques et que vous avez toujours besoin de plus de quota, consultez la section Bonnes pratiques pour demander un quota supplémentaire.

Ressources sur le débit d'ingestion de données

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