Best practice per il throughput di importazione dei dati

Questa pagina descrive le best practice per ottimizzare il throughput dei dati durante l'importazione dei dati nell'API Cloud Healthcare. Questi consigli sono rivolti a professionisti tecnici con esperienza nella gestione del throughput dei dati per sistemi di grandi dimensioni.

Velocità in Mbps

Il throughput dei dati è la quantità di risorse, ad esempio risorse FHIR o istanze DICOM, o byte che l'API Cloud Healthcare acquisisce ogni secondo.

Limiti di throughput dei dati

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

• Non hai previsto 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 breve tempo.
• Più transazioni simultanee modificano la stessa risorsa dell'API Cloud Healthcare, causando contese sui dati.
• Vengono effettuate troppe piccole richieste. Per ulteriori informazioni, consulta la sezione Evitare richieste di importazione ed esportazione di piccole dimensioni.
• Troppe operazioni a lunga esecuzione (LRO) vengono eseguite contemporaneamente e la larghezza di banda è limitata.
• Sono pianificate troppe richieste LRO contemporaneamente, il che causa errori.

Ritenta le richieste non riuscite

Se un client ritenta rapidamente e ripetutamente 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 jitter e code di nuovi tentativi permanenti

Il backoff esponenziale con jitter introdotto è una strategia di gestione degli errori standard per le applicazioni di rete. Un client riprova periodicamente le richieste non riuscite con ritardi esponenzialmente crescenti tra un nuovo tentativo e l'altro e un piccolo ritardo casuale.

Assicurati che l'implementazione del backoff esponenziale sia idempotente per ogni nuovo tentativo, in particolare se utilizzi una logica personalizzata per bypassare le condizioni di errore. Per ulteriori informazioni, consulta la sezione 9.2.2 Metodi idempotenti nelle specifiche HTTP.

La maggior parte dei linguaggi di programmazione offre librerie per semplificare l'implementazione del backoff esponenziale e di strategie di ripetizione simili. Per i tentativi di più processi o a lungo termine, implementa una coda di ripetizione permanente. Questa coda può reimpostare il meccanismo di ripetizione se superi il tempo di backoff massimo.

Utilizza il backoff esponenziale quando esegui nuovamente queste richieste:

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

• Richieste LRO sincrone. Riprova se si verifica un errore all'avvio dell'LRO o se l'LRO non va a buon fine.

  Gli LRO presentano errori unici che potrebbero richiedere l'implementazione delle seguenti strategie di ripetizione:

  • Utilizza un bundle separato per archiviare i dati per i quali non è riuscita un'operazione di importazione o creazione.
  • Utilizza le richieste sincrone per i dati di cui non è stato possibile completare l'elaborazione.

Esempio di algoritmo di backoff esponenziale

Un algoritmo di backoff esponenziale riprova le richieste in modo esponenziale, aumentando il tempo di attesa tra i tentativi fino a un tempo di backoff massimo. Il seguente algoritmo implementa il backoff esponenziale troncato con jitter:

1. Invia una richiesta all'API Cloud Healthcare.

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

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

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

5. Continua questo schema, aspettando 2ⁿ + random-fraction secondi dopo ogni tentativo, fino a un massimo di maximum-backoff volte.

6. Dopo deadline secondi, interrompi la ripetizione della richiesta.

Utilizza i seguenti valori durante 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 minore o uguale a 1. Utilizza un valore diverso per ogni nuovo tentativo. L'aggiunta di questo valore casuale impedisce ai client di essere sincronizzati e di inviare molti tentativi di nuovo allo stesso tempo.

• Sostituisci maximum-backoff con il tempo massimo, in secondi, da attendere 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 i tentativi. Scegli un valore che rifletta il tuo caso d'uso.

Il client può riprovare dopo aver raggiunto il tempo maximum-backoff utilizzando lo stesso valore del backoff. Ad esempio, se il tempo 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 la definizione del profilo del traffico

Il limite di frequenza protegge i sistemi su larga scala impedendo che vengano sopraffatti da richieste eccessive. Se limitazione di frequenza lato client non è sufficiente, il sistema di quote dell'API Cloud Healthcare potrebbe limitare il throughput dei dati. Per ulteriori informazioni, consulta Best practice per la gestione delle quote.

