Prácticas recomendadas para el rendimiento de la ingestión de datos

En esta página se describen las prácticas recomendadas para optimizar el rendimiento de los datos al ingerirlos en la API Cloud Healthcare. Estas recomendaciones están dirigidas a profesionales técnicos con experiencia en la gestión del rendimiento de datos en sistemas a gran escala.

Velocidad de transferencia de datos

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

Restricciones de rendimiento de datos

En la siguiente lista se describen los motivos por los que el rendimiento de los datos puede verse limitado:

• No has previsto un gran volumen de solicitudes que provoquen picos de tráfico.
• Las limitaciones de ancho de banda ralentizan la ingesta de grandes volúmenes de datos enviados en un breve periodo.
• Varias transacciones simultáneas cambian el mismo recurso de la API Cloud Healthcare, lo que provoca una contención de datos.
• Se están haciendo demasiadas solicitudes pequeñas. Para obtener más información, consulta Evitar solicitudes de importación y exportación pequeñas.
• Se ejecutan demasiadas operaciones de larga duración (LROs) simultáneamente y el ancho de banda es limitado.
• Se han programado demasiadas operaciones LRO al mismo tiempo, lo que provoca errores.

Reintentar solicitudes incorrectas

Si un cliente reintenta enviar solicitudes de forma rápida y repetida después de que se produzcan errores, puede superar las cuotas de la API Cloud Healthcare. En las siguientes secciones se describe cómo reintentar de forma eficiente las solicitudes fallidas.

Usa un tiempo de espera exponencial con fluctuación y colas de reintentos persistentes

El tiempo de espera exponencial con jitter es una estrategia de gestión de errores estándar para las aplicaciones de red. Un cliente vuelve a intentar periódicamente las solicitudes fallidas con retrasos que aumentan exponencialmente entre los reintentos y un pequeño retraso aleatorio.

Asegúrate de que tu implementación del tiempo de espera exponencial sea idempotente en cada reintento, sobre todo si usas una lógica personalizada para evitar las condiciones de error. Consulta más información en el apartado 9.2.2 Métodos idempotentes de la especificación HTTP.

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

Usa un tiempo de espera exponencial al volver a enviar estas solicitudes:

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

• Solicitudes de LRO síncronas. Vuelve a intentarlo si se produce un error al iniciar el LRO o si falla.

  Las operaciones de larga duración tienen errores únicos que pueden requerir que implementes las siguientes estrategias de reintento:

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

Ejemplo de algoritmo de tiempo de espera exponencial

Un algoritmo de espera exponencial vuelve a intentar enviar las solicitudes de forma exponencial, lo que aumenta el tiempo de espera entre reintentos hasta un tiempo de espera máximo. El siguiente algoritmo implementa un tiempo de espera exponencial truncado con fluctuación:

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

2. Si la solicitud no se ejecuta correctamente, espera 1 + random-fraction segundos y vuelve a intentarlo.

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

4. Si la solicitud no se ejecuta correctamente, espera 4 + random-fraction segundos y vuelve a intentarlo.

5. Sigue este patrón, esperando 2ⁿ + random-fraction segundos después de cada reintento, hasta maximum-backoff veces.

6. Después de deadline segundos, deja de volver a intentar la solicitud.

Usa los siguientes valores al implementar el algoritmo:

• Antes de cada reintento, el tiempo de espera es min((2n + random-fraction), maximum-backoff), con n empezando en 0 y aumentando en 1 en cada reintento.

• Sustituye random-fraction por un valor fraccionario aleatorio igual o inferior a 1. Usa un valor diferente para cada reintento. Al añadir este valor aleatorio, se evita que los clientes se sincronicen y envíen muchos reintentos al mismo tiempo.

• Sustituye maximum-backoff por el tiempo máximo, en segundos, que se debe esperar entre reintentos. Los valores habituales son 32 o 64 (2⁵ o 2⁶) segundos. Elige el valor que mejor se adapte a tu caso práctico.

• Sustituye deadline por el número máximo de segundos que se deben seguir enviando reintentos. Elige un valor que refleje tu caso práctico.

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

Implementar la limitación de frecuencia del lado del cliente con la limitación del tráfico

La limitación de la frecuencia protege los sistemas a gran escala, ya que evita que se vean desbordados por un número excesivo de solicitudes. Si la limitación de la frecuencia del lado del cliente no es suficiente, el sistema de cuotas de la API Cloud Healthcare puede restringir el volumen de datos. Para obtener más información, consulta las prácticas recomendadas para gestionar las cuotas.

