Best practice per la velocità effettiva di importazione dati

Questa pagina descrive le best practice per ottimizzare la velocità effettiva dei dati durante l'importazione di dati nell'API Cloud Healthcare. Questi suggerimenti sono rivolti ai professionisti tecnici con esperienza nella gestione della velocità effettiva dei dati per i sistemi su larga scala.

Velocità effettiva dati

La velocità effettiva dei dati è la quantità di risorse, ad esempio risorse FHIR o istanze DICOM, o i byte che l'API Cloud Healthcare importa ogni secondo.

Vincoli di velocità effettiva dei dati

L'elenco seguente descrive i motivi per cui la velocità effettiva dei dati potrebbe essere limitata:

• Non hai pianificato richieste di grandi volumi che causano picchi di traffico.
• I limiti di larghezza di banda rallentano l'importazione di grandi volumi di dati inviati in un breve periodo di tempo.
• Più transazioni simultanee modificano la stessa risorsa dell'API Cloud Healthcare che causa una contesa tra i dati.
• Sono state effettuate troppe richieste di piccole dimensioni. Per maggiori informazioni, consulta Evitare le richieste di importazione ed esportazione di piccole dimensioni.
• Troppe operazioni a lunga esecuzione (LRO) in esecuzione contemporaneamente e la larghezza di banda è limitata.
• Sono stati pianificati troppi LRO contemporaneamente, il che genera errori.

Ritenta le richieste non riuscite

Se un client riprova rapidamente e ripetutamente a inviare le richieste dopo gli errori, può superare le quote dell'API Cloud Healthcare. Le sezioni seguenti descrivono come riprovare in modo efficiente le richieste non riuscite.

Utilizza il backoff esponenziale con code di tentativi tremolio e persistenti

Il backoff esponenziale con il tremolio introdotto è una strategia standard di gestione degli errori per le applicazioni di rete. Un client tenta periodicamente di inviare richieste non riuscite, con un ritardo maggiore tra i nuovi tentativi e un ritardo casuale ridotto.

Assicurati che l'implementazione del backoff esponenziale sia idempotente per ogni nuovo tentativo, soprattutto se utilizzi una logica personalizzata per bypassare le condizioni di errore. Consulta 9.2.2 Metodi idempotenti nella specifica HTTP per ulteriori informazioni.

La maggior parte dei linguaggi di programmazione offre librerie per semplificare l'implementazione di backoff esponenziale e strategie simili per i nuovi tentativi. Per i nuovi tentativi a lungo termine o multi-processo, implementa una coda di nuovi tentativi. Questa coda può reimpostare il meccanismo di nuovo tentativo se superi il tempo di backoff massimo.

Utilizza il backoff esponenziale quando ripeti queste richieste:

• Operazioni che modificano una risorsa FHIR o un pacchetto di risorse FHIR.

• Richieste LRO sincrone. Riprova se si verifica un errore all'avvio dell'LRO o se l'LRO non riesce.

  Gli LRO presentano errori univoci che potrebbero richiedere l'implementazione delle seguenti strategie di nuovo tentativo:

  • Utilizza un bundle separato per archiviare i dati che non hanno superato un'operazione di importazione o creazione.
  • Utilizza richieste sincrone per i dati che non sono stati elaborati.

Esempio di algoritmo di backoff esponenziale

Un algoritmo di backoff esponenziale tenta di eseguire nuovamente le richieste in modo esponenziale, aumentando il tempo di attesa tra un tentativo e l'altro fino a un tempo di backoff massimo. Il seguente algoritmo implementa il backoff esponenziale troncato con il jitter:

1. Invia una richiesta all'API Cloud Healthcare.

2. Se la richiesta non va a buon fine, attendi 1 + random-fraction secondi, quindi riprova.

3. Se la richiesta non va a buon fine, attendi 2 + random-fraction secondi, quindi riprova.

4. Se la richiesta non va a buon fine, attendi 4 + random-fraction secondi, quindi riprova.

5. Continua questo pattern, attendendo 2ⁿ + random-fraction secondi dopo ogni nuovo tentativo, fino a una volta maximum-backoff.

