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 destinati professionisti tecnici con esperienza nella gestione della velocità effettiva dei dati per sistemi su larga scala.

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.

Vincoli di velocità effettiva dei dati

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

• Non avevi pianificato richieste di volumi elevati che potessero causare picchi di traffico.
• I vincoli 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, causando contese sui dati.
• Sono state effettuate troppe richieste di piccole dimensioni. 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 pianificati troppi LRO contemporaneamente, il che genera 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 code di nuovo tremore e nuovi tentativi permanenti

Backoff esponenziale con il jitter introdotto è una strategia standard di gestione degli errori per le applicazioni di rete. Un cliente riprova periodicamente richieste non riuscite, con ritardi in aumento esponenziale tra i nuovi tentativi e un piccolo ritardo casuale.

Assicurati che l'implementazione del backoff esponenziale sia idempotente a ogni nuovo tentativo, soprattutto se utilizzi una logica personalizzata per bypassare di errore. Vedi 9.2.2 Metodi idempotenti. nella specifica 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 nuovi tentativi a lungo termine o in più processi, implementa un'impostazione permanente nuovi tentativi in coda. 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 univoci che potrebbero richiedere l'implementazione di quanto segue strategie di ripetizione:

  • Utilizza un bundle separato per archiviare i dati per i quali non è riuscita un'operazione di importazione o creazione.
  • Utilizza richieste sincrone per i dati che non è stato possibile elaborare.

Esempio di algoritmo di backoff esponenziale

Un algoritmo di backoff esponenziale prova a ripetere le richieste in modo esponenziale. aumentando il tempo di attesa tra un nuovo tentativo e l'altro fino al 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 secondi + random-fraction, quindi 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 i nuovi tentativi di richiesta.

Utilizza i seguenti valori mentre implementi l'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 diventare sincronizzati e inviare molti nuovi tentativi contemporaneamente.

• 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 nuovi tentativi. Scegli un valore che rifletta il tuo caso d'uso.

Il cliente può riprovare dopo aver raggiunto maximum-backoff volta utilizzando lo stesso come 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 il formato di traffico

La limitazione di frequenza protegge i sistemi su larga scala impedendo loro di essere dovuto a un numero eccessivo di richieste. Se la limitazione di frequenza lato client non è sufficiente, il sistema delle quote dell'API Cloud Healthcare potrebbe limitare la velocità effettiva 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. Formato di traffico è una tecnica di limitazione della frequenza che mantiene la frequenza delle richieste lato client entro i vincoli della 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 di creazione, eliminazione, aggiornamento ed eliminazione (CRUD) sincrone, tra cui fhir.executeBundle.

Requisiti per il formato di 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 velocità di elaborazione in base ai limiti di quota.
• Ripristino di emergenza per lo spazio di archiviazione di elaborazione. In caso di emergenza, il sistema deve essere in grado di eseguire l'eliminazione definitiva o il ripristino in coda.
• Riduzione degli LRO nelle 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, il formato di traffico potrebbe essere necessario solo per una singola fase della pipeline:

• Limitare il numero di worker che estraggono da un passaggio della pipeline precedente.
• Limitazione di ogni singolo worker.
• 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 limite di frequenza in altre aree del sistema

Puoi utilizzare linguaggi di programmazione e framework esistenti per implementare il traffico la modellazione. Considera i seguenti progetti open source e predefiniti di Google Cloud:

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

• 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 di alto livello Pub/Sub.

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 delle seguenti 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 limite di velocità in base al numero di istanze oppure può coordinarsi con un processo di controllo che regola il limite di velocità ogni pochi secondi. Per il livello proxy per tenere traccia del numero di istanze e della loro tariffa limiti, ogni istanza proxy può leggere regolarmente un file o creare di procedura (RPC) con i limiti di frequenza codificati.

L'elaborazione sincrona a volte presenta i seguenti svantaggi:

• Risorse nel client e i livelli proxy non sono disponibili mentre il client blocca attende una risposta. Questo può causare errori, timeout e una riduzione dei dati rendendola più difficile da scalare.

• 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 eseguire l'offload richieste a una coda. Cloud Tasks imposta e monitora automaticamente le seguenti quote di Google Cloud:

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

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

Quando utilizzi Cloud Tasks, considera quanto segue:

• Cloud Tasks non garantisce la consegna "exactly-once". In una sola volta nella consegna, tutte le richieste contenenti dati duplicati vengono riconosciute come duplicate e ignorati dal server. Per ulteriori informazioni, consulta Dopo Lambda: elaborazione exactly-once in Dataflow, Parte 1.
• La dimensione massima dell'attività potrebbe essere molto inferiore a quella massima del bundle FHIR nell'API Cloud Healthcare. Per saperne di più, 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

Il riavvio 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 in batch e di transazioni a Cloud Tasks, che invia le richieste nel bundle all'API Cloud Healthcare. Se il limitatore di frequenza è al massimo 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 accodare i bundle.

Per evitare che la coda del limitatore di frequenza 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.

Utilizzo di connessioni HTTP permanenti (keep-alive riutilizzabile)

Per impostazione predefinita, l'API Cloud Healthcare apre una nuova connessione TCP Richiesta CRUD. Ciò richiede handshake TCP, il che può causare overhead e peggiorare le prestazioni. Per migliorare le prestazioni, utilizza Keep-alive HTTP per tenere la connessione TCP aperta per più richieste.

Per utilizzare 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 evitando così 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 che il codice funzioni e ti consente di:

• 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.
• Testare le strategie di accodamento sincrone e asincrone per regolare il flusso di traffico o verifica se il livello proxy gestisce il pushback.
• Pianifica il ripristino di emergenza. Questa operazione richiede in genere la reimpostazione dei dati traffico o utilizzo delle code per riprendere traffico al termine della catastrofe.