Si tienes requisitos adicionales, como la entrega garantizada en todos los reintentos, puede que las estrategias de Reintentar solicitudes fallidas no sean suficientes. La limitación del tráfico es una técnica de limitación de la frecuencia que mantiene la frecuencia de las solicitudes del lado del cliente dentro de las restricciones de ancho de banda. De esta forma, los picos de carga se distribuyen a lo largo de horas o minutos, lo que mejora el rendimiento. Cuando la cuota está limitada, la limitación del tráfico puede conseguir un rendimiento mayor que si solo se usan reintentos, ya que evita el rechazo y hace un seguimiento de las unidades de trabajo.

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

Requisitos de limitación del tráfico

Para implementar la limitación del tráfico, tu sistema debe implementar lo siguiente:

• Una cola de procesamiento respaldada por almacenamiento con redundancia para evitar errores en el disco.
• Trabajadores coordinados para extraer datos de la cola de procesamiento.
• Usa la detección general para ajustar el número de trabajadores y su velocidad de procesamiento en función de los límites de cuota.
• Recuperación tras fallos de la cola de procesamiento respaldada por almacenamiento. En caso de desastre, el sistema debe poder purgar o recuperar la cola.
• Se han reducido las LROs durante las horas punta. Para obtener más información, consulta Planificar y usar las cuotas de forma eficiente y Poner en cola y gestionar operaciones LRO.

En los siguientes casos, es posible que solo se requiera la limitación del tráfico en una fase de la canalización:

• Limitar el número de trabajadores que extraen datos de un paso anterior de la canalización.
• Limitar cada trabajador de forma individual.
• Usar 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 ingeridos por segundo.

Implementar la limitación de frecuencia en otras áreas del sistema

Puedes usar lenguajes de programación y frameworks que ya tengas para implementar la limitación del tráfico. Echa un vistazo a los siguientes proyectos de software libre y soluciones prediseñadas:

• Limitación del lado del cliente en Apache Beam. Consulta Adaptación dinámica horizontal para obtener información sobre cómo controlar la limitación mediante las marcas numWorkers y maxNumWorkers.

• La clase RateLimiter de Java de la colección de bibliotecas principales de Java de Google Guava.

• El módulo de Python ratelimiter.

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

Elegir entre el procesamiento asíncrono y el síncrono

Una capa de proxy del lado del cliente que envuelve las solicitudes a la API Cloud Healthcare, como se muestra en Gestionar errores en varias capas, también puede controlar la limitación en los servicios que usan la API Cloud Healthcare. En función del tipo de limitación del tráfico que necesites, usa una de estas opciones:

Asíncrono

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 devuelve respuestas 200 OK después de que se haya puesto en cola cada solicitud. Esta opción es la más adecuada para las solicitudes de escritura, pero se puede usar para las solicitudes de lectura en un marco de trabajo de LRO si los clientes pueden recibir resultados de lectura.

Síncrona

El procesamiento síncrono proporciona un mecanismo de comentarios sencillo si una unidad de trabajo depende de que se complete una unidad anterior. Una capa de proxy retrasa las solicitudes salientes en función de 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 en función del número de instancias o coordinarse con un proceso de controlador que ajuste el límite de frecuencia cada pocos segundos. Para que la capa de proxy pueda monitorizar el número de instancias y sus límites de frecuencia, cada instancia de proxy puede leer periódicamente un archivo o hacer 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 de cliente y proxy no están disponibles mientras el cliente bloquea y espera una respuesta. Esto puede provocar errores, tiempos de espera y una menor capacidad de procesamiento de datos, lo que dificulta el escalado.

• Si se desconectan el cliente y la capa proxy, se necesita más trabajo para asegurarse de que los datos se han modificado según lo solicitado.

Usar Cloud Tasks

Usa Cloud Tasks para derivar solicitudes a una cola. Cloud Tasks define y monitoriza automáticamente las siguientes Google Cloud cuotas:

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

