:Termes dans OSS

Bucket

Un bucket est un conteneur pour les objets stockés dans OSS. Chaque objet dans OSS réside dans un bucket. Vous pouvez configurer diverses propriétés d'un bucket, notamment la région, la liste de contrôle d'accès (ACL) et la classe de stockage. Les classes de stockage sont utiles lorsque vous devez stocker des données ayant différents modèles d'accès.

• OSS utilise une structure plate plutôt qu'une structure hiérarchique pour les objets. Chaque objet appartient à un bucket.

• Vous pouvez créer plusieurs buckets.

• Le nom d'un bucket doit être unique dans OSS au sein d'un compte Alibaba Cloud. Les noms de bucket ne peuvent pas être modifiés après la création des buckets.

  Remarque

  Les noms des buckets créés par tous les comptes Alibaba Cloud doivent être uniques. Par exemple, si l'utilisateur A crée un bucket nommé example, les autres utilisateurs ne peuvent pas créer un autre bucket portant le même nom.

• Un bucket peut contenir un nombre illimité d'objets.

Le nom d'un bucket doit respecter les conventions de nommage suivantes :

• Le nom ne peut contenir que des lettres minuscules, des chiffres et des traits d'union (-).

• Le nom doit commencer et se terminer par une lettre minuscule ou un chiffre.

• La longueur du nom doit être comprise entre 3 et 63 caractères.

Object

Les objets constituent l'unité de données la plus petite dans OSS. Les fichiers téléchargés vers OSS sont appelés objets. Contrairement aux systèmes de fichiers classiques, les objets dans OSS sont stockés selon une structure plate et non hiérarchique. Un objet est composé d'une clé, de métadonnées et des données stockées dans l'objet. Chaque objet d'un bucket est identifié de manière unique par sa clé. Les métadonnées d'objet forment un ensemble de paires clé-valeur qui définissent les propriétés d'un objet, telles que le type de fichier et le format d'encodage. Vous pouvez également spécifier des métadonnées utilisateur personnalisées pour les objets dans OSS.

Le cycle de vie d'un objet commence lors de son téléchargement et se termine lors de sa suppression. À l'exception des objets appendables, vous ne pouvez pas modifier le contenu d'un objet à aucun stade de son cycle de vie. Pour modifier le contenu d'un objet, vous devez télécharger un nouvel objet pour remplacer l'objet existant. Le nouvel objet doit porter le même nom que l'objet dont vous souhaitez modifier le contenu.

Le nom d'un objet doit respecter les conventions suivantes :

• Le nom doit être encodé en UTF-8.

• La longueur du nom doit être comprise entre 1 et 1 023 caractères.

• Le nom ne peut pas commencer par une barre oblique (/) ou une barre oblique inverse (\).

  Remarque

  Les noms d'objets sont sensibles à la casse. Sauf indication contraire, la documentation OSS désigne tous les objets ou fichiers sous le terme « objects ».

Object key

Dans les SDK OSS pour différents langages de programmation, object key, key et object name indiquent le chemin complet de l'objet. Vous devez spécifier le chemin complet d'un objet lorsque vous effectuez des opérations sur celui-ci. Par exemple, lors du téléchargement d'un objet vers un bucket, ObjectKey indique le chemin complet incluant l'extension de l'objet, tel que abc/efg/123.jpg.

Object types

Les objets peuvent être classés dans les catégories suivantes selon leur mode de création :

• Normal

  Ce type d'objet est créé via un simple upload. Une fois téléchargés, ces objets sont accessibles en lecture seule et ne peuvent pas être modifiés. Pour modifier le contenu d'un objet existant, vous devez télécharger un objet portant le même nom afin d'écraser l'objet existant. Le simple upload permet de télécharger un objet dont la taille est inférieure à 5 Go. Cette méthode convient aux scénarios où vous pouvez télécharger un objet en envoyant une seule requête HTTP. Pour plus d'informations, consultez Simple upload.

