Prácticas recomendadas para la capacidad de procesamiento de transferencia de datos

En esta página, se describen las prácticas recomendadas para optimizar la capacidad de procesamiento de datos cuando se transfieren datos a la API de Cloud Healthcare. Estas recomendaciones son para profesionales técnicos con experiencia en la administración de la capacidad de procesamiento de datos en sistemas a gran escala.

Capacidad de procesamiento de datos

La capacidad de procesamiento de datos es la cantidad de recursos, como los recursos de FHIR o las instancias de DICOM, o los bytes que la API de Cloud Healthcare transfiere cada segundo.

Restricciones de la capacidad de procesamiento de datos

En la siguiente lista, se describen los motivos por los que la capacidad de procesamiento de datos puede verse limitada:

• No planificaste solicitudes de gran volumen que causan aumentos repentinos de tráfico.
• Las restricciones de ancho de banda ralentizan la transferencia de grandes volúmenes de datos que se envían en poco tiempo.
• Varias transacciones simultáneas cambian el mismo recurso de la API de Cloud Healthcare, lo que causa la contención de datos.
• Se están realizando demasiadas solicitudes pequeñas. Para obtener más información, consulta Evita solicitudes pequeñas de importación y exportación.
• Demasiadas operaciones de larga duración (LRO) se ejecutan en simultáneo y el ancho de banda es limitado.
• Hay demasiadas LRO programadas al mismo tiempo, lo que genera fallas.

Vuelve a intentar con las solicitudes que fallaron

Si un cliente vuelve a intentar realizar las solicitudes con rapidez y repetidamente después de fallas, puede exceder las cuotas de la API de Cloud Healthcare. En las siguientes secciones, se describe cómo reintentar de manera eficiente las solicitudes fallidas.

Usa la retirada exponencial con jitter y colas de reintento persistentes

La retirada exponencial con el jitter presentado es una estrategia estándar de manejo de errores para aplicaciones de red. Un cliente reintenta de forma periódica las solicitudes con errores con retrasos que aumentan de forma exponencial entre los reintentos y un pequeño retraso aleatorio.

Asegúrate de que tu implementación de retirada exponencial sea idempotente en cada reintento, en especial si usas lógica personalizada para omitir las condiciones de falla. Consulta 9.2.2 Métodos Idempotentes en la especificación HTTP para obtener más información.

La mayoría de los lenguajes de programación ofrecen bibliotecas para simplificar la implementación de retiradas exponenciales y estrategias de reintento similares. Para reintentos a largo plazo o de varios procesos, implementa una cola de reintentos persistente. Esta cola puede restablecer el mecanismo de reintento si superas el tiempo de retirada máximo.

Usa la retirada exponencial cuando reintentes estas solicitudes:

• Operaciones que modifican un recurso o paquete de recursos de FHIR.

• Solicitudes LRO síncronas Vuelve a intentarlo si se produce un error cuando se inicia la LRO o si falla.

  Las LRO tienen errores únicos que pueden requerir que implementes las siguientes estrategias de reintento:

  • Usa un paquete independiente para almacenar datos que no se pudieron importar o crear.
  • Usa solicitudes síncronas para los datos que no se pudieron procesar.

Ejemplo de algoritmo de retirada exponencial

Un algoritmo de retirada exponencial vuelve a intentar las solicitudes de forma exponencial, lo que aumenta el tiempo de espera entre los reintentos hasta un tiempo de retirada máximo. El siguiente algoritmo implementa una retirada exponencial truncada con jitter:

1. Envía una solicitud a la API de Cloud Healthcare.

2. Si la solicitud falla, espera 1 + random-fraction segundos y vuelve a intentar la solicitud.

3. Si la solicitud falla, espera 2 + random-fraction segundos y vuelve a intentar la solicitud.

4. Si la solicitud falla, espera 4 + random-fraction segundos y vuelve a intentar la solicitud.

5. Continúa con este patrón, espera 2ⁿ + random-fraction segundos después de cada reintento, hasta un tiempo de maximum-backoff.

6. Después de deadline segundos, deja de reintentar la solicitud.

