E/S de dados e criptografia

O tamanho do objeto pode ter impactos significativos no desempenho do IBM Cloud® Object Storage Escolha a abordagem certa para a sua carga de trabalho

Transferências multipartes

Em condições típicas, os uploads e downloads de várias partes são um método muito eficiente para dividir as transferências em muitas transações paralelas.. Dependendo do tamanho do objeto, um tamanho de parte de 100MB geralmente é recomendado Em qualquer caso, é mais eficiente configurar o tamanho da peça para um múltiplo de 4MiB para otimizar a alimentação de dados e saída do COS.

Como com o AWS S3, o uso de transferências de múltiplas partes fornece as vantagens a seguir:

Rendimento melhorado-É possível fazer upload de peças em paralelo para melhorar o rendimento.
Recuperação rápida de quaisquer problemas de rede-O tamanho da parte menor minimiza o impacto de reiniciar um upload com falha devido a um erro de rede
Pausar e retomar uploads de objetos-Fazer upload de partes de objetos ao longo de um tempo Quando um upload de várias partes é iniciado, não há expiração; ele deve ser explicitamente concluído ou o upload de várias partes deve ser interrompido.
Inicie um upload antes que o tamanho do objeto final seja conhecido-Um objeto pode ser transferido por upload conforme ele está sendo criado.

Devido à complexidade adicional de transferências multipartes, é recomendável usar bibliotecas, ferramentas ou SDKs apropriadas do S3 que oferecem suporte para transferências multipartes gerenciadas:

Embora não haja nenhuma API dedicada para um download de várias partes, é possível usar um cabeçalho Range em uma solicitação GET para ler apenas uma parte específica de um objeto e muitas leituras variadas podem ser emitidas em paralelo, assim como ao fazer upload de partes Após todas as partes terem sido transferidas por download, elas podem ser concatenadas e o objeto completo pode ser verificado quanto à integridade.. Conforme mencionado anteriormente, o uso de SDKs ou outras ferramentas é recomendado para evitar as complexidades de gerenciar manualmente essas transferências.

Os fluxos de trabalho que precisam armazenar grandes números de objetos muito pequenos podem ser melhor atendidos ao agregar os arquivos pequenos em uma estrutura de dados maior, como [Parquet].

Para objetos maiores que 200mb em tamanho, especialmente em redes menos estáveis ou em distâncias muito longas em que a perda de pacotes é uma preocupação, o Aspera High-Speed Transfer pode entregar excelente desempenho. As transferências do Aspera também podem fazer upload de estruturas de diretório aninhadas de forma eficiente dentro de uma única solicitação

Exclusões de lote de regulagem

A API S3 fornece um mecanismo para excluir até 1.000 objetos com uma única solicitação de exclusão em lote. Recomenda-se regular essas solicitações do lado do cliente para minimizar as chances de desempenho depreciativo dentro do Sistema COS Quando o número de exclusões emitidas for muito alto para o sistema, o cliente receberá erros HTTP 503 com uma mensagem de erro indicando "desacelerar".

Impactos de consistência

O IBM Cloud Object Storage System garante consistência imediata para todas as operações de objeto, que inclui gravações, sobrescrições, exclusões, operações de várias partes e modificações de ACL. A criação do depósito também é imediatamente consistente Os metadados e a configuração do depósito são eventualmente consistentes, como é o caso de outros sistemas de armazenamento de objetos, o que significa que as mudanças em um sistema altamente distribuído podem não ser sincronizadas por um curto período de tempo Isso ocorre devido ao armazenamento em cache de metadados que fornece benefícios de desempenho significativos e também protege contra a possibilidade de ataques de negação de serviço..

Alguns aplicativos substituirão o mesmo objeto ou excluirão e regravarão o mesmo objeto repetidamente por um curto período de tempo. Isso pode causar contenção nos índices no Sistema COS e deve ser evitado. No caso raro em que sobrescrever dados com a mesma chave de objeto (nome) em uma frequência muito alta e em períodos estendidos de tempo é um aspecto crítico de um design de aplicativo, uma plataforma de armazenamento diferente (arquivo, bloco, noSQL, etc.) pode ser uma opção melhor..

Verificações de existência

Os aplicativos podem querer verificar se um objeto existe ou se foi modificado antes de gravar nele. Geralmente isso leva a uma lógica de aplicativo ineficiente que enviará uma solicitação HEAD seguida por uma solicitação PUT ou GET. Esse antipadrão resulta em desperdício de recursos de rede e servidor e deve ser desencorajado.