Se hai requisiti aggiuntivi, come l'invio garantito durante i tentativi di invio, le strategie in Riprova le richieste non riuscite potrebbero non essere sufficienti. La modulazione del 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 su ore o minuti, migliorando il throughput. Quando la quota è limitata, la definizione del profilo del traffico può raggiungere un throughput più elevato rispetto all'utilizzo dei soli tentativi di nuovo invio perché evita il pushback e monitora le unità di lavoro.

Puoi implementare la definizione del profilo del traffico per le operazioni sincrone di creazione, eliminazione, aggiornamento ed eliminazione (CRUD), tra cui fhir.executeBundle.

Requisiti per la definizione del profilo del traffico

Per implementare la definizione del profilo del traffico, il sistema deve implementare quanto segue:

• Una coda di elaborazione basata su archiviazione con ridondanza per evitare guasti del disco.
• Lavoratori coordinati per estrarre dalla coda di elaborazione.
• Rilevamento dell'utilizzo complessivo per regolare il numero di worker e la relativa velocità di elaborazione in base ai limiti di quota.
• Ripristino di emergenza per la coda di elaborazione basata su archiviazione. In caso di disastro, il sistema deve essere in grado di eliminare o recuperare la coda.
• Ridotti i LRO durante le ore di punta. Per ulteriori informazioni, consulta Pianificare e utilizzare la quota in modo efficiente e Formare una coda e gestire le richieste di operazione di lettura.

Nei seguenti casi, la definizione del traffico potrebbe essere necessaria solo per un singolo livello della pipeline:

• Limitare il numero di worker che estraggono da un passaggio della pipeline precedente.
• Limitare ciascun worker singolarmente.
• Utilizzo di un coordinatore del pool di worker per regolare la frequenza con cui vengono elaborate le singole unità di lavoro, ad esempio query al secondo (QPS) o byte importati al secondo.

Implementare il limitazione di frequenza in altre aree del sistema

Puoi utilizzare framework e linguaggi di programmazione esistenti per implementare la gestione del traffico. Valuta i seguenti progetti open source e soluzioni predefinite:

• Ritardo lato client in Apache Beam. Consulta la sezione 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 Python ratelimiter.

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

Scegli tra elaborazione asincrona e sincrona

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

Asincrona

Utilizza l'elaborazione asincrona per mettere in coda le richieste e controllare i worker. Un livello proxy scrive le richieste in arrivo nella coda e restituisce le risposte 200 OK dopo che ogni richiesta è stata messa in coda. Questo approccio è ideale per le richieste di scrittura, ma può essere utilizzato anche per le richieste di lettura in un framework LRO se i client possono ricevere i 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 QPS o di throughput in byte e il client si blocca e attende la risposta del livello proxy.

Il livello proxy può regolare il limitazione di frequenza in base al numero di istanze oppure può coordinarsi con un processo di controllo che regola il limite di frequenza ogni pochi secondi. Affinché il livello proxy monitori il numero di istanze e i relativi limiti di frequenza, ogni istanza proxy può leggere regolarmente un file o eseguire una chiamata di procedura remota (RPC) con i limiti di frequenza codificati.

L'elaborazione sincrona a volte presenta i seguenti svantaggi:

• Le risorse nei livelli client e proxy non sono disponibili mentre il client si blocca e attende una risposta. Ciò può comportare errori, timeout e una minore throughput dei dati, rendendo più difficile la scalabilità.

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

Utilizzo di Cloud Tasks

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

• Dimensione massima burst e concorrenza massima delle richieste utilizzando l'oggetto RateLimits
• Limiti di ripetizione utilizzando l'oggetto RetryConfig

Consulta Creare code per creare le code in Cloud Tasks. La risorsa Queue mostra le opzioni che puoi impostare in 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 vari linguaggi.

Quando utilizzi Cloud Tasks, tieni presente quanto segue:

• Cloud Tasks non garantisce la consegna "exactly-once". Nella pubblicazione esattamente una volta, tutte le richieste contenenti dati duplicati vengono riconosciute come duplicate e ignorate dal server. Per ulteriori informazioni, consulta Dopo Lambda: elaborazione exactly-once 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.

Combinare i bundle FHIR con i limitatori di frequenza

La ripetizione dei bundle FHIR con backoff esponenziale e limitatori di frequenza contribuisce a mantenere un'elevata velocità in termini di dati e a gestire i picchi di carico.

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

Per evitare che la coda del limitatore di velocità si riempia, monitora queste risorse:

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

Se la coda del limitatore di velocità si riempie, il sistema deve avvisare un utente e impedire al client di inviare richieste.

Utilizzare le connessioni HTTP permanenti (keep-alive riutilizzabili)

Per impostazione predefinita, l'API Cloud Healthcare apre una nuova connessione TCP per ogni richiesta CRUD. Ciò richiede un handshake TCP, che può causare un sovraccarico e peggiorare 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 simultanee, che evita 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 e poi passalo nella richiesta.

Utilizzare un framework di test

Un framework di test garantisce il funzionamento del codice e ti aiuta a:

• Preparati a picchi di traffico improvvisi in un'applicazione o in una pipeline.
• Verifica se il backoff esponenziale e il limite di frequenza lato client migliorano il rendimento. I test possono mostrare se queste implementazioni creano un backlog di attività che devono essere gestite separatamente.
• Separa e controlla il traffico ad alta priorità. Ad esempio, se un utente è in attesa di una risposta, il carico di lavoro delle attività di elaborazione in background può essere ridotto per garantire che l'esperienza utente non venga degradata.
• Testa le strategie di coda sincrone e asincrone per regolare il flusso di traffico oppure verifica se il livello proxy gestisce il pushback.
• Pianifica il ripristino di emergenza. In genere, è necessario reimpostare il traffico in entrata o utilizzare le code per riprendere il traffico al termine dell'evento catastrofico.

Usa Cloud Monitoring

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

• Integra 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 monitorare metriche chiave come i tentativi di nuovo invio, le dimensioni delle code e la loro età.
• Crea obiettivi del livello di servizio (SLO) e indicatori del livello del servizio (SLI) per i tuoi ambienti. Per i consigli, consulta Introduzione agli SLI.
• Crea criteri di avviso utilizzando Google Cloud Observability. I criteri di avviso ti avvisano di problemi come un sistema sotto stress o che richiede intervento umano.
• Crea 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 staging per rispondere ai seguenti scenari:

  • Code causate dalla limitazione di frequenza
  • Pushback causato dal superamento dei limiti di quota
  • Picchi di traffico in entrata

Evitare errori 429 Resource Exhausted operation_too_costly

Eseguire migliaia di aggiornamenti paralleli ogni giorno a una risorsa FHIR può causare competizione per i blocchi, latenza e impedire il completamento delle transazioni. Le transazioni che non possono essere completate possono creare un backlog di errori 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"
}

Nell'errore, "costo" si riferisce all'utilizzo delle risorse e al throughput dei dati, non ai costi di fatturazione.

Un errore 429 Too Many Requests non indica sempre un problema con la quota. L'errore può verificarsi quando il server FHIR dell'API Cloud Healthcare rileva una contesa eccessiva dei blocchi sui record del database. Questo 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 tentano di aggiornare la risorsa Patient in parallelo e si verifica una contesa per i blocchi. Le risposte con errori includono un campo diagnostics con il testo Resource type: PATIENT.

   Puoi riprovare ad aggiornare la risorsa Patient con il backoff esponenziale, ma periodi di contesa lunghi possono causare timeout, riduzione del throughput e aumento dell'utilizzo delle risorse.

3. Il server FHIR dell'API Cloud Healthcare rileva infine un backlog di transazioni e riduce il carico restituendo errori operation_too_costly. In questo modo, il traffico viene limitato ed è possibile evitare ulteriori errori.

   Gli errori operation_too_costly riducono la velocità di tutte le operazioni CRUD FHIR nel tuo progetto Google Cloud, il che influisce su tutte le applicazioni collegate al progetto.