6. Dopo deadline secondi, interrompi i nuovi tentativi di richiesta.

Utilizza i seguenti valori per l'implementazione dell'algoritmo:

• Prima di ogni nuovo tentativo, il tempo di attesa è min((2n + random-fraction), maximum-backoff), con n che inizia da 0 e viene incrementato di 1 per ogni nuovo tentativo.

• Sostituisci random-fraction con un valore frazionario casuale inferiore o uguale a 1. Utilizza un valore diverso per ogni nuovo tentativo. L'aggiunta di questo valore casuale impedisce ai client di sincronizzarsi e di inviare molti nuovi tentativi contemporaneamente.

• Sostituisci maximum-backoff con il tempo massimo, in secondi, di attesa tra un nuovo tentativo e l'altro. I valori tipici sono 32 o 64 (2⁵ o 2⁶) secondi. Scegli il valore più adatto al tuo caso d'uso.

• Sostituisci deadline con il numero massimo di secondi per continuare a inviare nuovi tentativi. Scegli un valore che rifletta il tuo caso d'uso.

Il client può riprovare dopo aver raggiunto l'ora maximum-backoff utilizzando lo stesso valore del backoff. Ad esempio, se il tempo di maximum-backoff è di 64 secondi, riprova ogni 64 secondi. Assicurati che il client non riprovi a tempo indeterminato.

Implementare la limitazione di frequenza lato client con il formato di traffico

La limitazione di frequenza protegge i sistemi su larga scala evitando che vengano sovraccaricati da richieste eccessive. Se la limitazione di frequenza lato client non è sufficiente, il sistema di quote dell'API Cloud Healthcare potrebbe limitare la velocità effettiva dei dati. Per ulteriori informazioni, consulta le best practice per la gestione della quota.

Se hai requisiti aggiuntivi, come la consegna garantita tra i tentativi, le strategie descritte in Riprovare le richieste non riuscite potrebbero non essere sufficienti. Il formato di traffico è una tecnica di limitazione della frequenza che mantiene la frequenza delle richieste lato client entro i limiti di larghezza di banda. In questo modo i picchi di carico vengono distribuiti tra ore o minuti, migliorando la velocità effettiva. Quando la quota è limitata, il formato di traffico può raggiungere una velocità effettiva superiore rispetto all'uso dei soli nuovi tentativi, poiché evita il pushback e traccia le unità worker.

Puoi implementare il formato di traffico per le operazioni sincrone di creazione, eliminazione, aggiornamento ed eliminazione (CRUD), tra cui fhir.executeBundle.

Requisiti per la modellazione del traffico

Per implementare il formato di traffico, il sistema deve implementare quanto segue:

• Una coda di elaborazione basata sullo spazio di archiviazione con ridondanza per evitare un guasto del disco.
• Lavoratori coordinati per il pull dalla coda di elaborazione.
• Rilevamento dell'utilizzo complessivo per regolare il numero di worker e la loro velocità di elaborazione in base ai limiti di quota.
• Ripristino di emergenza della coda di elaborazione basata sullo spazio di archiviazione. In caso di emergenza, il sistema deve essere in grado di eliminare definitivamente o ripristinare la coda.
• LRO ridotti durante le ore di punta. Per maggiori informazioni, consulta Pianificare e utilizzare la quota in modo efficiente e Mettere in coda e gestire gli LRO.

Nei seguenti casi, il formato di traffico potrebbe essere necessario solo per una singola fase della pipeline:

• Limitazione del numero di worker che stanno eseguendo il pull da un passaggio precedente della pipeline.
• Limitare ogni singolo lavoratore.
• Utilizzando un coordinatore del pool di worker per regolare la frequenza di elaborazione delle singole unità di lavoro, ad esempio query al secondo (QPS) o byte importati al secondo.

Implementare la limitazione di frequenza in altre aree del sistema

Per implementare il formato di traffico, puoi utilizzare i linguaggi di programmazione e i framework esistenti. Prendi in considerazione i seguenti progetti open source e soluzioni predefinite:

• Limitazione lato client in Apache Beam. Consulta Scalabilità automatica orizzontale per informazioni su come controllare la limitazione utilizzando i flag numWorkers e maxNumWorkers.

