Я ищу способ включить небольшие части данных (с моего сервера) с объектами во время процесса загрузки (например, идентификатор пользователя, идентификатор файла и т.д.). Изучив документацию по S3, я не уверен, что более целесообразно включать эти данные в качестве тегов объектов или метаданных объекта.
Является ли цель тегов для категоризации? И метаданные для данных для объекта?
В чем отличия? Как вы думаете, что было бы более подходящим для этой ситуации?
И метаданные, и теги по сути являются "метаданными", но есть важные различия в том, как они могут (или не могут) использоваться для изменения поведения службы и как можно (или нельзя) получать доступ к их значениям.
Объект в S3, включая его метаданные, строго говоря, является неизменным. Консоль дает вам возможность "редактировать" метаданные, но это не точное описание того, что происходит. Когда вы редактируете метаданные объекта, вы фактически перезаписываете объект своей копией с измененными метаданными. Если корзина версионирована, у вас теперь есть две копии объекта с двумя разными датами и измененными метаданными.
Теги являются "подресурсом" - в некотором смысле "в стороне" от объекта - они управляются отдельно и могут быть изменены без изменения самого объекта.
Метаданные включаются в запрос PUT виде заголовков HTTP при создании объекта. Теги сохраняются путем отправки второго запроса. Полная поддержка тегов вплоть до ограничений по количеству и размеру, приведенных ниже, требует отправки второго запроса к подресурсу ?tagging Tagging на конечной точке API, но вызов PUT (Object) REST также имеет ограниченную поддержку тегов, что позволяет использовать до 2 КБ URL -кодировать, запрашивать ключи и значения тегов в стиле параметров для x-amz-tagging в одном заголовке запроса HTTP PUT x-amz-tagging. Например, x-amz-tagging: hipaa_restrict=false&pci_restrict=true&owner=Accounting%20and%20Payroll. Документация неясна в отношении того, включает ли 2K длину байта имени заголовка, сама по себе, или этот 2K является тем же 2K, что и теги метаданных пользователя x-amz-meta-*. Предположительно, это два разных ограничения 2К, но ограничение тега 2К, вероятно, включает в себя URL-кодированную форму ключей и значений, а также длину заголовка.
Вы можете отдельно контролировать с помощью политики, может ли пользователь IAM читать или записывать объекты + метаданные или теги. Объекты и метаданные обрабатываются вместе в разрешениях (если вы можете сделать одно, вы всегда можете использовать другое), но теги являются отдельными разрешениями.
Когда вы GET объект, фактические метаданные возвращаются в заголовках ответа HTTP. Это означает, что пользователь, загружающий объект, может видеть метаданные, если он знает, как проверять заголовки HTTP.
И наоборот, теги не возвращаются в заголовках в ответ на запрос GET; вместо этого возвращается только заголовок x-amz-tagging-count: сообщающий о количестве тегов на объекте, если он не равен нулю. Обратите внимание, что хотя теги больше подходят для хранения проприетарных данных, они не подходят для хранения незашифрованных конфиденциальных данных.
Сумма всех ключей и значений метаданных для каждого объекта ограничена 2 КБ. Обратите внимание, что ограничение выражается в байтах, поэтому многобайтовые символы потребляют более одного байта на символ в направлении ограничения. Количество ключей метаданных не ограничено - только общее ограничение в 2 КБ для метаданных пользователя. Только ключи US-ASCII полностью поддерживаются в ключах и значениях метаданных объекта, а метаданные должны состоять из символов, которые действительны как заголовки HTTP, так как метаданные объекта отправляются.
Ограничения на теги разные. Каждый объект может иметь до 10 тегов, каждый ключ тега ограничен 128 символами (не байтами), а каждое значение тега ограничено 256 символами (не байтами), хотя ограничения ниже, как отмечено выше, когда теги перемещаются вместе с запросом PUT. В отличие от метаданных, теги поддерживают UTF-8.
Ключи и значения метаданных учитываются как оплачиваемые байты, которые вносят вклад в расчетный размер хранилища объектов. Тэги оплачиваются отдельно с другим форумом.
Ни теги, ни метаданные не могут быть использованы для "сканирования" объектов. Невозможно запросить у службы S3 список объектов с конкретными тегами или с конкретными метаданными.
Теги могут быть использованы для изменения поведения службы, по крайней мере, двумя важными способами, которые метаданные не могут (и на самом деле, здесь могут быть и другие, о которых я сейчас не думаю):
Политики IAM для групп/пользователей/ролей могут проверять значения тегов в целях контроля доступа, но не могут проверять значения метаданных.
Существуют ключи условий политики IAM, которые позволяют управлять доступом к объектам на основе тегов. Нет похожих функций контроля доступа на основе метаданных.
Политики жизненного цикла корзины могут проверять значения тегов, но не значения метаданных.
Политики жизненного цикла можно использовать для изменения класса хранилища объектов (для стандартного/нечастого доступа или ледника) или для очистки объектов или версий после настраиваемого интервала времени. До введения тегов объектов эти правила применялись либо ко всей корзине, либо к определенному префиксу, например, images/. Теперь теги позволяют применять политики жизненного цикла на основе тегов объектов, поэтому (например) временные данные можно смешивать с постоянными данными при одновременном применении политик жизненного цикла без необходимости сохранять объекты в разных иерархиях ключей для сопоставления префиксов.
В ситуации, описанной в этом вопросе, я был бы склонен хранить эти значения в метаданных, если только вы не видите в качестве проблемы безопасности тот факт, что они видны в заголовках HTTP-ответа.
Если вы используете S3 вместе с CloudFront, вы можете использовать триггер Lambda @Edge Origin Response, чтобы редактировать или удалять метаданные объекта из ответов в полете, чтобы они не отображались в браузере. Триггер Origin Response - это лямбда-функция, написанная в Node.js, которая может программно изменять ответы до того, как они будут сохранены в кеше CloudFront, что означает, что ее нужно запускать только при промахах кэша. Подобные функциональные возможности также могут быть реализованы путем маршрутизации запросов к корзине через прокси-сервер в EC2, такой как HAProxy или Nginx, но не при непосредственном доступе к корзине. Служба S3 всегда возвращает метаданные в заголовках ответа HTTP, но возвращает только количество тегов (если у объекта есть теги), а не сами теги при загрузке объекта.