Prácticas recomendadas para 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

El flujo de datos es la cantidad de recursos, como recursos de FHIR o instancias de DICOM, o bytes que la API de Cloud Healthcare transfiere cada segundo.

Restricciones de 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 planificaste solicitudes de gran volumen que provoquen 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 volver a intentar de forma eficiente las solicitudes que fallaron.

Usa la retirada exponencial con jitter y colas de reintentos persistentes

La retirada exponencial con el jitter incorporado es una estrategia estándar de manejo de errores para aplicaciones de red. Un cliente vuelve a intentar las solicitudes con errores de forma periódica, cada vez con más demoras 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, en especial si usas lógica personalizada para omitir las condiciones de error. Para obtener más información, consulta 9.2.2 Idempotent Methods en la especificación HTTP.

La mayoría de los lenguajes de programación ofrecen bibliotecas para simplificar la implementación de la atenuación 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 vuelvas a intentar estas solicitudes:

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

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

  Los LRO tienen errores únicos que podrían requerir que implementes las siguientes estrategias de reintento:

  • Usa un paquete independiente para almacenar los 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 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 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. 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. Elige un valor que refleje tu caso de uso.

El cliente puede reintentar después de alcanzar el tiempo de maximum-backoff con el mismo valor que el tiempo de espera. 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 conformación de 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. 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 en todos los reintentos, es posible que las estrategias de Cómo reintentar solicitudes fallidas no sean suficientes. La modificación del tráfico es una técnica de limitación de frecuencia que mantiene la tasa de solicitudes del cliente dentro de las restricciones de 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á restringida, la conformación de tráfico puede lograr una mayor capacidad de procesamiento que con solo los reintentos, ya que evita el rechazo y hace un seguimiento de las unidades de trabajo.

Puedes implementar la conformación de tráfico para las 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 conformación de 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 la fila de procesamiento con copia de seguridad en el almacenamiento Si ocurre un desastre, el sistema debe poder purgar o recuperar 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 Coloca en cola y administra las 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 cada trabajador de forma 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 y frameworks de programación existentes para implementar la conformación de tráfico. Considera los siguientes proyectos de código abierto y soluciones precompiladas:

• 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 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 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 modelado de tráfico requerido, usa una de estas opciones:

Asíncrono

Usa el procesamiento asíncrono para poner en cola solicitudes y controlar 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 limitación de frecuencia según la cantidad de instancias o coordinarse con un proceso de controlador 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.

El procesamiento síncrono a veces 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 el cliente y la capa de proxy, se requiere más trabajo para garantizar que los datos se hayan modificado según se solicitó.

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

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 las cuotas y límites de Cloud Tasks y los límites y cuotas de la API de Cloud Healthcare.
• Cloud Tasks tiene problemas y limitaciones.

Combina paquetes de FHIR con limitadores de frecuencia

Reintentar paquetes de FHIR con retardo exponencial y limitadores de frecuencia ayuda a mantener una alta capacidad de procesamiento de datos y a administrar los picos 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 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 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 de CRUD. Esto requiere un protocolo de enlace de TCP, que puede generar sobrecarga y disminuir el rendimiento. Para mejorar el rendimiento, usa el keepalive de HTTP para mantener la conexión TCP abierta para varias solicitudes.

Para usar el estado activo HTTP en HTTP/1.1, establece el encabezado Connection en 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.

La biblioteca requests de Python usa el estado activo HTTP de forma predeterminada. Si usas Node.js, establece keepAlive en true cuando crees un objeto http.Agent y, luego, pasa 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 aumentos repentinos del tráfico en una aplicación o canalización.
• Prueba si la pausa exponencial y el límite de frecuencia del cliente mejoran 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 vea afectada.
• 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 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 con otros servicios de supervisión y registro de Google Cloud, como los registros de auditoría de Cloud.
• Crea métricas personalizadas con la API de Cloud Monitoring para hacer un seguimiento de métricas clave, como reintentos, tamaños de cola y antigüedad de cola.
• 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, por ejemplo, si tu sistema está bajo presión o requiere intervención humana.
• Crea libros de jugadas operativos para que los administradores del sistema sepan qué hacer si una política de alertas envía una notificación.

• Usa los libros de jugadas operativos en un entorno de pruebas para responder a las siguientes situaciones:

  • Colas causadas por el límite de frecuencia
  • Rechazo debido a que se superaron los límites de cuota
  • Picos de tráfico entrante

Cómo evitar errores de 429 Resource Exhausted operation_too_costly

Realizar miles de actualizaciones en paralelo todos los días en un recurso FHIR puede causar contención de bloqueos, latencia y evitar 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 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 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 volver a intentar actualizar el recurso Patient con una retirada exponencial, pero los períodos de contención de bloqueo prolongados pueden generar tiempos de espera, una reducción de la capacidad de procesamiento y un mayor uso de 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 más errores.

   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.

Soluciona errores 429 Too Many Requests

Para solucionar problemas de errores 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 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. Prueba 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 deben implementar una lógica adicional para administrar el subconjunto de recursos de FHIR que fallaron en una transacción.

Los paquetes por lotes pueden encontrar errores 429 Too Many Requests y 413 Request Entity Too Large, así como cuellos de botella de rendimiento, si son grandes o tienen un QPS alto.

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 los recursos de FHIR no dependen entre sí, actualízalos por separado. Por ejemplo, un recurso de FHIR puede no depender 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 de lotes de tamaño similar tienen menos contención porque no mantienen bloqueos en las actualizaciones de recursos de FHIR.

Los paquetes de transacciones pequeños evitan la contención, ya que solo mantienen unos pocos bloqueos a la vez y terminan 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 datos de FHIR es pequeño o moderado, usa fhir.create para almacenar los 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, o el rendimiento de los datos podría verse limitado.

• La importación de FHIR es menos compleja que usar paquetes de FHIR. Por ejemplo, no tienes que hacer lo siguiente:

  • Cómo particionar 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 actualización de los datos sea una prioridad alta. Las importaciones pueden ser rápidas, pero pueden retrasarse durante 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. La importación de FHIR no admite 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 con una buena arquitectura, el rendimiento de los datos puede verse limitado por lo siguiente:

  • Demoras en el procesamiento de canalizaciones upstream Es posible que las canalizaciones necesiten más tiempo para preparar los datos antes de que se puedan transferir.
  • Capas de proxy de tiempo de espera, reintentos y modelado de 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 un alto rendimiento 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 que usa el protocolo elemento de servicio de mensajes de DICOM (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 cumplas con los siguientes 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 única, debes medir los cambios en el tamaño de los datos a lo largo del tiempo para determinar qué cambió.
• 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
• Programar 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 obtener más información, consulta 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 almacén de DICOMweb

Usa este método para almacenar datos de DICOM de forma 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 datos. 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 tus requisitos de cuota, primero analiza el tráfico diario habitual de tu aplicación cliente. Incluso si el tráfico es predecible, planifica una cuota mayor que 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 los 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 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 alto supera la cuota disponible. Esto puede generar errores 429 Resource Exhausted para todas las solicitudes de tu proyecto.

Figura 2: Una 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, 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 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 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 una cuota adicional.

Recursos de rendimiento 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 las cargas de trabajo en Google Cloud.