Usa los siguientes valores cuando implementes el algoritmo:

• Antes de cada reintento, el tiempo de espera es de min((2n + random-fraction), maximum-backoff), en el que n comienza en 0 y se incrementa en 1 para cada reintento.

• Reemplaza random-fraction por un valor fraccionario aleatorio menor o igual que 1. Usa un valor diferente para cada reintento. Agregar este valor aleatorio evita que los clientes se sincronicen y envíen muchos reintentos al mismo tiempo.

• Reemplaza maximum-backoff por la cantidad máxima de tiempo, en segundos, que se debe esperar entre los reintentos. Los valores típicos son 32 o 64 (2⁵ o 2⁶) segundos. Elige el valor que funcione mejor para tu caso de uso.

• Reemplaza deadline por la cantidad máxima de segundos para seguir enviando reintentos. Elige un valor que refleje tu caso de uso.

El cliente puede volver a intentarlo después de alcanzar el tiempo maximum-backoff con el mismo valor que la retirada. Por ejemplo, si el tiempo de maximum-backoff es de 64 segundos, vuelve a intentarlo cada 64 segundos. Asegúrate de que el cliente no vuelva a intentarlo de forma indefinida.

Cómo implementar el límite de frecuencia del cliente con determinación por tráfico

El límite de frecuencia protege los sistemas a gran escala, ya que evita que se vean abrumados por el exceso de solicitudes. Si el límite de frecuencia del cliente no es suficiente, el sistema de cuotas de la API de Cloud Healthcare podría restringir la capacidad de procesamiento de datos. Si quieres obtener más información, consulta Prácticas recomendadas para la administración de cuotas.

Si tienes requisitos adicionales, como la entrega garantizada entre reintentos, las estrategias en Reintentar solicitudes fallidas podrían no ser suficientes. La modelación del tráfico es una técnica de límite de frecuencia que mantiene la frecuencia de las solicitudes del cliente dentro de las restricciones del ancho de banda. Esto reparte los aumentos repentinos de carga entre horas o minutos, lo que mejora la capacidad de procesamiento. Cuando la cuota está limitada, la determinación por tráfico puede alcanzar una capacidad de procesamiento mayor que el uso de reintentos únicamente, ya que evita el retroceso y realiza un seguimiento de las unidades de trabajador.

Puedes implementar la determinación por tráfico para operaciones de creación, eliminación, actualización y eliminación síncronas (CRUD), incluidas las fhir.executeBundle.

Requisitos para determinar el tráfico

Para implementar la determinación por tráfico, tu sistema debe implementar lo siguiente:

• Una cola de procesamiento respaldada por almacenamiento con redundancia para evitar la falla del disco
• Coordinó a los trabajadores para que extraigan de la cola de procesamiento.
• La detección de uso general para ajustar la cantidad de trabajadores y su velocidad de procesamiento según los límites de cuota
• Recuperación ante desastres para la cola de procesamiento respaldada por almacenamiento. Si ocurre un desastre, tu sistema debe poder borrar definitivamente o recuperar la cola.
• Se redujeron los LRO durante las horas pico. Para obtener más información, consulta Planifica y usa la cuota de manera eficiente y Pon en cola y administra las LRO.

En los siguientes casos, es posible que la determinación por tráfico solo sea necesaria para una sola etapa de canalización:

• Limitar la cantidad de trabajadores que extraen de un paso de canalización anterior
• Limitar cada trabajador de forma individual
• Usa un coordinador de grupo de trabajadores para ajustar la velocidad a la que se procesan las unidades de trabajo individuales, como las consultas por segundo (QPS) o los bytes transferidos por segundo.

Implementa límite de frecuencia en otras áreas de tu sistema

Puedes usar lenguajes de programación y frameworks existentes para implementar la determinación por tráfico. Considera los siguientes proyectos de código abierto y soluciones ya compiladas:

• Limitación del cliente en Apache Beam. Consulta Ajuste de escala automático horizontal si quieres obtener información para controlar la limitación con las marcas numWorkers y maxNumWorkers.

