Best practice per il throughput di importazione dei dati

In questa pagina vengono descritte le best practice per ottimizzare la velocità effettiva dei dati quando per importare 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à effettiva dati

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

Il seguente elenco descrive i motivi per cui la velocità effettiva 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, vedi Evita 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 cliente rapidamente e riprova ripetutamente dopo gli errori, può superare l'API Cloud Healthcare quote. Le seguenti sezioni 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 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 a ogni nuovo tentativo, soprattutto se utilizzi la logica personalizzata per bypassare 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 strategie simili per i nuovi tentativi. 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 di nuovo queste richieste:

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

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

  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 cui 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 riprova le richieste in modo esponenziale, aumentando il tempo di attesa tra i tentativi fino a un tempo di backoff massimo. La Il seguente algoritmo implementa il backoff esponenziale troncato con tremolio:

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 e riprova.

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

5. Continua questa sequenza, attendendo 2ⁿ + random-fraction secondi dopo ogni riprova, fino a maximum-backoff volta.

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 parte da 0 e incrementato di 1 per ogni tentativo.

• Sostituisci random-fraction con un valore frazionario casuale minore o uguale a 1. Utilizza le funzionalità di un valore diverso per ogni 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, 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 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 di maximum-backoff è 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, vedi Best practice per la gestione delle quote.

Se hai requisiti aggiuntivi, come la pubblicazione garantita in più tentativi, le strategie in Riprova 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. Questo consente di distribuire i picchi di carico tra ore o minuti per migliorare la velocità effettiva. Quando la quota è limitata, la definizione del profilo del traffico può raggiungere una velocità in uscita superiore rispetto all'utilizzo dei soli tentativi di nuovo invio perché evita il pushback e monitora le unità di lavoro.

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

Requisiti per il formato di 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 l'uso di dischi errore.
• Lavoratori coordinati per eseguire il pull 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.
• Ridotti i LRO 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, la definizione del profilo del traffico potrebbe essere necessaria solo per un singolo livello della pipeline:

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

Implementa la limitazione di frequenza in altre aree del sistema

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

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

• Il comando Java RateLimiter dell'insieme di librerie Java principali di Google Guava.

• Il comando Python ratelimiter in maggior dettaglio più avanti in questo modulo.

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 aggrega le richieste all'API Cloud Healthcare, mostrata in Gestire gli errori su più livelli, controllare la limitazione tra servizi che utilizzano l'API Cloud Healthcare. In base tipo di formato di traffico richiesto, utilizza una delle seguenti opzioni:

Asincrona

Utilizza l'elaborazione asincrona per inserire in coda le richieste e controllare i worker. Un livello proxy scrive le richieste in entrata nella coda restituisce 200 OK risposte 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 dipende dalla finitura di un'unità precedente. Un livello proxy ritarda le richieste in uscita in base su QPS o limiti di velocità effettiva di byte, e il client blocca e attende il proxy la risposta del livello.

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 del client e quello del proxy si disconnettono, è necessario svolgere più attività per garantire i dati sono 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 per i nuovi tentativi utilizzando l'oggetto RetryConfig

Consulta Creare code per creare in Cloud Tasks. La Queue mostra le opzioni che puoi impostare in una coda. Per Ad esempio, puoi utilizzare la classe RetryConfig per implementare il backoff esponenziale. Consulta Librerie client di Cloud Tasks per librerie specifiche dei linguaggi.

Quando utilizzi Cloud Tasks, tieni presente 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 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 bundle FHIR con limiti di frequenza

Riprovare i bundle FHIR con backoff esponenziale e limiti di frequenza consente di mantenere un'elevata velocità effettiva dei dati e 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 frequenza si riempie, il sistema deve avvisare una persona e impedisce 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 un'handshake TCP, che può causare un sovraccarico 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.

Il Python requests che utilizza il keep-alive HTTP per impostazione predefinita. Se utilizzi Node.js, imposta keepAlive a true quando crei un oggetto http.Agent e poi passi l'oggetto nella tua richiesta.

Utilizza 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 un backlog di attività che devono essere gestite 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 compromessa.
• 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 nuovi tentativi, dimensioni delle code l'età della coda.
• 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 informano di problemi, ad esempio se il tuo impianto è sotto stress o richiede l'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

