Skip to main content
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Recommandations pour la mise en œuvre de l'API REST S3 avec StorageGRID

PDF

${post_edited_translations.segment}

${post_edited_translations.segment}

Si votre application vérifie régulièrement si un objet existe dans un chemin où vous ne vous attendez pas à ce que l'objet existe réellement, vous devez utiliser le niveau « Available » "cohérence". Par exemple, vous devez utiliser la cohérence « Available » si votre application effectue une requête HEAD sur un emplacement avant d'y effectuer un PUT.

Sinon, si l'opération HEAD ne trouve pas l'objet, vous pourriez recevoir un grand nombre d'erreurs 500 Internal Server errors si deux ou plusieurs Storage Nodes du même site sont indisponibles ou si un site distant est inaccessible.

Vous pouvez définir la cohérence « Disponible » pour chaque compartiment à l’aide de la requête "Cohérence PUT Bucket", ou vous pouvez spécifier la cohérence dans l’en-tête de requête pour une opération API individuelle.

Recommandations concernant les clés d'objet

Suivez ces recommandations pour les noms de clés d'objet, en fonction du moment où le compartiment a été créé pour la première fois.

Compartiments créés dans StorageGRID 11.4 ou une version antérieure

  • N'utilisez pas de valeurs aléatoires comme premiers quatre caractères des clés d'objet. Ceci contraste avec l'ancienne recommandation d'AWS concernant les préfixes de clés. Utilisez plutôt des préfixes non aléatoires et non uniques, tels que image.

  • Si vous suivez l'ancienne recommandation d'AWS d'utiliser des caractères aléatoires et uniques dans les préfixes de clés, préfixez les clés d'objet avec un nom de répertoire. C'est-à-dire, utilisez ce format :

    mybucket/mydir/f8e3-image3132.jpg

    Au lieu de ce format :

    mybucket/f8e3-image3132.jpg

${post_edited_translations.segment}

Il n'est pas nécessaire de restreindre les noms de clés d'objets pour respecter les bonnes pratiques en matière de performances. Dans la plupart des cas, vous pouvez utiliser des valeurs aléatoires pour les quatre premiers caractères des noms de clés d'objets.

Astuce Une exception à cela est une charge de travail S3 qui supprime continuellement tous les objets après une courte période. Pour minimiser l'impact sur les performances pour ce cas d'utilisation, faites varier la partie initiale du nom de la clé tous les quelques milliers d'objets avec un élément tel que la date. Par exemple, supposez qu'un client S3 écrive généralement 2 000 objets/seconde et que la politique ILM ou de cycle de vie du compartiment supprime tous les objets après trois jours. Pour minimiser l'impact sur les performances, vous pouvez nommer les clés en utilisant un modèle comme celui-ci : /mybucket/mydir/yyyymmddhhmmss-random_UUID.jpg

${post_edited_translations.segment}

Si la "option globale pour compresser les objets stockés" est activée, les applications clientes S3 doivent éviter d’effectuer des opérations GetObject qui spécifient le retour d’une plage d’octets. Ces opérations de « lecture par plage » sont inefficaces car StorageGRID doit effectivement décompresser les objets pour accéder aux octets demandés. Les opérations GetObject qui demandent une petite plage d’octets à partir d’un objet très volumineux sont particulièrement inefficaces ; par exemple, il est inefficace de lire une plage de 10 Mo à partir d’un objet compressé de 50 Go.

Si les plages sont lues à partir d'objets compressés, les requêtes client peuvent expirer.

Remarque Si vous devez compresser des objets et que votre application cliente doit utiliser des lectures par plage, augmentez le délai d'expiration de lecture pour l'application.