• La clase RateLimiter de Java del conjunto de bibliotecas principales de Java de Google Guava

• El módulo ratelimiter de Python

Para el control de flujo, usa la biblioteca cliente de Pub/Sub de alto nivel.

Elige entre procesamiento asíncrono y síncrono

Una capa de proxy del cliente que une las solicitudes a la API de Cloud Healthcare, que se muestra en Soluciona errores en varias capas, también puede controlar la limitación entre los servicios que usan la API de Cloud Healthcare. Según el tipo de determinación de tráfico requerida, usa una de estas opciones:

Asíncrona

Usa el procesamiento asíncrono para poner en cola las solicitudes y controlar los trabajadores. Una capa de proxy escribe las solicitudes entrantes en la cola y muestra respuestas 200 OK después de que cada solicitud está en cola. Esto funciona mejor para las solicitudes de escritura, pero se puede usar para las solicitudes de lectura en un framework de LRO si los clientes pueden recibir resultados de lectura.

Síncrona

El procesamiento síncrono proporciona un mecanismo de comentarios simple si una unidad de trabajo depende de la finalización de una unidad anterior. Una capa de proxy retrasa las solicitudes salientes en función de los límites de capacidad de procesamiento de bytes o QPS, y el cliente bloquea y espera la respuesta de la capa del proxy.

La capa del proxy puede ajustar su límite de frecuencia en función de la cantidad de instancias o se puede coordinar con un proceso del controlador que ajuste el límite de frecuencia cada pocos segundos. Para que la capa de proxy realice un seguimiento de la cantidad de instancias y sus límites de frecuencia, cada instancia de proxy puede leer un archivo con regularidad o realizar una llamada de procedimiento remoto (RPC) con los límites de frecuencia codificados.

El procesamiento síncrono a veces tiene las siguientes desventajas:

• Los recursos de las capas de cliente y proxy no están disponibles mientras el cliente bloquea y espera una respuesta. Esto puede generar errores, tiempos de espera y una capacidad de procesamiento reducida de datos, lo que dificulta el escalamiento.

• Si se desconectan la capa de cliente y de proxy, se requiere más trabajo para garantizar que los datos se modificaron según lo solicitado.

Usar Cloud Tasks

Usa Cloud Tasks para descargar las solicitudes en una cola. Cloud Tasks configura y supervisa automáticamente las siguientes cuotas de Google Cloud:

• Tamaño máximo de aumento de actividad y simultaneidad máxima de solicitudes con el objeto RateLimits
• Límites de reintentos con el objeto RetryConfig

Consulta Cómo crear colas para crear colas en Cloud Tasks. En el recurso Queue, se muestran las opciones que puedes configurar en una cola. Por ejemplo, puedes usar el objeto RetryConfig para implementar la retirada exponencial. Consulta las bibliotecas cliente de Cloud Tasks para ver bibliotecas específicas de cada lenguaje.

Cuando uses Cloud Tasks, ten en cuenta lo siguiente:

• Cloud Tasks no garantiza la entrega “exactamente una vez”. En la entrega “exactamente una vez”, las solicitudes que contengan datos duplicados se reconocen como duplicadas y el servidor las ignora. Para obtener más información, consulta Después de Lambda: exactamente una vez el procesamiento en Dataflow, parte 1.
• El tamaño máximo de la tarea puede ser mucho menor que el tamaño máximo del paquete de FHIR en la API de Cloud Healthcare. Para obtener más información, consulta Cuotas y límites de Cloud Tasks y Cuotas y límites de la API de Cloud Healthcare.
• Cloud Tasks tiene problemas y limitaciones.

Combina paquetes de FHIR con limitadores de frecuencia

Volver a intentar los paquetes de FHIR con retirada exponencial y limitadores de frecuencia ayuda a mantener una capacidad de procesamiento de datos alta y administrar los aumentos de carga.

Un cliente puede enviar paquetes de FHIR por lotes y transacciones a Cloud Tasks, que envía las solicitudes del paquete a la API de Cloud Healthcare. Si el limitador de frecuencia está lleno o supera la cuota porque alcanzó su tamaño máximo de cola y se quedó sin espacio en el disco, el cliente puede implementar la retirada exponencial para poner en cola los paquetes.