Consulta Crear colas para crear colas en Cloud Tasks. El recurso Queue muestra las opciones que puedes definir en una cola. Por ejemplo, puedes usar el objeto RetryConfig para implementar un tiempo de espera exponencial. Consulta las bibliotecas de 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 las tareas se entreguen solo una vez. En el envío exactamente una vez, el servidor reconoce como duplicadas las solicitudes que contienen datos duplicados y las ignora. Para obtener más información, consulta After Lambda: procesamiento "una sola vez" en Dataflow (parte 1).
• El tamaño máximo de las tareas puede ser mucho menor que el tamaño máximo de los paquetes FHIR en la API Cloud Healthcare. Para obtener más información, consulta las cuotas y los límites de Cloud Tasks y las cuotas y los límites de la API de Cloud Healthcare.
• Cloud Tasks tiene problemas y limitaciones.

Combinar paquetes FHIR con limitadores de frecuencia

Volver a intentar enviar paquetes FHIR con retroceso exponencial y limitadores de frecuencia ayuda a mantener un alto rendimiento de datos y a gestionar los picos de carga.

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

Para evitar que la cola del limitador de frecuencia se llene, monitoriza estos recursos:

• Cuotas de operaciones de FHIR en la API de Cloud Healthcare
• Cuotas de 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.

Usar conexiones HTTP persistentes (keep-alive y reutilizables)

De forma predeterminada, la API de Cloud Healthcare abre una nueva conexión TCP para cada solicitud CRUD. Esto requiere un handshake TCP, lo que puede provocar una sobrecarga y reducir el rendimiento. Para mejorar el rendimiento, usa keep-alive de HTTP para mantener abierta la conexión TCP en varias solicitudes.

Para usar la función de mantener activa la conexión HTTP en HTTP/1.1, define el encabezado Connection como keep-alive:

Connection: keep-alive

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

La biblioteca de Python requests usa keep-alive de HTTP de forma predeterminada. Si usas Node.js, asigna el valor true a keepAlive cuando crees un objeto http.Agent y, a continuación, envía el objeto en tu solicitud.

Usar un framework de pruebas

Un framework de pruebas asegura que tu código funciona y te ayuda a hacer lo siguiente:

• Prepárate para picos de tráfico repentinos en una aplicación o una canalización.
• Prueba si el retroceso exponencial y la limitación de la frecuencia del lado del cliente mejoran el rendimiento. Las pruebas pueden mostrar si estas implementaciones crean una cartera de tareas que deben gestionarse por separado.
• Separa y controla el tráfico de alta prioridad. Por ejemplo, si un usuario está esperando una respuesta, se puede reducir la carga de trabajo de las tareas de procesamiento en segundo plano para que la experiencia de usuario no se vea afectada.
• Prueba las estrategias de colas síncronas y asíncronas para regular el flujo de tráfico o comprueba si la capa de proxy gestiona el rechazo.
• Planifica la recuperación tras fallos. Normalmente, esto requiere restablecer el tráfico entrante o usar colas para reanudar el tráfico una vez que haya pasado la emergencia.

Usa Cloud Monitoring

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

• Integra Cloud Tasks con otros servicios de registro y monitorización, como Registros de auditoría de Cloud.Google Cloud
• Crea métricas personalizadas con la API Cloud Monitoring para monitorizar métricas clave, como reintentos, tamaños de colas y antigüedad de las colas.
• Crea objetivos de nivel de servicio (SLOs) e indicadores de nivel de servicio (SLIs) para tus entornos. Consulta la introducción a los SLIs para ver recomendaciones.
• Crea políticas de alertas con Google Cloud Observability. Las políticas de alertas te avisan de problemas, como si tu sistema está sometido a mucha carga o requiere la intervención humana.
• Crea manuales de procedimientos 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 operativas en un entorno de staging para responder a los siguientes casos:

  • Retrasos causados por la limitación de frecuencia
  • Rechazo debido a que se han superado los límites de cuota
  • Picos de tráfico entrante

Evitar errores de 429 Resource Exhausted operation_too_costly

Si se realizan miles de actualizaciones paralelas al día en un recurso FHIR, se pueden producir conflictos de bloqueo y latencia, y las transacciones no se podrán completar. Las transacciones que no se pueden completar pueden crear un registro 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" hace referencia al uso de recursos y al rendimiento de los datos, no a los costes de facturación.

Un error 429 Too Many Requests no siempre indica un problema de cuota. Este error puede producirse cuando el servidor FHIR de la API 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 FHIR o a una combinación de operaciones CRUD.

Veamos la siguiente situación:

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