Evitare errori 429 Resource Exhausted operation_too_costly

L'esecuzione di migliaia di aggiornamenti paralleli ogni giorno a una risorsa FHIR può causare bloccare il conflitto, la 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 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. Ciò può accadere a causa di molte operazioni in un bundle FHIR o 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 i carichi di lavoro restituendo operation_too_costly errori. In questo modo si limita il traffico e si evitano ulteriori errori.

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

Risolvi 429 Too Many Requests di errori

Per risolvere i problemi relativi agli errori 429 Too Many Requests, esegui una ricerca in Cloud Logging. Gli errori contenenti operation_too_costly indicano un conflitto di blocchi. Se gli errori sono causati dall'esaurimento delle risorse, controlla la presenza di problemi relativi alle quote.

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 i pacchetti di grandi dimensioni.

L'errore 429 Too Many Requests è più probabile con transazioni di grandi dimensioni bundle. I bundle di qualsiasi dimensione possono creare colli di bottiglia della velocità effettiva. 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 client devono implementare una logica aggiuntiva per gestire il sottoinsieme di risorse FHIR che non è riuscito 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 pacchetti batch di dimensioni simili hanno meno conflitti perché non contengono 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 finire 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 dimensioni ridotte o moderate, 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 ha meno complessità rispetto all'utilizzo di bundle FHIR. Ad esempio, non fare quanto segue:

  • Suddividi i bundle di grandi dimensioni in altri più piccoli
  • Gestisci pianificazioni
  • Riprova per gli 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 veloce, ma potrebbe subire ritardi di ore o giorni.

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

• L'importazione FHIR può raggiungere una velocità effettiva dei dati elevata se l'applicazione è in grado di gestire e gli errori 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.

• È necessario applicare l'integrità referenziale.

• È necessario applicare forzatamente la convalida del profilo FHIR.

• Devi inviare notifiche Pub/Sub quando le risorse FHIR vengono archiviate. L'importazione FHIR non supporta 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 strutturato, la velocità effettiva dei dati può essere limitata 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:

• Quota e fatturazione vengono applicate a ogni operazione nel pacchetto come se 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 transazione che alla contesa del blocco. Per maggiori informazioni, vedi Prevenire gli errori di 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 DIMSE (Message Service Element)

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 può sostenere i picchi di velocità effettiva dei dati.

Utilizza questo adattatore se non riesci a caricare i file DICOM in Cloud Storage utilizzando Storage Transfer Service o un altro un'opzione di trasferimento. Ad esempio, potresti non essere in grado di soddisfare 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.
• Massimizzare le prestazioni del trasferimento degli agenti
• Pagamento e allocazione dello spazio di archiviazione Cloud Storage.
• Convalida dei trasferimenti di dati in Cloud Storage in corso...
• Rimozione delle risorse Cloud Storage dopo l'importazione dei dati nell'API Cloud Healthcare e correzione di 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 utilizzare Storage Transfer Service per un singolo caricamento batch per compilare un archivio DICOM. Utilizzo regolare di Storage Transfer Service richiede 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 di archiviazione DICOMweb

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

Gestire la quota per ottimizzare la velocità in bit 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 per prima cosa le caratteristiche tipiche dell'applicazione client traffico giornaliero. Anche se il traffico è prevedibile, pianifica una quota superiore a quella media di cui hai bisogno. In questo modo, puoi evitare errori e offrire un margine di sicurezza contro i picchi di traffico. o aumenti occasionali nell'uso quotidiano.

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 dell'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 punta. Per ulteriori informazioni, consulta l'articolo Favorire regolarmente le transazioni di volume ridotto.

Il seguente diagramma mostra un modello di traffico prevedibile. Tuttavia, un richiesta batch di grandi dimensioni durante un periodo di picco di traffico supera le quota. Ciò può causare errori 429 Resource Exhausted per tutte le richieste nel tuo 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 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 una velocità effettiva dei dati elevata ed evitare 429 Resource Exhausted errori, Consulta le best practice in questa pagina, in particolare Gestisci la quota per ottimizzare la velocità effettiva 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 sulla velocità effettiva di importazione dati, consulta Gestisci il traffico e il carico dei carichi di lavoro in Google Cloud.