Data IO e crittografia

La dimensione dell'oggetto può avere impatti significativi sulle prestazioni di IBM Cloud® Object Storage. Scegli l'approccio giusto per il tuo carico di lavoro.

Trasferimenti multiparte

In condizioni tipiche, i caricamenti e i download in più parti sono un metodo molto efficiente per suddividere i trasferimenti in molte transazioni parallele. In base alla dimensione dell'oggetto, è generalmente consigliata una dimensione parte di 100MB. In ogni caso, è più efficiente impostare la dimensione della parte su un multiplo di 4MiB per ottimizzare l'inserimento e l'uscita dei dati da COS.

Come con AWS S3, l'uso di trasferimenti multiparte fornisce i seguenti vantaggi:

Throughput migliorato - È possibile caricare parti in parallelo per migliorare il throughput.
Ripristino rapido da eventuali problemi di rete - La dimensione della parte più piccola riduce l'impatto del riavvio di un caricamento non riuscito a causa di un errore di rete.
Sospendi e riprende i caricamenti di oggetti - Carica parti di oggetti nel tempo. Una volta avviato un caricamento in più parti, il caricamento in più parti non ha scadenza; deve essere completato esplicitamente o il caricamento in più parti deve essere interrotto.
Inizia un caricamento prima che la dimensione dell'oggetto finale sia nota - Un oggetto può essere caricato mentre viene creato.

A causa della complessità aggiuntiva dei trasferimenti in più parti, si consiglia di utilizzare le librerie, gli strumenti o gli SDK S3 appropriati che offrono il supporto per i trasferimenti in più parti gestiti:

Sebbene non vi sia alcuna API dedicata per un download multipart, è possibile utilizzare un'intestazione Range in una richiesta GET per leggere solo una parte specifica di un oggetto e molte letture a intervalli possono essere emesse in parallelo, proprio come quando si caricano le parti. Dopo che tutte le parti sono state scaricate, possono essere concatenate e l'oggetto completo può essere controllato per l'integrità. Come menzionato in precedenza, l'utilizzo di SDK o di altri strumenti è consigliato per evitare la complessità della gestione manuale di questi trasferimenti.

I flussi di lavoro che devono memorizzare un numero elevato di oggetti molto piccoli possono essere utilizzati meglio aggregando i piccoli file in una struttura di dati più grande, ad esempio [Parquet].

Per oggetti di dimensione superiore a 200mb, specialmente in reti meno stabili o su distanze molto lunghe in cui la perdita di pacchetti è un problema, Aspera High-Speed Transfer può fornire prestazioni eccellenti. I trasferimenti Aspera possono anche caricare strutture di directory nidificate in modo efficiente all'interno di una sola richiesta.

Limitazione delle eliminazioni batch

L'API S3 fornisce un meccanismo per eliminare fino a 1.000 oggetti con una singola richiesta di eliminazione batch. Si consiglia di limitare queste richieste lato client per ridurre al minimo le possibilità di prestazioni dispregiative all'interno del sistema COS. Quando il numero di eliminazioni emesse è troppo elevato per il sistema, il client riceverà errori HTTP 503 con un messaggio di errore che indica "rallentamento".

Impatti sulla coerenza

IBM Cloud Object Storage System garantisce la congruenza immediata per tutte le operazioni oggetto, che include le operazioni di scrittura, sovrascrittura, eliminazione, multiparte e modifiche ACL. Anche la creazione del bucket è immediatamente coerente. I metadati del bucket e la configurazione sono alla fine congruenti, come nel caso di altri sistemi di archiviazione oggetti, il che significa che le modifiche in un sistema altamente distribuito potrebbero non essere sincronizzate per un breve periodo di tempo. Ciò si verifica a causa della memorizzazione nella cache dei metadati che fornisce vantaggi significativi in termini di prestazioni e protegge dalla possibilità di attacchi DoS (denial - of - service).

Alcune applicazioni sovrascriveranno lo stesso oggetto oppure elimineranno e riscriveranno ripetutamente lo stesso oggetto per un breve periodo di tempo. Ciò può causare un conflitto negli indici all'interno del sistema COS e deve essere evitato. Nel raro caso in cui la sovrascrittura dei dati con la stessa chiave oggetto (nome) ad una frequenza molto elevata e per periodi di tempo estesi sia un aspetto critico di una progettazione di applicazione, una diversa piattaforma di archiviazione (file, blocco, noSQL, ecc.) potrebbe essere una scelta migliore.

Verifiche di esistenza

Le applicazioni potrebbero voler controllare se un oggetto esiste o è stato modificato prima di scriverlo. Spesso ciò porta a una logica dell'applicazione inefficiente che invierà una richiesta HEAD seguita da una richiesta PUT o GET. Questo anti - pattern provoca uno spreco di risorse di rete e server e dovrebbe essere scoraggiato.

Invece di utilizzare una richiesta HEAD come controllo di esistenza all'interno di una funzione, utilizzare un'intestazione della richiesta condizionale. Queste intestazioni HTTP standard confronteranno gli hash MD5 o le date / ore per determinare se l'operazione dei dati deve procedere o meno. Per ulteriori informazioni, vedere Richieste condizionali.

