Cosa significa il nuovo annuncio "S3 Aumento del tasso di richiesta"

Il 17 luglio 2018 c'è stato un annuncio AWS ufficiale che spiegava che non è più necessario randomizzare i primi caratteri di ogni chiave oggetto S3 per ottenere le massime prestazioni: https://aws.amazon.com/about-aws/whats-new / 2018/07 / amazon-s3-annuncia-aumento-richiesta-rate-prestazioni /

Amazon S3 annuncia un aumento del tasso di richieste

Pubblicato il: 17 luglio 2018

Amazon S3 ora offre prestazioni migliorate per supportare almeno 3.500 richieste al secondo per aggiungere dati e 5.500 richieste al secondo per recuperare i dati, il che può far risparmiare tempo di elaborazione significativo senza costi aggiuntivi. Ogni prefisso S3 può supportare queste percentuali di richiesta, rendendo semplice aumentare significativamente le prestazioni.

Le applicazioni in esecuzione su Amazon S3 oggi godranno di questo miglioramento delle prestazioni senza modifiche e i clienti che sviluppano nuove applicazioni su S3 non devono effettuare personalizzazioni delle applicazioni per raggiungere queste prestazioni. Il supporto di Amazon S3 per richieste parallele significa che puoi scalare le tue prestazioni S3 in base al fattore del tuo cluster di calcolo, senza apportare personalizzazioni alla tua applicazione. Scala delle prestazioni per prefisso, in modo da poter utilizzare tutti i prefissi necessari in parallelo per ottenere il throughput richiesto. Non ci sono limiti al numero di prefissi.

Questo aumento delle prestazioni della frequenza di richiesta S3 rimuove qualsiasi guida precedente per randomizzare i prefissi degli oggetti per ottenere prestazioni più veloci. Ciò significa che ora è possibile utilizzare modelli di denominazione logici o sequenziali nella denominazione di oggetti S3 senza implicazioni sulle prestazioni. Questo miglioramento è ora disponibile in tutte le regioni AWS. Per ulteriori informazioni, visita la Guida per gli sviluppatori di Amazon S3.

È fantastico, ma è anche confuso. Dice che ogni prefisso S3 può supportare questi tassi di richiesta, rendendo semplice aumentare significativamente le prestazioni

Ma poiché prefissi e delimitatori sono solo argomenti per l' GET Bucket (List Objects)API quando si elenca il contenuto dei bucket, come può avere senso parlare delle prestazioni di recupero degli oggetti "per prefisso". Ogni chiamata a GET Bucket (List Objects)può scegliere qualunque prefisso e delimitatore desideri, quindi i prefissi non sono un'entità predefinita.

Ad esempio, se il mio bucket ha questi oggetti:

a1/b-2
a1/c-3

Quindi potrei scegliere di utilizzare "/" o "-" come delimitatore ogni volta che elenco il contenuto del bucket, quindi potrei considerare i miei prefissi come

a1/ 

o

a1/b-
a1/c-

Ma poiché l' GET ObjectAPI utilizza l'intera chiave, il concetto di un prefisso o delimitatore particolare non esiste per il recupero degli oggetti. Quindi posso aspettarmi 5.500 req / sec su a1/o in alternativa 5.500 req / sec su a1/b-e 5.500 on a1/c-?

Qualcuno può quindi spiegare cosa si intende per annuncio quando suggerisce un determinato livello di prestazioni (ad es. +5.500 richieste al secondo per recuperare i dati) per "ogni prefisso s3"?

Ciò che viene effettivamente indicato qui come prefisso sembra essere una semplificazione eccessiva che si riferisce in realtà a ciascuna partizione dell'indice bucket. L'indice è lessicale, quindi le suddivisioni si verificano in base ai caratteri iniziali nella chiave dell'oggetto. Quindi, viene indicato come prefisso .

S3 gestisce le partizioni di indice in modo automatico e trasparente, quindi la definizione precisa di un "prefisso" qui è in realtà un po 'imprecisa: è "qualunque cosa S3 decida sia necessaria per supportare il carico di lavoro del bucket." S3 divide le partizioni di indice in risposta al carico di lavoro, quindi due oggetti che potrebbero avere lo stesso "prefisso" oggi potrebbero avere prefissi diversi domani, tutti eseguiti in background.

In questo momento, a1 / a -... e a1 / b -... e a1 / c -... possono essere tutti un singolo prefisso. Ma getta abbastanza traffico al bucket e S3 potrebbe decidere di dividere la partizione, in modo che domani a1 / a- e a1 / b- possano trovarsi in un prefisso, mentre a1 / c- potrebbe trovarsi nel proprio prefisso. (Cioè, le chiavi <a1 / c- sono in una partizione, mentre le chiavi> = a1 / c- sono ora in una partizione diversa).

Dove e quando e in particolare quale soglia attiva il comportamento diviso non è documentato, ma sembra essere correlato solo al numero di richieste e non al numero o alla dimensione degli oggetti. In precedenza, queste partizioni erano limitate a poche centinaia di richieste al secondo ciascuna, e questo è stato notevolmente aumentato.