Prácticas recomendadas de 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 para sistemas a gran escala.

Capacidad de procesamiento de datos

La capacidad de procesamiento de datos es la cantidad de recursos, como recursos de FHIR o DICOM instancias o 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 podría estar limitada:

• No planificaste solicitudes de gran volumen que causan aumentos repentinos del 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 genera una contención de datos.
• Se están realizando demasiadas solicitudes pequeñas. Para obtener más información, consulta Evita las solicitudes de importación y exportación pequeñas.
• Se ejecutan demasiadas operaciones de larga duración (LRO) de forma simultánea y el ancho de banda es limitado.
• Se programaron demasiados LRO al mismo tiempo, lo que genera fallas.

Vuelve a intentar con las solicitudes que fallaron

Si un cliente reintenta solicitudes de forma rápida y reiterada después de fallas, puede exceder las cuotas de la API de Cloud Healthcare. En las siguientes secciones, se describe cómo reintentar de forma eficiente las solicitudes que fallaron.

Usa la retirada exponencial con jitter y colas de reintentos persistentes

Retirada exponencial con el jitter introducido una estrategia estándar de manejo de errores para aplicaciones de red. Un cliente vuelve a intentarlo periódicamente de solicitudes erróneas con retrasos exponencialmente crecientes entre los reintentos y un retraso pequeño y aleatorio.

Asegúrate de que la implementación de la retirada exponencial sea idempotente para cada reintento, especialmente si usas una lógica personalizada 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 la retirada exponencial 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 máximo tiempo de retirada.

Usa la retirada exponencial cuando vuelvas a intentar estas solicitudes:

• Operaciones que modifican un recurso o paquete de FHIR.

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

  Las LRO tienen errores únicos que podrían requerir que implementes lo siguiente: Estrategias de reintento:

  • Usa un paquete independiente para almacenar los datos que no pasaron una operación de importación o creación.
  • Usa solicitudes síncronas para los datos que no se pudieron procesar.

Ejemplo del 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 El siguiente algoritmo implementa la 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 y espera 2ⁿ + random-fraction segundos después de cada uno reintentar, hasta maximum-backoff vez.

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 min((2n + random-fraction), maximum-backoff), con n a partir de 0 y, luego, incrementado 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, para esperar entre reintentos. Los valores típicos son 32 o 64 (2⁵ o 2⁶) segundos. Elegir el valor que mejor se adapte a 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 llegar a la hora maximum-backoff con el mismo valor como 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.

Implementa el límite de frecuencia del cliente con la determinación por tráfico

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

Si tienes requisitos adicionales, como la entrega garantizada en todos los reintentos, es posible que las estrategias de Cómo reintentar solicitudes fallidas no sean suficientes. Determinación por tráfico es una técnica de límite de frecuencia que mantiene la tasa de solicitudes del cliente dentro de las restricciones del ancho de banda. Esto distribuye los aumentos repentinos de carga en 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 usando solo los reintentos, ya que evita los rechazos y hace un seguimiento de las unidades trabajadoras.

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

Requisitos de la determinación por 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 fallas en el disco.
• Trabajadores coordinados para extraer de la cola de procesamiento
• Detección del 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 el almacenamiento respaldado en la fila de procesamiento. Si hay un desastre, tu sistema debe poder borrarse definitivamente o recuperarse en la fila.
• Se redujeron los LRO durante las horas pico. Para obtener más información, consulta Planifica y usa la cuota de manera eficiente. y Poner en cola y administrar LRO.

En los siguientes casos, la determinación por tráfico podría requerirse solo para un de la canalización:

• Limitar la cantidad de trabajadores que extraen de un paso anterior de la canalización
• Limitar a cada trabajador de manera individual
• Usar un coordinador de grupos de trabajo 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 el límite de frecuencia en otras áreas de tu sistema

Puedes usar lenguajes de programación y frameworks existentes para implementar el tráfico dar forma. Ten en cuenta los siguientes proyectos de código abierto soluciones:

• Restricción del cliente en Apache Beam. Consulta Ajuste de escala automático horizontal. para obtener información sobre cómo controlar la limitación con numWorkers y maxNumWorkers.

• El 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 el 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 Cómo controlar errores en varias capas, también puede controlar la limitación en los servicios que usan la API de Cloud Healthcare. Según el tipo de tráfico que se requiere, usa una de estas opciones:

Asíncrono

Usar el procesamiento asíncrono para poner en cola solicitudes y controlar a los trabajadores Una capa de proxy escribe las solicitudes entrantes en la cola y muestra respuestas 200 OK después de que cada solicitud se pone en cola. Esto funciona mejor para las solicitudes de escritura, pero se puede usar para 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 que finalice una unidad anterior. Una capa de proxy retrasa las solicitudes salientes según los límites de QPS o de rendimiento de bytes, y el cliente bloquea y espera la respuesta de la capa de proxy.

La capa de proxy puede ajustar su límite de frecuencia según el número de instancias o puede coordinar con una que ajusta 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 a procedimiento remoto (RPC) con los límites de frecuencia codificados.

A veces, el procesamiento síncrono tiene las siguientes desventajas:

• Los recursos de las capas cliente y de proxy no están disponibles mientras el cliente bloquea y espera una respuesta. Esto puede generar errores, tiempos de espera y una menor productividad de los datos, lo que dificulta la escalabilidad.

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

Usar Cloud Tasks

Usa Cloud Tasks para transferir solicitudes a 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 Crea colas para crear colas en Cloud Tasks. La Queue recurso muestra las opciones que puedes configurar en una cola. Para Por ejemplo, puedes usar RetryConfig para implementar una retirada exponencial. Consulta Bibliotecas cliente de Cloud Tasks para ver las bibliotecas específicas de cada lenguaje.

Cuando uses Cloud Tasks, ten en cuenta lo siguiente:

• Cloud Tasks no garantiza que se entreguen exactamente una vez. En la entrega de exactamente una vez, el servidor reconoce como duplicados y, luego, ignora las solicitudes que contienen datos duplicados. Para obtener más información, consulta Después de Lambda: procesamiento de tipo "exactamente una vez" 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 las cuotas y los límites de la API de Cloud Healthcare.
• Cloud Tasks tiene problemas y limitaciones.

Combina paquetes de FHIR con limitadores de frecuencia

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

Un cliente puede enviar paquetes de FHIR de lotes y transacciones a Cloud Tasks, que envía las solicitudes del paquete a la API de Cloud Healthcare. Si el botón el límite de frecuencia está lleno o excedió 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 los paquetes en cola.

Supervisa estos recursos para evitar que la cola del limitador de frecuencia se llene:

• Cuotas de operaciones de FHIR en la API de Cloud Healthcare
• Cuotas del límite de frecuencia
• Errores del límite 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 nueva conexión TCP para cada CRUD. Esto requiere un Protocolo de enlace TCP, lo que puede generar sobrecarga y degradar el rendimiento. Para mejorar el rendimiento, usa Keep-alive de HTTP para mantener la conexión TCP abierta para varias solicitudes.

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

Connection: keep-alive

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

El código de Python requests de código abierto usan keep-alive HTTP de forma predeterminada. Si usas Node.js, configura keepAlive a true cuando creas un objeto http.Agent y, luego, pasas el objeto en tu solicitud.

Usa un framework de pruebas

Un framework de pruebas garantiza que tu 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.
• Probar si la retirada exponencial y el límite de frecuencia del cliente mejorar el rendimiento. Las pruebas pueden mostrar si estas implementaciones crean un backlog de tareas que se deben controlar por separado.
• Separa y controla el tráfico de alta prioridad. Por ejemplo, si un usuario espera una respuesta, se puede reducir la carga de trabajo en las tareas de procesamiento en segundo plano para garantizar que la experiencia del usuario no se deteriore.
• Prueba estrategias de colas síncronas y asíncronas para regular el flujo de tráfico o comprobar 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 filas para reanudarlo después de que finalice el desastre.

Use Cloud Monitoring

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

• Integra Cloud Tasks en otros Servicios de registro y supervisión de Google Cloud, como Registros de auditoría de Cloud
• Crea métricas personalizadas con el la API de Cloud Monitoring para hacer un seguimiento de las métricas clave, como los reintentos, los tamaños de las colas y antigüedad de la fila.
• Crea objetivos de nivel de servicio (SLO) y indicadores de nivel de servicio (SLI) para tus entornos. Consulta Introducción a los SLI para obtener recomendaciones.
• Crea políticas de alertas con Google Cloud Observability. Las políticas de alertas te notifican sobre problemas, como si el sistema está bajo presión o requiere intervención humana.
• Crea guías operativas para que los administradores de sistema saben 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 las siguientes situaciones:

  • Colas causadas por el límite de frecuencia
  • Devolución causada por exceder los límites de cuota
  • Aumentos repentinos de tráfico entrante

Evita errores 429 Resource Exhausted operation_too_costly

Realizar miles de actualizaciones paralelas todos los días en un recurso de FHIR puede causar la contención de bloqueo, la latencia y evita que se completen las transacciones. Las transacciones que no se pueden completar pueden crear un retraso 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 la capacidad de procesamiento de 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 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 un paquete de FHIR o una combinación de operaciones CRUD.

Considera la siguiente situación:

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

2. Varios paquetes de FHIR intentan actualizar el recurso Patient 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 Patient con la retirada exponencial, pero Los largos períodos de contención de bloqueo pueden provocar tiempos de espera, una capacidad de procesamiento reducida y el aumento en el uso de los recursos.

3. Con el tiempo, el servidor FHIR de la API de Cloud Healthcare detecta una cantidad de transacciones pendientes y pérdidas de carga si se muestra operation_too_costly errores. Esto limita el tráfico y evita errores futuros.

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

Solucionar el problema de 429 Too Many Requests errores

Para solucionar los 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, verifica si hay problemas de cuota.

Si se produce la limitación, es posible que los paquetes de transacciones fallen debido a niveles altos de contención de bloqueo y produzcan 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 problema, ve al vínculo FHIR transactional bundle aborted due to cumulative heavy load en el campo diagnostics.

Evita los paquetes grandes

Es más probable que se produzca el error 429 Too Many Requests con paquetes de transacciones grandes. Los paquetes de cualquier tamaño pueden crear cuellos de botella de rendimiento. Probar diferentes paquetes para encontrar el tamaño óptimo.

Los paquetes grandes con reintentos pueden tener rendimientos de rendimiento decrecientes y son más susceptibles de tener varias fallas. Los clientes deberían implementar lógica adicional para administrar el subconjunto de recursos de FHIR que falló en una transacción.

Los paquetes por lotes pueden encontrar 429 Too Many Requests y 413 Request Entity Too Large y cuellos de botella en la capacidad de procesamiento si son grandes o tener una QPS alta.

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

• Usa paquetes de transacciones más pequeños que admitan la coherencia de los datos. Si FHIR recursos 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 el procesamiento por lotes en los paquetes y evita las solicitudes individuales. El procesamiento por 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 contienen bloqueos entre actualizaciones de recursos de FHIR.

Los paquetes de transacciones pequeños evitan la contención porque solo contienen algunos bloqueos a la vez y terminar rápidamente. Esto ayuda a evitar un retraso 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 tus datos de FHIR es de bajo 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 para decidir si usarás 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. Cómo evitar las simultáneos las importaciones grandes o la latencia alta, o la capacidad de procesamiento de datos puede ser limitada.

• La importación de FHIR tiene menos complejidad que usar paquetes de FHIR. Por ejemplo, no tendrás que hacer lo siguiente:

  • Dividir paquetes grandes en paquetes más pequeños
  • Administrar programas
  • Vuelve a intentar errores transitorios a nivel del recurso o del 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 actualidad de los datos sea de alta prioridad. Las importaciones pueden ser rápida, pero podría tener retrasos de horas o días.

• Las importaciones de FHIR tienen un mejor rendimiento cuando hay pocos LRO en tu proyecto de Google Cloud.

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

Usa paquetes de FHIR

Usa paquetes de FHIR en lugar de la importación de FHIR en los siguientes casos:

• Es demasiado costoso, ya sea 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 de perfiles de FHIR.

• Debes enviar notificaciones de Pub/Sub. cuando se almacenan los recursos de FHIR. No se admite la importación de FHIR Notificaciones de Pub/Sub.

• La actualización de los datos es una prioridad, y estos deben transferirse en segundos o minutos. Sin embargo, incluso en un sistema bien diseñado, la capacidad de procesamiento de datos puede estar limitada por lo siguiente:

  • Retrasos ascendentes en las canalizaciones de procesamiento. Es posible que las canalizaciones necesiten más tiempo para preparar los 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 del paquete como si cada operación se ejecutara 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 aplicadas al paquete son las mismas que si esas operaciones se ejecutaran de forma independiente.

• Es más probable que los paquetes de transacciones grandes tengan conflictos de transacciones que generen contención de bloqueo. Para obtener más información, consulta Cómo evitar errores 429 Resource Exhausted operation_too_costly.

• Los paquetes por lotes pueden mejorar el rendimiento de los datos, pero no tienen capacidades de coherencia de transacciones, como la integridad referencial.

• Los paquetes de lotes grandes pueden tener una capacidad de procesamiento reducida. Para obtener más información, consulta Evita los 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 de un sistema de comunicación y archivado 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 Elemento de servicio de mensajes (DIMSE)

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

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

• Activar un sistema de archivos en cada máquina que aloje agentes en tu grupo de agentes para recuperar datos de origen
• Si transfieres datos a intervalos regulares en lugar de una carga por lotes, debes medir los cambios en el tamaño de los datos a lo largo del tiempo para determinar qué ha cambiado.
• Maximiza el rendimiento de la transferencia de agentes.
• Pagar por el almacenamiento de Cloud Storage y asignarlo
• Valida las 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 según la red y la capacidad de almacenamiento de un sistema clínico.

Te recomendamos que uses el Servicio de transferencia de almacenamiento para una sola carga por lotes para propagar un almacén de DICOM. Usar el Servicio de transferencia de almacenamiento con regularidad requiere trabajo adicional, como una canalización de importación síncrona. Para para obtener más información, consulta los detalles de la 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 almacenamiento 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 datos de procesamiento. Si deseas 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 tráfico diario. Incluso si el tráfico es predecible, planifica más cuota de la que necesitas en promedio. Esto te ayuda a evitar errores y proporciona un margen de seguridad contra los aumentos repentinos de 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 consistentes en el tamaño y se envían en patrones predecibles:

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

Planifica la cuota para solicitudes de gran volumen

Evita programar trabajos por lotes grandes durante las horas pico. Para obtener más información, Consulta Favorecer las transacciones de bajo volumen de manera 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 alto supera la cuota disponible. Esto puede generar errores 429 Resource Exhausted en todas las solicitudes de tu proyecto.

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

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

Para evitar que un solo trabajo por lotes grande cause aumentos repentinos de tráfico, consulta Evita los paquetes grandes.

Solicitar cuota adicional

Para mantener un alto rendimiento de datos y evitar errores 429 Resource Exhausted, consulta las prácticas recomendadas de esta página, en especial Cómo administrar la cuota para optimizar el rendimiento de datos. Estas prácticas recomendadas garantizan que tu aplicación cliente sea sólida y pueda escalar con los cambios en el volumen de solicitudes. Es poco probable que solicites una cuota adicional sin implementar las prácticas recomendadas. para evitar errores a largo plazo.

Si implementas las prácticas recomendadas y aún necesitas más cuota, consulta Prácticas recomendadas para solicitar una 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.