Amazon S3 - другое правило жизненного цикла для "подкаталога", чем для родительского "каталога"

Скажем, у меня есть следующая структура данных:

/
/Foo
/Foo/бар
/Foo/Baz

Можно ли назначить ему следующие правила жизненного цикла:

/(1 месяц)
/foo (2 месяца)
/foo/bar (3 месяца)
/foo/baz (6 месяцев)

Официальная документация, к сожалению, в этом отношении несогласованна. Кажется, он не работает с консолью AWS, что делает меня несколько сомнительным, что SDK/REST будут разными:)

В противном случае моя основная проблема: у меня есть 4 типа проектов. У самого рудиментарного типа есть несколько тысяч проектов, у других - несколько десятков. Каждый тип, который я обязан хранить в течение другого периода времени. Каждый проект содержит сотни тысяч объектов. Он выглядит более или менее:

тип A, 90% проектов, требуется x хранения
тип B, 6% проектов, требуется 2x хранения
тип C, 3% проектов, требуется 4 раза хранения
тип D, 1% проектов, требуется 8-кратное хранилище

До сих пор так просто. Однако. Проекты могут быть обновлены или изменены с одного типа на другой. И, как я уже сказал, у меня есть несколько тысяч экземпляров первого типа, поэтому я не могу писать конкретные правила для каждого из них (помните 1000 правил для каждого ведра). И поскольку они могут обновляться с одного типа на другой, я не могу просто вставить их в свои собственные папки (например, только проекты определенного типа) или ведро. Или так я думаю? Существуют ли какие-либо другие варианты для меня, кроме итерации по каждому объекту, каждый раз, когда я хочу очистить файлы с истекшим сроком действия - что я бы скорее не сделал из-за большого количества объектов?

Может быть, какой-то файл "перемещать/переносить" между ведрами, которые не изменяют метаданные времени создания, и не дорого для нашего сервера?

Было бы очень важно:)

Ответ 1

Политики жизненного цикла основаны на префиксе, а не в подкаталоге.

Итак, если объекты, соответствующие префиксу foo/, должны быть удалены через 2 месяца, не логично запрашивать, чтобы объекты с префиксом foo/bar/ были удалены через 3 месяца, поскольку они будут удалены через 2 месяца... так как они также соответствуют префиксу foo/. Префикс означает префикс. Разделители не являются фактором правил жизненного цикла.

Также обратите внимание, что ключи и префиксы в S3 не начинаются с /. Политика, влияющая на весь массив, использует пустую строку в качестве префикса, а не /.

Кроме того, вы, вероятно, хотите запомнить конечные косые черты при указании префиксов, потому что foo/bar соответствует файлу foo/bart.jpg, а foo/bar/ - нет.

Итерация по объектам для удаления не так плоха, как вы это делаете, поскольку вызов API объектов списка возвращает 1000 объектов на запрос (или меньше, если хотите) и позволяет указать как префикс, так и разделитель ( обычно вы будете использовать / в качестве разделителя, если вы хотите, чтобы ответы были сгруппированы с использованием модели псевдопапки, используемой консолью для создания иерархического отображения)... и каждый ключ объекта и дата-метка предоставляются в XML-ответе. Также существует запрос API для удаления нескольких объектов за один вызов.

Любой вид перемещения, передачи, копирования и т.д. всегда будет reset датой создания объекта. Даже изменение метаданных, потому что объекты неизменяемы. Каждый раз, когда вы перемещаете, переносите, копируете или "переименовываете" объект (который на самом деле копирует и удаляет) или изменяют метаданные (которые фактически копируются на один и тот же ключ с разными метаданными), вы фактически создаете новый объект.

Ответ 2

@Zardii вы можете использовать уникальные теги объектов s3 [1] для объектов под этими префиксами

Затем вы можете применить политику жизненного цикла по тегу с различным периодом хранения/удаления.

[1] https://docs.aws.amazon.com/AmazonS3/latest/dev/object-tagging.html

Префикс -теги S3

/ tag => delete_after_one_month

/foo tag => delete_after_two_months

/foo/bar tag => delete_after_three_months

/foo/baz tag => delete_after_six_month