• Multipart

  Ce type d'objet est créé via un multipart upload. Une fois téléchargés, ces objets sont accessibles en lecture seule et ne peuvent pas être modifiés. Pour modifier le contenu d'un objet existant, vous devez télécharger un objet portant le même nom afin d'écraser l'objet existant. Le multipart upload est adapté aux scénarios nécessitant d'accélérer le téléchargement d'objets volumineux, lorsque la condition du réseau est instable et que la taille de l'objet est inconnue. Pour plus d'informations, consultez Multipart upload.

• Appendable

  Ce type d'objet est créé via un append upload. Vous pouvez utiliser l'append upload pour télécharger des données vidéo vers le même objet immédiatement après leur génération. L'append upload convient aux flux vidéo en temps réel générés dans des domaines tels que la vidéosurveillance et le streaming en direct. Pour plus d'informations, consultez Append upload.

Region

Une region est un emplacement physique à partir duquel OSS fournit ses services. Lors de la création d'un bucket, vous pouvez sélectionner une region en fonction du coût ou de l'emplacement depuis lequel le bucket est le plus fréquemment consulté. Dans la plupart des cas, l'accès à OSS depuis un emplacement géographique plus proche offre une vitesse d'accès plus rapide. Pour plus d'informations, consultez Regions and endpoints.

La region d'un bucket doit être spécifiée lors de sa création. Une fois le bucket créé, sa region ne peut plus être modifiée. Tous les objets du bucket sont stockés dans la region où se trouve le bucket. Les regions sont configurées au niveau des buckets et non des objets.

Endpoint

Un endpoint est un nom de domaine utilisé pour accéder à OSS. OSS propose des endpoints spécifiques à chaque region que vous pouvez utiliser pour accéder à vos données. Vous pouvez gérer vos données dans différentes regions à l'aide des opérations API OSS. Une region dispose de différents endpoints pour l'accès via le réseau interne et pour l'accès via Internet. Par exemple, l'endpoint public utilisé pour accéder aux données OSS dans la region Chine (Hangzhou) est oss-cn-hangzhou.aliyuncs.com, et l'endpoint interne est oss-cn-hangzhou-internal.aliyuncs.com. Pour plus d'informations, consultez Regions and endpoints.

AccessKey pair

Une AccessKey pair est utilisée pour authentifier un demandeur. Elle se compose d'un AccessKey ID et d'un AccessKey secret. OSS utilise une AccessKey pair pour mettre en œuvre un chiffrement symétrique et vérifier l'identité du demandeur. L'AccessKey ID sert à identifier un utilisateur. L'AccessKey secret est utilisé pour chiffrer et vérifier la chaîne de signature. L'AccessKey secret doit rester confidentiel. OSS prend en charge les AccessKey pairs obtenues par les méthodes suivantes :

• AccessKey pairs demandées par le propriétaire du bucket.

• AccessKey pairs accordées par le propriétaire du bucket via Resource Access Management (RAM).

• AccessKey pairs accordées par le propriétaire du bucket via Security Token Service (STS).

Pour plus d'informations, consultez Create an AccessKey pair.

Atomicity and strong consistency

• Atomicity

  Les opérations sur les objets dans OSS sont atomiques. Elles aboutissent soit à un succès, soit à un échec, sans états intermédiaires. Lorsqu'un objet est téléchargé, vous obtenez soit les données avant le téléchargement, soit les données après. Vous ne pouvez pas obtenir de données partielles ou corrompues.

• Strong consistency

  Les opérations sur les objets dans OSS offrent une forte cohérence. Par exemple, lorsque vous recevez une réponse de succès pour un téléchargement (PUT), vous pouvez lire immédiatement l'objet téléchargé, et des réplicas de l'objet sont créés pour la redondance. Il n'existe donc aucun scénario où les données ne sont pas obtenues lors d'une opération de lecture après écriture. De même, après la suppression d'un objet, l'objet et ses réplicas n'existent plus.

Data redundancy mechanism