Usa Cloud Monitoring

Utilizza Cloud Monitoring per monitorare il test e ambienti 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à.
• Creare obiettivi del livello di servizio (SLO) e gli indicatori del livello del servizio (SLI) per i tuoi ambienti. Consulta: Introduzione agli SLI per ricevere consigli.
• 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.

• Utilizzare i playbook operativi in un ambiente di gestione temporanea per rispondere alle i seguenti scenari:

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

Evita 429 Resource Exhausted operation_too_costly errori

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 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. La un errore può verificarsi quando il server FHIR dell'API Cloud Healthcare rileva un blocco eccessivo sui record dei 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 Pazient 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 Paziente con backoff esponenziale, ma lunghi periodi di contesa del blocco possono portare a timeout, a una velocità effettiva ridotta e di utilizzo delle risorse.

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

   Gli errori operation_too_costly limitano tutte le operazioni FHIR CRUD nel tuo progetto Google Cloud, che interessa tutte le applicazioni collegate al tuo progetto.

Risolvere gli errori 429 Too Many Requests

Per risolvere gli 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.

In caso di limitazione, i pacchetti di transazioni potrebbero non riuscire a causa di livelli elevati della contesa del blocco e producono 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 pacchetto 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 set di transazioni di grandi dimensioni. I set di qualsiasi dimensione possono creare colli di bottiglia nel throughput. Testa diverse pacchetti per trovare la dimensione ottimale.

I bundle di grandi dimensioni con nuovi tentativi possono generare ritorni in termini di rendimento inferiori e sono più suscettibile di avere più errori. I clienti dovrebbero implementare logica aggiuntiva per gestire il sottoinsieme di risorse FHIR non riuscite in una transazione.

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

Evita di utilizzare pacchetti di grandi dimensioni con migliaia di transazioni. Utilizza invece seguenti:

• Utilizza pacchetti di transazioni più piccoli che supportano la coerenza dei dati. Se FHIR le risorse 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 un po' di raggruppamento in batch ed evita le singole richieste. Batch possono migliorare le prestazioni, ma batch di grandi dimensioni possono causare errori e peggiorare e la velocità effettiva dei dati. I batch bundle di dimensioni simili hanno meno conflitti perché non mantengono i blocchi tra gli aggiornamenti delle risorse FHIR.

I pacchetti di transazioni di piccole dimensioni evitano i conflitti perché contengono solo alcuni blocchi alla volta e terminare rapidamente. Ciò consente di evitare un backlog di transazioni in pila.

Velocità effettiva LRO

Consulta Velocità effettiva dei dati LRO.

Opzioni di archiviazione dei dati FHIR

Se il volume dei dati FHIR è di piccole o medie dimensioni, 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 FHIR.

Importa risorse FHIR

Per decidere se utilizzare l'importazione FHIR, considera 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 in Cloud Storage e importarle. Evita la simultanea a latenza elevata o a importazioni di grandi dimensioni oppure la velocità effettiva dei dati potrebbe essere limitata.

• L'importazione FHIR è meno complessa rispetto all'utilizzo dei bundle FHIR. Ad esempio, non 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 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 se nel progetto Google Cloud sono presenti 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.

Utilizza 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.

• È necessario applicare forzatamente 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 pacchetti 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 la velocità effettiva dei dati, ma non hanno di coerenza come l'integrità referenziale.

• I set di batch di grandi dimensioni possono avere una maggiore latenza. Per maggiori informazioni, vedi Evitare i pacchetti di grandi dimensioni.

Opzioni di archiviazione dei dati DICOM

Puoi utilizzare i seguenti metodi per ottenere una velocità effettiva dei dati elevata durante l'invio di dati da un sistema di archiviazione e comunicazione immagini (PACS) al 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 delle prestazioni e verifica che l'adattatore può sostenere i picchi di velocità effettiva 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:

• Montaggio di 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 intervalli regolari anziché in un caricamento batch una tantum, devi misurare le modifiche alla dimensione dei dati nel tempo per determinare che cosa è cambiato.
• Massimizzazione del rendimento del trasferimento dell'agente.
• Pagamento e allocazione dello spazio di archiviazione di 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 in batch in base alla rete e alla capacità di archiviazione di un sistema clinico.

Ti consigliamo di usare Storage Transfer Service per compilare un singolo caricamento in batch un datastore DICOM. Utilizzo regolare di Storage Transfer Service richiede lavoro aggiuntivo, ad esempio una pipeline di importazione sincrona. Per Per saperne di più, consulta Dettagli sul trasferimento del file system di Storage Transfer Service.

dicomStores.import

Utilizza questo metodo per archiviare grandi volumi di dati DICOM.

Transazione di archiviazione 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 i dati e la velocità effettiva effettiva. 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 media di cui hai bisogno. 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 coerenti nelle dimensioni e inviati in pattern prevedibili:

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

Quota del piano per richieste di volumi elevati

Evita di pianificare job batch di grandi dimensioni durante le ore di punta. Per ulteriori informazioni, consulta l'articolo Favorire regolarmente le transazioni di volume ridotto.

Il seguente diagramma mostra un modello 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.

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

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

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

Richiedi quota aggiuntiva

Per mantenere un'elevata velocità in bit dei dati ed evitare errori 429 Resource Exhausted, consulta le best practice riportate in questa pagina, in particolare Gestire la quota per ottimizzare la velocità in bit 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, ma hai ancora bisogno di aumentare la quota, consulta Best practice per la richiesta di una quota aggiuntiva.

Risorse per il throughput di importazione dati

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