Скажем, у меня есть следующая структура данных:
- /
- /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 правил для каждого ведра). И поскольку они могут обновляться с одного типа на другой, я не могу просто вставить их в свои собственные папки (например, только проекты определенного типа) или ведро. Или так я думаю? Существуют ли какие-либо другие варианты для меня, кроме итерации по каждому объекту, каждый раз, когда я хочу очистить файлы с истекшим сроком действия - что я бы скорее не сделал из-за большого количества объектов?
Может быть, какой-то файл "перемещать/переносить" между ведрами, которые не изменяют метаданные времени создания, и не дорого для нашего сервера?
Было бы очень важно:)