2. Varios paquetes FHIR intentan actualizar el recurso Patient en paralelo y se produce un conflicto 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 un tiempo de espera exponencial, pero los periodos largos de contención de bloqueos pueden provocar tiempos de espera, reducir el rendimiento y aumentar el uso de recursos.

3. El servidor FHIR de la API Cloud Healthcare detecta una acumulación de transacciones y reduce la carga devolviendo errores operation_too_costly. De esta forma, se limita el tráfico y se evitan más errores.

   Los errores operation_too_costly limitan todas las operaciones CRUD de FHIR de tu proyectoGoogle Cloud , lo que afecta a todas las aplicaciones conectadas a él.

Solucionar errores de 429 Too Many Requests

Para solucionar errores de 429 Too Many Requests, busca en Cloud Logging. Los errores que contienen operation_too_costly indican un conflicto de bloqueo. Si los errores se deben al agotamiento de recursos, comprueba si hay problemas con las cuotas.

Si se produce una limitación, es posible que los paquetes de transacciones fallen debido a los altos niveles de contención de bloqueos y se produzca 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, vaya al enlace FHIR transactional bundle aborted due to cumulative heavy load (Paquete transaccional de FHIR anulado debido a una carga pesada acumulativa) del campo diagnostics.

Evitar paquetes grandes

El error 429 Too Many Requests es más probable con paquetes de transacciones grandes. Los paquetes de cualquier tamaño pueden crear cuellos de botella en el rendimiento. Prueba diferentes paquetes para encontrar el tamaño óptimo.

Los paquetes grandes con reintentos pueden tener rendimientos decrecientes y son más susceptibles de tener varios errores. Los clientes deben implementar lógica adicional para gestionar el subconjunto de recursos de FHIR que no se han podido procesar en una transacción.

Los paquetes por lotes pueden provocar errores 429 Too Many Requests y 413 Request Entity Too Large, así como cuellos de botella en el rendimiento, si son grandes o tienen un nivel de consultas por segundo (CPS) elevado.

Evita usar paquetes grandes con miles de transacciones. En su lugar, haga 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 FHIR puede no depender de la versión específica de otro recurso del 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 provocar errores y reducir el volumen de datos. Los paquetes de lotes de tamaño similar tienen menos contención porque no mantienen bloqueos en las actualizaciones de recursos FHIR.

Los paquetes de transacciones pequeñas evitan la contención porque solo mantienen unos pocos bloqueos a la vez y terminan rápidamente. De esta forma, se evita que se acumulen transacciones.

Rendimiento de LRO

Consulta Rendimiento de datos de LRO.

Opciones de almacenamiento de datos 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 FHIR, usa fhir.executeBundle o fhirStores.import. Para obtener información sobre cada método, consulta las opciones de importación de FHIR.

Importar recursos FHIR

Tenga en cuenta lo siguiente a la hora de decidir 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 FHIR supera los 50 MB, puedes subir los recursos FHIR a Cloud Storage e importarlos. Evita las importaciones simultáneas con latencia alta o de gran tamaño, ya que el rendimiento de los datos podría verse limitado.

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

  • Dividir paquetes grandes en otros más pequeños
  • Gestionar horarios
  • 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 utilice 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 horas o días.

• Las importaciones de FHIR funcionan mejor cuando hay pocos LROs en tu proyecto de Google Cloud .

• La importación de FHIR puede lograr un alto rendimiento de datos si tu aplicación puede gestionar errores y fallos masivos en un subconjunto de recursos.

Usar paquetes FHIR

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

• Es demasiado caro, ya sea en costes de facturación o en ancho de banda de red, crear una canalización para almacenar datos en Cloud Storage e importarlos.

• Se debe aplicar la integridad referencial.

• Se debe aplicar la validación de perfiles FHIR.

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

• La actualización de los datos es una prioridad y los datos deben ingerirse en segundos o minutos. Sin embargo, incluso en un sistema bien diseñado, el rendimiento de los datos puede verse limitado por lo siguiente:

  • Retrasos en el procesamiento de las canalizaciones anteriores. Es posible que las canalizaciones necesiten más tiempo para preparar los datos antes de que se puedan ingerir.
  • Capas de proxy de retardo exponencial, reintentos y limitación del tráfico.

Los paquetes 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 provoquen contención de bloqueos. Para obtener más información, consulta Evitar errores de 429 Resource Exhausted operation_too_costly.

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

• Los paquetes grandes pueden tener un rendimiento reducido. Para obtener más información, consulta Evitar paquetes grandes.

