:Termos do OSS

Bucket

Um bucket é um contêiner para objetos armazenados no OSS. Todo objeto no OSS reside em um bucket. Configure várias propriedades para um bucket, incluindo região, lista de controle de acesso (ACL) e classe de armazenamento. As classes de armazenamento são úteis para armazenar dados com diferentes padrões de acesso.

• O OSS usa uma estrutura plana, e não hierárquica, para os objetos. Cada objeto pertence a um bucket.

• Crie vários buckets.

• O nome de um bucket deve ser exclusivo no OSS dentro de uma conta da Alibaba Cloud. Não é possível alterar os nomes dos buckets após a criação.

  Nota

  Os nomes dos buckets criados por todas as contas da Alibaba Cloud não podem ser iguais. Por exemplo, caso o Usuário A crie um bucket chamado example, outros usuários não poderão criar outro bucket com o nome example.

• Um bucket pode conter um número ilimitado de objetos.

O nome de um bucket deve seguir as convenções de nomenclatura abaixo:

• O nome pode conter apenas letras minúsculas, dígitos e hifens (-).

• O nome deve começar e terminar com uma letra minúscula ou um dígito.

• O nome deve ter de 3 a 63 caracteres.

Objeto

O objeto é a menor unidade de dados no OSS. Arquivos enviados para o OSS são chamados de objetos. Ao contrário dos sistemas de arquivos tradicionais, os objetos no OSS são armazenados em uma estrutura plana, em vez de hierárquica. Um objeto é composto de uma chave, metadados e dados armazenados no próprio objeto. Cada objeto em um bucket é identificado exclusivamente pela chave. Os metadados do objeto são um conjunto de pares chave-valor que definem as propriedades de um objeto, como o tipo de arquivo e o formato de codificação. Especifique metadados de usuário personalizados para os objetos no OSS.

O ciclo de vida de um objeto começa no momento do envio e termina na exclusão. Com exceção dos objetos anexáveis, não é possível modificar o conteúdo de um objeto em nenhuma etapa do seu ciclo de vida. Para modificar o conteúdo de um objeto, envie um novo objeto para substituir o existente. O novo objeto deve ter o mesmo nome do objeto cujo conteúdo será modificado.

O nome de um objeto deve seguir as convenções abaixo:

• O nome deve ser codificado em UTF-8.

• O nome deve ter de 1 a 1.023 caracteres.

• O nome não pode começar com uma barra (/) ou uma barra invertida (\).

  Nota

  Os nomes dos objetos fazem distinção entre letras maiúsculas e minúsculas. Salvo indicação em contrário, a documentação do OSS refere-se a todos os objetos ou arquivos simplesmente como objetos.

Chave do objeto

Nos SDKs do OSS para diferentes linguagens de programação, os termos "object key" (chave do objeto), "key" (chave) e "object name" (nome do objeto) indicam o caminho completo do objeto. Especifique o caminho completo de um objeto ao executar operações no objeto. Por exemplo, ao enviar um objeto para um bucket, ObjectKey indica o caminho completo que inclui a extensão do objeto, como abc/efg/123.jpg.

Tipos de objeto

Os objetos dividem-se nos tipos a seguir conforme o método de criação:

• Normal

  Esse tipo de objeto é criado por envio simples. Após o envio, os objetos admitem apenas leitura e não podem ser modificados. Para alterar o conteúdo de um objeto existente, envie um novo objeto com o mesmo nome para substituí-lo. O envio simples permite enviar um objeto com tamanho inferior a 5 GB. Esse método é adequado para cenários nos quais é possível enviar um objeto por meio de uma única solicitação HTTP. Para mais informações, consulte Simple upload.

• Multipart

  Esse tipo de objeto é criado por envio multipart. Após o envio, os objetos admitem apenas leitura e não podem ser modificados. Para alterar o conteúdo de um objeto existente, envie um novo objeto com o mesmo nome para substituí-lo. O envio multipart é ideal para cenários que exigem aceleração no envio de objetos grandes, condições de rede instáveis ou tamanho de objeto desconhecido. Para mais informações, consulte Multipart upload.

• Anexável

  Esse tipo de objeto é criado por envio por anexação. Use o envio por anexação para enviar dados de vídeo para o mesmo objeto imediatamente após a geração desses dados. Esse método é recomendado para fluxos de vídeo em tempo real gerados em áreas como videomonitoramento e transmissões ao vivo. Para mais informações, consulte Append upload.

Região

Uma região é um local físico de onde o OSS oferece serviços. Ao criar um bucket, selecione uma região com base no custo ou no local de acesso mais frequente ao bucket. Na maioria dos casos, o acesso ao OSS a partir de uma localização geograficamente mais próxima resulta em maior velocidade. Para mais informações, consulte Regions and endpoints.

Especifique a região de um bucket no momento da criação. Após a criação do bucket, não é possível alterar sua região. Todos os objetos no bucket são armazenados na região na qual o bucket está. A configuração de regiões aplica-se a buckets, e não a objetos.

Endpoint

Um endpoint é um nome de domínio usado no acesso ao OSS. O OSS fornece endpoints específicos para cada região, destinados ao acesso aos seus dados. Gerencie seus dados em diferentes regiões por meio das operações da API do OSS. Uma região possui endpoints distintos para acesso pela rede interna e pela Internet. Por exemplo, o endpoint público usado para acessar dados do OSS na região China (Hangzhou) é oss-cn-hangzhou.aliyuncs.com, e o endpoint interno é oss-cn-hangzhou-internal.aliyuncs.com. Para mais informações, consulte Regions and endpoints.

Par de AccessKey

Um par de AccessKey autentica um solicitante. É composto de um AccessKey ID e um AccessKey secret. O OSS usa o par de AccessKey para implementar criptografia simétrica e verifique a identidade do solicitante. O AccessKey ID identifica o usuário, enquanto o AccessKey secret criptografa e verifique a string de assinatura. Mantenha o AccessKey secret em sigilo. O OSS aceita pares de AccessKey obtidos das formas abaixo:

• Solicitados pelo proprietário do bucket.

• Concedidos pelo proprietário do bucket por meio do Resource Access Management (RAM).

• Concedidos pelo proprietário do bucket por meio do Security Token Service (STS).

Para mais informações, consulte Create an AccessKey pair.

Atomicidade e consistência forte

• Atomicidade

  As operações em objetos no OSS são atômicas. São totalmente bem-sucedidas ou falham, sem estados intermediários. Ao enviar um objeto, o sistema retorna os dados antes ou depois do envio, nunca dados parciais ou corrompidos.

• Consistência forte

  As operações em objetos no OSS possuem alta consistência. Por exemplo, ao receber uma resposta de sucesso de envio (PUT), é possível ler imediatamente o objeto enviado, e o sistema cria réplicas do objeto para redundância. Portanto, não há cenários de falha na obtenção de dados ao executar a operação de leitura após gravação. Da mesma forma, após a exclusão de um objeto, ele e suas réplicas deixam de existir.

Mecanismo de redundância de dados