Risolvere gli errori 429 Too Many Requests

Per risolvere i problemi relativi agli errori 429 Too Many Requests, cerca in Cloud Logging. Gli errori contenenti operation_too_costly indicano una contesa per i blocchi. Se gli errori sono causati dall'esaurimento delle risorse, controlla se ci sono problemi di quota.

Se si verifica il throttling, i pacchetti di transazioni potrebbero non riuscire a causa di livelli elevati di contesa per i 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 FHIR transactional bundle aborted due to cumulative heavy load nel campo diagnostics.

Evita pacchetti di grandi dimensioni

L'errore 429 Too Many Requests è più probabile con set di transazioni di grandi dimensioni. I set di qualsiasi dimensione possono creare colli di bottiglia nel throughput. Prova diversi set per trovare la dimensione ottimale.

I set di pacchetti di grandi dimensioni con i tentativi di nuovo invio possono avere un rendimento decrescente e sono più soggetti a più errori. I client devono implementare una logica aggiuntiva per gestire il sottoinsieme di risorse FHIR che non è riuscito in una transazione.

I pacchetti batch possono generare errori 429 Too Many Requests e 413 Request Entity Too Large e colli di bottiglia del throughput se sono di grandi dimensioni o hanno un QPS elevato.

Evita di utilizzare pacchetti di grandi dimensioni 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.
• Utilizza il raggruppamento in pacchetti ed evita le richieste individuali. L'aggregazione può migliorare le prestazioni, ma i batch di grandi dimensioni possono causare errori e ridurre la velocità in bit dei dati. I batch bundle di dimensioni simili hanno meno conflitti perché non mantengono i blocchi tra gli aggiornamenti delle risorse FHIR.

I piccoli pacchetti di transazioni evitano le contese perché mantengono solo alcune serrature contemporaneamente e terminano rapidamente. In questo modo si evita un accumulo di transazioni.

Velocità effettiva LRO

Consulta Throughput dei dati LRO.

Opzioni di archiviazione dei dati FHIR

Se il volume dei dati FHIR è ridotto o 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 Opzioni di importazione FHIR.

Importa risorse FHIR

Quando decidi se utilizzare l'importazione FHIR, tieni presente quanto segue:

• 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 su Cloud Storage e importarle. Evita importazioni contemporaneamente di grandi dimensioni o con latenza elevata, altrimenti la velocità in bit dei dati potrebbe essere limitata.

• L'importazione FHIR è meno complessa rispetto all'utilizzo dei bundle FHIR. Ad esempio, non devi fare quanto segue:

  • Suddividi i bundle di grandi dimensioni in altri più piccoli
  • Gestisci pianificazioni
  • Riprovare in caso di errori temporanei a livello di risorsa o bundle

• L'importazione FHIR non applica l'integrità referenziale. Per ulteriori informazioni, consulta la sezione Integrità referenziale FHIR.

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

• Le importazioni FHIR hanno un rendimento migliore quando il progetto Google Cloud contiene pochi LRO.

• L'importazione FHIR può raggiungere un elevato throughput dei dati se la tua applicazione è in grado di gestire errori e guasti collettivi su un sottoinsieme di risorse.

Utilizzare i bundle FHIR

Utilizza i bundle FHIR anziché l'importazione FHIR nei seguenti casi:

• È troppo costoso, in termini di costi di fatturazione o larghezza di banda della rete, costruire una pipeline per archiviare i dati in Cloud Storage e importarli.

• L'integrità referenziale deve essere applicata.

• Deve essere applicata la convalida del profilo FHIR.

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

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

  • Ritardi a monte nelle pipeline di elaborazione. Le pipeline potrebbero richiedere più tempo per preparare i dati prima che possano essere importati.
  • Ritiri, tentativi di nuovo invio e livelli proxy di definizione del traffico.

I bundle FHIR presentano le seguenti limitazioni:

• La quota e la fatturazione vengono applicate a ogni operazione nel bundle come se ogni operazione fosse eseguita in modo indipendente. Ad esempio, se un bundle contiene 10 operazioni POST, 5 operazioni GET e 1 operazione DELETE, la quota e la fatturazione applicate al bundle sono le stesse che se queste operazioni fossero state eseguite in modo indipendente.

