«Версии файлов в S3 на уровне хранилища. Два варианта: А — нативное versioning бакета, Б — ключи files/{artifact_id}/v{n}.ext? Если я использую MinIO»
Сравнение построено на 12 задокументированных поведениях из официальной документации: 6 страниц docs.min.io и 6 страниц docs.aws.amazon.com (общая S3-семантика и специфика MinIO разделены). Оценка — 10 архитектурных критериев, каждый вариант получает 0–2 балла.
Ключ files/{artifact_id}/v{n}.ext неизменяем; номер версии, статус и указатель latest живут в БД. Приложение атомарно выделяет n в БД, пишет объект ровно один раз (If-None-Match предотвращает overwrite), затем переводит запись в READY. Latest определяет БД, а не лексикографический максимум ключа; для сортировки листинга помогает zero-padding (v000001), но истина — в БД.
Включённое bucket versioning в MinIO страхует от случайного overwrite и delete: каждый PUT создаёт полную новую версию, DELETE без versionId — лишь DeleteMarker. Это же условие для Object Lock/WORM и репликации.
Старые версии — не дельты и расходуют место; noncurrent versions и delete markers истекают только по явным lifecycle-правилам. Держите короткое окно хранения noncurrent-версий.
| Тема | Поведение | Следствие | Источник |
|---|
Метод: 12 строк официальных задокументированных поведений версионирования S3/MinIO, отобранных 2026-09-07 с двух независимых хостов — docs.min.io и docs.aws.amazon.com, по 6 уникальных URL и 50% строк с каждого; ни один URL не поддерживает более половины строк. Баллы scorecard (0–2) — редакционная оценка соответствия критерию для сценария «бизнес-версии артефактов», опирающаяся на эти строки. AWS-специфичные функции (MFA Delete, Outposts) помечены как общая S3-семантика, не гарантия MinIO. Сокращено: полные тексты страниц-источников.