O que significa novo anúncio de "Desempenho de Taxa de Solicitação Aumentada S3"

Question

Em 17 de julho de 2018, houve um anúncio oficial da AWS explicando que não há mais a necessidade de randomizar os primeiros caracteres de cada chave de objeto S3 para obter o máximo desempenho: link

Amazon S3 Announces Increased Request Rate Performance

Posted On: Jul 17, 2018

Amazon S3 now provides increased performance to support at least 3,500 requests per second to add data and 5,500 requests per second to retrieve data, which can save significant processing time for no additional charge. Each S3 prefix can support these request rates, making it simple to increase performance significantly.

Applications running on Amazon S3 today will enjoy this performance improvement with no changes, and customers building new applications on S3 do not have to make any application customizations to achieve this performance. Amazon S3’s support for parallel requests means you can scale your S3 performance by the factor of your compute cluster, without making any customizations to your application. Performance scales per prefix, so you can use as many prefixes as you need in parallel to achieve the required throughput. There are no limits to the number of prefixes.

This S3 request rate performance increase removes any previous guidance to randomize object prefixes to achieve faster performance. That means you can now use logical or sequential naming patterns in S3 object naming without any performance implications. This improvement is now available in all AWS Regions. For more information, visit the Amazon S3 Developer Guide.

Isso é ótimo, mas também é confuso. Ele diz que o prefixo Cada S3 pode suportar essas taxas de solicitação, tornando simples aumentar significativamente o desempenho

Mas, como os prefixos e delimitadores são apenas argumentos para a API GET Bucket (List Objects) ao listar o conteúdo de buckets, como pode fazer sentido falar sobre o desempenho de recuperação de objeto "por prefixo". Cada chamada para GET Bucket (List Objects) pode escolher qualquer prefixo e delimitador que desejar, portanto, os prefixos não são uma entidade pré-definida.

Por exemplo, se meu bucket tiver esses objetos:

a1/b-2
a1/c-3

Então, eu posso optar por usar "/" ou "-" como meu delimitador sempre que eu listar o conteúdo do intervalo, para que eu possa considerar meus prefixos como

a1/ 

ou

a1/b-
a1/c-

Mas como a API GET Object usa a chave inteira, o conceito de um prefixo ou delimitador específico não existe para a recuperação de objetos. Então, eu posso esperar 5.500 req / seg em a1/ ou alternativamente 5,500 req / s em a1/b- e 5,500 em a1/c- ?

Então, alguém pode explicar o significado do anúncio quando sugere um determinado nível de desempenho (por exemplo, +5.500 solicitações por segundo para recuperar dados) para "cada prefixo s3"?

    

Answer 1

O que está sendo referido aqui como um prefixo parece ser uma simplificação excessiva que realmente se refere a cada partição do índice do intervalo. O índice é léxico, portanto, as divisões ocorrem com base nos principais caracteres da chave do objeto. Por isso, é chamado de prefixo .

O S3 gerencia as partições de índice de forma automática e transparente, portanto a definição precisa de um "prefixo" aqui é na verdade um pouco imprecisa: "o que o S3 decidir é necessário para suportar a carga de trabalho do seu bucket". O S3 divide as partições de índice em resposta à carga de trabalho, portanto, dois objetos que podem ter o mesmo "prefixo" hoje podem ter prefixos diferentes amanhã, tudo feito em segundo plano.

Agora, a1 / a -... e a1 / b -... e a1 / c -... podem ser todos um único prefixo. Mas jogue bastante tráfego no balde, e o S3 pode decidir que a partição deve ser dividida, de modo que amanhã, a1 / ae a1 / b- possam estar em um prefixo, enquanto a1 / c- pode estar em seu próprio prefixo. (Isto é, as chaves < a1 / c- estão em uma partição, enquanto as chaves > = a1 / c- estão agora em uma partição diferente).

Onde e quando e especificamente qual limite dispara o comportamento de divisão não é documentado, mas parece estar relacionado apenas ao número de solicitações, e não ao número ou tamanho dos objetos. Anteriormente, essas partições eram limitadas a algumas centenas de solicitações por segundo, e isso aumentou significativamente.