• I pacchetti di transazioni di grandi dimensioni hanno maggiori probabilità di avere conflitti di transazioni che portano a contese sui blocchi. Per ulteriori informazioni, consulta la sezione Evitare errori 429 Resource Exhausted operation_too_costly.

• I pacchetti batch possono migliorare il throughput dei dati, ma non dispongono di funzionalità di coerenza transactional come l'integrità referenziale.

• I set di batch di grandi dimensioni possono avere una maggiore latenza. Per ulteriori informazioni, consulta la sezione Evitare pacchetti di grandi dimensioni.

Opzioni di archiviazione dei dati DICOM

Puoi utilizzare i seguenti metodi per ottenere un'elevata velocità in bit dei dati quando li invii da un sistema PACS (Picture Archiving and Communication System) 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 il throughput dei dati quando sincronizzi un PACS con l'API Cloud Healthcare. Prima di eseguire la sincronizzazione, esegui test di prestazioni e verifica che l'adattatore possa supportare il picco di throughput dei dati.

Utilizza questo adattatore se non riesci a caricare i file DICOM su 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 gli agenti nel tuo pool di agenti per recuperare i dati di origine.
• Se trasferisci i dati a un intervallo regolare anziché con un caricamento collettivo una tantum, devi misurare le modifiche alle dimensioni dei dati nel tempo per determinare cosa è cambiato.
• Massimizzazione del rendimento del trasferimento dell'agente.
• Pagamento e allocazione dello spazio di archiviazione Cloud Storage.
• Convalida dei trasferimenti di dati in Cloud Storage.
• Rimuovere le risorse Cloud Storage dopo aver importato i dati nell'API Cloud Healthcare e aver corretto eventuali errori di importazione.
• Pianificazione degli intervalli di importazione collettiva in base alla rete e alla capacità di archiviazione di un sistema clinico.

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

dicomStores.import

Utilizza questo metodo per archiviare grandi volumi di dati DICOM.

Transazione dell'archivio DICOMweb

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

Gestire la quota per ottimizzare la velocità in bit dei dati

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

Pianifica la quota per il traffico prevedibile

Pianifica i requisiti di quota analizzando innanzitutto 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 avere un margine di sicurezza contro picchi di traffico o aumenti occasionali nell'utilizzo giornaliero.

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

Pianificare la quota per le richieste di grandi volumi

Evita di pianificare job batch di grandi dimensioni durante le ore di punta. Per ulteriori informazioni, consulta la sezione Favorire le transazioni a basso volume in modo coerente.

Il seguente diagramma mostra un pattern di traffico prevedibile. Tuttavia, una richiesta collettiva di volume elevato durante un periodo di picco del traffico supera la quota disponibile. Ciò può causare errori 429 Resource Exhausted per tutte le richieste nel tuo progetto.

Se il tuo sistema dispone di una quota di flessibilità aggiuntiva, i piccoli picchi di traffico non causeranno errori o causeranno errori nei picchi di carico prevedibili. I piccoli picchi devono essere distribuiti tra molti datastore, applicazioni e altri client che producono carico all'interno del progetto Google Cloud.

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

Richiedi quota aggiuntiva

Per mantenere un elevato throughput dei dati ed evitare errori 429 Resource Exhausted, consulta le best practice riportate in questa pagina, in particolare Gestire la quota per ottimizzare il throughput dei dati. Queste best practice garantiscono che l'applicazione client sia solida e possa essere scalata con le variazioni del volume delle richieste. La richiesta di una quota aggiuntiva senza l'implementazione delle best practice difficilmente impedirà gli errori nel lungo periodo.

Se implementi le best practice e hai ancora bisogno di una quota maggiore, consulta la sezione Best practice per la richiesta di quota aggiuntiva.

Risorse per il throughput di importazione dati

Per ulteriori informazioni sul throughput di importazione dati, consulta Gestire il traffico e il carico per i carichi di lavoro in Google Cloud.