• La classe Java RateLimiter del set di librerie Java di base di Google Guava.

• Il modulo ratelimiter di Python.

Per il controllo del flusso, utilizza la libreria client di alto livello Pub/Sub.

Scegliere tra l'elaborazione asincrona e quella sincrona

Un livello proxy lato client che aggrega le richieste all'API Cloud Healthcare, mostrato in Gestire gli errori in più livelli, può anche controllare la limitazione tra i servizi che utilizzano l'API Cloud Healthcare. A seconda del tipo di formato di traffico richiesto, utilizza una di queste opzioni:

Asincrona

Usa l'elaborazione asincrona per inserire in coda le richieste e controllare i worker. Un livello proxy scrive le richieste in entrata nella coda e restituisce le risposte 200 OK dopo che ogni richiesta è stata messa in coda. Questo funziona meglio per le richieste di scrittura, ma può essere utilizzato per le richieste di lettura in un framework LRO se i client possono ricevere risultati di lettura.

Sincrona

L'elaborazione sincrona fornisce un semplice meccanismo di feedback se un'unità di lavoro dipende dal completamento di un'unità precedente. Un livello proxy ritarda le richieste in uscita in base ai limiti di velocità effettiva di QPS o byte e il client blocca e attende la risposta del livello proxy.

Il livello proxy può regolare la limitazione di frequenza in base al numero di istanze oppure può coordinarsi con un processo controller che regola il limite di frequenza a intervalli di pochi secondi. Affinché il livello proxy tenga traccia del numero di istanze e dei relativi limiti di frequenza, ogni istanza proxy può leggere regolarmente un file o effettuare una chiamata di procedura remota (RPC) con i limiti di frequenza codificati.

A volte l'elaborazione sincrona presenta i seguenti svantaggi:

• Le risorse nei livelli client e proxy non sono disponibili mentre il client blocca e attende una risposta. Questo può causare errori, timeout e una riduzione della velocità effettiva dei dati, con una conseguente complessità di scalabilità.

• Se il livello client e il livello proxy si disconnettono, è necessario ulteriore lavoro per verificare che i dati siano stati modificati come richiesto.

Utilizzo di Cloud Tasks

Utilizza Cloud Tasks per trasferire le richieste in una coda. Cloud Tasks imposta e monitora automaticamente le seguenti quote di Google Cloud:

• Dimensione massima del burst e massima contemporaneità delle richieste utilizzando l'oggetto RateLimits
• Puoi limitare nuovamente i tentativi utilizzando l'oggetto RetryConfig

Consulta Creare code per creare code in Cloud Tasks. La risorsa Queue mostra le opzioni che puoi impostare su una coda. Ad esempio, puoi utilizzare l'oggetto RetryConfig per implementare il backoff esponenziale. Consulta le librerie client di Cloud Tasks per le librerie specifiche per i linguaggi.

Quando utilizzi Cloud Tasks, considera quanto segue:

• Cloud Tasks non garantisce la consegna "exactly-once". Nella consegna "exactly-once", tutte le richieste contenenti dati duplicati vengono riconosciute come duplicati e ignorate dal server. Per maggiori informazioni, consulta After Lambda: Exact Once Processing in Dataflow, Parte 1.
• La dimensione massima dell'attività potrebbe essere molto inferiore alla dimensione massima del bundle FHIR nell'API Cloud Healthcare. Per ulteriori informazioni, consulta Quote e limiti di Cloud Tasks e Quote e limiti dell'API Cloud Healthcare.
• Cloud Tasks presenta problemi e limitazioni.

Combina i bundle FHIR con i limitatori di frequenza

Il tentativo di riprovare con i bundle FHIR con backoff esponenziale e i limitatori di frequenza aiuta a mantenere una velocità effettiva dei dati elevata e a gestire i picchi di carico.

Un client può inviare bundle FHIR in batch e transazioni a Cloud Tasks, che invia le richieste nel bundle all'API Cloud Healthcare. Se il limitatore di frequenza è esaurito o supera la quota perché ha raggiunto la dimensione massima della coda e ha esaurito lo spazio su disco, il client può implementare il backoff esponenziale per inserire in coda i bundle.