Evita que la cola del limitador de frecuencia se llene mediante la supervisión de estos recursos:

• Cuotas de operaciones de FHIR en la API de Cloud Healthcare
• Cuotas del limitador de frecuencia
• Errores del limitador de frecuencia

Si la cola del limitador de frecuencia se llena, tu sistema debe alertar a una persona y evitar que el cliente envíe solicitudes.

Usa conexiones HTTP persistentes (keep-alive reutilizables)

De forma predeterminada, la API de Cloud Healthcare abre una conexión TCP nueva para cada solicitud CRUD. Esto requiere un protocolo de enlace TCP, que puede causar sobrecarga y degradar el rendimiento. Para mejorar el rendimiento, usa keep-alive de HTTP a fin de mantener la conexión TCP abierta para varias solicitudes.

Para usar keep-alive de HTTP en HTTP/1.1, establece el encabezado Connection en keep-alive:

Connection: keep-alive

HTTP/2 usa una conexión TCP a las solicitudes secuenciales y simultáneas, lo que evita automáticamente la sobrecarga.

La biblioteca requests de Python usa keep-alive de HTTP de forma predeterminada. Si usas Node.js, configura keepAlive como true cuando crees un objeto http.Agent y, luego, pasa el objeto en tu solicitud.

Usa un framework de pruebas

Un framework de prueba garantiza que el código funcione y te ayuda a hacer lo siguiente:

• Prepárate para los aumentos repentinos de tráfico en una aplicación o canalización.
• Prueba si la retirada exponencial y el límite de frecuencia del cliente mejoran el rendimiento. Las pruebas pueden mostrar si estas implementaciones crean una lista de tareas pendientes que deben manejarse por separado.
• Separa y controla el tráfico de prioridad alta. Por ejemplo, si un usuario está esperando una respuesta, la carga de trabajo en las tareas de procesamiento en segundo plano se puede reducir para garantizar que no se degrade la experiencia del usuario.
• Prueba las estrategias de cola síncronas y asíncronas para regular el flujo de tráfico o prueba si la capa del proxy controla el rechazo.
• Planifica la recuperación ante desastres. Por lo general, esto requiere restablecer el tráfico entrante o usar colas para reanudar el tráfico después de que termine el desastre.

Use Cloud Monitoring

Usa Cloud Monitoring para supervisar tus entornos de prueba y producción. Sigue estas recomendaciones:

• Integrar Cloud Tasks a otros servicios de registro y supervisión de Google Cloud, como los Registros de auditoría de Cloud
• Crea métricas personalizadas con la API de Cloud Monitoring para realizar un seguimiento de las métricas clave, como los reintentos, los tamaños y la antigüedad de las colas.
• Crea objetivos de nivel de servicio (SLO) y también indicadores de nivel de servicio (SLI) para tus entornos. Consulta Introducción a los SLI para obtener recomendaciones.
• Crear políticas de alertas con la observabilidad de Google Cloud Las políticas de alertas te notifican si tu sistema está bajo estrés o requiere intervención humana.
• Crea guías operativas para que los administradores del sistema sepan qué hacer si una política de alertas envía una notificación.

• Usa las guías operativas en un entorno de etapa de pruebas para responder a las siguientes situaciones:

  • Tareas pendientes causadas por el límite de frecuencia
  • Retroceso provocados por exceder los límites de cuota
  • Aumentos repentinos del tráfico entrante

Evita 429 Resource Exhausted operation_too_costly errores

Realizar miles de actualizaciones paralelas todos los días en un recurso de FHIR puede causar contención de bloqueo y latencia, además de evitar que se completen las transacciones. Las transacciones que no se pueden completar pueden crear una lista de errores 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"
}

En el error, “costo” se refiere al uso de recursos y a la capacidad de procesamiento de los datos, no a los costos de facturación.

Un error 429 Too Many Requests no siempre indica un problema de cuota. El error puede ocurrir cuando el servidor de FHIR de la API de Cloud Healthcare detecta una contención de bloqueo excesiva en los registros de la base de datos. Esto puede ocurrir debido a muchas operaciones en un paquete de FHIR o una combinación de operaciones de CRUD.

Considera la siguiente situación:

1. Un paquete de transacciones de FHIR que actualiza un recurso de FHIR y otros recursos de FHIR bloquea el recurso paciente hasta que finaliza la transacción.

2. Varios paquetes de FHIR intentan actualizar el recurso de paciente en paralelo, y se produce una contención de bloqueo. Las respuestas de error incluyen un campo diagnostics con el texto Resource type: PATIENT.

   Puedes reintentar la actualización del recurso Paciente con una retirada exponencial, pero los períodos prolongados de contención de bloqueo pueden generar tiempos de espera, una capacidad de procesamiento reducida y un aumento en el uso de recursos.

3. En algún momento, el servidor de FHIR de la API de Cloud Healthcare detecta una acumulación de transacciones y cobertores de carga cuando devuelve errores operation_too_costly. Esto limita el tráfico y evita errores adicionales.

   Los errores operation_too_costly limitan todas las operaciones de FHIR CRUD en tu proyecto de Google Cloud, lo que afecta a todas las aplicaciones conectadas a tu proyecto.

Solucionar 429 Too Many Requests errores

Para solucionar errores de 429 Too Many Requests, busca en Cloud Logging. Los errores que contienen operation_too_costly indican una contención de bloqueo. Si los errores se deben al agotamiento de los recursos, comprueba si hay problemas de cuota.

Si se produce una limitación, los paquetes de transacciones pueden fallar debido a los altos niveles de contención de bloqueo y producir el siguiente error:

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

Para solucionar el error, ve al vínculo Se anuló el paquete de transacciones de FHIR debido a una carga pesada acumulativa en el campo diagnostics.

Evita los paquetes grandes

Es más probable que el error 429 Too Many Requests se relacione con paquetes de transacciones grandes. Los paquetes de cualquier tamaño pueden crear cuellos de botella en la capacidad de procesamiento. Prueba diferentes paquetes para encontrar el tamaño óptimo.

Los paquetes grandes con reintentos pueden tener rendimientos decrecientes y son más propensos a tener varias fallas. Los clientes deben implementar una lógica adicional para administrar el subconjunto de recursos de FHIR que fallaron en una transacción.

Los conjuntos por lotes pueden encontrar errores 429 Too Many Requests y 413 Request Entity Too Large, y cuellos de botella en la capacidad de procesamiento si son grandes o tienen altas QPS.

Evita usar paquetes grandes con miles de transacciones. En cambio, haz lo siguiente:

• Usa paquetes de transacciones más pequeños que respalden la coherencia de los datos. Si los recursos de FHIR no dependen unos de otros, actualízalos por separado. Por ejemplo, es posible que un recurso de FHIR no dependa de la versión específica de otro recurso en el mismo paquete.
• Usa algunos lotes en paquetes y evita solicitudes individuales. La agrupación en lotes puede mejorar el rendimiento, pero los lotes grandes pueden causar errores y degradar la capacidad de procesamiento de datos. Los paquetes por lotes de tamaño similar tienen menos contención porque no tienen bloqueos en las actualizaciones de recursos de FHIR.

Los paquetes de transacciones pequeños evitan la contención porque solo tienen algunos bloqueos a la vez y finalizan rápidamente. Esto ayuda a evitar una acumulación de transacciones apiladas.

Capacidad de procesamiento de LRO

Consulta Capacidad de procesamiento de datos de LRO.

Opciones de almacenamiento de datos de FHIR

Si el volumen de datos de FHIR es de pequeño a moderado, usa fhir.create para almacenar datos. Para almacenar grandes volúmenes de recursos de FHIR, usa fhir.executeBundle o fhirStores.import. Para obtener información sobre cada método, consulta Opciones de importación de FHIR.

Importa recursos de FHIR

Ten en cuenta lo siguiente cuando decidas si usar la importación de FHIR:

• La importación de FHIR no limita el tamaño total de los datos que importa. Si un paquete de FHIR supera los 50 MB, puedes subir los recursos de FHIR a Cloud Storage y, luego, importarlos. Evita las importaciones simultáneas de alta latencia o grandes, ya que la capacidad de procesamiento de datos podría estar limitada.

• La importación de FHIR tiene menos complejidad que el uso de paquetes de FHIR. Por ejemplo, no tienes que hacer lo siguiente:

  • Divide los paquetes grandes en otros más pequeños
  • Administrar programas
  • Reintentar errores transitorios a nivel de recurso o paquete

• La importación de FHIR no aplica la integridad referencial. Para obtener más información, consulta Integridad referencial de FHIR.

• No uses la importación de FHIR cuando la actualización de los datos sea una prioridad alta. Las importaciones pueden ser rápidas, pero podrían retrasarse durante horas o días.

• Las importaciones de FHIR funcionan mejor cuando hay pocas LRO en tu proyecto de Google Cloud.

• La importación de FHIR puede lograr una capacidad de procesamiento de datos alta si tu aplicación puede manejar fallas y errores masivos en un subconjunto de recursos.

Usa paquetes de FHIR

Usa paquetes de FHIR en lugar de importarlos en los siguientes casos:

• Es muy costoso, en costos de facturación o en ancho de banda de red, compilar una canalización para almacenar datos en Cloud Storage y, luego, importarlos.

• Se debe aplicar la integridad referencial.

• Se debe aplicar la validación del perfil de FHIR.

• Debes enviar notificaciones de Pub/Sub cuando se almacenan los recursos de FHIR. La importación de FHIR no admite notificaciones de Pub/Sub.

• La actualidad de los datos es una prioridad y los datos deben transferirse en segundos o minutos. Sin embargo, incluso en un sistema bien diseñado, la capacidad de procesamiento de datos puede verse limitada por los siguientes factores:

  • Demoras ascendentes en las canalizaciones de procesamiento Las canalizaciones pueden necesitar más tiempo para preparar datos antes de que se puedan transferir.
  • Retiradas, reintentos y capas de proxy que dan forma al tráfico.

Los paquetes de FHIR tienen las siguientes limitaciones:

• La cuota y la facturación se aplican a cada operación en el paquete como si cada operación se hubiera ejecutado de forma independiente. Por ejemplo, si un paquete tiene 10 operaciones POST, 5 operaciones GET y 1 operación DELETE, la cuota y la facturación que se aplican al paquete son las mismas que si esas operaciones se ejecutaran de forma independiente.

• Los paquetes de transacciones grandes tienen más probabilidades de tener conflictos de transacciones que generen una contención de bloqueo. Para obtener más información, consulta Cómo evitar errores 429 Resource Exhausted operation_too_costly.

• Los conjuntos por lotes pueden mejorar la capacidad de procesamiento de datos, pero no tienen funciones de coherencia transaccional como la integridad referencial.

• Los paquetes por lotes grandes pueden tener una capacidad de procesamiento reducida. Para obtener más información, consulta Cómo evitar paquetes grandes.

Opciones de almacenamiento de datos de DICOM

Puedes usar los siguientes métodos para lograr una alta capacidad de procesamiento de datos cuando envías datos desde un sistema de archivo y comunicación de imágenes (PACS) a la API de Cloud Healthcare:

El adaptador de DICOM de la API de Cloud Healthcare de código abierto con el protocolo de elementos de servicio de mensajes (DIMSE) de DICOM

El adaptador optimiza la capacidad de procesamiento de datos cuando sincronizas un PACS con la API de Cloud Healthcare. Antes de la sincronización, ejecuta pruebas de rendimiento y verifica que el adaptador pueda soportar la capacidad de procesamiento máxima de datos.

Usa este adaptador si no puedes subir archivos DICOM a Cloud Storage mediante el Servicio de transferencia de almacenamiento o alguna otra opción de transferencia. Por ejemplo, es posible que no puedas cumplir con los siguientes requisitos del Servicio de transferencia de almacenamiento:

• Activar un sistema de archivos en cada máquina que aloja agentes en tu grupo de agentes para recuperar datos de origen
• Si transfieres datos en un intervalo regular en lugar de una carga por lotes única, debes medir los cambios en el tamaño de los datos a lo largo del tiempo para determinar qué cambió.
• Maximización del rendimiento de la transferencia de agentes.
• Pagar y asignar el almacenamiento en Cloud Storage
• Validar transferencias de datos a Cloud Storage
• Quitar recursos de Cloud Storage después de importar datos a la API de Cloud Healthcare y corregir cualquier error de importación
• Programa intervalos de transferencia por lotes en función de la capacidad de almacenamiento y la red de un sistema clínico.

Recomendamos usar el Servicio de transferencia de almacenamiento para que una sola carga por lotes propague un almacén de DICOM. El uso del Servicio de transferencia de almacenamiento suele requerir trabajo adicional, como una canalización de importación síncrona. Para obtener más información, consulta Detalles de transferencia del sistema de archivos del Servicio de transferencia de almacenamiento.

dicomStores.import

Usa este método para almacenar grandes volúmenes de datos de DICOM.

Transacción de almacén de DICOMweb

Usa este método para almacenar datos de DICOM de manera programática.

Administra la cuota para optimizar la capacidad de procesamiento de datos

En las siguientes secciones, se describe cómo administrar y planificar la cuota para optimizar la capacidad de procesamiento de los datos. Si quieres conocer las prácticas recomendadas generales sobre la administración de cuotas, consulta Prácticas recomendadas para la administración de cuotas.

Planifica la cuota para el tráfico predecible

Para planificar los requisitos de cuota, primero analiza el tráfico diario típico de la aplicación cliente. Incluso si el tráfico es predecible, planifica una cuota superior a la que necesitas en promedio. Esto te ayuda a evitar errores y proporciona un margen de seguridad contra aumentos repentinos del tráfico o aumentos ocasionales en el uso diario.

En el siguiente diagrama, se muestran las solicitudes a la API de Cloud Healthcare que son coherentes en tamaño y se envían en patrones predecibles:

Figura 1: La carga total de API por hora en todos los conjuntos de datos y almacenes de datos de un proyecto de Google Cloud.

Planifica la cuota para solicitudes de grandes volúmenes

Evita programar grandes trabajos por lotes durante las horas pico. Para obtener más información, consulta Prioriza las transacciones de bajo volumen de forma coherente.

En el siguiente diagrama, se muestra un patrón de tráfico predecible. Sin embargo, una solicitud por lotes de gran volumen durante un período de tráfico máximo excede la cuota disponible. Esto puede causar errores 429 Resource Exhausted en todas las solicitudes de tu proyecto.

Figura 2: Una distribución irregular del uso de recursos causada por un gran trabajo por lotes durante las horas pico.

Si tu sistema tiene una cuota de flexibilidad adicional, los pequeños aumentos de tráfico no causarán errores ni causarán que las cargas máximas predecibles experimenten errores. Los pequeños aumentos deben distribuirse entre muchos almacenes de datos, aplicaciones y otros clientes que produzcan carga dentro del proyecto de Google Cloud.

Para evitar que un solo trabajo por lotes grande genere aumentos repentinos de tráfico, consulta Cómo evitar paquetes grandes.

Solicitar cuota adicional

Para mantener una capacidad de procesamiento de datos alta y evitar errores 429 Resource Exhausted, consulta las prácticas recomendadas de esta página, especialmente Administra la cuota para optimizar la capacidad de procesamiento de datos. Estas prácticas recomendadas garantizan que tu aplicación cliente sea sólida y pueda escalarse con los cambios en el volumen de solicitudes. Es poco probable que solicitar una cuota adicional sin implementar las prácticas recomendadas evite errores a largo plazo.

Si implementas las prácticas recomendadas y aún necesitas más cuota, consulta Prácticas recomendadas para solicitar cuota adicional.

Recursos de capacidad de procesamiento de transferencia de datos

Para obtener más información sobre la capacidad de procesamiento de transferencia de datos, consulta Administra el tráfico y la carga de tus cargas de trabajo en Google Cloud.