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

En esta página, se describen las prácticas recomendadas para optimizar el rendimiento de los 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 restringida:

• No planeaste solicitudes de gran volumen que causen 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 genera una 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.
• Se ejecutan demasiadas operaciones de larga duración (LRO) de forma simultánea y el ancho de banda es limitado.
• Se programan demasiadas LRO al mismo tiempo, lo que genera fallas.

Vuelve a intentar con las solicitudes que fallaron

Si un cliente lo hace rápidamente y reintenta solicitudes repetidas después de fallas, es posible que supere la API de Cloud Healthcare y cuotas. En las siguientes secciones, se describe cómo reintentar de manera eficiente las solicitudes con errores.

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 tiempo de retirada máximo.

Usa la retirada exponencial cuando reintentes 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 que se incrementa en 1 con 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 y enviar 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 mejor se adapte a tu caso de uso.

• Reemplaza deadline por la cantidad máxima de segundos para seguir enviando reintentos. Elegir 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 los sistemas a gran escala, ya que evita que se abrumado por una cantidad excesiva 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. Para obtener más información, consulta Prácticas recomendadas para la administración de cuotas.

Si tienes requisitos adicionales, como una entrega garantizada en los reintentos, Es posible que las estrategias en Reintentar solicitudes con errores 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 la usando solo los reintentos, ya que evita el rechazo y hace un seguimiento de las unidades trabajadoras.

Puedes implementar la conformación de tráfico para operaciones síncronas de creación, actualización y eliminación (CRUD), incluida 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 y con redundancia para evitar el disco falla.
• Se coordinaron trabajadores 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 las 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, es posible que solo se requiera la conformación de tráfico para una sola etapa 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 grupo de trabajadores para ajustar la velocidad a la que unidades de trabajo individuales, como consultas por segundo (QPS) o bytes transferidos por segundo.

Implementa el límite de frecuencia en otras áreas del sistema

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

• Limitació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.

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

• El ratelimiter de Python módulo.

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

Elige entre el procesamiento asíncrono y síncrono

Una capa de proxy del cliente que une solicitudes a la API de Cloud Healthcare. que se muestra en Cómo solucionar errores en varias capas también pueden controlar la limitación entre los servicios que usan la API de Cloud Healthcare. Según el tipo de determinación por tráfico requerido, 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 Devuelve las respuestas 200 OK después de que cada solicitud se pone en cola. Funciona mejor con 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 retroalimentación simple si una unidad de depende del final de una unidad previa. Una capa de proxy retrasa las solicitudes salientes según sobre los límites de capacidad de procesamiento de QPS o bytes, y el cliente bloquea y espera la llegada del la respuesta de la capa.

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 el capa de proxy para rastrear la cantidad de instancias y su tasa de proxy, cada instancia de proxy puede leer regularmente un archivo o hacer llamada de procedimiento (RPC) con los límites de frecuencia codificados.

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

• Recursos en el cliente y las capas de proxy no están disponibles mientras el cliente bloquea y espera una respuesta. Esto puede generar errores, tiempos de espera y una reducción de los datos. de procesamiento, lo que dificulta el escalamiento.

• 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

Usar Cloud Tasks para descargar las 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. El Queue recurso muestra las opciones que puedes configurar en una cola. Por ejemplo, puedes usar el objeto RetryConfig para implementar la retirada exponencial. Consulta Bibliotecas cliente de Cloud Tasks para bibliotecas de lenguaje específico.

Cuando uses Cloud Tasks, ten en cuenta lo siguiente:

• Cloud Tasks no garantiza la entrega 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 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 fila y se quedó sin espacio en el disco, el cliente puede implementar una retirada exponencial para poner en cola los paquetes.

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 se llena la cola del limitador de frecuencia, el sistema debe alertar a una persona impedir 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 de CRUD. Esto requiere un protocolo de enlace de TCP, que puede generar sobrecarga y disminuir 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 de tareas pendientes que deben manejarse por separado.
• Separa y controla el tráfico de prioridad alta. Por ejemplo, si un usuario está esperando para una respuesta, la carga de trabajo en tareas de procesamiento en segundo plano puede reducirse para garantizar que no se degrade la experiencia del usuario.
• Prueba las estrategias de colas síncronas y asíncronas para regular el flujo de tráfico o prueba si la capa de proxy controla el rechazo.
• Planifica la recuperación ante desastres. Por lo general, esto requiere restablecer tráfico o el uso de colas para reanudar el tráfico después de que finalice el desastre.

Use Cloud Monitoring

Usa Cloud Monitoring para supervisar tus pruebas y entornos de 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 los indicadores de nivel de servicio (SLI) de tus entornos. Consulta Introducción a los SLI para obtener recomendaciones.
• Crear políticas de alertas con Google Cloud Observability Las políticas de alertas te notifican sobre problemas, por ejemplo, si tu sistema está bajo estrés 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

Cómo evitar errores de 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 trabajos pendientes. de 429 Resource Exhausted operation_too_costly errores:

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, "cost" 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 intenta 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. El servidor de FHIR de la API de Cloud Healthcare, con el tiempo, detecta un retraso de transacciones y realiza una reducción de carga mostrando errores operation_too_costly. Esto limita el tráfico y evita errores futuros.

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

Solucionar el problema de 429 Too Many Requests errores

Para solucionar problemas 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 aplica una limitación, los paquetes de transacciones podrían fallar debido a los altos niveles de la contención de bloqueo y produce 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 Paquete transaccional de FHIR anulado debido a la carga pesada acumulativa en el campo diagnostics.

Evita los paquetes grandes

Es más probable que el error 429 Too Many Requests se produzca con una transacción grande paquetes. Los paquetes de cualquier tamaño pueden crear cuellos de botella en la capacidad de procesamiento. 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 su lugar, haz 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. Agrupación en lotes pueden 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 una acumulación de transacciones apiladas.

Capacidad de procesamiento de LRO

Consulta Capacidad de procesamiento de datos de LRO.

Opciones de almacenamiento de datos 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 . Si un paquete de FHIR supera los 50 MB, puedes subir los recursos de FHIR a Cloud Storage y, luego, importarlos. Evita las tareas simultáneas 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
  • 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 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 funcionan mejor cuando hay pocas 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 y errores masivos 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 caro para los costos de facturación o el ancho de banda de la red crear 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 perfil 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 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 estar limitada por lo siguiente:

  • Demoras upstream en el procesamiento de canalizaciones Es posible que las canalizaciones necesiten más tiempo para preparar los datos antes de que puedan transferirse.
  • 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 se ejecutó 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.

• Los paquetes de transacciones grandes tienen más probabilidades de tener conflictos puede llevar a la 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 la capacidad de procesamiento de datos, pero no tienen y capacidades de coherencia, 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 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 puede sostener 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:

• Activa 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 transferencias de datos a Cloud Storage.
• Quitar recursos de Cloud Storage después de importar datos a la API de Cloud Healthcare y corregir los errores de importación
• Programa intervalos de transferencia por lotes según la red y la capacidad de almacenamiento de un sistema clínico.

Recomendamos usar el Servicio de transferencia de almacenamiento para que se propague una sola carga por lotes 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. Para 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 se son coherentes en tamaño y se envían en patrones predecibles:

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 Prioriza las transacciones de bajo volumen de forma coherente.

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

Si tu sistema tiene una cuota de flexibilidad adicional, los pequeños aumentos repentinos de tráfico no generarán errores ni harán que las cargas máximas predecibles encuentren 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 del tráfico, consulta Evita los paquetes grandes.

Solicitar cuota adicional

Para mantener una alta capacidad de procesamiento de datos y evitar errores 429 Resource Exhausted, consulta las prácticas recomendadas de esta página, en especial la sección Administra la cuota para optimizar la capacidad de procesamiento de los 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 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.