Impedisci che la coda del limitatore di frequenza si esaurisca monitorando queste risorse:

• Quote per le operazioni FHIR nell'API Cloud Healthcare
• Quote limite di frequenza
• Errori del limitatore di frequenza

Se la coda del limitatore di frequenza è piena, il sistema deve avvisare l'utente e interrompere l'invio delle richieste da parte del client.

Utilizza connessioni HTTP permanenti (keep-alive riutilizzabile)

Per impostazione predefinita, l'API Cloud Healthcare apre una nuova connessione TCP per ogni richiesta CRUD. Ciò richiede un handshake TCP, che può causare overhead e compromettere le prestazioni. Per migliorare le prestazioni, utilizza il keep-alive HTTP per mantenere aperta la connessione TCP per più richieste.

Per utilizzare il keep-alive HTTP in HTTP/1.1, imposta l'intestazione Connection su keep-alive:

Connection: keep-alive

HTTP/2 utilizza una connessione TCP per le richieste sequenziali e in parallelo, evitando automaticamente l'overhead.

La libreria Python requests utilizza il keep-alive HTTP per impostazione predefinita. Se utilizzi Node.js, imposta keepAlive su true quando crei un oggetto http.Agent, quindi passa l'oggetto nella richiesta.

Utilizzare un framework di test

Un framework di test garantisce che il codice funzioni e ti aiuta a:

• Prepararsi a picchi di traffico improvvisi in un'applicazione o una pipeline.
• Verifica se il backoff esponenziale e la limitazione di frequenza lato client migliorano le prestazioni. I test possono mostrare se queste implementazioni creano un arretrato di attività da gestire separatamente.
• Separa e controlla il traffico ad alta priorità. Ad esempio, se un utente sta aspettando una risposta, il carico di lavoro sulle attività di elaborazione in background può essere ridotto per garantire che l'esperienza utente non venga ridotta.
• Testa le strategie di coda sincrone e asincrone per regolare il flusso di traffico o verifica se il livello proxy gestisce il pushback.
• Pianifica il ripristino di emergenza. In genere, questa operazione richiede la reimpostazione del traffico in entrata o l'utilizzo di code per riprendere il traffico al termine dell'emergenza.

Usa Cloud Monitoring

Utilizza Cloud Monitoring per monitorare gli ambienti di test e produzione. Segui questi consigli:

• Integrare Cloud Tasks con altri servizi di logging e monitoraggio di Google Cloud, come Cloud Audit Logs.
• Crea metriche personalizzate con l'API Cloud Monitoring per tenere traccia di metriche chiave come nuovi tentativi, dimensioni delle code ed età della coda.
• Crea obiettivi del livello del servizio (SLO) e indicatori del livello del servizio (SLI) per i tuoi ambienti. Per suggerimenti, consulta Introduzione agli SLI.
• Crea criteri di avviso utilizzando l'osservabilità di Google Cloud. I criteri di avviso ti informano di problemi, ad esempio se il sistema è sotto stress o se richiede un intervento umano.
• Creare playbook operativi in modo che gli amministratori di sistema sappiano cosa fare se un criterio di avviso invia una notifica.

• Utilizza i playbook operativi in un ambiente di gestione temporanea per rispondere ai seguenti scenari:

  • Backlog causati dalla limitazione di frequenza
  • Respingimento causato dal superamento dei limiti di quota
  • Picchi di traffico in entrata

Impedisci 429 Resource Exhausted operation_too_costly di errori

Effettuare migliaia di aggiornamenti paralleli ogni giorno a una risorsa FHIR può causare contese dei blocchi, latenza e impedisce il completamento delle transazioni. Le transazioni che non possono essere completate possono creare un arretrato di 429 Resource Exhausted operation_too_costly errori:

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

Nell'errore, "costo" si riferisce all'utilizzo delle risorse e alla velocità effettiva dei dati, non ai costi di fatturazione.

Un errore 429 Too Many Requests non sempre indica un problema di quota. L'errore può verificarsi quando il server FHIR dell'API Cloud Healthcare rileva un conflitto eccessivo di blocchi sui record del database. Ciò può accadere a causa di molte operazioni in un bundle FHIR o di una combinazione di operazioni CRUD.