Opciones de almacenamiento de datos DICOM

Puedes usar los siguientes métodos para conseguir un alto rendimiento de datos al enviar datos desde un sistema de archivo y comunicación de imágenes (PACS) a la API Cloud Healthcare:

El adaptador DICOM de la API Cloud Healthcare de código abierto que usa el protocolo elemento de servicio de mensajes DICOM (DIMSE)

El adaptador optimiza el rendimiento de los datos cuando sincronizas un PACS con la API Cloud Healthcare. Antes de sincronizar, haz pruebas de rendimiento y comprueba que el adaptador pueda mantener el rendimiento máximo de datos.

Usa este adaptador si no puedes subir archivos DICOM a Cloud Storage con el Servicio de transferencia de Storage u otra opción de transferencia. Por ejemplo, es posible que no puedas cumplir estos requisitos de Storage Transfer Service:

• Montar un sistema de archivos en cada máquina que aloje agentes de tu grupo de agentes para recuperar los datos de origen.
• Si transfiere datos a intervalos regulares en lugar de hacerlo en una sola carga por lotes, debe medir los cambios en el tamaño de los datos a lo largo del tiempo para determinar qué ha cambiado.
• Maximizar el rendimiento de la transferencia de agentes.
• Pagar y asignar almacenamiento de Cloud Storage.
• Validar las transferencias de datos a Cloud Storage.
• Eliminar recursos de Cloud Storage después de importar datos a la API de Cloud Healthcare y corregir los errores de importación.
• Programar intervalos de ingestión por lotes en función de la capacidad de red y almacenamiento de un sistema clínico.

Te recomendamos que uses el Servicio de transferencia de Storage para cargar un solo lote y rellenar un almacén DICOM. Para usar el Servicio de transferencia de Storage con regularidad, se necesita trabajo adicional, como una canalización de importación síncrona. Para obtener más información, consulta los detalles de la transferencia del sistema de archivos del Servicio de transferencia de Storage.

dicomStores.import

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

Transacción de almacenamiento de DICOMweb

Usa este método para almacenar datos DICOM mediante programación.

Gestionar la cuota para optimizar el volumen de datos

En las siguientes secciones se describe cómo gestionar y planificar la cuota para optimizar el rendimiento de los datos. Para consultar las prácticas recomendadas generales sobre la gestión de cuotas, consulta Prácticas recomendadas para gestionar las cuotas.

Planificar la cuota para el tráfico predecible

Planifica tus requisitos de cuota analizando primero el tráfico diario habitual de tu aplicación cliente. Aunque el tráfico sea predecible, planifica una cuota superior a la que necesites de media. De esta forma, evitas errores y tienes un margen de seguridad frente a los picos de tráfico o los aumentos ocasionales del uso diario.

En el siguiente diagrama se muestran solicitudes a la API Cloud Healthcare que tienen un tamaño constante y se envían con patrones predecibles:

.

Planificar la cuota para solicitudes de gran volumen

Evita programar tareas por lotes grandes durante las horas punta. Para obtener más información, consulta Priorizar las transacciones de poco volumen de forma constante.

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

Si tu sistema tiene una cuota de flexibilidad adicional, los pequeños picos de tráfico no provocarán errores ni harán que se produzcan errores en las cargas máximas predecibles. Los picos pequeños deben distribuirse entre muchos almacenes de datos, aplicaciones y otros clientes que generen carga en el proyecto Google Cloud .

Para evitar que un único trabajo por lotes grande provoque picos de tráfico, consulta Evitar paquetes grandes.

Solicitar cuota adicional

Para mantener un alto volumen de datos y evitar errores 429 Resource Exhausted, consulte las prácticas recomendadas de esta página, especialmente la sección Gestionar la cuota para optimizar el volumen de datos. Estas prácticas recomendadas aseguran que tu aplicación cliente sea sólida y pueda escalarse con los cambios en el volumen de solicitudes. Si solicitas cuota adicional sin implementar las prácticas recomendadas, es poco probable que evites errores a largo plazo.

Si implementas las prácticas recomendadas y sigues necesitando más cuota, consulta las prácticas recomendadas para solicitar cuota adicional.

Recursos de rendimiento de ingestión de datos

Para obtener más información sobre el rendimiento de la ingestión de datos, consulta Gestionar el tráfico y la carga de las cargas de trabajo en Google Cloud.