:Termos do OSS

Bucket

Um bucket é um contêiner para objetos armazenados no OSS. Cada objeto no OSS está contido em um bucket. É possível configurar diversas propriedades para um bucket, incluindo a região, a lista de controle de acesso (ACL) e a classe de armazenamento. As classes de armazenamento são úteis quando você precisa armazenar dados com diferentes padrões de acesso.

• O OSS usa uma estrutura plana em vez de hierárquica para os objetos. Cada objeto pertence a um bucket.

• É possível criar vários buckets.

• O nome de um bucket deve ser exclusivo no OSS dentro de uma conta Alibaba Cloud. Os nomes dos buckets não podem ser alterados após a criação.

  null

  Os nomes de buckets em todas as contas Alibaba Cloud não podem ser iguais. Por exemplo, se o Usuário A criar um bucket chamado example, nenhum outro usuário poderá criar um bucket com o mesmo nome.

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

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

• 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

Objetos são a menor unidade de dados no OSS. Os arquivos enviados ao OSS são chamados de objetos. Diferentemente dos sistemas de arquivos típicos, os objetos no OSS são armazenados em uma estrutura plana em vez de hierárquica. Um objeto é composto por uma chave, metadados e os dados armazenados nele. Cada objeto em um bucket é identificado exclusivamente pela chave. Os metadados de um objeto são um grupo de pares de chave-valor que definem as propriedades do objeto, como o tipo de arquivo e o formato de codificação. Também é possível especificar metadados de usuário personalizados para objetos no OSS.

O ciclo de vida de um objeto começa no upload e termina na exclusão. Com exceção dos objetos appendable, não é possível modificar o conteúdo de um objeto em nenhuma etapa do 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 você deseja modificar.

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

• 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 (\).

  null

  Os nomes de objetos diferenciam maiúsculas de minúsculas. Salvo indicação em contrário, a documentação do OSS se refere a todos os objetos ou arquivos como objetos.

Chave do objeto

Nos SDKs do OSS para diferentes linguagens de programação, object key, key e object name indicam o caminho completo do objeto. Você deve especificar o caminho completo de um objeto ao realizar operações nele. 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 podem ser classificados nos seguintes tipos com base na forma como são criados:

• Normal

  Objetos desse tipo são criados com o upload simples. Após o envio, os objetos podem apenas ser lidos, sem possibilidade de modificação. Para modificar o conteúdo de um objeto existente, envie um novo objeto com o mesmo nome para substituí-lo. O upload simples permite enviar objetos com tamanho inferior a 5 GB. Esse método é adequado para cenários em que o envio do objeto pode ser concluído em uma única solicitação HTTP. Para mais informações, consulte Upload simples.

• Multipart

  Objetos desse tipo são criados com o upload multipart. Após o envio, os objetos podem apenas ser lidos, sem possibilidade de modificação. Para modificar o conteúdo de um objeto existente, envie um novo objeto com o mesmo nome para substituí-lo. O upload multipart é indicado para cenários em que é necessário acelerar o envio de objetos grandes, a condição da rede é instável ou o tamanho do objeto é desconhecido. Para mais informações, consulte Upload multipart.

• Appendable

  Objetos desse tipo são criados com o upload append. O upload append permite enviar dados de vídeo para o mesmo objeto imediatamente após a geração. Esse método é adequado para fluxos de vídeo em tempo real gerados em áreas como videovigilância e transmissão ao vivo. Para mais informações, consulte Upload append.

Região

Uma região é uma localização física a partir da qual o OSS fornece serviços. Ao criar um bucket, você pode selecionar uma região com base no custo ou na localização de onde o bucket é acessado com mais frequência. Na maioria dos casos, acessar o OSS de uma localização mais próxima proporciona maior velocidade. Para mais informações, consulte Regiões e endpoints.

A região de um bucket deve ser especificada no momento da criação. Após a criação, a região não pode ser alterada. Todos os objetos do bucket são armazenados na região em que o bucket está localizado. As regiões são configuradas por bucket, e não por objeto.

Endpoint

Um endpoint é um nome de domínio usado para acessar o OSS. O OSS fornece endpoints específicos por região para acesso aos seus dados. É possível gerenciar dados em diferentes regiões usando operações da API do OSS. Uma região possui endpoints diferentes para acesso pela rede interna e pela Internet. Por exemplo, o endpoint público 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 Regiões e endpoints.

Par de AccessKey

Um par de AccessKey é usado para autenticar um solicitante. O par de AccessKey é composto por um AccessKey ID e um AccessKey secret. O OSS usa o par de AccessKey para implementar criptografia simétrica e verificar a identidade do solicitante. O AccessKey ID identifica o usuário, enquanto o AccessKey secret criptografa e verifica a string de assinatura. O AccessKey secret deve ser mantido confidencial. O OSS oferece suporte a pares de AccessKey obtidos pelos seguintes métodos:

• Pares de AccessKey solicitados pelo proprietário do bucket.

• Pares de AccessKey concedidos pelo proprietário do bucket por meio do Resource Access Management (RAM).

• Pares de AccessKey concedidos pelo proprietário do bucket por meio do Security Token Service (STS).

Para mais informações, consulte Criar um par de AccessKey.

Atomicidade e consistência forte

• Atomicidade

  As operações de objetos no OSS são atômicas. As operações resultam em sucesso ou falha, sem estados intermediários. Ao fazer o upload de um objeto, é possível obter apenas os dados anteriores ou posteriores ao upload. Não é possível obter dados parciais ou corrompidos.

• Consistência forte

  As operações de objetos no OSS são fortemente consistentes. Por exemplo, ao receber uma resposta de sucesso de upload (PUT), você pode ler imediatamente o objeto enviado, e réplicas do objeto são criadas para redundância. Portanto, não existem cenários em que os dados não são obtidos ao realizar a operação de leitura após gravação. Da mesma forma, após excluir um objeto, o objeto e suas réplicas deixam de existir.

Mecanismo de redundância de dados