Em vez de usar uma solicitação HEAD como uma verificação de existência em alguma função, use um cabeçalho de solicitação condicional. Esses cabeçalhos HTTP padrão compararão hashes ou registros de data e hora de MD5 para determinar se a operação de dados deve continuar ou não. Para obter mais informações, consulte Solicitações Condicionais

Usando solicitações condicionais

Ao fazer uma solicitação para ler ou gravar dados, é possível configurar condições nessa solicitação para evitar operações desnecessárias.. Isso é feito usando os cabeçalhos HTTP pré-condicionais a seguir: If-Match, If-None-Match, If-Modified-Since e If-Unmodified-Since.

Geralmente é preferível usar If-Match porque a granularidade do valor Last-Modified é apenas em segundos e pode não ser suficiente para evitar condições de disputa em alguns aplicativos.

Usando If-Match

Em uma solicitação de objeto PUT, HEAD ou GET, o cabeçalho If-Match verificará se um Etag fornecido (hashMD5 do conteúdo do objeto) corresponde ao valor Etag fornecido.. Se esse valor corresponder, a operação continuará. Se a correspondência falhar, o sistema retornará um erro 412 Precondition Failed..

If-Match é mais frequentemente usado com métodos de mudança de estado (por exemplo, POST, PUT, DELETE) para evitar sobrescrições acidentais quando vários agentes do usuário podem estar agindo em paralelo no mesmo recurso (ou seja, para evitar o problema de "atualização perdida").

Usando If-None-Match

Em uma solicitação de objeto PUT, HEAD ou GET, o cabeçalho If-None-Match verificará se um Etag fornecido (hashMD5 do conteúdo do objeto) corresponde ao valor Etag fornecido.. Se este valor não corresponder, a operação prosseguirá. Se a correspondência for bem-sucedida, o sistema retornará um erro 412 Precondition Failed em um PUT e um 304 Not Modified em GET ou HEAD..

If-None-Match é usado principalmente em solicitações GET condicionais para ativar atualizações eficientes de informações armazenadas em cache com uma quantia mínima de sobrecarga de transação Quando um cliente deseja atualizar uma ou mais respostas armazenadas que possuem tags de entidade, o cliente DEVE gerar um campo de cabeçalho If-None-Match contendo uma lista dessas tags de entidade ao fazer uma solicitação GET; isso permite que os servidores destinatários enviem uma resposta 304 (Não Modificado) para indicar quando uma dessas respostas armazenadas corresponde à representação selecionada..

Usando If-Modified-Desde

Em uma solicitação de objeto HEAD ou GET, o cabeçalho If-Modified-Since verificará se o valor Last-Modified do objeto (por exemplo Sat, 14 March 2020 19:43:31 GMT) é mais recente que um valor fornecido. Se o objeto tiver sido modificado, a operação continuará. Se o objeto não tiver sido modificado, o sistema retornará um 304 Not Modified

If-Modified-Since é geralmente usado para dois propósitos distintos: para permitir atualizações eficientes de uma representação em cache que não tem um Etag e para limitar o escopo de uma passagem da web para recursos que foram recentemente alterados.

Usando If-Unmodified-Desde

Em uma solicitação de objeto PUT, HEAD ou GET, o cabeçalho If-Unmodified-Since verificará se o valor Last-Modified do objeto (por exemplo, Sat, 14 March 2020 19:43:31 GMT) é igual ou anterior a um valor fornecido... Se o objeto não tiver sido modificado, a operação continuará. Se o valor Last-Modified for mais recente, o sistema retornará um erro 412 Precondition Failed em PUT e um 304 Not Modified em GET ou HEAD.

If-Unmodified-Since é mais frequentemente usado com métodos de mudança de estado (por exemplo, POST, PUT, DELETE) para evitar substituições acidentais quando vários agentes do usuário podem estar agindo em paralelo em um recurso que não fornece tags de entidade com suas representações (ou seja, para evitar o problema de "atualização perdida"). Ele também pode ser usado com métodos seguros para interromper uma solicitação se a representação selecionada não corresponder a uma já armazenada (ou parcialmente armazenada) de uma solicitação anterior.

Estratégia de nova tentativa

Embora a maioria das bibliotecas e SDKs manipulem automaticamente a lógica de nova tentativa, deve-se tomar cuidado ao gravar software que usa a API diretamente para manipular corretamente erros temporários. Mais importante, é fundamental fornecer lógica de nova tentativa apropriada que implementa back-off exponencial ao receber 503 erros.

Afinação de cifra

O IBM COS suporta uma variedade de configurações de Cipher para criptografar dados em trânsito Nem todas as configurações de cifra produzem o mesmo desempenho de nível e o uso de TLS em geral leva a uma pequena degradação de desempenho As seguintes configurações de cifra são recomendadas (em ordem decrescente de prioridade):

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