Em 17 de julho de 2018, houve um anúncio oficial da AWS explicando que não há mais necessidade de aleatorizar os primeiros caracteres de cada chave de objeto S3 para obter o desempenho máximo: https://aws.amazon.com/about-aws/whats-new / 2018/07 / amazon-s3-anuncia-aumento-da-taxa-de-desempenho /
Amazon S3 anuncia aumento no desempenho da taxa de solicitações
Publicado em: 17 de jul de 2018
O Amazon S3 agora oferece desempenho aprimorado para oferecer suporte a pelo menos 3.500 solicitações por segundo para adicionar dados e 5.500 solicitações por segundo para recuperar dados, o que pode economizar tempo de processamento significativo sem custo adicional. Cada prefixo S3 pode suportar essas taxas de solicitação, simplificando o aumento significativo do desempenho.
Os aplicativos em execução no Amazon S3 hoje desfrutam dessa melhoria de desempenho sem alterações, e os clientes que criam novos aplicativos no S3 não precisam fazer personalizações de aplicativos para obter esse desempenho. O suporte do Amazon S3 para solicitações paralelas significa que você pode dimensionar o desempenho do S3 pelo fator do seu cluster de computação, sem fazer nenhuma personalização no seu aplicativo. Escalas de desempenho por prefixo, para que você possa usar quantos prefixos precisar em paralelo para obter a taxa de transferência necessária. Não há limites para o número de prefixos.
Esse aumento no desempenho da taxa de solicitação do S3 remove qualquer orientação anterior para randomizar prefixos de objetos para obter um desempenho mais rápido. Isso significa que agora você pode usar padrões de nomeação lógica ou seqüencial na nomeação de objetos S3 sem implicações de desempenho. Agora, essa melhoria está disponível em todas as regiões da AWS. Para obter mais informações, visite o Guia do desenvolvedor do Amazon S3.
Isso é ótimo, mas também é confuso. Diz que cada prefixo S3 pode suportar essas taxas de solicitação, simplificando o aumento significativo do desempenho
Porém, como prefixos e delimitadores são apenas argumentos para a GET Bucket (List Objects)API ao listar o conteúdo de buckets, como pode fazer sentido falar sobre o desempenho de recuperação de objetos "por prefixo". Cada chamada para GET Bucket (List Objects)pode escolher o prefixo e o delimitador que desejar, portanto, os prefixos não são uma entidade predefinida.
Por exemplo, se meu bucket tiver estes objetos:
a1/b-2
a1/c-3
Então, posso optar por usar "/" ou "-" como meu delimitador sempre que listar o conteúdo do bloco, para que eu possa considerar meus prefixos como
a1/
ou
a1/b-
a1/c-
Mas como a GET ObjectAPI usa a chave inteira, o conceito de um prefixo ou delimitador específico não existe para a recuperação de objetos. Então, posso esperar 5.500 req / s a1/ou, alternativamente, 5.500 req / s a1/b-e 5.500 a1/c-?
Então, alguém pode explicar o significado do anúncio quando sugere um nível específico de desempenho (por exemplo, 5.500 solicitações por segundo para recuperar dados) para "cada prefixo s3"?
fonte
Respostas:
O que está sendo referido aqui como prefixo parece ser uma simplificação excessiva que realmente se refere a cada partição do índice do bucket. O índice é lexical; portanto, as divisões ocorrem com base nos caracteres iniciais na chave do objeto. Portanto, é referido como o prefixo .
O S3 gerencia as partições de índice de maneira automática e transparente, de modo que a definição precisa de um "prefixo" aqui é realmente um tanto imprecisa: é "o que o S3 decide que é necessário para suportar a carga de trabalho do seu bucket". O S3 divide as partições do índice em resposta à carga de trabalho; portanto, dois objetos que podem ter o mesmo "prefixo" hoje podem ter prefixos diferentes amanhã, todos feitos em segundo plano.
No momento, a1 / a -... e a1 / b -... e a1 / c -... podem ser todos um único prefixo. Mas jogue tráfego suficiente no bucket e S3 pode decidir que a partição deve ser dividida, para que amanhã a1 / a- e a1 / b- possam estar em um prefixo, enquanto a1 / c- esteja em seu próprio prefixo. (Ou seja, as chaves <a1 / c- estão em uma partição, enquanto as chaves> = a1 / c- agora estão em uma partição diferente).
Onde, quando e especificamente qual limite aciona o comportamento de divisão não está 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 cada, e isso era significativamente aumentado.
fonte