Considera il seguente scenario:

1. Un bundle di transazioni FHIR che aggiorna una risorsa Patient e altre risorse FHIR blocca la risorsa Patient fino al termine della transazione.

2. Più bundle FHIR provano ad aggiornare la risorsa Patient in parallelo e si verifica la contesa del blocco. Le risposte di errore includono un campo diagnostics con il testo Resource type: PATIENT.

   Puoi riprovare ad aggiornare la risorsa Paziente con backoff esponenziale, ma periodi più lunghi in contesa dei blocchi possono portare a timeout, velocità effettiva ridotta e aumento dell'utilizzo delle risorse.

3. Il server FHIR dell'API Cloud Healthcare alla fine rileva un backlog di transazioni e dipartimenti di carico restituendo errori operation_too_costly. In questo modo si limita il traffico e si evitano ulteriori errori.

   Gli errori operation_too_costly limitano tutte le operazioni CRUD FHIR nel tuo progetto Google Cloud, interessando tutte le applicazioni connesse al progetto.

Risolvi 429 Too Many Requests di errori

Per risolvere gli errori relativi a 429 Too Many Requests, cerca in Cloud Logging. Gli errori contenenti operation_too_costly indicano una contesa del blocco. Se gli errori sono causati dall'esaurimento di risorse, verifica la presenza di problemi di quota.

Se si verifica una limitazione, i bundle di transazioni potrebbero non riuscire a causa di livelli elevati di contesa dei blocchi e generare il seguente errore:

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

Per risolvere l'errore, vai al link Bundle transazionale FHIR interrotto a causa di un carico elevato cumulativo nel campo diagnostics.

Evita pacchetti di grandi dimensioni

L'errore 429 Too Many Requests è più probabile con pacchetti di transazioni di grandi dimensioni. I pacchetti di qualsiasi dimensione possono creare colli di bottiglia della velocità effettiva. Prova diversi pacchetti per trovare la dimensione ottimale.

I bundle di grandi dimensioni con nuovi tentativi possono avere ritorni in termini di prestazioni inferiori ed sono più soggetti ad avere più errori. I client dovrebbero implementare una logica aggiuntiva per gestire il sottoinsieme di risorse FHIR che non hanno superato una transazione.

I bundle batch possono presentare errori 429 Too Many Requests e 413 Request Entity Too Large e colli di bottiglia della velocità effettiva se sono di grandi dimensioni o hanno un valore QPS elevato.

Evita di utilizzare grandi pacchetti con migliaia di transazioni. Procedi invece nel seguente modo:

• Utilizza pacchetti di transazioni più piccoli che supportano la coerenza dei dati. Se le risorse FHIR non dipendono l'una dall'altra, aggiornale separatamente. Ad esempio, una risorsa FHIR potrebbe non dipendere dalla versione specifica di un'altra risorsa nello stesso bundle.
• Usane alcune per creare pacchetti ed evita richieste singole. Il batch può migliorare le prestazioni, ma batch di grandi dimensioni possono causare errori e ridurre la velocità effettiva dei dati. I bundle batch di dimensioni simili hanno meno contese perché non mantengono i blocchi negli aggiornamenti delle risorse FHIR.

I pacchetti di transazioni di piccole dimensioni evitano i conflitti perché prevedono solo alcuni blocchi alla volta e terminano rapidamente. Ciò aiuta a evitare un backlog di transazioni in pila.

Velocità effettiva LRO

Vedi Velocità effettiva dei dati LRO.

Opzioni di archiviazione dati FHIR

Se il volume di dati FHIR è da piccolo a moderato, utilizza fhir.create per archiviare i dati. Per archiviare grandi volumi di risorse FHIR, utilizza fhir.executeBundle o fhirStores.import. Per informazioni su ciascun metodo, consulta le opzioni di importazione di FHIR.

Importa risorse FHIR

Tieni presente quanto segue quando decidi se utilizzare l'importazione FHIR:

• L'importazione FHIR non limita le dimensioni totali dei dati che importa. Se un bundle FHIR supera i 50 MB, puoi caricare le risorse FHIR in Cloud Storage e importarle. Evita importazioni simultanee ad alta latenza o di grandi dimensioni, altrimenti la velocità effettiva dei dati potrebbe essere limitata.

• L'importazione FHIR ha meno complessità rispetto all'utilizzo dei bundle FHIR. Ad esempio, non è necessario che tu esegua le seguenti operazioni:

  • Esegui il partizionamento dei bundle di grandi dimensioni in pacchetti più piccoli
  • Gestisci pianificazioni
  • Riprova gli errori temporanei a livello di risorsa o bundle

• L'importazione FHIR non applica l'integrità referenziale. Per ulteriori informazioni, consulta la pagina relativa all'integrità referenziale di FHIR.

• Non utilizzare l'importazione FHIR quando l'aggiornamento dei dati è una priorità elevata. Le importazioni possono essere rapide, ma potrebbero subire ritardi di ore o giorni.

• Le importazioni FHIR funzionano meglio quando sono presenti pochi LRO nel tuo progetto Google Cloud.

• L'importazione FHIR può raggiungere una velocità effettiva dei dati elevata se l'applicazione è in grado di gestire errori e errori collettivi su un sottoinsieme di risorse.

Usa bundle FHIR

Utilizza i bundle FHIR invece dell'importazione FHIR nei seguenti casi:

• È troppo costoso, sia in termini di costi di fatturazione che di larghezza di banda, creare una pipeline per archiviare i dati in Cloud Storage e importarli.

• Deve essere applicata l'integrità referenziale.

• È necessario applicare la convalida del profilo FHIR.

• Devi inviare notifiche Pub/Sub quando vengono archiviate le risorse FHIR. L'importazione FHIR non supporta le notifiche Pub/Sub.

• L'aggiornamento dei dati è una priorità e i dati devono essere importati in pochi secondi o minuti. Tuttavia, anche in un sistema ben progettato, la velocità effettiva dei dati può essere limitata da quanto segue:

  • Ritardi upstream nelle pipeline di elaborazione. Le pipeline potrebbero richiedere più tempo per preparare i dati prima di poterli importare.
  • Backoff, nuovi tentativi e livelli proxy di modellazione del traffico.

I bundle FHIR hanno le seguenti limitazioni:

• Quota e fatturazione vengono applicate a ogni operazione nel bundle come se ogni operazione fosse eseguita in modo indipendente. Ad esempio, se un bundle presenta 10 operazioni POST, 5 operazioni GET e 1 operazione DELETE, la quota e la fatturazione applicate al bundle corrispondono a quelle applicate in modo indipendente.

• I pacchetti di transazioni di grandi dimensioni hanno maggiori probabilità di avere conflitti di transazioni che comportano il blocco dei conflitti. Per maggiori informazioni, vedi Evitare errori relativi a 429 Resource Exhausted operation_too_costly.

• I bundle batch possono migliorare la velocità effettiva dei dati, ma non hanno funzionalità di coerenza transazionale come l'integrità referenziale.

• I bundle batch di grandi dimensioni possono avere una velocità effettiva ridotta. Per ulteriori informazioni, consulta l'articolo Evitare pacchetti di grandi dimensioni.

Opzioni di archiviazione dei dati DICOM

Puoi utilizzare i seguenti metodi per ottenere una velocità effettiva elevata dei dati durante l'invio di dati da un sistema di archiviazione e comunicazione immagini (PACS) all'API Cloud Healthcare:

L'adattatore DICOM dell'API Cloud Healthcare open source che utilizza il protocollo DICOM Message Service Element (DIMSE).

L'adattatore ottimizza la velocità effettiva dei dati quando sincronizzi un PACS con l'API Cloud Healthcare. Prima di eseguire la sincronizzazione, esegui test delle prestazioni e verifica che l'adattatore possa sostenere la velocità effettiva dei dati massima.

Utilizza questo adattatore se non riesci a caricare i file DICOM in Cloud Storage utilizzando Storage Transfer Service o un'altra opzione di trasferimento. Ad esempio, potresti non essere in grado di soddisfare i seguenti requisiti di Storage Transfer Service:

• Montare un file system su ogni macchina che ospita agenti nel tuo pool di agenti per recuperare i dati di origine.
• Se trasferisci i dati a intervalli regolari anziché un caricamento batch una tantum, devi misurare le modifiche apportate alle dimensioni dei dati nel tempo per determinare cosa è cambiato.
• Massimizza le prestazioni dei trasferimenti degli agenti.
• Pagamento e allocazione dello spazio di archiviazione in Cloud Storage.
• Convalida dei trasferimenti di dati a Cloud Storage.
• Rimuovi le risorse di Cloud Storage dopo aver importato i dati nell'API Cloud Healthcare e correggi eventuali errori di importazione.
• Pianificazione degli intervalli di importazione dei batch in base alla rete e alla capacità di archiviazione del sistema clinico.

Ti consigliamo di utilizzare Storage Transfer Service per un singolo caricamento batch per completare un archivio DICOM. L'utilizzo regolare di Storage Transfer Service richiede attività aggiuntive, ad esempio una pipeline di importazione sincrona. Per ulteriori informazioni, consulta Dettagli per il trasferimento del file system di Storage Transfer Service.

dicomStores.import

Utilizza questo metodo per archiviare grandi volumi di dati DICOM.

Transazione negozio DICOMweb

Utilizza questo metodo per archiviare i dati DICOM in modo programmatico.

Gestisci la quota per ottimizzare la velocità effettiva dei dati

Le seguenti sezioni descrivono come gestire e pianificare la quota per ottimizzare la velocità effettiva dei dati. Per le best practice generali sulla gestione delle quote, consulta Best practice per la gestione delle quote.

Quota del piano per il traffico prevedibile

Pianifica i tuoi requisiti di quota analizzando prima il traffico giornaliero tipico della tua applicazione client. Anche se il traffico è prevedibile, pianifica una quota superiore a quella necessaria in media. In questo modo puoi evitare errori e offrire un margine di sicurezza contro picchi di traffico o aumenti occasionali nell'uso quotidiano.

Il seguente diagramma mostra le richieste all'API Cloud Healthcare che sono coerenti per dimensioni e inviate in pattern prevedibili:

Figura 1. Il carico orario aggregato delle API nei set di dati e nei datastore di un progetto Google Cloud.

Quota del piano per richieste di volumi elevati

Evita di pianificare job batch di grandi dimensioni durante le ore di picco. Per saperne di più, consulta Favorire regolarmente transazioni a basso volume.

Il seguente diagramma mostra un modello di traffico prevedibile. Tuttavia, una richiesta batch di grandi volumi durante un periodo di traffico di picco supera la quota disponibile. Questo può causare errori 429 Resource Exhausted per tutte le richieste nel progetto.

Figura 2. Una distribuzione irregolare dell'utilizzo delle risorse causata da un job batch di grandi dimensioni durante le ore di punta.

Se il sistema dispone di una quota di flessibilità aggiuntiva, piccoli picchi di traffico non causano errori né causeranno picchi prevedibili dei carichi di lavoro. I piccoli picchi devono essere distribuiti tra molti datastore, applicazioni e altri client che generano carico all'interno del progetto Google Cloud.

Per evitare che un singolo job batch di grandi dimensioni provochi picchi di traffico, consulta Evitare pacchetti di grandi dimensioni.

Richiedi quota aggiuntiva

Per mantenere una velocità effettiva dei dati elevata ed evitare errori 429 Resource Exhausted, consulta le best practice in questa pagina, in particolare Gestisci la quota per ottimizzare la velocità effettiva dei dati. Queste best practice assicurano che la tua applicazione client sia solida e possa scalare in base alle modifiche del volume di richieste. È improbabile che richiedere una quota aggiuntiva senza implementare le best practice per evitare errori a lungo termine.

Se implementi le best practice, ma hai comunque bisogno di una quota maggiore, consulta Best practice per richiedere una quota aggiuntiva.

Risorse relative alla velocità effettiva di importazione dati

Per ulteriori informazioni sulla velocità effettiva di importazione dati, consulta Gestire il traffico e il carico per i tuoi carichi di lavoro in Google Cloud.