Utilizzo di richieste condizionali

Quando si effettua una richiesta di lettura o scrittura dei dati, è possibile impostare le condizioni su tale richiesta per evitare operazioni non necessarie. Ciò viene realizzato utilizzando le seguenti intestazioni HTTP pre - condizionali: If-Match, If-None-Match, If-Modified-Since e If-Unmodified-Since.

È generalmente preferibile utilizzare If-Match perché la granularità del valore Last-Modified è solo in secondi e potrebbe non essere sufficiente per evitare condizioni di conflitto in alcune applicazioni.

Utilizzo di If - Match

Su una richiesta PUT, HEAD o GET dell'oggetto, l'intestazione If-Match controllerà se un Etag fornito (hashMD5 del contenuto dell'oggetto) corrisponde al valore Etag fornito. Se questo valore corrisponde, l'operazione procederà. Se la corrispondenza ha esito negativo, il sistema restituirà un errore 412 Precondition Failed.

If - Match è più spesso utilizzato con metodi di modifica dello stato (ad esempio, POST, PUT, DELETE) per evitare sovrascritture accidentali quando più agent utente potrebbero agire in parallelo sulla stessa risorsa (ovvero, per evitare il problema di "aggiornamento perso").

Utilizzo di If - None - Match

Su una richiesta PUT, HEAD o GET dell'oggetto, l'intestazione If-None-Match controllerà se un Etag fornito (hashMD5 del contenuto dell'oggetto) corrisponde al valore Etag fornito. Se questo valore non corrisponde, l'operazione procederà. Se la corrispondenza ha esito positivo, il sistema restituirà un errore 412 Precondition Failed su un PUT e un errore 304 Not Modified su GET o HEAD.

If - None - Match viene utilizzato principalmente nelle richieste GET condizionali per abilitare gli aggiornamenti efficienti delle informazioni memorizzate nella cache con una quantità minima di overhead di transazione. Quando un client desidera aggiornare una o più risposte memorizzate che hanno tag di entità, il client DEVE generare un campo di intestazione If - None - Match contenente un elenco di tali tag di entità quando effettua una richiesta GET; ciò consente ai server destinatari di inviare una risposta 304 (non modificata) per indicare quando una di tali risposte memorizzate corrisponde alla rappresentazione selezionata.

Utilizzo di If - Modified - Since

Su una richiesta HEAD o GET dell'oggetto, l'intestazione If-Modified-Since controllerà se il valore Last-Modified dell'oggetto (ad esempio, Sat, 14 March 2020 19:43:31 GMT) è più recente di un valore fornito. Se l'oggetto è stato modificato, l'operazione procederà. Se l'oggetto non è stato modificato, il sistema restituirà un 304 Not Modified.

If - Modified - Since viene generalmente utilizzato per due scopi distinti: consentire aggiornamenti efficienti di una rappresentazione memorizzata nella cache che non ha un Etag e limitare l'ambito di un attraversamento web alle risorse che sono state modificate di recente.

Utilizzo di If - Unmodified - Since

Su una richiesta PUT, HEAD o GET dell'oggetto, l'intestazione If-Unmodified-Since controllerà se il valore Last-Modified dell'oggetto (ad esempio, Sat, 14 March 2020 19:43:31 GMT) è uguale o precedente a un valore fornito. Se l'oggetto non è stato modificato, l'operazione procederà. Se il valore Last-Modified è più recente, il sistema restituirà un errore 412 Precondition Failed su un PUT e un errore 304 Not Modified su GET o HEAD.

If - Unmodified - Since è spesso utilizzato con i metodi di modifica dello stato (ad esempio, POST, PUT, DELETE) per evitare sovrascritture accidentali quando più agent utente potrebbero agire in parallelo su una risorsa che non fornisce tag di entità con le relative rappresentazioni (ovvero, per evitare il problema di "aggiornamento perso"). Può anche essere utilizzato con metodi sicuri per interrompere una richiesta se la rappresentazione selezionata non corrisponde a una già memorizzata (o parzialmente memorizzata) da una precedente richiesta.

Strategia per i nuovi tentativi

Mentre la maggior parte delle librerie e degli SDK gestiranno automaticamente la logica dei nuovi tentativi, è necessario prestare attenzione quando si scrive il software che utilizza direttamente l'API per gestire correttamente gli errori transitori. Ancora più importante, è fondamentale fornire una logica di ripetizione appropriata che implementa il back-off esponenziale quando si ricevono 503 errori.

Ottimizzazione Cypher

IBM COS supporta una varietà di impostazioni Cipher per crittografare i dati in transito. Non tutte le impostazioni di cifratura producono le stesse prestazioni di livello e l'utilizzo di TLS in genere porta a un piccolo peggioramento delle prestazioni. Si consiglia di utilizzare le seguenti impostazioni di cifratura (in ordine decrescente di priorità):

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA